Compiler default initialization of array types

Compiler default initialization of array types

[Sebastian]

Hello,

I wonder if Ada always assignes Array types with default values?

In case this is true; is there some way to suppress this feature?

/Sebastian

Re: Compiler default initialization of array types

[Lutz Donnerhacke]

* Sebastian wrote:
> I wonder if Ada always assignes Array types with default values?

It can happen.

> In case this is true; is there some way to suppress this feature?

pragma Import(Ada, array_variable); -- directly after the definition.

Re: Compiler default initialization of array types

[Matthew Heaney]

"Sebastian" <sebastian.madunic@avionics.saab.se> wrote in message
news:aombha$ong$1@newstoo.ericsson.se...
> I wonder if Ada always assignes Array types with default values?

Only if the component subtype is default initialized.  Otherwise no.

For example:

declare
   S : String (1 ..10);
begin

The array S is NOT initialized.

However, if we have this:

type String_Access_Array is
    array (Positive range <>) of Ada.Strings.Unbounded.String_Access;

declare
   S  : String_Access_Array (1 .. 10);
begin

Then here array S IS initialized.

> In case this is true; is there some way to suppress this feature?

As someone already pointed out, you might be able to use pragma Import (Ada,
<array object>) to suppress the initialization, but I haven't tried this
with an array object.  Another possibility is to turn off
default-initialization of the array component subtype.  Is there a pragma to
do this?  I forget.

However, if the array component subtype is controlled, I don't think there's
any way to turn of controlled initialization.  But I wouldn't think you'd
want to, either.

Is the array component subtype scalar?

Perhaps we could help you more if you provided the declarations of the array
component subtype and array subtype.

Re: Compiler default initialization of array types

[Grein, Christoph]

> I wonder if Ada always assignes Array types with default values?

How do you come to this conclusion? In the RM, there are only a few places where 
default initialization is required, notably for pointers.

Generally there is no default initialization except when explicitly required by 
the programmer.

> In case this is true; is there some way to suppress this feature?

Re: Compiler default initialization of array types

[Peter Richtmyer]

Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnaqtdlb.q0.lutz@taranis.iks-jena.de>...
> * Sebastian wrote:
> > I wonder if Ada always assignes Array types with default values?
> 
> It can happen.
> 
> > In case this is true; is there some way to suppress this feature?
> 
> pragma Import(Ada, array_variable); -- directly after the definition.

I have used the "Pragma Import" successfully in some circumstances,
but for a simple array, Gnat would not allow it. The error message
looks strange to me, maybe a "bug". See below.

(Gnat does not assign default values, the example shows what happens
 if values are assigned in the array using the record...)


with text_io;
procedure artest is

    type r is 
        record 
            i: integer := 1;
        end record;             
    pragma pack (r);
    for r'size use 32;    

    type a_t is array (1 .. 2) of r;
    for a_t'size use 64;

    type i_t is array (1 .. 2) of integer;
    for i_t'size use 64;

    b : a_t;    
    -- pragma import (Ada, b);   -- Gnat 3.14p NOT LEGAL:   
