Re: Containers with Ada

["Ken Garlington" <Ken.Garlington@computer.org>]

<jeltsch@my-deja.com> wrote in message news:8v8pii$dvo$1@nnrp1.deja.com...


:    1. Copying of large data structures
:    In my opinion one main problem of Ada is implicit copying of variables.
So
:    it's no good idea to define such a intuitive function like
:       function Element_At(Current_List : in List; Current_Index : in
Index)
:                          return Element;
:    In this example the list which could contain thousands of elements
would
:    be copied just to get one element out of it.

If List contains "thousands of elements", I suspect it's probably not an
elementary type [Ada Reference Manual 3.2:3]. (It may _reference_ them, but
then only the reference is being passed, not the elements). Therefore, it
doesn't have to be passed by copy [ARM 6.2:3], and most compilers won't.
Similar rules apply to the returned value. It may be a good idea to declare
List a limited type, but not for reasons of controlling the passing
convention.

:    2. Complicated use of element access with generic procedures

Making a type limited does impose some "complications" (an investment that
yields impressive returns when used in the right way at the right time), but
since you don't have to declare the type limited for performance reasons, I
assume this is no longer an issue.

:    3. High memory consumption with unconstrained arrays

:    An easy way to define a type for lists with fixed length would be for
:    instance
:       type Element_Array is array(Positive range <>) of Element;
:       type List(Length : Natural) is record
:          Elements : Element_Array(1 .. Length);
:       end record;
:    With this implementation one could even think of making the whole type
:    definition public. But one cannot expect that a compiler will generate
code
:    that dynamically allocates memory that is just enough for Elements. As
I
:    can see GNAT doesn't operate with implicit pointers to dynamically
:    allocated memory but sets the size of List so that it is big enough for
:    every value for Length. In the above example that means that every List
:    would (try to) consume about 2 GB of memory on my platform.

There's nothing in the standard that requires this for the _exact_ example
you post, AFAIK. If you really think you're seeing this, you may want to
contact GNAT. Note that replacing "Length : Natural" with "Length : Natural
:= 0" will cause the behavior you describe, as well as a potential GNAT
message - "warning: creation of object of this type may raise
Storage_Error.". That _is_ consistent with the standard.

Here's a sample program I just tried with GNAT 3.12p for Windows, default
switches (e.g. no optimizations). It ran immediately on my machine, which
shouldn't be the case for the behavior you describe:

-- Test_Data_Structure.ads
package Test_Data_Structure is
  subtype Element is Character;
  type Element_Array is array(Positive range <>) of Element;
  type List(Length : Natural) is record
     Elements : Element_Array(1 .. Length) := (others => '?');
  end record;
end Test_Data_Structure;

-- Make_Data_Structure.adb
with Ada.Text_IO, Test_Data_Structure;
procedure Make_Data_Structure is
  package Test renames Test_Data_Structure;
  List_1 : Test.List(1);
  List_2 : Test.List(2);
  List_3 : Test.List(3);
  List_4 : Test.List(4);
begin
  Ada.Text_IO.Put(List_1.Elements(1));
  Ada.Text_IO.Put(List_2.Elements(2));
  Ada.Text_IO.Put(List_3.Elements(3));
  Ada.Text_IO.Put(List_4.Elements(4));
  Ada.Text_IO.New_Line;
end Make_Data_Structure;

:    4. Limitations with controlled types
:    Because I cannot use unconstrained arrays like in the above example

Hopefully, now you can!