Access types

Access types

[jsanchor]

HI, I am working with access types and have a challenge at hand which I seem
to be losing. Need some help. I have data in Non Volatile Memory and RAM that
I need to access using access types. The problem is I need to have the same
"types" to work on the data, ie compare them, calculate checksum, etc.
ex. I have a package that looks like this:
-------------NVM--------------------------------------
type Non_Volatile_Type is tagged private;

type Ptr_to_Non_Volatile_Type is access all Non_Volatile_Type'class;

????Ptr_to_Data : access Non_Volatile_Type'Class?????;

type Information_Record_Type is
record
    Tag_Part   : Tag;
    NVM_Access : Ptr_to_Data???;
    RAM_Access : Ptr_to_Data???;
end record;

procedure Compute_Checksum (block : ???Ptr_to_Data);
           or
procedure Compute_Checksum (block : ???access Non_Volatile_Type'Class);

private

   type Non_Volatile_Type is tagged
      record
         checksum : Storage_Element;
      end record;

Somebody trying to use my package will declare a package somewhat like this
---------------------USER Spec------------------------------------
  type List_NVM_Type is new ddNVM.Non_Volatile_Type with
  record
     word1 : INTEGER := 8;
  end record;
---------------------USER Body------------------------------------
   procedure test is
      my_nvm : aliased List_NVM_Type;
   begin

      ddNVM.Compute_checksum(my_nvm'access);
   end test;

Does anybody know of a way. Thanks in advance.

sincerely,
Jay Sanchorawala.










-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: Access types

[Jerry van Dijk]

jsanchor@my-dejanews.com wrote:

: HI, I am working with access types and have a challenge at hand which I seem
: to be losing. Need some help. I have data in Non Volatile Memory and RAM that
: I need to access using access types. The problem is I need to have the same
: "types" to work on the data, ie compare them, calculate checksum, etc.

What you seem to mean is something like:

	package Memory is

	   type Memory_Type is abstract tagged
	      record
	         null; -- Put the data here
	      end record;

	   type Memory_Ptr is access Memory_Type'Class;

	   type ROM is new Memory_Type with null record;

	   type RAM is new Memory_Type with null record;
      
	end Memory;

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada

Re: Access types

[jsanchor]

Well, it's tip of the ice berg.
Package Memory has a subprogram

procedure Checksum(access_to_ram : access Memory_Type'class);--
primitive
--  operation

RAM is declared in another package.
And somebody trying to use checksum will say something like this:

package RAMS is
 type RAM_Type is new Memory.Memory_Type with null record;
 RAM: aliased RAM_Type;
 Memory.Checksum(RAM'access);

end RAMS;

Now my problem is: I want RAM'access to be the same type as Memory_Ptr because
of the nature of my program. But I just can't do it.
I tried casting it, like this
  Ptr_to_memory : Memory_Ptr;

  Ptr_to_memory : Memory_Ptr(access_to_ram); it compiled, but does not run.
Gives me a run time error....PROGRAM_ERROR.


--------------------------------------------------------------------
> What you seem to mean is something like:
>
> 	package Memory is
>
> 	   type Memory_Type is abstract tagged
> 	      record
> 	         null; -- Put the data here
> 	      end record;
>
> 	   type Memory_Ptr is access Memory_Type'Class;
>
> 	   type ROM is new Memory_Type with null record;
>
> 	   type RAM is new Memory_Type with null record;
>
> 	end Memory;
>
> --
> -- Jerry van Dijk  | email: jdijk@acm.org
> -- Leiden, Holland | member Team-Ada
>


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: Access types

[Jerry van Dijk]

jsanchor@my-dejanews.com wrote:

: Now my problem is: I want RAM'access to be the same type as Memory_Ptr because
: of the nature of my program. But I just can't do it.
: I tried casting it, like this
:   Ptr_to_memory : Memory_Ptr;

:   Ptr_to_memory : Memory_Ptr(access_to_ram); it compiled, but does not run.
: Gives me a run time error....PROGRAM_ERROR.

Sounds like Ptr_to_memory isn't actually pointing to something.

BTW I guess there is some specific reason why you are using type
extension instead of subtypes ?

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada

Access Types

[Ronald Ayoub]

For this line of code:

type File_Access is access constant File_Type;

I understand this to mean that File_Access points to a File_Type variable
which cannot be changed but the value pointed to can be changed. Is this
correct?

How would you specify that the value pointed to is constant? Would it be

type File_Access is constant access File_Type;

Would this specify that both semantic elements are constant

type File_Access is constant access constant File_Type;

Thanks.

Ron 

Re: Access Types

[Robert A Duff]

rayoub@wam.umd.edu (Ronald Ayoub) writes:

> For this line of code:
> 
> type File_Access is access constant File_Type;
>
> I understand this to mean that File_Access points to a File_Type variable
> which cannot be changed but the value pointed to can be changed. Is this
> correct?

Um, the thing pointed to *is* the File_Type variable.  Maybe this will help:

    type Pointer_To_Const is access constant Integer;
    type Pointer_To_Var   is access all      Integer;

    X: Pointer_To_Const := ...;
    Y: Pointer_To_Var := ...;

    Z: constant Pointer_To_Const := ...;
    W: constant Pointer_To_Var := ...;

    X.all := 1; -- Illegal.
    X := new Integer'(3); -- OK.
    Y.all := 1; -- OK.
    Y := new Integer'(3); -- OK.
    
    Z.all := 1; -- Illegal;
    Z := new Integer'(3); -- Illegal.
    W.all := 1; -- OK.
    W := new Integer'(3); -- Illegal.
    
    ...

X and Y are constants; Z and W are variables.

The objects Y and W point to are variables.
The objects X and Z point to might be constant or variable,
but they're read-only via X.all and Z.all.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Access Types

[Steve Folly]

Robert A Duff <bobduff@world.std.com> wrote in message
news:wcchfmxsy3y.fsf@world.std.com...
> rayoub@wam.umd.edu (Ronald Ayoub) writes:
>
>     type Pointer_To_Const is access constant Integer;
>     type Pointer_To_Var   is access all      Integer;
>
>     X: Pointer_To_Const := ...;
>     Y: Pointer_To_Var := ...;
>
>     Z: constant Pointer_To_Const := ...;
>     W: constant Pointer_To_Var := ...;
>
>     X.all := 1; -- Illegal.
>     X := new Integer'(3); -- OK.
>     Y.all := 1; -- OK.
>     Y := new Integer'(3); -- OK.
>
>     Z.all := 1; -- Illegal;
>     Z := new Integer'(3); -- Illegal.
>     W.all := 1; -- OK.
>     W := new Integer'(3); -- Illegal.
>
>     ...
>
> X and Y are constants; Z and W are variables.
>
> The objects Y and W point to are variables.
> The objects X and Z point to might be constant or variable,
> but they're read-only via X.all and Z.all.
>
> - Bob
> --
> Change robert to bob to get my real email address.  Sorry.

That makes perfect sense for declared variables. But what about subprogram
access type parameters.
For example, you can have...

    function Foo(Bar : access Object) return Boolean;

Which means the function takes an access to an Object variable.
The function is free to change the value of the variable that Bar 'points'
to.

What seems to be missing is something along the lines of...

    function Foo(Bar : access constant Object) return Boolean;

Which would imply that the function cannot change the variable the Bar
points to.

Why is this not included in the language definition. Is there an
alternative?



--
Regards,
Steve Folly -  Y2K compliant since 32nd Februark 1998
http://www.follysplace.demon.co.uk
donationsto:myaccount@mybank.co.uk

Re: Access Types

[Tucker Taft]

Steve Folly wrote:
> ... But what about subprogram
> access type parameters.
> For example, you can have...
> 
>     function Foo(Bar : access Object) return Boolean;
> 
> Which means the function takes an access to an Object variable.
> The function is free to change the value of the variable that Bar 'points'
> to.
> 
> What seems to be missing is something along the lines of...
> 
>     function Foo(Bar : access constant Object) return Boolean;
> 
> Which would imply that the function cannot change the variable the Bar
> points to.
> 
> Why is this not included in the language definition. 

Because it is largely redundant with "Bar : in Object".  If you
don't intend to update the pointed-to object, why not just
pass it "in"?

Be that as it may, I would also like to see "access constant" parameters
added in for orthogonality reasons, and because for certain tagged
types, essentially all of the primitive operations are most appropriately
written using access parameters.  This change will probably be included
in the next round of language enhancements, though there are no guarantees.
I would recommend the use of "in" in the interim.


> ... Is there an
> alternative?

"in"

> 
> --
> Regards,
> Steve Folly -  Y2K compliant since 32nd Februark 1998
> http://www.follysplace.demon.co.uk
> donationsto:myaccount@mybank.co.uk

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

access types

[Brian May]

Hello,

Ok, so maybe my Ada is rusty.


However, I had a situation where I want to do the following:

=== cut ===
package a is

        type X is tagged private;

        ...

        type X_reference is access X'class;

        ...

        type Y is new X with private;
        procedure do_stuff(my_object : in out Y);

        ...

        type Y_reference is access Y'Class;

        ...
end a

package b is
        procedure save_reference(my_object : in X_reference);
end b;

and I want to be able to do:

declare
        U : Y_reference;
        V : X_reference;
begin
        U := new Y;
        do_stuff(U.all);

        V := U;
        save_reference(V); 
end;
=== cut ===

notes:

- do_stuff is not defined for X only Y, so I can't skip the
Y_reference and go straight to a X_reference.

- not compiled; but hopefully understandable


The problem is the 2nd last instruction (V := U) won't compile, as the
compiler complains it is not possible to convert a Y_Reference to a
X_Reference;

Is it possible to convert a Y_reference to a X_reference?

As the X_reference can access X'Class, which presumable includes
Y'Class, I thought it should be possible somehow, without creating a
separate copy of the object.

(yes, maybe it would be ideal if I didn't need so many access types,
however these objects need to be referenced from multiple objects and
access types would seem the most natural solution).


Thanks.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: access types

[Robert A Duff]

Brian May <bam@snoopy.apana.org.au> writes:

>         V := U;

Try V := U.all'Access.

- Bob

Re: access types

[Dmitry A. Kazakov]

On Sat, 30 Jun 2007 21:54:15 -0400, Robert A Duff wrote:

> Brian May <bam@snoopy.apana.org.au> writes:
> 
>>         V := U;
> 
> Try V := U.all'Access.

No, that won't work, because the access types are pool-specific. It is a
nasty problem one has to fight all the way when dealing with tagged types
and pool-specific access types.

Sorry, Brian, you probably have to resort to Unchecked_Conversion or else
add "all" to your access types.

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

Re: access types

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 30 Jun 2007 21:54:15 -0400, Robert A Duff wrote:
>
>> Brian May <bam@snoopy.apana.org.au> writes:
>> 
>>>         V := U;
>> 
>> Try V := U.all'Access.
>
> No, that won't work, because the access types are pool-specific.

Ah, thanks, I missed that.

>... It is a
> nasty problem one has to fight all the way when dealing with tagged types
> and pool-specific access types.
>
> Sorry, Brian, you probably have to resort to Unchecked_Conversion or else
> add "all" to your access types.

"Doctor, it hurts when I forget 'all'."

"So don't do that."

;-)

Access-to-classwide should normally use "all".
In fact, you won't go too far wrong if you always say "all"
for all named access-to-variable types.

Unch_Conv is not the right solution, here!

- Bob

Re: access types

[Dmitry A. Kazakov]

On Sun, 01 Jul 2007 10:57:17 -0400, Robert A Duff wrote:

> Access-to-classwide should normally use "all".
> In fact, you won't go too far wrong if you always say "all"
> for all named access-to-variable types.

I appreciate storage pools too much to agree with that. There are so many
interesting things we can do with pools, multiple inheritance for example!
(:-))

I could never understand why explicit conversion is not allowed for
pointers from the same pool.

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

Re: access types

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 01 Jul 2007 10:57:17 -0400, Robert A Duff wrote:
>
>> Access-to-classwide should normally use "all".
>> In fact, you won't go too far wrong if you always say "all"
>> for all named access-to-variable types.
>
> I appreciate storage pools too much to agree with that. There are so many
> interesting things we can do with pools, multiple inheritance for example!
> (:-))

OK, I'll bite.  ;-)

How do you do multiple inheritance with pools?

Anyway, "all" does not stop you from using pools.

> I could never understand why explicit conversion is not allowed for
> pointers from the same pool.

Well, that might make sense, but we never thought of that.
"Pool specific" is somewhat of a misnomer.  It really just
means "Ada 83-style access type".

- Bob

Re: access types

[Dmitry A. Kazakov]

On Sun, 01 Jul 2007 20:12:23 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 01 Jul 2007 10:57:17 -0400, Robert A Duff wrote:
>>
>>> Access-to-classwide should normally use "all".
>>> In fact, you won't go too far wrong if you always say "all"
>>> for all named access-to-variable types.
>>
>> I appreciate storage pools too much to agree with that. There are so many
>> interesting things we can do with pools, multiple inheritance for example!
>> (:-))
> 
> OK, I'll bite.  ;-)
> 
> How do you do multiple inheritance with pools?

