Ada.Containers.Indefinite_Holders and limited types

Ada.Containers.Indefinite_Holders and limited types

[Victor Porton]

Why Ada.Containers.Indefinite_Holders (as of Ada2012) accepts "private" 
Element_Type? I would like it be "limited private" instead.

The particular reason I want this is to hold Timing_Event inside an 
indefinite holder inside a record.

-- 
Victor Porton - http://portonvictor.org

Re: Ada.Containers.Indefinite_Holders and limited types

[Simon Wright]

Victor Porton <porton@narod.ru> writes:

> Why Ada.Containers.Indefinite_Holders (as of Ada2012) accepts
> "private" Element_Type? I would like it be "limited private" instead.
>
> The particular reason I want this is to hold Timing_Event inside an
> indefinite holder inside a record.

Because there are Holder operations that allow copying of the
Element_Type, perhaps; e.g. Copy.

Why not use "access Timing_Event'Class" or suchlike?

Re: Ada.Containers.Indefinite_Holders and limited types

[Dmitry A. Kazakov]

On 15/11/2017 01:00, Victor Porton wrote:
> Why Ada.Containers.Indefinite_Holders (as of Ada2012) accepts "private"
> Element_Type? I would like it be "limited private" instead.
> 
> The particular reason I want this is to hold Timing_Event inside an
> indefinite holder inside a record.

It is a design choice. Handles can use either external or internal 
allocator. The latter option requires copying, so it cannot be limited, 
the former option might be less comfortable.

I prefer design with an external allocator, so I pass a access type to 
my generic handles package.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Containers.Indefinite_Holders and limited types

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ougu7j$1g1c$1@gioia.aioe.org...
> On 15/11/2017 01:00, Victor Porton wrote:
>> Why Ada.Containers.Indefinite_Holders (as of Ada2012) accepts "private"
>> Element_Type? I would like it be "limited private" instead.
>>
>> The particular reason I want this is to hold Timing_Event inside an
>> indefinite holder inside a record.
>
> It is a design choice. Handles can use either external or internal 
> allocator. The latter option requires copying, so it cannot be limited, 
> the former option might be less comfortable.

Right. The Insert operation of all of the containers requires making a new 
copy of the element in the container. That's necessary if one wants the 
container to handle all of the storage management for the elements (which 
was an explicit design goal of the containers -- preventing the need to use 
explicit access types for non-limited element types).

> I prefer design with an external allocator, so I pass a access type to my 
> generic handles package.

That's a fine alternative; it does put the storage management burden on the 
client (which we were trying to avoid). Note that you can use the definite 
containers to do this - which is another reason to use non-limited element 
types.

Several of us have tried to design containers that could directly contain 
limited objects, but no one (me included) has been able to come up with 
anything that had any significant advantage over just putting an explicit 
general access value into the container instead (and getting that value from 
'Access of an aliased object).

                                                 Randy.