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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b0d82b33b231ad02,start X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!newsfeed.stueberl.de!newsfeed01.sul.t-online.de!newsmm00.sul.t-online.de!t-online.de!news.t-online.com!not-for-mail From: Martin Krischik Newsgroups: comp.lang.ada Subject: Ragged Arrays Date: Wed, 22 Sep 2004 17:48:39 +0200 Organization: AdaCL Message-ID: <1126500.B7JMUKYEJj@linux1.krischik.com> Reply-To: krischik@users.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.t-online.com 1095923108 01 8818 CRBiX806ipMXSdDK 040923 07:05:08 X-Complaints-To: usenet-abuse@t-online.de X-ID: reuuqZZdoexcfEZnfk61x4JhpEvlTkqjmba-60lWFaWpaWwVlGKK4u User-Agent: KNode/0.7.7 Xref: g2news1.google.com comp.lang.ada:3990 Date: 2004-09-22T17:48:39+02:00 List-Id: I found this statement from Tucker Taft quite interesting as it puts a hole new twist to the rugged array problem: ---------- Weitergeleitete Nachricht ---------- Subject: Re: [Ada-Comment] new in contants Date: Mittwoch, 22. September 2004 14:01 From: Tucker Taft To: Ada-Comment List For what it is worth, the AdaMagic front end performs this same "optimization." That means that Aonix and Green Hills compilers also have it. One of the intents was that a "ragged" table of strings could be created fully statically as follows: type Message is access constant String; Message_Table : constant array(Positive range <>) of Message := (1 => new String'("syntax error"), 2 => new String'("undefined identifier"), 3 => new String'("ambiguous expression"), ...); This kind of thing is trivial to do in C, because C string literals automatically become pointers to statically allocated, statically initialized arrays of characters. We were trying to enable the same thing in Ada. As Pascal points out, explicitly declaring each string separately as an aliased constant, and then using 'Access, works in all compilers. The above approach works in "most" compilers, if that is enough for you (I'll admit to being a bit disappointed that it doesn't work in all Ada 95 compilers, given our original intent). -Tucker Taft Pascal Leroy wrote: >>>>>If the pointers are to constant strings (I should have stressed >>>>>this) there is no call to __gnat_malloc. As is >>>>> >>>>> type String_P is access constant String; >>>>> S : constant String_P := new String'("foo!"); >>>> >>>>However, no one there was able to confirm if this is a >> >>gnat specific >> >>>>optimisation or a true language feature. >>>> >>>>Any comments? >>> >>>See 13.11(24): >>> >>> 24. A default (implementation-provided) storage pool for an >>> access-to-constant type should not have overhead to support >>> deallocation of individual objects. >> >>Thank you - now I see - If deallocation is not needed then >>allocation is not needed as well. Cool. > > No, this is confused. > > 13.11(24) is an implementation advice, so it is not binding, and an > implementation is free to ignore it. At any rate, the reason for this > advice is that Unchecked_Deallocation is not available for an access to > constant, so there is no need to do the bookkeeping that is normally > required to properly deallocate objects. This has nothing to do with how > the allocation is performed. > > AARM 13.11(24.b) notes that, if the size of the allocated object is known > at compile time, the entire allocation may be avoided. This is apparently > what GNAT does, and it's a good optimization, but it's not required by the > language. Interestingly, the same paragraph points out that Storage_Error > should be raised in the following case: > > type String_P is access constant String; > for String_P'Storage_Size use 0; > S : constant String_P := new String'("foo!"); > > So this probably means that some code must be emitted on the allocator to > check for the size consumed in the storage pool, even if there is no > dynamic allocation. > > Because this optimization is not a requirement of the language (it's not > testable in the first place), the portable idiom to avoid dynamic > allocation is the following: > > type String_P is access constant String; > X : aliased constant String := "foo!"; > S : constant String_P := X'Access; > > Pascal -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com