From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9dec3ff1604723d9 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!news.zanker.org!border2.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!news-hub.cableinet.net!blueyonder!news-text.cableinet.net!53ab2750!not-for-mail User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: Bitmanipulation in Ada From: "(see below)" Newsgroups: comp.lang.ada Message-ID: References: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Date: Thu, 19 Aug 2004 15:25:20 GMT NNTP-Posting-Host: 82.41.185.234 X-Complaints-To: abuse@blueyonder.co.uk X-Trace: news-text.cableinet.net 1092929120 82.41.185.234 (Thu, 19 Aug 2004 16:25:20 BST) NNTP-Posting-Date: Thu, 19 Aug 2004 16:25:20 BST Organization: blueyonder (post doesn't reflect views of blueyonder) Xref: g2news1.google.com comp.lang.ada:2856 Date: 2004-08-19T15:25:20+00:00 List-Id: On 18/8/04 10:56 pm, in article cg0j9n$bkq$1@sparta.btinternet.com, "Martin Dowie" wrote: ... >>> TYPE ov is record >>> case boolean of >>> true : i : integer; >>> false : byte_array; >>> end; >>> end; >>> >>> Such overlay structures are not valid with Ada, so what do instead? >> >> Such usages are not valid in (ISO Standard) Pascal either, >> but you don't let that stop you. 8-) > > Where does the standard deem this "not valid" in Ada? I'm not sure who Martin is asking, nor what about; but: If "this" means Pascal-style tagless variant records, see the RM, section 3.8.1 "Variant Parts and Discrete Choices", where no such syntax appears. If "this" means assigning a value of type T1 to a field F1 of a variant V1 of a record structure R and retrieving a value of type T2 from a field F2 of a variant V2, "R.F1 := T1_Val; ...; T2_var := R.F2" then: (a) If the variant has not been changed from V1 to V2, then a discriminant check on access to F2 will raise a Constraint_Error. (b) If the variant has been changed to V2, then F2 has been given a new value and so does not retain the value placed in F1. (c) It cannot even be assumed that F1 and F2 coincide, unless a representation specification can be used to that effect. (I suspect Martin knows all this perfectly well, so I wonder why he asks.) -- Bill Findlay chez blueyonder.co.uk