generic question

generic question

[markww]

Hi,

I've been going through ada tutorials, and am looking at the generics
support. I can't quite understand how to accomplish having a record
which has a generic data member. For example, something like:

    type NODE_REC is
        record
            unknown_data_type : generic;  -- not sure how to express
this in ada
            Next_Node : NODE_REC_PTR;
            Prev_Node : NODE_REC_PTR;
      end record;

I'd like to be able to store either an integer, a float, or some other
user defined record type in there so that this node record becomes a
container. Is this possible?

Thanks,
Mark

Re: generic question

[Ludovic Brenta]

markww writes:
>     type NODE_REC is
>         record
>             unknown_data_type : generic;  -- not sure how to express
> this in ada
>             Next_Node : NODE_REC_PTR;
>             Prev_Node : NODE_REC_PTR;
>       end record;

generic
   type T is private;
package P is
   type Node;
   type Node_Ptr is access Node;
   type Node is record
      Data : T;
      Prev, Next : Node_Ptr;
   end record;
end P;

HTH

See also the predefined containers, in particular
Ada.Containers.Doubly_Linked_Lists [1]

[1] http://www.adaic.com/standards/05rm/html/RM-A-18-3.html

-- 
Ludovic Brenta.

Re: generic question

[Stefan Bellon]

Ludovic Brenta wrote:

> generic
>    type T is private;
> package P is
>    type Node;
>    type Node_Ptr is access Node;
>    type Node is record
>       Data : T;
>       Prev, Next : Node_Ptr;
>    end record;
> end P;

Or, since you are referring to the Ada 2005 container classes anyway,
using Ada 2005 and anonymous access:

generic
   type T is private;
package P is
   type Node is record
      Data : T;
      Prev : access Node;
      Next : access Node;
   end record;
end P;

-- 
Stefan Bellon

Re: generic question

[markww]

Thanks guys I'll give it a try now,

Mark

On Nov 19, 2:23 pm, Stefan Bellon <sbel...@sbellon.de> wrote:
> Ludovic Brenta wrote:
> > generic
> >    type T is private;
> > package P is
> >    type Node;
> >    type Node_Ptr is access Node;
> >    type Node is record
> >       Data : T;
> >       Prev, Next : Node_Ptr;
> >    end record;
> > end P;Or, since you are referring to the Ada 2005 container classes anyway,
> using Ada 2005 and anonymous access:
>
> generic
>    type T is private;
> package P is
>    type Node is record
>       Data : T;
>       Prev : access Node;
>       Next : access Node;
>    end record;
> end P;
> 
> --
> Stefan Bellon

Re: generic question

[Pascal Obry]

Stefan Bellon a �crit :
> Or, since you are referring to the Ada 2005 container classes anyway,
> using Ada 2005 and anonymous access:
> 
> generic
>    type T is private;
> package P is
>    type Node is record
>       Data : T;
>       Prev : access Node;
>       Next : access Node;
>    end record;
> end P;

You probably don't want "access Node" here as you won't be able to
deallocate such pointer. There is no way to instantiate
Unchecked_Conversion with an anonymous access type. This is something I
found quite irritating in Ada 2005.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: generic question

[Alex R. Mosteo]

Pascal Obry wrote:

> Stefan Bellon a �crit :
>> Or, since you are referring to the Ada 2005 container classes anyway,
>> using Ada 2005 and anonymous access:
>> 
>> generic
>>    type T is private;
>> package P is
>>    type Node is record
>>       Data : T;
>>       Prev : access Node;
>>       Next : access Node;
>>    end record;
>> end P;
> 
> You probably don't want "access Node" here as you won't be able to
> deallocate such pointer. There is no way to instantiate
> Unchecked_Conversion with an anonymous access type. This is something I
> found quite irritating in Ada 2005.

Isn't enough to have a wrapper access type at the point of deallocation? Or
are some scope rules preventing this?

Re: generic question

[Pascal Obry]

Alex R. Mosteo a �crit :
> Isn't enough to have a wrapper access type at the point of deallocation? Or
> are some scope rules preventing this?

Yes and no. The anonymous access types and named access types won't use
the same memory pool. So doing this will not be portable. I think it
will work with current compilers though...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: generic question

[Alex R. Mosteo]

