Access types and classwide programming

Access types and classwide programming

[chris.danx]

Hi,

Suppose that there is a package X , with the following body

package X is

    type xxx is tagged private;
    type xxx_access is access all xxx;
    type xxx_class_access is access all xxx'class;

    procedure init (s : out xxx);

    function get_something (sc : in xxx_class_access)
    return integer;

private
    ...

end X;

Now you want to test it, but there's a probem.
I've tried

with x; use x;
with ada.integer_text_io; use ada.integer_text_io;

procedure test_x is

    temp : aliased xxx;

begin
    init (temp);    -- this is ok!

    put( get_something(temp'access)); -- error 1 here
end x;


error 1 is "non-local pointer cannot point to local object"

I've tried lot's of different ways, (temp wasn't aliased the first run and
this lead to an error too).

What I want to do is to have a variable of type xxx and to pass it to
get_something and to init.

I'm probably not explaining this properly, hang on...


Suppose you have a tagged type ttype, and need an access type to ttype and
it's class.

type ttype is tagged ...;
type ttype_access is access all ttype;
type ttype_caccess is access all ttype;

How do you

a) get "access" to a variable of ttype?
b) create a new instance of a ttype which is pointed to by a variable of
type ttype_caccess?

I'm still not explaining it proper, am I?  I'm confused.


This is for a program which *in future* will use address to access
conversions (for hardware programming), so it has to be access types.  It's
not neccessary for it to use address to access conversions as no hardware
access is necessary at this point but it will do in the future.

Thanks,
Chris

Re: Access types and classwide programming

[chris.danx]

I unconfused myself, so to speak.

I used x.all'access to convert from xxx_access to xxx_class_access (haven't
tested it the otherway, but I assume it works), and just used xxx_access
with an allocation for a variable!  Now it's all sorted...


Bye,
Chris

[Different Topic] Endianess?

[chris.danx]

How could one detect Endianess with Ada 95?

I've seen some C snippets which exploit C arrays, but can see no obvious
mapping to Ada 95.  The C snippet says that for a union of a number and an
array of 4 bytes, setting the number to one will have a one in the zeroth
byte of the array for little endian, and zero for a big endian.  How do I
map this to Ada?  Use an unchecked conversion perhaps?

Is there another portable (simpler) way?


Thanks,
Chris

Re: [Different Topic] Endianess?

[Jeffrey Carter]

"chris.danx" wrote:
> 
> How could one detect Endianess with Ada 95?
> 
> I've seen some C snippets which exploit C arrays, but can see no obvious
> mapping to Ada 95.  The C snippet says that for a union of a number and an
> array of 4 bytes, setting the number to one will have a one in the zeroth
> byte of the array for little endian, and zero for a big endian.  How do I
> map this to Ada?  Use an unchecked conversion perhaps?
> 
> Is there another portable (simpler) way?

One way is to use System.Default_Bit_Order. Although technically not the
same as endianness, in practice the two are related.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail

Re: [Different Topic] Endianess?

[Juanma Barranquero]

On Sun, 16 Sep 2001 00:42:36 +0100, "chris.danx"
<chris.danx@ntlworld.com> wrote:

>How could one detect Endianess with Ada 95?

<snip>

> How do I map this to Ada?  Use an unchecked conversion perhaps?

More or less. I've been doing:

   type Byte_Order is (Little_Endian, Big_Endian);

   Default_Byte_Order : Byte_Order;

   type Word is mod 2 ** 32;
   subtype Chr4 is String (1..4);

   function UC is new Unchecked_Conversion(Word, Chr4);

   Test_Word : constant Word := 16#33323130#;
   Test_Chr4 : constant Chr4 := "0123";

   -- ...

   if UC(Test_Word) = Test_Chr4 then
      Default_Byte_Order := Little_Endian;
   else
      Default_Byte_Order := Big_Endian;
   end if;


                                                       /L/e/k/t/u

Assigning the value of a deferred constant?

[Juanma Barranquero]

On Mon, 17 Sep 2001 09:37:43 +0200, Juanma Barranquero
<lektu@terra.es> wrote:

>More or less. I've been doing:
>
>   type Byte_Order is (Little_Endian, Big_Endian);
>
>   Default_Byte_Order : Byte_Order;

