Re: Implementing pointers to pointers in Ada

Re: Implementing pointers to pointers in Ada

[Mark A Biggar]

In article <Pine.GSO.3.93.960909230243.7142A-100000@firefly.sd.monash.edu.au> Vasilios Tourloupis <vasilios@insect.sd.monash.edu.au> writes:
>Dear Ada users,
>As the title suggests, how would I go about implementing pointers to
>pointers in Ada?
>For example, I have declared the following variable in C:
>    unsigned **a;
>How would this be expressed in Ada terms?

type unisgned is ... ;
type u_ptr is access all unsigned;
type u_ptr_ptr is access all u_ptr;

a: u_ptr_ptr;

But, as ** variables in C a most often used to walk through C arrays of
pointer with ++, and you just don't manipulate arrays in Ada that way, such
declarations almost never appear in Ada programs. It usually makes more
sense (if translating a C algorithm to Ada) to redesign the algorithm to use
array indexing, then to emulate the C double indirection.

--
Mark Biggar
mab@wdl.lmco.com

Re: Implementing pointers to pointers in Ada

[Jonas Nygren]

Vasilios Tourloupis wrote:
> 
> Dear Ada users,
> 
> As the title suggests, how would I go about implementing pointers to
> pointers in Ada?
> 
> For example, I have declared the following variable in C:
> 
>     unsigned **a;

I think this will work:

with Interfaces;
subtype unsigned is Interfaces.Unsigned_32;
type unsigned_ref is access all unsigned;
type ref_unsigned_ref is access all unsigned_ref;

> 
> How would this be expressed in Ada terms?
> 
> Thanx in advance,
> 
> Bill Tourloupis
> +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
> | Vasilios E. Tourloupis             | vasilios@insect.sd.monash.edu.au |
> | Dept. of Software Development      | vasilios@hestia.sd.monash.edu.au |
> | Monash University,                 |                /\                |
> | Caulfield East, Vic., 3145         |___________/\  /  \_______________|
> | Australia                          |             \/                   |
> +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
> | Disclaimer: There are some that call me Bill!  But I don't know why?  |
> +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

Re: Implementing pointers to pointers in Ada

[John Herro]

Vasilios Tourloupis <vasilios@insect.sd.monash.edu.au> asks:
> unsigned **a;
> How would this be expressed in Ada?

with Interfaces;
...
   type P is access Interfaces.Unsigned_32;
   type P2 is access P;
   A : P2;

Of course, it's not obvious WHY you want to use two levels of indirection.
 Sometimes, instead of directly translating C to Ada, it's better to think
the problem through again, and see if Ada offers a better way of solving
the problem.  In general, Ada has a LOT less need of pointers (access
types) than C.
- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor

Re: Implementing pointers to pointers in Ada

[Norman H. Cohen]

In article <Pine.GSO.3.93.960909230243.7142A-100000@firefly.sd.monash.edu.au>,
Vasilios Tourloupis <vasilios@insect.sd.monash.edu.au> writes: 

|> For example, I have declared the following variable in C: 
|>
|>     unsigned **a;
|>
|> How would this be expressed in Ada terms?

   type Unsigned is mod 2**Integer'Size;  -- or whatever you choose
   type Pointer_To_Unsigned is access all Unsigned;
   type Pointer_to_Pointer_To_Unsigned is access all Pointer_To_Unsigned;

   A: Pointer_To_Pointer_To_Unsigned;

Are you sure you need pointer-to-pointer-to unsigned?  In particular, if
you are writing a procedure intended to set a Pointer_To_Unsigned
variable, you can pass that variable itself as a Pointer_To_Unsigned
parameter of mode out or in out, rather than passing a pointer to that
variable as a Pointer_To_Pointer_To_Unsigned parameter.

--
Norman H. Cohen    ncohen@watson.ibm.com

Implementing pointers to pointers in Ada

[Vasilios Tourloupis]

Dear Ada users,

As the title suggests, how would I go about implementing pointers to
pointers in Ada?

For example, I have declared the following variable in C:

    unsigned **a;

How would this be expressed in Ada terms?

Thanx in advance,

