Ragged Arrays

Ragged Arrays

[Martin Krischik]

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 <stt@sofcheck.com>
To: Ada-Comment List <ada-comment@ada-auth.org>

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