And vaguely related: Is there any way to declare a deferred constant
and assign its value in the body of the declaring package, during
elaboration? Something like:

  package Test is

     pragma Elaborate_Body;

     type Byte_Order is (Little_Endian, Big_Endian);
     Default_Byte_Order : constant Byte_Order;

  private

     Machine_Order : Byte_Order := Big_Endian;

     Default_Byte_Order : constant Byte_Order := Machine_Order;
     for Default_Byte_Order'Address use Machine_Order'Address;

  end Test;


  with Unchecked_Conversion;

  package body Test is

     type Word is mod 2 ** 32;
     subtype Chr4 is String (1..4);

     function UC is new Unchecked_Conversion(Word, Chr4);

     Test_Word : constant Word := 16#33323130#;
     Test_Chr4 : constant Chr4 := "0123";

  begin
     if UC(Test_Word) = Test_Chr4 then
        Machine_Order := Little_Endian;
     else
        Machine_Order := Big_Endian;
     end if;
  end Test;


That's not working (on Windows, with GNAT 3.13p), but I don't know if
it should or shouldn't :(

I know I could have different bodies for different architectures, or
just substitute a function for the deferrent constant, doing instead:

  function Default_Byte_Order returns Byte_Order;
  pragma Inline(Default_Byte_Order);

or something similar. But the question remains: Is there an easy
and/or portable way to have a public constant view of a private
variable?

Thanks,

                                                       /L/e/k/t/u

Re: Assigning the value of a deferred constant?

[Ted Dennison]

In article <d7abqt09p6i75u5nf014dbge4o11a0534r@4ax.com>, Juanma Barranquero
says...
>
>On Mon, 17 Sep 2001 09:37:43 +0200, Juanma Barranquero
><lektu@terra.es> wrote:
>
>>More or less. I've been doing:
>>
>>   type Byte_Order is (Little_Endian, Big_Endian);
>>
>>   Default_Byte_Order : Byte_Order;
>
>And vaguely related: Is there any way to declare a deferred constant
>and assign its value in the body of the declaring package, during
>elaboration? Something like:


Sure. Declare it as a function instead of a constant.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Assigning the value of a deferred constant?

[Juanma Barranquero]

On Mon, 17 Sep 2001 14:04:43 GMT, Ted Dennison<dennison@telepath.com>
wrote:

>Sure. Declare it as a function instead of a constant.

From my previous message:

>I know I could have different bodies for different architectures, or
>just substitute a function for the deferrent constant, doing instead:
>
>  function Default_Byte_Order returns Byte_Order;
>  pragma Inline(Default_Byte_Order);

so I'd dare to say I had thought of that solution.

I'm not discussing whether what I try to do is elegant, efficient or
good from a software engineering point of view. I'm just asking if it
is posible or not in Ada. I seem to remember that Barnes' book
"Programming in Ada 95" discussed at some point the posibility of
having a constant view of a private variable, but I cannot find it
anymore, so I must be misremembering.

Still, it is posible?

Thanks,
                                                       /L/e/k/t/u

Re: Assigning the value of a deferred constant?

[tmoran]

>is posible or not in Ada. I seem to remember that Barnes' book
  You can't elaborate the body before you're done elaborating the
spec, but you can elaborate a different package, including its body.
Borrowing from Barnes p. 258 discussion of pragma Elaborate,

  package Early is
    function Is_Big_Endian return Boolean;
  end Early;
  package body Early is
    function Is_Big_Endian return Boolean is ...
  end Early;


  with Early;
  pragma Elaborate(Early);
  package Test is

     type Byte_Order is (Little_Endian, Big_Endian);
     Default_Byte_Order : constant Byte_Order;

  private

     Default_Byte_Order : constant Byte_Order
       := Byte_Order'val(Boolean'pos(Early.Is_Big_Endian));

  end Test;

Re: Assigning the value of a deferred constant?

[Juanma Barranquero]

On Mon, 17 Sep 2001 17:36:05 GMT, tmoran@acm.org wrote:

>  You can't elaborate the body before you're done elaborating the
>spec, but you can elaborate a different package, including its body.

Yes, that's a solution, but still it is strange to be forced to use
another package just to initialize the constant.