Pascal Obry wrote:

> Alex R. Mosteo a �crit :
>> Isn't enough to have a wrapper access type at the point of deallocation?
>> Or are some scope rules preventing this?
> 
> Yes and no. The anonymous access types and named access types won't use
> the same memory pool. So doing this will not be portable. I think it
> will work with current compilers though...

If I'm not mistaken, point 13.11.2(16) would make it not even not portable
but indeed erroneous. Unless you use a named access type for the initial
allocation and the final deallocation. Admittedly I'm not very sure of any
of this.

Re: generic question

[markww]

Hi all,

I was planning on having each node use the same generic type once
instantiated. I am still new with Ada, but thought it would work
similarly to C++:

    vector<CMyClassType> vMyVector;

now this instance of the vector can only contain type CMyClassType.

Thanks,
Mark

On Nov 20, 1:10 pm, "Alex R. Mosteo" <devn...@mailinator.com> wrote:
> Pascal Obry wrote:
> > Alex R. Mosteo a écrit :
> >> Isn't enough to have a wrapper access type at the point of deallocation?
> >> Or are some scope rules preventing this?
>
> > Yes and no. The anonymous access types and named access types won't use
> > the same memory pool. So doing this will not be portable. I think it
> > will work with current compilers though...If I'm not mistaken, point 13.11.2(16) would make it not even not portable
> but indeed erroneous. Unless you use a named access type for the initial
> allocation and the final deallocation. Admittedly I'm not very sure of any
> of this.

Re: generic question

[Matthew Heaney]

markww wrote:
>
> I was planning on having each node use the same generic type once
> instantiated. I am still new with Ada, but thought it would work
> similarly to C++:
>
>     vector<CMyClassType> vMyVector;
>
> now this instance of the vector can only contain type CMyClassType.

That's exactly how it would work in Ada05 too:

with My_Types;  use My_Types;
with Ada.Containers.Vectors;

package My_Vector_Types is
  new Ada.Containers.Vectors (My_Class_Type);

where My_Types is an instantiation of some generic package containing
the declaration of type My_Class_Type.

Re: generic question

[Matthew Heaney]

Pascal Obry wrote:
>
> You probably don't want "access Node" here as you won't be able to
> deallocate such pointer. There is no way to instantiate
> Unchecked_Conversion with an anonymous access type. This is something I
> found quite irritating in Ada 2005.

Storage pools are associated with named access types.  (I think it's
possible to allocate using an anonymous access type, but to me that's
thoroughly confusing and so I have never attempted to do so.)

With anonymous access types the programmer must maintain the
association between allocated instance and its pool.  You can only
allocate from a pool, and you must deallocate to the same pool from
which you allocated, so at some point there needs to be a conversion
between the anonymous access type and the named access type (with which
the storage pool is associated).

Re: generic question

[Pascal Obry]

Matthew Heaney a �crit :
> Storage pools are associated with named access types.  (I think it's
> possible to allocate using an anonymous access type, but to me that's
> thoroughly confusing and so I have never attempted to do so.)

Yes of course:

   C : access Integer;
   ...
   C := new Integer'(12);

> With anonymous access types the programmer must maintain the
> association between allocated instance and its pool.  You can only
> allocate from a pool, and you must deallocate to the same pool from
> which you allocated, so at some point there needs to be a conversion
> between the anonymous access type and the named access type (with which
> the storage pool is associated).

I do not follow. The conversion will change nothing:

1. you allocate an anonymous access from a "compiler specific pool A"

2. you convert the anonymous access type to a named access type : NAT

3. you deallocate NAT from a "compiler specific pool B"

This will allocate and deallocate on different pool. And AFAIK there is
no way to specify the anonymous access type pool.

I don't see a solution to that problem at the moment...
or I'm confused :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: generic question

[Alex R. Mosteo]

Pascal Obry wrote:

