little precision about anonymous access types

little precision about anonymous access types

[Mehdi Saada]

I have a little question about (anonymous) access types:
I can do that:
procedure main is
   type A is access INTEGER;
   A_O : A := new INTEGER'(54);
begin
   declare
      B: access INTEGER;
   begin
      B := A_O;
   end;
end main;

But I can't do that, without being told A must be a general access type:
procedure main is
   type A is access INTEGER;
   A_O : A;
begin
   declare
      B: access INTEGER := new INTEGER'(7);
   begin
      A_O := A(B);
   end;
end main;
But I'm doing A_O := some_variable_of_the_stack'Access,
I'm affecting A_O to another access object. Not taking an 'Access out of it.

At first, I wondered what were the scope of declaration of anonymous access objects like B.
Is: "B: access INTEGER := new INTEGER'(7);"
STRICTLY equivalent to
"type B_ANONYMOUS_TYPE is access INTEGER;
B: B_ANONYMOUS_OBJECT;"
chiefly regards to what and when I can affect things to of from anonymous access objects.

Re: little precision about anonymous access types

[Mehdi Saada]

Also, why that:
procedure main is
   B: access INTEGER;
begin
   declare
      type A_TYPE is access INTEGER;
      A : A_TYPE := new INTEGER'(7);
   begin
      B := A;
   end;
end main;
is ILLEGAL (cannot convert local pointer to non-local access type) ? It seems that B's type's scope is LONGER than A_type's.

whereas that:
procedure main is
   type A_TYPE is access all INTEGER;
   A : A_TYPE;
begin
   declare
      B: access INTEGER := new INTEGER'(7);
   begin
      A := A_TYPE(B);
   end;
   if A.all > 8 then null; end if;
end main;
is legal (yet needs "all" for a reason unknown to me) ?
Since B dies before A, where does go B's memory content, so that A can still refer to it after the "end;" ?

Re: little precision about anonymous access types

[Mehdi Saada]

At last, I would like to know what happens exactly when one tries to deallocate a pointer, referencing a variable *on the stack* ?
I got free(): invalid pointer, at runtime. I suppose it is the risk with the liberty "all" offers, right ?

Re: little precision about anonymous access types

[AdaMagica]

Am Montag, 19. März 2018 02:18:34 UTC+1 schrieb Mehdi Saada:
> At last, I would like to know what happens exactly when one tries to deallocate a pointer, referencing a variable *on the stack* ?

This is erroneous. See in the RM what erroneous means.

Also note that deallocation of an object allocated via new is erroneous when done with a different access type than was used to allocate the object.

Do never ever allocate with anonymous access types.
(Exception: coextensions - which some Ada aficionados consider a bad mistake.)

I do not know where such an object is allocated, so I cannot tell what happens when you convert to a named access type:

declare
   type A_TYPE is access all INTEGER;
   A : A_TYPE;
begin
   declare
      B: access INTEGER := new INTEGER'(7);
   begin
      A := A_TYPE(B);
   end;
end;

Re: little precision about anonymous access types

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:edf7b96a-f340-408c-994f-d5aa73b9f2db@googlegroups.com...
>I have a little question about (anonymous) access types:

There are several different kinds of anonymous access types, all with 
different semantics in details. The best possible advice is to not use them 
at all, since they're more likely to be confusing than useful. If you follow 
that advice, you don't have to worry about differing details. :-)

                    Randy.

Re: little precision about anonymous access types

[G. B.]

Randy Brukardt <randy@rrsoftware.com> wrote:
> "Mehdi Saada" <00120260a@gmail.com> wrote in message 
> news:edf7b96a-f340-408c-994f-d5aa73b9f2db@googlegroups.com...
>> I have a little question about (anonymous) access types:
> 
> There are several different kinds of anonymous access types, all with 
> different semantics in details. The best possible advice is to not use them 
> at all, since they're more likely to be confusing than useful. If you follow 
> that advice, you don't have to worry about differing details. :-)


Seen from a business perspective, judicious use of unnamed
entities creates opportunities of specialization. If you know
names, but do not tell them, then by way of leveraging anonymous 
entities and their “correct” use, you might hope to reap the benefits
of Rumpelstilskin economics...

Anonymous types might work until some business person 
decides he has had enough of the special, costly treatment
that they require.