Bill Tourloupis
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Vasilios E. Tourloupis             | vasilios@insect.sd.monash.edu.au |
| Dept. of Software Development      | vasilios@hestia.sd.monash.edu.au |
| Monash University,                 |                /\                |
| Caulfield East, Vic., 3145         |___________/\  /  \_______________|
| Australia                          |             \/                   | 
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Disclaimer: There are some that call me Bill!  But I don't know why?  |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

Re: Implementing pointers to pointers in Ada

[Samuel Tardieu]

>>>>> "Vasilios" == Vasilios Tourloupis
>>>>> <vasilios@insect.sd.monash.edu.au> writes:

Vasilios> Dear Ada users, As the title suggests, how would I go about
Vasilios> implementing pointers to pointers in Ada?

Vasilios> For example, I have declared the following variable in C:
Vasilios>     unsigned **a;
Vasilios> How would this be expressed in Ada terms?

If you have a type called Unsigned, you may do (note the need of
declaring new types):

  type Unsigned_Access is access all Unsigned;
  type Unsigned_Access_Access is access all Unsigned_Access;

  A : aliased Unsigned_Access_Access;

 Sam
-- 
  Samuel Tardieu -- sam@ada.eu.org

Re: Implementing pointers to pointers in Ada

[David Shochat]

John Herro wrote:

> Of course, it's not obvious WHY you want to use two levels of indirection.