> Matthew Heaney a �crit :
>> Storage pools are associated with named access types.  (I think it's
>> possible to allocate using an anonymous access type, but to me that's
>> thoroughly confusing and so I have never attempted to do so.)
> 
> Yes of course:
> 
>    C : access Integer;
>    ...
>    C := new Integer'(12);
> 
>> With anonymous access types the programmer must maintain the
>> association between allocated instance and its pool.  You can only
>> allocate from a pool, and you must deallocate to the same pool from
>> which you allocated, so at some point there needs to be a conversion
>> between the anonymous access type and the named access type (with which
>> the storage pool is associated).
> 
> I do not follow. The conversion will change nothing:
> 
> 1. you allocate an anonymous access from a "compiler specific pool A"
> 
> 2. you convert the anonymous access type to a named access type : NAT
> 
> 3. you deallocate NAT from a "compiler specific pool B"
> 
> This will allocate and deallocate on different pool. And AFAIK there is
> no way to specify the anonymous access type pool.
> 
> I don't see a solution to that problem at the moment...
> or I'm confused :)

I think Matthew meant (and I certainly did in my other post):

type AI is access Integer;

function Get_Some return access Integer is
   Local : constant AI := new Integer'(...);
begin
   return Local;
   --  Instead of return new Integer'();
end Get_Some;

and then you convert back to AI for deallocation. This way you allocate and
deallocate from AI'Storage_Pool.

I'm not sure about what use cases this can be useful though...

Re: generic question

[Matthew Heaney]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> I think Matthew meant (and I certainly did in my other post):

Yes, exactly.
 

> I'm not sure about what use cases this can be useful though...

What you did above would be the idiom when you using the package itself to
control allocation of objects:

package P is
  type T (<>) is limited private;
  function New_T return not null access T;
  -- ops go here
  procedure Free (O : access T);
...
end P;

Inside package P you allocate and deallocate through a named access type.

Re: generic question

[Matthew Heaney]

Matthew Heaney wrote:
> "Alex R. Mosteo" <devnull@mailinator.com> writes:
>
> What you did above would be the idiom when you using the package itself to
> control allocation of objects:

Actually, I might do this differently for tagged vs. non-tagged types:

package P is
  type T (<>) is limited private;
  type T_Access is access T;
  function New_T return T_Access;
  procedure Free (X : in out T_Access);
...
end P;

At least this way you can set the pointer value to null on return from
Free.  For tagged types I'd probably do something like:

package Q is
  type T (<>) is tagged limited private;
  function New_T return not null access T;
  procedure Free (X : access T'Class);
...
private
  procedure Do_Free (X : access T);
...
end;

and then implement Free as a dispatching call to Do_Free, which can be
overridden by types that derive from T.

The reason for declaring Free with type T'Class is that if it were
declared as type T, then Free would be primitive for the type.  That
would make X a controlling operand and hence would have to be non-null.
 By declaring Free with type T'Class, the operation is no longer
primitive, X is not controlling, and so you can pass a null access
value without error.  You do lose the ability to set the access value
to null on return, however.  (Yes, you could use named access types,
but that defeats the implicit conversions that happen when you use
anonymous access types.)

In general when you're dealing with hierarchies of tagged types then
use anonymous access types, since this facilitates converting among
types in the hierarchy.

Re: generic question

[Pascal Obry]

Matthew Heaney a �crit :
> Matthew Heaney wrote:
>> "Alex R. Mosteo" <devnull@mailinator.com> writes:
>>
>> What you did above would be the idiom when you using the package itself to
>> control allocation of objects:
> 
> Actually, I might do this differently for tagged vs. non-tagged types:
> 
> package P is
>   type T (<>) is limited private;
>   type T_Access is access T;
>   function New_T return T_Access;
>   procedure Free (X : in out T_Access);
> ....
> end P;
> 
> At least this way you can set the pointer value to null on return from
> Free.  

Yes, but there is no more anonymous access type... as I said in a
previous message (and you made my point)... why even bother with them ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: generic question

[Matthew Heaney]

Pascal Obry wrote:
>
> Yes, but there is no more anonymous access type...

Not really necessary if this is a non-tagged type.

> as I said in a
> previous message (and you made my point)... why even bother with them ?

So that conversions towards the root of a tagged type hierarchy don't
require explicit type conversions.

Re: generic question

[Dmitry A. Kazakov]

On 21 Nov 2006 10:15:42 -0800, Matthew Heaney wrote:

> So that conversions towards the root of a tagged type hierarchy don't
> require explicit type conversions.

True, but it is only because there is no subtypes of access types like:

type T is tagged ...;
type T_Ptr is access T'Class;

type S is new T with ...;
subtype S_Ptr is T_Ptr in S'Class;

In the present design three uncorrelated things are bundled together in
anonymous access types:

1. subtypes hierarchy inherited from the target types hierarchy
2. general pool
3. controlledness in primitive subprograms

In Ada 95 it was even four:

4. not null

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

Re: generic question

[Matthew Heaney]

Pascal Obry <pascal@obry.net> writes:

> This will allocate and deallocate on different pool. 

Right, so don't do that!


> And AFAIK there is
> no way to specify the anonymous access type pool.

Fine, then don't allocate from an anonymous access type pool!

Re: generic question

[Pascal Obry]

Matthew Heaney a �crit :
>> And AFAIK there is
>> no way to specify the anonymous access type pool.
> 
> Fine, then don't allocate from an anonymous access type pool!

Thanks, we have gone a big step forward :)