Normally one would emulate MI with a mix-in:

type M (Base1 : access B1; Base2 : access B2) is new B3 with private;

The idea is to allocate M in a user pool. The pool would route Allocate and
Deallocate to the standard pool, but doing that Allocate would also reserve
some space for the instances of B1 and B2 in front of the object. M becomes
a pointer. Discriminants can eventually be removed if there is a way to
determine the addresses of B1 and B2 from a pointer (address) to B3.

This is of course a poor man's MI. But it works nicely for some things. For
example I used it for multiple doubly-linked lists of anything. An object
can stay in as many lists one could wish. For each list a record with Prev
and Next pointers is added when the object gets allocated in the pool.
Items of lists are accessed via plain access type, no further redirection
needed, no problem with unconstrained arrays as list items. Write "new
Thing", and the work is done.

> Anyway, "all" does not stop you from using pools.

In some cases it does. access all T is sort of doubly-dispatching. One of
its classes is T'Class, another is Root_Storage_Pool'Class.

The problem is that the second class is not available. We cannot define new
primitive operations which would dispatch on the pointer according to the
specific pool. Only Allocate and Deallocate would.

>> I could never understand why explicit conversion is not allowed for
>> pointers from the same pool.
> 
> Well, that might make sense, but we never thought of that.
> "Pool specific" is somewhat of a misnomer.  It really just
> means "Ada 83-style access type".

