Deallocation of Unbounded_String

Deallocation of Unbounded_String

[vlc]

Hi *,

when using Unbounded_String, is it necessary to deallocate instances
of Unbounded_String after use or is there a kind of garbage collector
implemented?

There is a "Free" function in Ada.Strings.Unbounded, but it takes an
access to String as argument, not an access to Unbounded_String.

If I'm supposed to use this "Free" function to deallocate the memory
of my unused Unbounded_String, what is the correct usage of this
function (typecast of "access Unbounded_String" to "access String")?

Thanks a lot in advance!

Re: Deallocation of Unbounded_String

[sjw]

On Jul 25, 5:37 pm, vlc <just.another.spam.acco...@googlemail.com>
wrote:

> when using Unbounded_String, is it necessary to deallocate instances
> of Unbounded_String after use or is there a kind of garbage collector
> implemented?

Unbounded_Strings are controlled, and look after their own memory when
they go out of scope or are overwritten.

If you had a variable currently holding a really huge unbounded string
which you needed to keep in scope you could free its memory by saying

   My_Unbounded_String := Ada.Strings.Unbounded.Null_Unbounded_String;

> There is a "Free" function in Ada.Strings.Unbounded, but it takes an
> access to String as argument, not an access to Unbounded_String.

Hadn't noticed that; no idea why it's there (might be some use in
Ada.Strings.Fixed?)

> If I'm supposed to use this "Free" function to deallocate the memory
> of my unused Unbounded_String, what is the correct usage of this
> function (typecast of "access Unbounded_String" to "access String")?

Very Bad Things would happen if you did this. The memory layout of the
two types of object is going to be entirely different. An
Unbounded_String is likely to be chained through a list of objects to
be finalized when the scope is left - you interfere with that sort of
construct at your peril.

Re: Deallocation of Unbounded_String

[vlc]

On Jul 25, 7:09 pm, sjw <simon.j.wri...@mac.com> wrote:
> On Jul 25, 5:37 pm, vlc <just.another.spam.acco...@googlemail.com>
> wrote:
>
> > when using Unbounded_String, is it necessary to deallocate instances
> > of Unbounded_String after use or is there a kind of garbage collector
> > implemented?
>
> Unbounded_Strings are controlled, and look after their own memory when
> they go out of scope or are overwritten.
>
> If you had a variable currently holding a really huge unbounded string
> which you needed to keep in scope you could free its memory by saying
>
>    My_Unbounded_String := Ada.Strings.Unbounded.Null_Unbounded_String;
>
> > There is a "Free" function in Ada.Strings.Unbounded, but it takes an
> > access to String as argument, not an access to Unbounded_String.
>
> Hadn't noticed that; no idea why it's there (might be some use in
> Ada.Strings.Fixed?)
>
> > If I'm supposed to use this "Free" function to deallocate the memory
> > of my unused Unbounded_String, what is the correct usage of this
> > function (typecast of "access Unbounded_String" to "access String")?
>
> Very Bad Things would happen if you did this. The memory layout of the
> two types of object is going to be entirely different. An
> Unbounded_String is likely to be chained through a list of objects to
> be finalized when the scope is left - you interfere with that sort of
> construct at your peril.

Thanks a lot for your help!

Re: Deallocation of Unbounded_String

[Yannick Duchêne Hibou57]

Hello,

At least, the GNAT private part for this package specification, shows
that it is derived from Ada.Finalization.Controlled

The ARM A.4.5, states that the pragma Preelaborable_Initialization is
applied to this type. I do not know the pragma
Preelaborable_Initialization, but I guess it has something to deal
with the latter.

Whenever resource management is required, if possible, it is a good
idea to use either Ada.Finalization.Controlled or
Ada.Finalization.Limited_Controlled, so we may guess this good idea is
extensively used in such packages.

Any way, at leat with GNAT, I can assert you that it is done
automatically : you do not have to bother when you create an
Unbounded_String, when you copy one into another or when you leave a
scope containing such an object, as it is properly handled like it is
with any types derived from Ada.Finalization.Controlled.

Now and next, just have to check about the pragma
Preelaborable_Initialization, to see what it means exactly

Re: Deallocation of Unbounded_String

[Jeffrey R. Carter]

vlc wrote:
 >
 > when using Unbounded_String, is it necessary to deallocate instances
 > of Unbounded_String after use or is there a kind of garbage collector
 > implemented?

The "Implementation Requirements" of ARM A.4.5(88) say, "No storage associated
with an Unbounded_String object shall be lost upon assignment or scope exit."
This means the user doesn't have to worry about it; objects of the type take
care of their own memory management. [ARM A.4.5(72.1/2, "The type
Unbounded_String needs finalization (see 7.6)," gives you a clue about how this
is probably done.]

 > There is a "Free" function in Ada.Strings.Unbounded, but it takes an
 > access to String as argument, not an access to Unbounded_String.

That and the type String_Access have nothing to do with Unbounded_String, and
really shouldn't be there. The likely explanation for them is that
implementations were expected to use access-to-String, and it was thought that
these declarations would be generally useful. Even then, they would be better
off in Ada.Strings than in Ada.Strings.Unbounded.

-- 
Jeff Carter
"If a sperm is wasted, God gets quite irate."
Monty Python's the Meaning of Life
56