artest.adb:17: undefined reference to `b'
    
    c : i_t := (others => 3);
    d : a_t;
    for d'address use c'address;


    e : i_t := (others => 5);
    f : a_t;
    for f'address use e'address;
    pragma import (Ada, f);
    
begin 
   for j in a_t'range loop     
      text_io.put_line ("-- b(" & integer'image(j) & ").i is " &
integer'image(b(j).i));
      text_io.put_line ("-- d(" & integer'image(j) & ").i is " &
integer'image(d(j).i));
      text_io.put_line ("-- f(" & integer'image(j) & ").i is " &
integer'image(f(j).i));
      text_io.put_line ("-- --------------------");   
   end loop;   
   
-- b( 1).i is  1
-- d( 1).i is  1
-- f( 1).i is  5    (THE PRAGMA SUPPRESSED INITIALIZATION)
-- --------------------
-- b( 2).i is  1
-- d( 2).i is  1
-- f( 2).i is  5 
-- -------------------- 
end artest;

Peter

Re: Compiler default initialization of array types

[Robert A Duff]

"Matthew Heaney" <mheaney@on2.com> writes:

> "Sebastian" <sebastian.madunic@avionics.saab.se> wrote in message
> news:aombha$ong$1@newstoo.ericsson.se...
> > I wonder if Ada always assignes Array types with default values?
> 
> Only if the component subtype is default initialized.  Otherwise no.
> 
> For example:
> 
> declare
>    S : String (1 ..10);
> begin
> 
> The array S is NOT initialized.
> 
> However, if we have this:
> 
> type String_Access_Array is
>     array (Positive range <>) of Ada.Strings.Unbounded.String_Access;
> 
> declare
>    S  : String_Access_Array (1 .. 10);
> begin
> 
> Then here array S IS initialized.

Just to clarify: the components of S are initialized because access
types always have a default initial value of null.  For an array of
records, the subcomponents are initialized if the record declares
defaults for its components.  As you said, an array of character or
integers or something like that is not initialized by default.

> > In case this is true; is there some way to suppress this feature?
> 
> As someone already pointed out, you might be able to use pragma Import (Ada,
> <array object>) to suppress the initialization, but I haven't tried this
> with an array object.  Another possibility is to turn off
> default-initialization of the array component subtype.  Is there a pragma to
> do this?  I forget.

No.  The pragma Import(Ada,..) should work for objects.  If it doesn't,
it's a compiler bug.

But there is no pragma on a type to say never default-initialize objects
of that type.  For an array of records, it's no big deal -- just don't
put any defaults on the record components.  But for an array of pointers
(or array of records containing pointers, etc), the compiler will want
to initialize the pointers to null.

I have written code where there were lots of giant arrays of pointers,
inside a record with another component indicating how many are valid.
Something like:

    type T is
        record
            Last: Natural := 0;
            Pointers: Pointer_Array(1..Big_Number);

Typically, objects of type T would use just a few pointers -- like Last
might be 3 or 4, but very unusual for it to be 1000 or 1_000_000.

It turned out that initializing all those unused pointers to null was a
serious performance problem.  So I cheated: I declared the array as an
array of integers (where the integer type was chosen to be the same size
as a pointer), and used unchecked_conversion.

> However, if the array component subtype is controlled, I don't think there's
> any way to turn of controlled initialization.  But I wouldn't think you'd
> want to, either.
> 
> Is the array component subtype scalar?

If so, it has no particular default, so the compiler will typically not
default-initialize.

Unless you use pragma Normalize_Scalars, which attempts to detect
uninitialized variables by default-initializing them to out-of-range
values.

> Perhaps we could help you more if you provided the declarations of the array
> component subtype and array subtype.

True.  It would also help if the OP explained why default-init is
undesirable.  Efficiency?  Interfacing to objects initialized in some
other language, or by hardware?

- Bob

Re: Compiler default initialization of array types

[Larry Kilgallen]

In article <wcc3cr4vcti.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> I have written code where there were lots of giant arrays of pointers,
> inside a record with another component indicating how many are valid.
> Something like:
> 
>     type T is
>         record
>             Last: Natural := 0;
>             Pointers: Pointer_Array(1..Big_Number);
> 
> Typically, objects of type T would use just a few pointers -- like Last
> might be 3 or 4, but very unusual for it to be 1000 or 1_000_000.
> 
> It turned out that initializing all those unused pointers to null was a
> serious performance problem.  So I cheated: I declared the array as an
> array of integers (where the integer type was chosen to be the same size
> as a pointer), and used unchecked_conversion.

Efficiency will depend on the compiler and potentially the operating
system.  For package-level data on VMS, compilers that need a lot of
zeroed memory will typically emit linker instructions to "fake it"
with manipulation of the memory management system.

>        It would also help if the OP explained why default-init is
> undesirable.  Efficiency?  Interfacing to objects initialized in some
> other language, or by hardware?

Re: Compiler default initialization of array types

[Matthew Heaney]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc3cr4vcti.fsf@shell01.TheWorld.com...
>
> I have written code where there were lots of giant arrays of pointers,
> inside a record with another component indicating how many are valid.
> Something like:
>
>     type T is
>         record
>             Last: Natural := 0;
>             Pointers: Pointer_Array(1..Big_Number);
>
> Typically, objects of type T would use just a few pointers -- like Last
> might be 3 or 4, but very unusual for it to be 1000 or 1_000_000.
>
> It turned out that initializing all those unused pointers to null was a
> serious performance problem.  So I cheated: I declared the array as an
> array of integers (where the integer type was chosen to be the same size
> as a pointer), and used unchecked_conversion.

I've been thinking about this same issue while writing the Charles vector
type.  The STL plays tricks like you mention above, but it's not obvious how
to do this in Ada (portably, anyway).

One possibility is to declare a special storage pool type that works off the
internal array, and return the address of the array component that needs
initialization or finalization.  This would give you the rough equivalent of
placement new and explicit dtor invokation.

Something like this?

generic
   type Element_Type is private;
package GP is
...
private
   subtype Component_Subtype is
      Storage_Array (1 .. Element_Type'Max_Size_In_Storage_Elements);

   type Element_Array is
     array (Positive range <>) of aliased Component_Subtype;
...

Hmmm, that just might work.  Any possibility that
Max_Size_In_Storage_Elements will return a "large" value, even for a generic
actual type that is definite?

The only issue is that a storage pool is limited, which would make the
container type containing the pool limited too.  Maybe you could declare a
pool object in the body, but then you'd loose Preelaborate categorization,
and probably have to start worrying about synchronization issues.  Oh, the
joys of library design....

Re: Compiler default initialization of array types

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> Efficiency will depend on the compiler and potentially the operating
> system.  For package-level data on VMS, compilers that need a lot of
> zeroed memory will typically emit linker instructions to "fake it"
> with manipulation of the memory management system.

The zero-page tricks of VMS are nice, but they couldn't help in the case
I mentioned.  Nor could compiler optimizations, unless the compiler was
*really* clever.

These objects were heap-allocated.  An OS can use virtual-memory tricks
to produce huge arrays of zero pages, but it seems infeasible to always
go directly to the OS for every "new".

- Bob

Re: Compiler default initialization of array types

[Larry Kilgallen]

In article <wcc3cr3stc5.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
>> Efficiency will depend on the compiler and potentially the operating
>> system.  For package-level data on VMS, compilers that need a lot of
>> zeroed memory will typically emit linker instructions to "fake it"
>> with manipulation of the memory management system.
> 
> The zero-page tricks of VMS are nice, but they couldn't help in the case
> I mentioned.  Nor could compiler optimizations, unless the compiler was
> *really* clever.
> 
> These objects were heap-allocated.  An OS can use virtual-memory tricks
> to produce huge arrays of zero pages, but it seems infeasible to always
> go directly to the OS for every "new".

Certainly.

But if initialization is overwhelming for a particular application,
switching to non-heap allocation (I hesitate to ever use the word
"static" in this newsgroup) might help in some environments.

Re: Compiler default initialization of array types

[Wes Groleau]

> It turned out that initializing all those unused pointers to null was a
> serious performance problem.  So I cheated: I declared the array as an
> array of integers (where the integer type was chosen to be the same size
> as a pointer), and used unchecked_conversion.

I'd use an overlay so that the array is the type I want.