They fit nicely into Ada's OO model, as I described above. Maybe it was an
unexpected by-product. Which shows the strength of Ada's fundamentals.

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

Re: access types

[Adam Beneschan]

On Jul 1, 7:57 am, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> writes:
>
> > On Sat, 30 Jun 2007 21:54:15 -0400, Robert A Duff wrote:
>
> >> Brian May <b...@snoopy.apana.org.au> writes:
>
> >>>         V := U;
>
> >> Try V := U.all'Access.
>
> > No, that won't work, because the access types are pool-specific.
>
> Ah, thanks, I missed that.
>
> >... It is a
> > nasty problem one has to fight all the way when dealing with tagged types
> > and pool-specific access types.
>
> > Sorry, Brian, you probably have to resort to Unchecked_Conversion or else
> > add "all" to your access types.
>
> "Doctor, it hurts when I forget 'all'."
>
> "So don't do that."
>
> ;-)
>
> Access-to-classwide should normally use "all".
> In fact, you won't go too far wrong if you always say "all"
> for all named access-to-variable types.

In fact, if I'm interpreting the manual correctly, once you add "all"
to the access types, then the type conversion should be legal:

   V := X_Reference(U);

[Technically, only X_Reference has to be "access all" for this to be
legal, but you should do this for both access types anyway.]

                          -- Adam