Generic formal access types

Generic formal access types

[@ 2003-04-30 18:30 UTC (permalink / raw)]

Does anybody know why Ada does not have something like:

generic
    type Access_Type is access (<>);  --  ?

I would like to specify in a generic package that it should be 
instantiated by an access type, no matter what type it is pointing to. 	

Ok, it is not very useful to have an access type if you do not know its 
content, but the package implements a list and I am just storing them. I 
"need" that because I want to return the value "null" from a function in 
the generic package that returns "Access_Type".

There is a possible workaround:

generic
    type Element is (<>);
    type Access_Type is access Element;

But I do not like it because it forces me to pass also the "Element" in 
the instantiation.

Any support for a possible proposal?

Rodrigo

Re: Generic formal access types

[Simon Wright]

Rodrigo Garc�a <rodrigo.garcia.ARROBA.epfl.ch> writes:

> Does anybody know why Ada does not have something like:
> 
> generic
>     type Access_Type is access (<>);  --  ?
> 
> I would like to specify in a generic package that it should be
> instantiated by an access type, no matter what type it is pointing
> to.
> 
> Ok, it is not very useful to have an access type if you do not know
> its content, but the package implements a list and I am just storing
> them. I "need" that because I want to return the value "null" from a
> function in the generic package that returns "Access_Type".
> 
> There is a possible workaround:
> 
> generic
>     type Element is (<>);
>     type Access_Type is access Element;
> 
> But I do not like it because it forces me to pass also the "Element"
> in the instantiation.

I think 'type Element is limited private' would be better (I can't
rememer if you can allow it to be unconstrained as well, 'type Element
(<>) is limited private' ... GNAT is happy).

I can understand why a formal type has to be tagged for you to declare
it abstract, you would have thought a private constraint { (<>) }
would have been a possibility here ..

There's no way I can see that you can instantiate a generic with an
access-to-subprogram, but I'm not sure that the uses would be worth
the trouble!

Re: Generic formal access types

[Chad R. Meiners]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

How about

generic
   type Access_Type is private;
   Null_Value : Access_Type;

-CRM

"Rodrigo Garc�a" <rodrigo.garcia.ARROBA.epfl.ch> wrote in message
news:3eb01630@epflnews.epfl.ch...
> Does anybody know why Ada does not have something like:
>
> generic
>     type Access_Type is access (<>);  --  ?
>

Re: Generic formal access types

[@ 2003-05-01 8:58 UTC (permalink / raw)]

Simon Wright wrote:
> Rodrigo Garc�a <rodrigo.garcia.ARROBA.epfl.ch> writes:
> 
> 
>>Does anybody know why Ada does not have something like:
>>
>>generic
>>    type Access_Type is access (<>);  --  ?
>>
>>I would like to specify in a generic package that it should be
>>instantiated by an access type, no matter what type it is pointing
>>to.
>>
>>Ok, it is not very useful to have an access type if you do not know
>>its content, but the package implements a list and I am just storing
>>them. I "need" that because I want to return the value "null" from a
>>function in the generic package that returns "Access_Type".
>>
>>There is a possible workaround:
>>
>>generic
>>    type Element is (<>);
>>    type Access_Type is access Element;
>>
>>But I do not like it because it forces me to pass also the "Element"
>>in the instantiation.
> 
> 
> I think 'type Element is limited private' would be better (I can't
> rememer if you can allow it to be unconstrained as well, 'type Element
> (<>) is limited private' ... GNAT is happy).

Sorry, I meant:

generic
    type Elment (<>) is private;
    --  Yes, (<>) allows Element to be unconstrained.
    type Access_Type is access Element;

But the "problem" is still there. I have to pass an actual "Element" as 
well as an actual "Access_Type" when I instantiate the generic package. 
I would like to only pass the "Access_Type".

> I can understand why a formal type has to be tagged for you to declare
> it abstract, you would have thought a private constraint { (<>) }
> would have been a possibility here ..

You are probably right, but I am not dealing with tagged types here. My 
problem is much simpler.

> There's no way I can see that you can instantiate a generic with an
> access-to-subprogram, but I'm not sure that the uses would be worth
> the trouble!

Hmmm... I was not thinking of that either. Just access to objects by 
now.  :^)

Rodrigo

Re: Generic formal access types

[@ 2003-05-01 9:06 UTC (permalink / raw)]

That seems a nice workaround, although I still have to pass two 
parameters during instantiation. I will give it a try!

Thanks,

Rodrigo



Chad R. Meiners wrote:

How about

generic
    type Access_Type is private;
    Null_Value : Access_Type;

-CRM

Re: Generic formal access types

[Martin Krischik]

Rodrigo Garcï¿œa <rodrigo.garcia.ARROBA.epfl.ch> wrote:

should

generic
     type Access_Type is private;
    Null_Value : Access_Type := nul;

not work as well?

Regards

Martin

> That seems a nice workaround, although I still have to pass two
> parameters during instantiation. I will give it a try!
> 
> Thanks,
> 
> Rodrigo
> 
> Chad R. Meiners wrote:
> 
> How about
> 
> generic
>     type Access_Type is private;
>     Null_Value : Access_Type;
> 
> -CRM

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Generic formal access types

[@ 2003-05-01 10:09 UTC (permalink / raw)]

Well, the workaround has another problem: the compiler cannot check if 
the type I pass in the instantiation is an access type nor if the 
"Null_Value" object is really null... But I suppose that is why we call 
it a "workaround".   ;^)

