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!newspeer1.nwr.nac.net!newspeer.monmouth.com!nntp.abs.net!news.abs.net!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Default rep specs for record types - documented?? References: From: Stephen Leake Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:RMG6hvlGP2Ir1MFG7aMFlXjwu7I= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Nov 2005 08:26:06 -0500 NNTP-Posting-Host: 66.159.65.1 X-Complaints-To: abuse@toad.net X-Trace: news.abs.net 1131110778 66.159.65.1 (Fri, 04 Nov 2005 08:26:18 EST) NNTP-Posting-Date: Fri, 04 Nov 2005 08:26:18 EST Xref: g2news1.google.com comp.lang.ada:6187 Date: 2005-11-04T08:26:06-05:00 List-Id: Anonymous Coward writes: > In article , Steve wrote: > > What's disappointing is that rep specs add considerable clutter. Yes. Ada explicitly favors being precise over being concise. > 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. The compiler ensures that the names are spelled the same, and the locations do not overlap. 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'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. 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. -- -- Stephe