Of course I can also altogether stop using anonymous access type.

You are saying that for every anonymous access type you need to declare
a named access type from which allocate/deallocate. One point of the
anonymous access type was to avoid proliferation of named access type...

I find anonymous access type less useful this way... Why even bother
with them then ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: generic question

[Lutz Donnerhacke]

* Pascal Obry wrote:
> I find anonymous access type less useful this way... Why even bother
> with them then ?

Because you can derive pointers without allocation.
E.g. self references of limited types.

Re: generic question

[Alex R. Mosteo]

Lutz Donnerhacke wrote:

> * Pascal Obry wrote:
>> I find anonymous access type less useful this way... Why even bother
>> with them then ?
> 
> Because you can derive pointers without allocation.
> E.g. self references of limited types.

But, I'd say, this already was doable without named access types with access
discriminants.

Re: generic question

[Matthew Heaney]

Lutz Donnerhacke wrote:
>
> Because you can derive pointers without allocation.
> E.g. self references of limited types.

As Alex pointed out, it is probably wrong to use a named access type
for this purpose.

Re: generic question

[Randy Brukardt]

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrnem6dkc.3tk.lutz@belenus.iks-jena.de...
> * Pascal Obry wrote:
> > I find anonymous access type less useful this way... Why even bother
> > with them then ?
>
> Because you can derive pointers without allocation.
> E.g. self references of limited types.

Well, that's one use. There are three others, IMHO:

* To stand in for the lack of "in out" parameters on functions;
* To avoid unnecessary type conversions between
access-to-declared-in-limited-with;
* To stand in for the lack of subprogram types (anonymous
access-to-subprogram parameters).

That's it. All other uses (especially controlling access parameters) are
junk and should be avoided.

In part, that follows from my opinion that there should be no access types
in the vast majority of reusable Ada packages (if the user needs dynamic
allocation, they can provide it). Of course, the implementation of the such
a package might have some access types, but those might as well be named
(there is no need for implicit conversions there).

One of the reasons I feel this way that access types are inherently less
safe than direct use of objects (because of the possibility of dangling
pointers). And they force the customer of an abstraction to do memory
management (or unsafe programming with very ugly calls) even when an
stack-based allocation is fine.

The reason anonymous access parameters were invented was because some people
wanted to copy dubious OO designs from C++ directly into Ada without
appropriate conversion. Which just brings the flaws of those designs into
Ada - yuck. And, yes, I was against the expansion of the uses of anonymous
access types in Ada 2007. I lost that discussion primarily because I didn't
have a reasonable alternative for the second bullet above.

                          Randy.

Re: generic question

[Dmitry A. Kazakov]

On Wed, 22 Nov 2006 17:58:24 -0600, Randy Brukardt wrote:

> Well, that's one use. There are three others, IMHO:
> 
> * To stand in for the lack of "in out" parameters on functions;
> * To avoid unnecessary type conversions between
> access-to-declared-in-limited-with;
> * To stand in for the lack of subprogram types (anonymous
> access-to-subprogram parameters).
> 
> That's it. All other uses (especially controlling access parameters) are
> junk and should be avoided.

Absolutely
 
[...]

> And, yes, I was against the expansion of the uses of anonymous
> access types in Ada 2007. I lost that discussion primarily because I didn't
> have a reasonable alternative for the second bullet above.