Re: little precision about anonymous access types

[Mehdi Saada]

It sounds interesting. Could you explain a bit more what effect you refer to ? Some code to show it ? Or a link to it.
For the time being, the few things I know is that anonymous types are useful and safe for : coextensions, and controlling access parameters/results and the dispatching they allow.
So if you allude to dispatching, I might understand your point (a bit), otherwise I don't.

Re: little precision about anonymous access types

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:42387d28-c983-4e58-9522-815ccd1ad0fb@googlegroups.com...
> It sounds interesting. Could you explain a bit more what effect you refer 
> to ? Some code to show it ? Or a link to it.
> For the time being, the few things I know is that anonymous types are 
> useful and safe for : coextensions, and controlling access 
> parameters/results and the dispatching they allow.
> So if you allude to dispatching, I might understand your point (a bit), 
> otherwise I don't.

Yikes. Anonymous access type act differently than their named counterparts 
in the following cases (to name a few):
    (1) Hard to set the convention, pre/postconditions, other aspects 
(because there's no declaration);
    (2) Accessibility for anonymous access parameters (both objects and 
subprograms), discriminants, stand-alone objects;
    (3) Full context passed with anonymous access-to-subprogram parameters;
    (4) Dynamic accessibility causes a "tripping hazard" (Program_Error with 
some actual parameters) - access parameters, stand-alone objects.
    (5) Hidden null exclusion for controlling anonymous access parameters.

               Randy.

Re: little precision about anonymous access types

[Mehdi Saada]

Thanks.
 Now I've gotten my hands on Barnes' book (hourra !!), I couldn't help go straight to the access types' chapter. I don't why I so like this part, despite that I already have been able to see how much the semantic of "references" is different (and a pain in the neck) than of normal variables.

so the book says:
type cell is
record
   next: access cell;
   value: data;
end record;

even though unchecked_deallocation doesn't work, I can't believe this feature would have be included without some sort of assurance that it could be deallocated, automatically. Otherwise it would be nothing short of insanely crazy batshit.

Re: little precision about anonymous access types

[Mehdi Saada]

I should ask this in another way: what strategy do you use with user-defined storage pools ? I can guess that since the user doesn't have as much "metalinguistic" on types and objects as the compiler, there's a limit to how much automatic and complex one might for instance,
build a default storage pool for anonymous access objects.

Re: little precision about anonymous access types

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:b0a9cf48-6a6f-4f10-93a7-fd77c427728c@googlegroups.com...
>Otherwise it would be nothing short of insanely crazy batshit.

The best description of anonymous accesss types I've read in a while. ;-)

The intent is that you use named access types to allocate/deallocate memory, 
and just use anonymous types to store them for short periods (i.e. 
parameters, stand-alone objects). But then why not just use the named types 
everywhere?

Anonymous access types started out as a(n unnecessary) hack to allow 
dispatching on access types, and grew into something monsterous that really 
doesn't help for any of the needs that they were touted for. The worst big 
mistake that we made with Ada post-95 was expanding the use of these 
things - lots of complication, little value.

                           Randy.

Re: little precision about anonymous access types

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:6c1e643d-b826-4b8b-b61c-13c56428ed23@googlegroups.com...
> I should ask this in another way: what strategy do you use with 
> user-defined
>storage pools ? I can guess that since the user doesn't have as much
>"metalinguistic" on types and objects as the compiler, there's a limit to 
>how
>much automatic and complex one might for instance,
>build a default storage pool for anonymous access objects.

Allocate/deallocate with a named access type. As you noted, it is impossible 
to deallocate individual objects with anonymous access types.

Note there is an alternative (not recommended by me): use a storage subpool, 
assign the pool to all anonymous access types using pragma 
Default_Storage_Pool, allocate objects from appropriate subpools, and 
deallocate the objects using Unchecked_Deallocate_Subpool when no longer 
needed.

Or you can just avoid using anonymous access types everywhere and forget (as 
much as possible) that they exist. :-)

                            Randy.

Re: little precision about anonymous access types

[Mehdi Saada]

So if it was you, you would have treated subprograms with access types parameters as primitives, as long as they are declared in the same immediate scope ? It sounds simple, why hasn't it be do that way ?