In the end, I think I will stick to my own workaround, but thanks again 
for your ideas.

Rodrigo

Rodrigo García wrote:
> That seems a nice workaround, although I still have to pass two 
> parameters during instantiation. I will give it a try!
> 
> Thanks,
> 
> Rodrigo
> 
> 
> 
> Chad R. Meiners wrote:
> 
> How about
> 
> generic
>    type Access_Type is private;
>    Null_Value : Access_Type;
> 
> -CRM
> 

Re: Generic formal access types

[@ 2003-05-01 13:00 UTC (permalink / raw)]

Martin Krischik wrote:
> Rodrigo Garcï¿œa <rodrigo.garcia.ARROBA.epfl.ch> wrote:
> 
> should
> 
> generic
>      type Access_Type is private;
>     Null_Value : Access_Type := nul;
> 
> not work as well?

   No, it does not work. The compiler does not know until you 
instantiate the package wether Access_Type is really an access type, so 
it will not accept "null" as initial value for Null_Value. That is, in 
fact, the problem and the reason why I would want to express somehow 
that "Access_Type" must be instantiated by an actual access type without 
necessarily specifying the accessed object type.

   I do not know if I made myself clear, but you can always try to 
compile your solution in order to convince you...

Rodrigo

> 
> Regards
> 
> Martin
> 
> 
>>That seems a nice workaround, although I still have to pass two
>>parameters during instantiation. I will give it a try!
>>
>>Thanks,
>>
>>Rodrigo
>>
>>Chad R. Meiners wrote:
>>
>>How about
>>
>>generic
>>    type Access_Type is private;
>>    Null_Value : Access_Type;
>>
>>-CRM
> 
> 

Re: Generic formal access types

[tmoran]

> Ok, it is not very useful to have an access type if you do not know its
> content, but the package implements a list and I am just storing them. I
> "need" that because I want to return the value "null" from a function in
> the generic package that returns "Access_Type".
  What's wrong with
generic
    type Element is (<>);
package Lists is
    type Node_Content_Ptr is access Element;

Re: Generic formal access types

[Ludovic Brenta]

Do you absolutely have to return null in one of the functions of your
generic package?  How about raising an exception instead?  Something
along the lines of:

generic
   type Element (<>) is private;
package List is
   No_Element_Error: Exception;
   type List is private;
   function Get_Element (L : List) return Element;
private
   type List is ... ;
end List;

package body List is
   function Get_Element (L : List) return Element is
   begin
      raise No_Element_Error; -- instead of return null
   end Get_Element;
end List;

I'm sure you've thought about that, but I'm curious to know why it
wouldn't work for you.

--
Ludovic Brenta.

