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,adae40bcc4d01baf X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada 95 constructors on limited types Date: Thu, 3 Jan 2008 19:38:38 -0600 Organization: Jacob's private Usenet server Message-ID: References: <08dc2b30-6c8c-4cff-9f2e-c0d4c377972d@i3g2000hsf.googlegroups.com> <1379898.fuxZSb5qdF@linux1.krischik.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1199410725 28878 69.95.181.76 (4 Jan 2008 01:38:45 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 4 Jan 2008 01:38:45 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Xref: g2news1.google.com comp.lang.ada:19185 Date: 2008-01-03T19:38:38-06:00 List-Id: "Martin Krischik" wrote in message news:1379898.fuxZSb5qdF@linux1.krischik.com... ... > > type Class_Access is access all Class'Class; > > Do you need that "all"? Because because the "all" does not come for free - > there are some penalties. Say what? The only penalty in using "all" is that a few very dubious constructs are illegal (they're legal for pool-specific types in order to maintain Ada 83 compatibility. Indeed, for Janus/Ada, it actually makes the code better (because we generate code that checks that pool-specific access values belong to their pool when they are dereferenced; for obvious reasons we can't do that for "all" or for user-defined pools). It also makes your code better as it allows you to avoid using allocators at all. Of course the very best solution is to avoid the access type altogether, which you may be able to do by using one of the containers libraries. > Read: > > http://en.wikibooks.org/wiki/Ada_Programming/Types/access#Access_vs._access_all The claim that additional checks may be needed on the deference of an "access all" is completely bogus; Janus/Ada always does *less* run-time checking for "access all" than "access". While it's probably true that for most compilers that it is the same, I can't think of any reason that it would be more -- at least not on typical machines. (There might be additional checks required because of the designated type, but those would be the same for access and access all.) One could imagine a super-safe Ada system that did extra checks to prevent problems with Unchecked_Deallocation, but that would not have any cost for dereferencing. The argument about safety is certainly true, but it may be misleading: Unchecked_Deallocation is always dangerous if misused. It is just as easy to deallocate a pool-specific object twice, and just as dangerous as deallocating a stack object. The advantage of "access all" is that you may not need to use Unchecked_Deallocation at all. Moral: if you have (or may have) a valid reason to store an 'Access or 'Unchecked_Access into an access type, then use "access all" and don't worry about it. If not, the mantra of "least privilege" suggests that the "all" should be left out (don't enable capabilities that you are not going to use), but it is hardly the level of concern that it should cause someone to complain about it's use in an example program. OTOH, the advice about avoiding access altogether for parameters, and especially anonymous access, is spot-on. Randy.