Re: little precision about anonymous access types

[Mehdi Saada]

I may add, that the craziest thing was to allow the very possibly of using allocators with non-discriminant/non-parameter anonymous access (though I have no idea, and it's not easy to find, where and for how long goes things like values like my_func(new something', ...) types. Their existence, that forbid and uselessness aside, it wouldn't be that much of a loophole. At least provide a way to bind the objects' life time to something, dudes...

Re: little precision about anonymous access types

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:d294e4a5-864c-4ab0-bf60-6c9a94ace651@googlegroups.com...
> So if it was you, you would have treated subprograms with
>access types parameters as primitives, as long as they are declared
>in the same immediate scope ? It sounds simple, why hasn't it be
>do that way ?

No, I wouldn't bother with dispatching on access values at all. Since Ada 
passes all tagged objects by reference, and 'Unchecked_Access is always 
allowed on tagged parameters, it's always possible to get an access to a 
tagged parameter if that is needed. There's no reason to *pass* that value - 
just pass the tagged object.

Essentially, there's no implementation difference (ignoring the abomination 
of dynamic accessibility) between "access T" and "in out T" for a tagged 
type T. So the former is not really needed - at best it saves 4 characters 
on calls (".all"), but in many circumstances it adds complication (needing 
to add "aliased" and "'Access" in various places).

                   Randy.

Re: little precision about anonymous access types

[Randy Brukardt]

The better solution here is restriction No_Anonymous_Allocators (see 
H.4(8.1/3)). Using that restriction helps because it forces all allocation 
to named access types (for which you can do deallocation in all of the 
normal ways). This is just to note that Ada does have ways to mitigate this 
problem (I noted another one, pragma Default_Storage_Pool, in a previous 
message). The annoyance is that these things aren't the default.

                   Randy.


"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:1fbd0763-bed4-49f5-a1c8-51a634e89eb2@googlegroups.com...
I may add, that the craziest thing was to allow the very possibly of using 
allocators with non-discriminant/non-parameter anonymous access (though I 
have no idea, and it's not easy to find, where and for how long goes things 
like values like my_func(new something', ...) types. Their existence, that 
forbid and uselessness aside, it wouldn't be that much of a loophole. At 
least provide a way to bind the objects' life time to something, dudes... 

Re: little precision about anonymous access types

[J-P. Rosen]

Le 17/05/2018 à 23:17, Randy Brukardt a écrit :
> No, I wouldn't bother with dispatching on access values at all. Since Ada 
> passes all tagged objects by reference, and 'Unchecked_Access is always 
> allowed on tagged parameters, it's always possible to get an access to a 
> tagged parameter if that is needed. There's no reason to *pass* that value - 
> just pass the tagged object.
Hmm... I don't remember the details, but wasn't it necessary for RACW
(Remote Access to Class Wide) types?

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: little precision about anonymous access types

[Dmitry A. Kazakov]

On 17/05/2018 23:17, Randy Brukardt wrote:
> "Mehdi Saada" <00120260a@gmail.com> wrote in message
> news:d294e4a5-864c-4ab0-bf60-6c9a94ace651@googlegroups.com...
>> So if it was you, you would have treated subprograms with
>> access types parameters as primitives, as long as they are declared
>> in the same immediate scope ? It sounds simple, why hasn't it be
>> do that way ?
> 
> No, I wouldn't bother with dispatching on access values at all. Since Ada
> passes all tagged objects by reference, and 'Unchecked_Access is always
> allowed on tagged parameters, it's always possible to get an access to a
> tagged parameter if that is needed. There's no reason to *pass* that value -
> just pass the tagged object.

You forgot the return. Return by reference was killed and there is no 
substitute for

    function Foo return access T;

> Essentially, there's no implementation difference (ignoring the abomination
> of dynamic accessibility) between "access T" and "in out T" for a tagged
> type T.

Yes, but there must be difference if the type system were fixed to allow 
classes of non-tagged and by-value objects.

I agree that controlling access T could be made superfluous by carefully 
designed references.

I also believe that having an operation for T and not having it for 
access T and conversely is not good. I.e. if there is

    procedure Foo (X : in out T);

then that must automatically define

    procedure Foo (X : access T);

and conversely. Rules for automatic dereferencing do this in some cases.

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