Re: Generic formal access types

[@ 2003-05-02 9:52 UTC (permalink / raw)]

tmoran@acm.org wrote:
>>Ok, it is not very useful to have an access type if you do not know its
>>content, but the package implements a list and I am just storing them. I
>>"need" that because I want to return the value "null" from a function in
>>the generic package that returns "Access_Type".
> 
>   What's wrong with
> generic
>     type Element is (<>);

First of all, I wrote this too fast and it is erroneous. It should read:

generic
    type Element (<>) is private;

> package Lists is
>     type Node_Content_Ptr is access Element;

If I declare the access type in the package, I will have a problem with 
the return type of the function:

function Whatever return Node_Content_Ptr;

Because I already have access types defined where I do the instantiation.

declare
    type Ptr is access Integer;
    package Instance is new Generic_Package (Integer);
    P : Ptr;
begin
    P := Instance.Whatever;
end;

Here, P is of type "Ptr" and the function returns "Node_Content_Ptr". 
For the compiler to accept this, I will have to declare Ptr as "access 
all Integer" and do an explicit conversion:

P := Ptr (Instance.Whatever);

Since I cannot change the definition of Ptr, this solution is not valid 
for me... Nice try, though!  :^)

Rodrigo

Re: Generic formal access types

[@ 2003-05-02 10:43 UTC (permalink / raw)]

Well, it is just that null is a perfectly possible return value for my 
function and I did not want to raise an exception to process that case. 
In your example however (Get_Element), it makes sense to raise an 
exception. But imagine a list of access types, even if some of them have 
the value null, you might want to return that value as well (it is not 
that they are not in the list).

Anyway, I still think it would be great if I could write something like:

generic
    type Pointer is access (<>);

Then, the compiler would be able to check that I am actually 
instantiating the package with an access type (something I do not have 
in your solution) and I could use the "null" value as well.

Rodrigo

Ludovic Brenta wrote:
> Do you absolutely have to return null in one of the functions of your
> generic package?  How about raising an exception instead?  Something
> along the lines of:
> 
> generic
>    type Element (<>) is private;
> package List is
>    No_Element_Error: Exception;
>    type List is private;
>    function Get_Element (L : List) return Element;
> private
>    type List is ... ;
> end List;
> 
> package body List is
>    function Get_Element (L : List) return Element is
>    begin
>       raise No_Element_Error; -- instead of return null
>    end Get_Element;
> end List;
> 
> I'm sure you've thought about that, but I'm curious to know why it
> wouldn't work for you.
> 
> --
> Ludovic Brenta.

Re: Generic formal access types

[@ 2003-05-02 10:50 UTC (permalink / raw)]

Rodrigo Garc�a wrote:
> But imagine a list of access types, even if some of them have 
> the value null, you might want to return that value as well (it is not 
> that they are not in the list).

Sorry, this argument is quite stupid from my part... you do not have to 
use the "null" keyword then, just return the object. Maybe I will have 
to rethink the possibility of using exceptions...

Rodrigo

Re: Generic formal access types

[tmoran]

>declare
>    type Ptr is access Integer;
>    package Instance is new Generic_Package (Integer);
>    P : Ptr;
>...
>Here, P is of type "Ptr" and the function returns "Node_Content_Ptr".
>For the compiler to accept this, I will have to declare Ptr as "access
>all Integer" and do an explicit conversion:
Why not
 declare
     package Instance is new Generic_Package (Integer);
     subtype Ptr is Instance.Node_Content_Ptr;
     P : Ptr;

Re: Generic formal access types

[Robert A Duff]

tmoran@acm.org writes:

> Why not
>  declare
>      package Instance is new Generic_Package (Integer);
>      subtype Ptr is Instance.Node_Content_Ptr;
>      P : Ptr;

That works only if you want to declare the pointer type at the same
place where the instantiation is.  In many cases, you don't.  For this
reason, it's almost always better to pass the pointer type into
generics.

When I invented the Address_To_Access_Conversions package (see chap 13),
I made the mistake of declaring the pointer type inside the generic,
because I thought the primary use would be peek/poke functionality, so
you would always say ".all" right away.  And it makes the instantiation
simpler.  But it turns out to be a pain.