Was it so important to compensate for all disadvantages access types bring
with?

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

Re: generic question

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:okqggs99v1j5$.p2upxltb2tgs$.dlg@40tude.net...
> On Wed, 22 Nov 2006 17:58:24 -0600, Randy Brukardt wrote:
...
> > And, yes, I was against the expansion of the uses of anonymous
> > access types in Ada 2007. I lost that discussion primarily because I
didn't
> > have a reasonable alternative for the second bullet above.
>
> Was it so important to compensate for all disadvantages access types bring
> with?

I guess so. The second bullet is about cases where an access type needed to
be exported anyway; there's no expansion in use implied. Limited with
doesn't allow exporting an access type (and we tried a number of ways to
allow that, but they didn't work without causing implementation and use
problems -- for instance, it wasn't possible to determine the appropriate
storage pool). One could argue that programmers shouldn't be exporting
access types in the first place, but that would not reflect the way many
programmers use Ada. And efforts to force people to do the right thing tend
to be doomed - better to avoid hamstringing people (which might cause them
to change to a less well-designed language).

                          Randy.

Re: generic question

[Matthew Heaney]

Randy Brukardt wrote:
> One could argue that programmers shouldn't be exporting
> access types in the first place, but that would not reflect the way many
> programmers use Ada.

Well it certainly reflects the way I program!  My use of named access
types has been limited to instantiating generics and for allocating
instances from a storage pool.

Re: generic question

[Matthew Heaney]

Pascal Obry wrote:
>
> You are saying that for every anonymous access type you need to declare
> a named access type from which allocate/deallocate.

Yes, to implement the factory function and destructor for a (tagged)
type.  But that's internal to the package that declares the tagged
type.  The factory function (called by a user of the package to create
instances of this specific type) should return an anonymous access type
as its return type.

If this is a non-tagged type, then anonymous access types are less
necessary, since there's no need for type conversions (as would be the
case for tagged types in a class).


> One point of the
> anonymous access type was to avoid proliferation of named access type...

No.  When you're doing object-oriented programming with different types
in a tagged type hierarchy, you need to be able to easily convert among
specific types and class-wide types towards the root of the hierarchy.
This is simpler with anonymous access types since the conversions are
implicit.

> I find anonymous access type less useful this way... Why even bother
> with them then ?

So that conversions towards the root of a tagged type hierachy are
implicit.  If you were to use named access types to convert towards the
root then this is crying wolf.  You want to reserve explicit
conversions for those times when you want the reader to take notice
that something special is going on, which is the case when performing a
down-cast, away from the root.

Re: generic question

[Randy Brukardt]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:1164132849.967832.310430@k70g2000cwa.googlegroups.com...
>
> Pascal Obry wrote:
> >
> > You are saying that for every anonymous access type you need to declare
> > a named access type from which allocate/deallocate.
>
> Yes, to implement the factory function and destructor for a (tagged)
> type.  But that's internal to the package that declares the tagged
> type.  The factory function (called by a user of the package to create
> instances of this specific type) should return an anonymous access type
> as its return type.

I don't think a factory function should ever return an access-to-object: it
should return the object itself. If the client needs to allocate that
dynamically, it can; else it can use the function for an appropriate static
initialization.

It has been argued that sometimes you don't want those constructors to be
inherited. In that case, it should return a classwide type, because even
access-to-object is considered primitive and thus inherited.

But, of course, YMMV.

                           Randy.

Re: generic question

[Dmitry A. Kazakov]

On Tue, 21 Nov 2006 18:12:54 +0100, Pascal Obry wrote:

> I find anonymous access type less useful this way... Why even bother
> with them then ?

To have controlled access parameters of primitive subprograms?

But I agree with you.

-------------------------
BTW, why is it

	X : access T

? Logically it should be: X : T'Access. Or else T'Class should be class T!
But attribute is better because it disambiguates

	T'Class'Access vs, T'Access'Class

and also allows

	in out T'Access

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

Re: generic question

[Matthew Heaney]

Dmitry A. Kazakov wrote:
>
> To have controlled access parameters of primitive subprograms?

That's what (anonymous) access parameters are for.  That was already
true in Ada95.  What changed in Ada05 is that now you can declare
objects as having an anonymous access type.  This is completely
orthogonal to the issue of allocation and deallocation, for which named
access types are still necessary.