After all, it is not (entirely) a matter of elaboration. If in my
example I do:

  package Test is

     pragma Elaborate_Body(Test);

     type Byte_Order is (Little_Endian, Big_Endian);
     Default_Byte_Order : Byte_Order;

  end Test;

  package body Test is
     -- whatever
  begin
     -- Default_Byte_Order assigned here
  end Test;

i.e., I substitute a variable for the deferred constant, it works as
expected. So I suppose that what I was really asking is why

  V : T;
  C : constant T := V;
  for C'Address use V'Address;

does not make C a constant view of V. Surprisingly, I've done some
more tests (with GNAT 3.13p) and it *does* make C a constant view of
V... if done in the public part of the package. So:

  package Test is
     -- other things

     Machine_Order : Byte_Order := Big_Endian;
     Default_Byte_Order : constant Byte_Order := Machine_Order;
     for Default_Byte_Order'Address use Machine_Order'Address;

  end Test;

works (at the cost of making the variable public and so allowing the
back-door modification of Default_Byte_Order), but

  package Test is
     -- other things

     Default_Byte_Order : constant Byte_Order;

  private

     Machine_Order : Byte_Order := Big_Endian;
     Default_Byte_Order : constant Byte_Order := Machine_Order;

     for Default_Byte_Order'Address use Machine_Order'Address;

  end Test;

does not. The only differences are that Default_Byte_Order is now
deferred and Machine_Order is private. Is that an implementation
issue, or the semantics intended by the ARM? I'm pretty confused right
now :)

Thanks,

                                                      /L/e/k/t/u

Re: Assigning the value of a deferred constant?

[Richard Riehle]

Ted Dennison wrote:

> In article <d7abqt09p6i75u5nf014dbge4o11a0534r@4ax.com>, Juanma Barranquero
> says...
>
> >And vaguely related: Is there any way to declare a deferred constant
> >and assign its value in the body of the declaring package, during
> >elaboration? Something like:
>
> Sure. Declare it as a function instead of a constant.

Ted makes an important point.   Except for limited types, deferred constants
should be promoted to functions.   In fact, it seems this is now a good policy
for most named numbers and declared values.   This leverages one of the
more powerful aspects of Ada:  the ability to defer the implementation of
a value to the body of a package.   It also goes a long way towared satisfying
the principle of referential transparency.

Richard Riehle
richard@adaworks.com

Re: Assigning the value of a deferred constant?

[Vincent Marciante]

Richard Riehle wrote:
> 
> Ted Dennison wrote:
> 
> > In article <d7abqt09p6i75u5nf014dbge4o11a0534r@4ax.com>, Juanma Barranquero
> > says...
> >
> > >And vaguely related: Is there any way to declare a deferred constant
> > >and assign its value in the body of the declaring package, during
> > >elaboration? Something like:
> >
> > Sure. Declare it as a function instead of a constant.
> 
> Ted makes an important point.   Except for limited types, deferred constants
> should be promoted to functions.   In fact, it seems this is now a good policy
> for most named numbers and declared values.   This leverages one of the
> more powerful aspects of Ada:  the ability to defer the implementation of
> a value to the body of a package.   It also goes a long way towared satisfying
> the principle of referential transparency.
> 
> Richard Riehle
> richard@adaworks.com

But a deferred contant might be completed by a static expression,
making its use legal in more places than where a function call is legal
-
right?

Vinny

Re: Assigning the value of a deferred constant?

[Juanma Barranquero]

On Tue, 18 Sep 2001 11:40:57 -0700, Richard Riehle
<richard@adaworks.com> wrote:

>Ted makes an important point.

Sure.

But I still don't know if what I tried to do (regardless of how
appropriate it is) can be done or not.

                                                     /L/e/k/t/u

Re: Access types and classwide programming

[Jeffrey Carter]

"chris.danx" wrote:
> 
> This is for a program which *in future* will use address to access
> conversions (for hardware programming), so it has to be access types.  It's
> not neccessary for it to use address to access conversions as no hardware
> access is necessary at this point but it will do in the future.

Frequently, address clauses are a better approach to hardware
programming than address to access conversions.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail

Re: Access types and classwide programming