The "right" solution to the OP's problem is to pass in the designated
type and the pointer type.  Yes, that requires an extra line of code at
the instantiation.  But I don't think there's a better solution.

- Bob

Re: Generic formal access types

[Randy Brukardt]

Robert A Duff wrote in message ...
>When I invented the Address_To_Access_Conversions package (see chap
13),
>I made the mistake of declaring the pointer type inside the generic,
>because I thought the primary use would be peek/poke functionality, so
>you would always say ".all" right away.  And it makes the instantiation
>simpler.  But it turns out to be a pain.


I always wondered whose fault that was. :-)

Whenever use that package, I almost always declare the access type
first, then realize that isn't right and have to change it. And, it
often is the case that it has to be converted to another type.

(But I've found that avoid System.Address altogether is a better
solution. There really is no reason to use it in Ada 95 outside of
address clauses.)

             Randy.

Re: Generic formal access types

[@ 2003-05-05 8:14 UTC (permalink / raw)]

Robert A Duff wrote:
> tmoran@acm.org writes:
> 
> 
>>Why not
>> declare
>>     package Instance is new Generic_Package (Integer);
>>     subtype Ptr is Instance.Node_Content_Ptr;
>>     P : Ptr;
> 
> 
> That works only if you want to declare the pointer type at the same
> place where the instantiation is.  In many cases, you don't.  For this
> reason, it's almost always better to pass the pointer type into
> generics.

   In my case, "Ptr" is already defined before the instantiation of the 
package and I should not change its definition.

   But again, I did not think of that possibility, so thanks for the 
suggestion.

Rodrigo

Re: Generic formal access types

[Matthew Heaney]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccof2lqoad.fsf@shell01.TheWorld.com>...
> 
> That works only if you want to declare the pointer type at the same
> place where the instantiation is.  In many cases, you don't.  For this
> reason, it's almost always better to pass the pointer type into
> generics.

That is indeed how the Charles library works wrt the Generic_Element
function: the client has to supply the access type.

To ensure complete generality for a reuseable component, passing in
the access type is the correct choice, since in many cases the client
already has an access type that goes with the designated type.

http://home.earthlink.net/~matthewjheaney/charles/


 
> When I invented the Address_To_Access_Conversions package (see chap 13),
> I made the mistake of declaring the pointer type inside the generic,
> because I thought the primary use would be peek/poke functionality, so
> you would always say ".all" right away.  And it makes the instantiation
> simpler.  But it turns out to be a pain.

I think a bigger problem is that the declared pointer type doesn't
turn off the storage pool.  If the designated type is T'Class, doesn't
this drag a lot of extra run-time baggage?

If you're converting from Address to Object_Pointer, then there's no
storage pool anyway, so it never made sense to me to give
Object_Pointer a storage pool.

 
> The "right" solution to the OP's problem is to pass in the designated
> type and the pointer type.  Yes, that requires an extra line of code at
> the instantiation.  But I don't think there's a better solution.

Yes.

Re: Generic formal access types

[Robert A Duff]

mheaney@on2.com (Matthew Heaney) writes:

> I think a bigger problem is that the declared pointer type doesn't
> turn off the storage pool.  If the designated type is T'Class, doesn't
> this drag a lot of extra run-time baggage?

I don't remember what Address_To_Access_Conversions says about pools,
and I'm too lazy to look it up.  Probably nothing.

In general, an access-to-T'Class type needs to worry about finalization,
because even if T has no finalization, some extension might.  I don't
think that introduces any overhead in the conversions, but a class-wide
allocator would have to check (probably at run time) whether the actual
type has any finalization, and if so, hook the object into some list of
to-be-finalized objects.  Did you have anything else in mind?

In my current project, we care a lot about storage management, so we
have a coding convention: *Every* access type must have "for
T'Storage_Pool use..." to indicate which pool, or "for T'Storage_Size
use 0;" to indicate that there are no allocators for that type, or a
comment saying why we're violating this rule.

- Bob