Re: generic question

[Jeffrey R. Carter]

markww wrote:
> 
> I'd like to be able to store either an integer, a float, or some other
> user defined record type in there so that this node record becomes a
> container. Is this possible?

This is a good exercise for learning about generics and access types, 
but for real development you should probably use an existing package for 
this kind of thing.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70

Re: generic question

[markww]

Oh yeah it's just an excercise, I had to do the same in C++ & java -
otherwise I'd definitely use the preexisting  stuff,

Mark

On Nov 19, 3:24 pm, "Jeffrey R. Carter"
<spam.not.jrcar...@acm.not.spam.org> wrote:
> markww wrote:
>
> > I'd like to be able to store either an integer, a float, or some other
> > user defined record type in there so that this node record becomes a
> > container. Is this possible?This is a good exercise for learning about generics and access types,
> but for real development you should probably use an existing package for
> this kind of thing.
>
> --
> Jeff Carter
> "In the frozen land of Nador they were forced to
> eat Robin's minstrels, and there was much rejoicing."
> Monty Python & the Holy Grail
> 70

Re: generic question

[Adam Beneschan]

markww wrote:
> Hi,
>
> I've been going through ada tutorials, and am looking at the generics
> support. I can't quite understand how to accomplish having a record
> which has a generic data member. For example, something like:
>
>     type NODE_REC is
>         record
>             unknown_data_type : generic;  -- not sure how to express
> this in ada
>             Next_Node : NODE_REC_PTR;
>             Prev_Node : NODE_REC_PTR;
>       end record;
>
> I'd like to be able to store either an integer, a float, or some other
> user defined record type in there so that this node record becomes a
> container. Is this possible?

Before we possibly get too far off track, I think we need to know: Are
all of the "unknown_data_type" fields in the same container going to
have the *same* type?  Or are you planning on mixing types---e.g.
creating a linked list where some elements in the list have an integer
for the unknown_data_type field and some elements in the same list
store a float or a user-defined record or something.

If it's the second, the generic solutions others have posted won't
work.  When you declare a generic, you can instantiate it with, say,
"integer", "float", or any other type; but then each generic instance
will define its own version of NODE_REC and NODE_REC_PTR, and those are
*different* types even though they have the same name.  Therefore, a
NODE_REC_PTR from one generic instance cannot point to a NODE_REC in a
different generic instance.

If this is what you're trying to do, we'll need a different approach,
probably one that will involve tagged types and classwide types.

                             -- Adam

Re: generic question

[Matthew Heaney]

markww wrote:
>
> I'd like to be able to store either an integer, a float, or some other
> user defined record type in there so that this node record becomes a
> container. Is this possible?

I should also have pointed out that if you simply need a container of
type X, then you can just instantiate one of the standard container
library packages on your particular type.  You don't need to declare
some node type yourself, since that's done already by the container
package itself.

generic question

[shoko]

hi i have the following generic package:
--------------------------------
generic 
   type s is (<>); -- enum type of the abc of the automat 
   type s_ARR (integer range <>) of s;

package a is
   someting
end a;

------------------------------------
generic
  with package a1 is new  a(<>);  
package b is
          
   
      procedure foo(str:String;var_s:a1.s_ARR);

end b;
--------------------------------------------
i have a procedure
 procedure foo(str:String;var_s:a1.s_ARR) is
 begin
 end foo;
-----------------------------------------------
and my main program:

procdure main is
  type s is('o','p');
  type s_ARR is array(integer range <>) of s;
  package instant_a is new a(s,s_ARR);
  package instant_b is new b(instant_a); 
begin
  instant_b.foo("opoo",<>);

end main;     
----------------------------------------------
i want to send the instant of the generic package a to the function b

how do i do it right?

Re: generic question

[Marius Amado Alves]

On Sun, 2003-11-23 at 20:59, shoko wrote:
> ....
> i want to send the instant of the generic package a to the function b
> 
> how do i do it right?

  X : Instance_A.S_Arr := ...
  Instance_B.Foo ("opoo", X);

(It seems you have not been listening. Before I said: packages are not
objects. And asked you to write good English and Ada style.)