[chris.danx]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3BA4447B.66842AB0@acm.org...
> "chris.danx" wrote:
> >
> > This is for a program which *in future* will use address to access
> > conversions (for hardware programming), so it has to be access types.
It's
> > not neccessary for it to use address to access conversions as no
hardware
> > access is necessary at this point but it will do in the future.
>
> Frequently, address clauses are a better approach to hardware
> programming than address to access conversions.

Do you mean

    type X is something;
    For x'address use blah;

I'm afraid I'm quite new to Ada hardware programming, having never done any,
but hoping to do some soon.  Perhaps there is something I can program to
gain minimal familiarity with it.  Any suggestions?  (PC with Win9x)


The problem is the development of file systems, without relying on a
hardware driver for the moment.  To solve this I'm in the process of
creating a basic 'disk driver' kit that creates an fs as a file on an
existing fs, which it is hoped, will allow a hardware driver to be developed
and 'dropped in'.  This means all you need to do is extend the type
disk_driver, fill in the operations that any disk_driver must support, set
the driver for the disk and away you go.  That's the dream anyway and
there'll probably be (lots of) problems along the way.

It's basically to give this Ada OS thingy that ppl keep talking about a kick
in the right direction, though I doubt it'll stop endless 'discussion' which
will likely kill it before it begins.  It should also work with my own OS
whenever that comes about (I've got to much to do with other things, this
being a welcome distraction from them).  I'm probably going to start with
FAT12, then FAT16, then FAT32 and onto the Linux/Unix FSes (time
permitting).



Chris

Re: Access types and classwide programming

[Jeffrey Carter]

"chris.danx" wrote:
> 
> "Jeffrey Carter" <jrcarter@acm.org> wrote in message
> news:3BA4447B.66842AB0@acm.org...
> >
> > Frequently, address clauses are a better approach to hardware
> > programming than address to access conversions.
> 
> Do you mean
> 
>     type X is something;
>     For x'address use blah;

Yes, that is an address clause for X.

> 
> I'm afraid I'm quite new to Ada hardware programming, having never done any,
> but hoping to do some soon.  Perhaps there is something I can program to
> gain minimal familiarity with it.  Any suggestions?  (PC with Win9x)

Hardware programming for Win32 is somewhat complicated. A better
approach would be to start with a simple OS, such as DOS; it might be
possible to simulate this using a DOS compiler and running in a DOS box
under Win32. Something I did once involved direct access to the text
screen memory. Having defined a type for the screen memory, I could do
things such as

Display : Screen_Memory;
for Display'Address use ...;

Buffer : Screen_Memory;

-- Create desired image in Buffer

Display := Buffer;

or

Buffer := Display; -- Save current screen image

-- Output to screen

Display := Buffer; -- Restore saved image

This was the sort of thing I did for an overlapping text-windowing
system, in which I kept a stack of screen images and associated
information. Before a window was created, I would make a copy of the
screen and push it on the stack. When the current window was closed, I
would pop the top image off the stack and copy it to the screen.

I have also used address clauses to directly manipulate a VGA card to do
color graphics under DOS. Now we can use things like GtkAda to achieve
the same thing more portably.

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail

Re: Access types and classwide programming

[David C. Hoos, Sr.]

Address clauses apply only to an object, program unit, or label --
not to a type.

----- Original Message -----
From: "Jeffrey Carter" <jrcarter@acm.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: September 16, 2001 11:49 AM
Subject: Re: Access types and classwide programming


"chris.danx" wrote:
>
> "Jeffrey Carter" <jrcarter@acm.org> wrote in message
> news:3BA4447B.66842AB0@acm.org...
> >
> > Frequently, address clauses are a better approach to hardware
> > programming than address to access conversions.
>
> Do you mean
>
>     type X is something;
>     For x'address use blah;

Yes, that is an address clause for X.

>
> I'm afraid I'm quite new to Ada hardware programming, having never done any,
> but hoping to do some soon.  Perhaps there is something I can program to
> gain minimal familiarity with it.  Any suggestions?  (PC with Win9x)

Hardware programming for Win32 is somewhat complicated. A better
approach would be to start with a simple OS, such as DOS; it might be
possible to simulate this using a DOS compiler and running in a DOS box
under Win32. Something I did once involved direct access to the text
screen memory. Having defined a type for the screen memory, I could do
things such as

Display : Screen_Memory;
for Display'Address use ...;

