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,fd173879a595bde X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc08.POSTED!20ae255c!not-for-mail Newsgroups: comp.lang.ada From: Anonymous Coward Subject: Re: Default rep specs for record types - documented?? References: Message-Id: User-Agent: slrn/0.9.7.4 (Linux) Date: Sat, 05 Nov 2005 03:33:43 GMT NNTP-Posting-Host: 141.149.78.234 X-Complaints-To: abuse@verizon.net X-Trace: trnddc08 1131161623 141.149.78.234 (Fri, 04 Nov 2005 22:33:43 EST) NNTP-Posting-Date: Fri, 04 Nov 2005 22:33:43 EST Xref: g2news1.google.com comp.lang.ada:6223 Date: 2005-11-05T03:33:43+00:00 List-Id: In article , Stephen Leake wrote: >> >> What's disappointing is that rep specs add considerable clutter. > > Yes. Ada explicitly favors being precise over being concise. Precision need not be at odds with conciseness. Consider an enumerated type: type my_enum is (first, second, third); I am *guaranteed* by the LRM that the representation will code "first" as zero, "second" as 1, and "third" as 2. Adding this rep spec: for my_enum use (first => 0, second => 1, third => 2); gives me no more precision, yet it dirties the code. Consequently, I will never rep spec an enum unless I intend to deviate from the default rep spec. And when I do deviate, the code will be more readable, because the reader will say "hey wait a minute, why is this rep spec'd and the others are not.. hmm.. there's something different here.." So differences will stand out, as they should. So being able to count on default representations (which are changable) is a good thing, because you can be both precise and concise. However, in the case of records, I've changed my opinion based on what I've read here. A compiler should be given opportunity to optimize where practical, and imposing a default rep spec could hinder the compilers ability to optimize record layout. >> Readable code avoids redundancy, so having default representation >> aspects that are guaranteed enable less noisey code. > > Representation clauses are not 'redundant'; they provide information > that is not provided by the type declaration. That seems to depend on what aspect of what kind of type we're talking about. In the enum case above, the "for .. use" rep spec *is* redundant. > One problem is that the compiler does _not_ warn you if you leave a > component out of the rep clause; a 'pragma Complete_Representation' > would be nice. Specifying the total size can mitigate this, but I > recently had a bug due to this problem. I can think of cases where rep spec'ing partial records would be useful. But I would agree that there should certainly be a warning. >> I'm not looking forward to rep specing records bit for bit simply to >> enforce the same order of elements that's specified in the operation >> specs. > > If 'operation specs' are defining the hardware you are interfacing > to, then yes, you need a rep clause for each hardware register. The > time spent writing those clauses _will_ be repaid later when it > comes to testing on the hardware; there _will_ be fewer bugs. Perhaps, but for interfacing with C operations (which is my case), I would prefer to simply write "pragma convention (C, my_record)" and be able to expect the compiler to base the representational spec purely off the operational spec, just as the C compiler would for a structure that only has an operational spec. I should not have to micromanage the bitwise layout of a record to interface with C code. It puts me at a lower level, and positions me to make human errors (like writing an incomplete rep spec for a record), when such errors can be avoided by keeping it high level. > Someone mentioned a 'pragma Preserve_Layout', which presumably means > "assume a representation clause that puts things in declaration order, > with the base size for each component, and no gaps". That would be > useful, in situations where the type declarations do in fact match the > hardware precisely. Hmm. That is true for most of the rep clauses I've > written recently. I'll have to suggest that to AdaCore as a possible > enhancement; it would have prevented my bug. Yes, I agree.. that would be useful. Or maybe better yet, mandate that pragma convention (C,...) matches representation order to declaration order to keep the number of pragmas minimal.