It was necessary for 68K Mac programming (I don't know about PPC). The
OS had to be able to move heap objects around whenever memory got tight,
so the programmer would access most GUI objects through a so-called
"handle" which was a pointer to a "master" pointer to the actual data.
In Meridian's Ada for the Mac, this was declared just as the examples in
this thread show (without the "all" -- it was Ada 83). This scheme was
crucial to allow the original Mac to run with only 128K. This scheme is
actually much older than the Mac.
-- David

Re: Implementing pointers to pointers in Ada

[Robert A Duff]

In article <512mt3$ret@goodnews.voicenet.com>,
John Demby <jdemby@voicenet.com> wrote:
>Vasilios Tourloupis <vasilios@insect.sd.monash.edu.au> wrote:
>
>>Dear Ada users,
>
>>As the title suggests, how would I go about implementing pointers to
>>pointers in Ada?
>>For example, I have declared the following variable in C:
>>    unsigned **a;
>>How would this be expressed in Ada terms?
>
>in general :
>
>type unsigned is blah;
>type unsigned_star is access unsigned;
>type unsigned_star_star is access unsigned_star;

Several people have suggested this, but I think it's highly unlikely to
be the answer the original poster is looking for.  In C, "unsigned **a"
means you're dealing with a pointer-to-pointer-to-unsigned, or a
pointer-to-array-of-unsigned, or an array-of-pointers-to-unsigned.  We
can't tell which it is, without knowing whether the code does a++ or
(*a)++ or whatever.  Or without knowing where the value of a comes from.

In any case, the "equivalent" Ada probably involves an array type, since
Ada has two separate features -- access types and arrays -- where C has
a single feature (pointers, which can point at single objects, or can
point at the first element of an array, or the middle of an array).
(Well, that's an oversimplification -- in C, arrays and pointers are not
*quite* the same thing, but they are in many circumstances, which is
quite confusing.)

Alternatively, maybe the "unsigned **a" is being used as a parameter.
If so, then the equivalent Ada probably involves an in-out parameter.

Perhaps the original poster can post more context, so we can see what
SORT of C pointers are being used, and advise whether they should
translate into arrays or in-out parameters, or whatever.

In Ada, I think I use access-to-access types approximately once per
decade, so I really don't think that's likely to be the right answer.

- Bob

Re: Implementing pointers to pointers in Ada

[John Demby]

Vasilios Tourloupis <vasilios@insect.sd.monash.edu.au> wrote:

>Dear Ada users,

>As the title suggests, how would I go about implementing pointers to
>pointers in Ada?
>For example, I have declared the following variable in C:
>    unsigned **a;
>How would this be expressed in Ada terms?

in general :

type unsigned is blah;
type unsigned_star is access unsigned;
type unsigned_star_star is access unsigned_star;

if you really need to make a pointer to a pointer to an unsigned
the package interfaces.c should have an type which is equivalent
to C's unsigned.

happy computing

John

Re: Implementing pointers to pointers in Ada

[Larry Kilgallen]

In article <3235E2C3.636F@itg-sepg.logicon.com>, David Shochat <shochat@itg-sepg.logicon.com> writes:
> John Herro wrote:
> 
>> Of course, it's not obvious WHY you want to use two levels of indirection.
> 
> It was necessary for 68K Mac programming (I don't know about PPC). The
> OS had to be able to move heap objects around whenever memory got tight,
> so the programmer would access most GUI objects through a so-called
> "handle" which was a pointer to a "master" pointer to the actual data.
> In Meridian's Ada for the Mac, this was declared just as the examples in
> this thread show (without the "all" -- it was Ada 83). This scheme was
> crucial to allow the original Mac to run with only 128K. This scheme is
> actually much older than the Mac.

I would _hope_ that Macintosh Ada 95 implementations would make
details of the handle mechanism _private_, since many mistakes
one can make involve saving a copy of the middle pointer when
the handle is not locked.

This is _exactly_ the sort of situation where higher level
languages can help, and Ada has the syntax to do it.

Larry Kilgallen

Re: Implementing pointers to pointers in Ada

[Dr. John B. Matthews]

In article <3235E2C3.636F@itg-sepg.logicon.com>, David Shochat <shochat@itg-sepg.logicon.com> writes:

> John Herro wrote:
>> Of course, it's not obvious WHY you want to use two levels of indirection.

> It was necessary for 68K Mac programming (I don't know about PPC). The
> OS had to be able to move heap objects around whenever memory got tight,
> so the programmer would access most GUI objects through a so-called
> "handle" which was a pointer to a "master" pointer to the actual data.

MacOS on PPC uses the same interface for memory management as 68K,
although the implementation has changed considerably:-) I recently
had the pleasure of working on MacOS bindings for GNAT on MacOS
with MachTen. The bindings rely extensively on declarations such as

   type ObjectRec is 
      record
         ...
      end record;
   type ObjectPtr is access ObjectRec;
   type ObjectHdl is access ObjectPtr;

The ObjectHdl.all.all syntax looks strange at first, but MacOS
programmers at a recent trade show seemed to have no trouble
following the sample code we showed them.

John
----------------------------------------------------------------
Dr. John B. Matthews
jmatthews@nova.wright.edu; john_matthews@ccmail.dayton.saic.com
"Whom the gods would destroy, they first invite to program in C"

Better MacOS Handles through Ada (was: Implementing Pointers to Pointe

[Larry Kilgallen]

In article <1996Sep12.144206@nova.wright.edu>, jmatthews@nova.wright.edu (Dr. John B. Matthews) writes:

> MacOS on PPC uses the same interface for memory management as 68K,
> although the implementation has changed considerably:-) I recently
> had the pleasure of working on MacOS bindings for GNAT on MacOS
> with MachTen. The bindings rely extensively on declarations such as
> 
>    type ObjectRec is 
>       record
>          ...
>       end record;
>    type ObjectPtr is access ObjectRec;
>    type ObjectHdl is access ObjectPtr;
> 
> The ObjectHdl.all.all syntax looks strange at first, but MacOS
> programmers at a recent trade show seemed to have no trouble
> following the sample code we showed them.

Although I was at what was probably the trade show to which you
allude, I did not discuss that aspect of Ada bindings with you.
I would maintain, however, that that construct is quite obvious
to anyone who has had to struggle with MacOS programming in any
other language.

I think this is an opportunity to prove the superiority of Ada,
by hiding those details so that future generations of MacOS
programmers do not have to deal with ugly constructs like
ObjectHdl.all.all the way their brethren do in less powerful
languages.

I believe those intricacies should be hidden in the private
part of type declarations for the various entities which might
be in heap.  Some "special" (in the church-lady sense) child
declarations might be available for direct access, but most
occasions for locking handles should be avoided and the rest
should be mediated by the handle package.  I believe what I
am looking for is a generic package, so that specific instances
can be declared for the various types one might put in heap.

I do not mean to suggest that what has been done to date is
improper -- certainly allowing MacOS programmers to emulate
their activities in previous languages is a good start, but
Ada has the capability to provide something better, hiding
some really arcane OS behaviour from programmers who have
more interest in correctness and productivity than winning
a MacOS trivia contest.

Larry Kilgallen

Re: Better MacOS Handles through Ada (was: Implementing Pointers to Pointe

[Dr. John B. Matthews]

In article <1996Sep13.080055.1@eisner>, kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> In article <1996Sep12.144206@nova.wright.edu>, jmatthews@nova.wright.edu (Dr. John B. Matthews) writes:
>> [...]
>> The ObjectHdl.all.all syntax looks strange at first, but MacOS
>> programmers at a recent trade show seemed to have no trouble
>> following the sample code we showed them.
> 
> Although I was at what was probably the trade show to which you
> allude, I did not discuss that aspect of Ada bindings with you.
> I would maintain, however, that that construct is quite obvious
> to anyone who has had to struggle with MacOS programming in any
> other language.

It was a pleasure to have met you at the show! That particualr
construct, ObjectHdl.all.all, doesn't appear in any of my sample
code; it was just something I recall trying while tinkering with the
compiler & bindings.
 
> [...]
> I do not mean to suggest that what has been done to date is
> improper -- certainly allowing MacOS programmers to emulate
> their activities in previous languages is a good start, but
> Ada has the capability to provide something better, hiding
> some really arcane OS behaviour from programmers who have
> more interest in correctness and productivity than winning
> a MacOS trivia contest.

I agree. I was particularly intrigued by the potential for tools
like AppMaker (a GUI-oriented, multi-language code generator from
Bowers Development) to be adapted to Ada. Another approach would be
a class library. I'd heard of an effort along this line, but never
tracked it down. Anybody?

John
----------------------------------------------------------------
Dr. John B. Matthews
jmatthews@nova.wright.edu; john_matthews@ccmail.dayton.saic.com
"Whom the gods would destroy, they first invite to program in C"

GUI Generators and Class Libraries (was: Better MacOS Handles...

[Larry Kilgallen]

In article <1996Sep14.150138@nova.wright.edu>, jmatthews@nova.wright.edu (Dr. John B. Matthews) writes:

> I agree. I was particularly intrigued by the potential for tools
> like AppMaker (a GUI-oriented, multi-language code generator from
> Bowers Development) to be adapted to Ada. Another approach would be
> a class library. I'd heard of an effort along this line, but never
> tracked it down. Anybody?

Since I have a lot of experience using AppMaker, I would love to be
able to use it for Ada programs on MacOS.  Templates can be created
by the end-user for AppMaker in addition to the ones supplied for
C* and Pascal, so I expect I will end up doing that.  If so I would
release them for general use sometime after the compiler world got
to the state of being able to build stand-along 68K applications for
Macintosh (that is when it makes business sense for me to spend the
time).  Jim Hopper has indicated he is interested in 68K, but there
are various obstacles.

But I do think that a GUI-generator like AppMaker really fills a
separate need than class libraries.  For Pascal and C, AppMaker will
generate your interface for raw compilation, or for use with the
MacApp or TCL class libraries (you have to specify at the start
which type of output you want).  When your GUI has been generated
to use a class library you respect, maintenance is much easier.

In looking at potential Macintosh class libraries, MacApp seemed to
stand out for keeping up to date with the latest Apple features, and
I thought I would possibly have to transliterate MacApp to Ada.  Jim
Hopper told me, however, that GNAT for Macintosh allowed Ada programs
to subclass C++ classes, meaning transliteration could be deferred and
MacApp could be used right away.  I have not tried this, but it sounds
reasonable.

There has been some talk about a portable Ada class library for
GUIs, but I am skeptical that anything covering multiple operating
systems can get all the nits of each correct.  Macintosh users expect
Balloon Help to be covered, along with hooks to Apple Guide.  Unix
users expect the new Common Desktop features associated with saving
application state to be there.  OS/2 users expect _their_ particular
set of right-mouse-button actions to be implemented.  I am skeptical
that platform-agnostic Ada zealots could match the performance of
language-agnostic-but-stuck-with-C++ platform zealots in meeting the
GUI requirements of the True Believers in various platforms. for that
reason, I am interested in good Ada bindings to, and eventually good
Ada implementation of, a well-designed MacOS class library.  Rewriting
MacApp in Ada might not be hard, but distributing the results involves
Apple's intellectual property.  Since they give away the C++ version,
they certainly don't view MacApp as a revenue source, but probably rather
a way to help folks develop for MacOS, so even getting them to distribute
an Ada version might be possible.

That's my take, but if someone has a different approach don't let
my enthusiasm be a deterrent to following another path as well.

Larry Kilgallen
LJK Software

Re: GUI Generators and Class Libraries (was: Better MacOS Handles...

[jim hopper]

In article <1996Sep15.091649.1@eisner>
kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> In looking at potential Macintosh class libraries, MacApp seemed to
> stand out for keeping up to date with the latest Apple features, and
> I thought I would possibly have to transliterate MacApp to Ada.  Jim
> Hopper told me, however, that GNAT for Macintosh allowed Ada programs
> to subclass C++ classes, meaning transliteration could be deferred and
> MacApp could be used right away.  I have not tried this, but it sounds
> reasonable.

Actually Larry, i said Gnat allows it, i have not tested it on gnat
mac.  if you are interested in testing it i will send you some info on
how its supposed to work. i am not a c or c++ programmer.

jim

Re: GUI Generators and Class Libraries (was: Better MacOS Handles...

[Larry Kilgallen]

In article <51hci8$277@news.syspac.com>, jhopper@erinet.com (jim hopper) writes:
> In article <1996Sep15.091649.1@eisner>
> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> 
>> In looking at potential Macintosh class libraries, MacApp seemed to
>> stand out for keeping up to date with the latest Apple features, and
>> I thought I would possibly have to transliterate MacApp to Ada.  Jim
>> Hopper told me, however, that GNAT for Macintosh allowed Ada programs
>> to subclass C++ classes, meaning transliteration could be deferred and
>> MacApp could be used right away.  I have not tried this, but it sounds
>> reasonable.
> 
> Actually Larry, i said Gnat allows it, i have not tested it on gnat
> mac.  if you are interested in testing it i will send you some info on
> how its supposed to work. i am not a c or c++ programmer.

Sorry to have misquoted you, Jim.

I am not a c or c++ programmer either, but we'll figure it out.
Of course if nobody else cares about Mac-specific class libraries,
it does not matter.

Larry

Re: GUI Generators and Class Libraries (wa

[David Kristola]

In article 1@eisner, kilgallen@eisner.decus.org (Larry Kilgallen) writes:

[snip]

>Of course if nobody else cares about Mac-specific class libraries,
>it does not matter.
>
>Larry

I care.  I was around here several months ago asking about an Ada GUI builder
for the Mac, and found nothing :(.  Now that i have MachTen & GNAT-Mac, i
might be looking at MacApp (URL is http://www.devtools.apple.com/macapp/ ).
For the time being, i guess i can do some mixed language programming.

david kristola
New email address: David95035@aol.com (until the spam gets too thick)

Re: GUI Generators and Class Libraries

[Dr. John B. Matthews]

In article <1996Sep15.223634.1@eisner>, kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> Of course if nobody else cares about Mac-specific class libraries,
> it does not matter.

One Marinus A. van der Lugt has a web page at

   http://members.aol.com/rlugt/index.html       

that features a prototypical Ada95 Macintosh Application Framework,
based on the existing MacOS/MachTen bindings. (Thanks to Jim Hopper
for the tip about this site.) 
                                                                            
The latest revision of the thin bindings may be found at                      
                                                                         
   ftp://pubmcada:@gnat-mac.com/usr/users/macada/public/
                                                                        
in the file bind0915.sea.bin. The working documentation, named            
bind0915.README and include in the distribution, is available as a              
separate file at the same location.         

John
----------------------------------------------------------------
Dr. John B. Matthews
jmatthews@nova.wright.edu; john_matthews@ccmail.dayton.saic.com
"Whom the gods would destroy, they first invite to program in C"