Buffer : Screen_Memory;

-- Create desired image in Buffer

Display := Buffer;

or

Buffer := Display; -- Save current screen image

-- Output to screen

Display := Buffer; -- Restore saved image

This was the sort of thing I did for an overlapping text-windowing
system, in which I kept a stack of screen images and associated
information. Before a window was created, I would make a copy of the
screen and push it on the stack. When the current window was closed, I
would pop the top image off the stack and copy it to the screen.

I have also used address clauses to directly manipulate a VGA card to do
color graphics under DOS. Now we can use things like GtkAda to achieve
the same thing more portably.

--
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail
_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: Access types and classwide programming

[Jeffrey Carter]

"David C. Hoos, Sr." wrote:
> 
> Address clauses apply only to an object, program unit, or label --
> not to a type.
> 
> ----- Original Message -----
> From: "Jeffrey Carter" <jrcarter@acm.org>
> Newsgroups: comp.lang.ada
> "chris.danx" wrote:
> >
> > "Jeffrey Carter" <jrcarter@acm.org> wrote in message
> > news:3BA4447B.66842AB0@acm.org...
> > >
> > > Frequently, address clauses are a better approach to hardware
> > > programming than address to access conversions.
> >
> > Do you mean
> >
> >     type X is something;
> >     For x'address use blah;
> 
> Yes, that is an address clause for X.

Oops! I hate to make silly mistakes like that in public. I looked at the
address clause for X and ignored X's definition.

That would be an address clause for X, if X were an object. Instead, you
need to say

V : X;
for V'Address use Blah;

This is what I did in the rest of my post, which I hope doesn't have any
more silly mistakes.

Sorry.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: Access types and classwide programming

[tmoran]

>   For x'address use blah;
> ...
> (PC with Win9x)
  You're barking up the wrong tree if you start worrying about address
clauses for an OS on x86 machines - they use IO instructions, not memory
mapped IO.

Re: Access types and classwide programming

[Ted Dennison]

In article <qpfp7.15438$L%5.12873076@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>
>>   For x'address use blah;
>> ...
>> (PC with Win9x)
>  You're barking up the wrong tree if you start worrying about address
>clauses for an OS on x86 machines - they use IO instructions, not memory
>mapped IO.

Now I'm just getting into this, so correct me if I'm wrong, but isn't I/O to the
PCI bus done almost entirely with memory mapped addresses and interrupts?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Access types and classwide programming

[tmoran]

> procedure test_x is
>
>     temp : aliased xxx;
>
> begin
>     init (temp);    -- this is ok!
>
>     put( get_something(temp'access)); -- error 1 here
> end x;
>
> error 1 is "non-local pointer cannot point to local object"
  Suppose function get_something put a copy of its parameter into a
global variable.  After exiting text_x, that global would be a pointer
to ???  Thus the error message.  There are two solutions: define
get_something to take as parameter a type which is declared inside
of text_x, in which case clearly no global could exist for get_something
to set, or else else temp'unchecked_access, thus telling the compiler
"I know this is dangerous but I've looked carefully and it's OK here".

> What I want to do is to have a variable of type xxx and to pass it to
> get_something and to init.
  The "init" case already works fine.  Why not change get_something to
    function get_something (sc : in xxx'class)
    return integer;
thus getting rid of the access type and the problem.

Suppose you have a tagged type ttype, and need an access type to ttype and
it's class.

> type ttype is tagged ...;
> type ttype_access is access all ttype;
> typ ttype_caccess is access all ttype'class;  -- [surely you meant this]
>
> How do you
>
> a) get "access" to a variable of ttype?
  x : aliased ttype;
  p : ttype_access;
  ...
  p := x'access;
  p := new ttype;

> b) create a new instance of a ttype which is pointed to by a variable of
> type ttype_caccess?
  y : aliased ttype;
  p : ttype_caccess;
  ...
  p := x'access;
  p := new ttype;

Re: Access types and classwide programming

[John McCabe]

On Sat, 15 Sep 2001 20:36:35 +0100, "chris.danx"
<chris.danx@ntlworld.com> wrote:

<..snip..>

>    put( get_something(temp'access)); -- error 1 here
>end x;

>error 1 is "non-local pointer cannot point to local object"

Have you tried 'Unchecked_Access?