Pointer function parameter

Pointer function parameter

[Mary]

How can you handle address-of-operator (&) in Ada. 

ie.

float calculation(float &num2, float num1)
{
float calc1, calc2;
//some stuff
}

Thanks.

Mary

Re: Pointer function parameter

[tmoran]

>How can you handle address-of-operator (&) in Ada.
  X'access   or   X'unchecked_access
where   x : aliased some_type;
Of course you need it a lot less than C because procedures (but not
functions) can have "out" or "in out" parameters, as well as "in" ones.

Re: Pointer function parameter

[Gautier]

Mary:

> How can you handle address-of-operator (&) in Ada.
> 
> ie.
> 
> float calculation(float &num2, float num1)

Good news: you can do everything with in/in out/out
parameters, almost no need of 'address or 'access.
"Bad" news: if you are trying to affect num2 (are you ?),
you can't do it in a function: a bug-prone side-effect. Do it as:

procedure calculation( num1: float; num2: in out float; result: out float ) is...

HTH
______________________________________________________
Gautier  --  http://members.nbci.com/gdemont/gsoft.htm

Re: Pointer function parameter

[Mario Amado Alves]

> How can you handle address-of-operator (&) in Ada. (Mary)

I think you should write "address-of operator",
                                    ^
or simply "address operator".

Ada access types serve most pointer necessities. In this vein, the 
Ada expression X'Access is the equivalent of the C expression &X (X being
an object).

> float calculation(float &num2, float num1)

I dont remember using & in function prototypes from my C days, but I may be
wrong (I do not have K&R at hand).

| |,| | | |RuaFranciscoTaborda24RcD 2815-249CharnecaCaparica 351+939354002
|M|A|R|I|O|
|A|M|A|D|O|DepartmentoDeInformaticaFCT/UNL 2825-114 Caparica 351+212958536
|A|L|V|E|S|                                                  fax 212948541
| | | | | |                 maa@di.fct.unl.pt                FCT 212948300

Re: Pointer function parameter

[Robert Dewar]

In article
<Pine.LNX.4.10.10010171217210.17222-100000@lexis.di.fct.unl.pt>,
  comp.lang.ada@ada.eu.org wrote:
> Ada access types serve most pointer necessities. In this vein,
the
> Ada expression X'Access is the equivalent of the C expression
&X (X being
> an object).


Misleading, since &x is a somewhat fundamental C diction,
whereas X'Access is rather specialized, and has few legitimate
uses outside certain well defined areas (including for example
interfacing to C functions :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Pointer function parameter

[Florian Weimer]

Mario Amado Alves <maa@di.fct.unl.pt> writes:

> > How can you handle address-of-operator (&) in Ada. (Mary)
> 
> I think you should write "address-of operator",
>                                     ^
> or simply "address operator".

Well, in the example posted there wasn't any adress operator at
all. ;-) I think it's called "reference declaration" by the C++
standard.

Re: Pointer function parameter

[tmoran]

>virtually all dynamic data structures (linked lists, trees, etc.)
>require them.  [access types]
  No. People were making those structures using array indexing and not
access types a long, long time ago.  Look at some old Fortran code.

Re: Pointer function parameter

[Ted Dennison]

In article <cJGH5.335638$i5.5078954@news1.frmt1.sfba.home.com>,
  tmoran@bix.com wrote:
> >virtually all dynamic data structures (linked lists, trees, etc.)
> >require them.  [access types]
>   No. People were making those structures using array indexing and not
> access types a long, long time ago.  Look at some old Fortran code.

...or refer to Donald Knuth's classic "The Art of Computer Programming".

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Pointer function parameter

[Mario Amado Alves]

On Wed, 18 Oct 2000, Robert Dewar wrote:

> In article
> <Pine.LNX.4.10.10010171217210.17222-100000@lexis.di.fct.unl.pt>,
>   comp.lang.ada@ada.eu.org wrote:
> > Ada access types serve most pointer necessities. In this vein,
> the
> > Ada expression X'Access is the equivalent of the C expression
> &X (X being
> > an object).
> 
> 
> Misleading, since &x is a somewhat fundamental C diction,
> whereas X'Access is rather specialized, and has few legitimate
> uses outside certain well defined areas (including for example
> interfacing to C functions :-)

The "in this vein" is there for a reason: in the vein of using Ada access
types for the same purposes you use C pointer types for--and only in this
vein--, attribute Access is in fact the Ada equivalent of the C address
operator &.

The equivalent strito senso--not in the vein above--is of course attribute
Address. But if you use Address everywhere where you use & in the
equivalent C program, you miss a great part of the gain of using Ada
instead of C.

(Perhaps you read "Address" where it says "Access" in my first reply?)

And surely there is a _lot_ of uses of access types besides interfacing to
C: virtually all dynamic data structures (linked lists, trees, etc.)
require them.

| |,| | | |RuaFranciscoTaborda24RcD 2815-249CharnecaCaparica 351+939354005
|M|A|R|I|O|
|A|M|A|D|O|DepartmentoDeInformaticaFCT/UNL 2825-114 Caparica 351+212958536
|A|L|V|E|S|                                                  fax 212948541
| | | | | |                 maa@di.fct.unl.pt                FCT 212948300

Re: Pointer function parameter

[Marin David Condic]

While there are a lot of uses for access types, what needs to be carefully
explained to the C programmer approaching Ada is that in Ada you need
access/address a WHOLE*LOT*LESS than you do in C. C programmers will typically
start trying to write Ada code with C semantics and instead of "in out"
parameters, will start passing 'Address or 'Access of everything to
everything. I've seen it done. Its not pretty. It would be instructive to the
C programmer approaching Ada to observe very vigorously that while Ada has the
means to get pointers to everything, that doesn't mean one should do so with
the same regularity one might in C.

MDC



Mario Amado Alves wrote:

> And surely there is a _lot_ of uses of access types besides interfacing to
> C: virtually all dynamic data structures (linked lists, trees, etc.)
> require them.

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Pointer function parameter

[Robert Dewar]

In article
<Pine.LNX.4.10.10010191126450.17222-100000@lexis.di.fct.unl.pt>,
  comp.lang.ada@ada.eu.org wrote:
> The "in this vein" is there for a reason: in the vein of using
> Ada access types for the same purposes you use C pointer types
> for--and only in this vein--, attribute Access is in fact the
> Ada equivalent of the C address operator &.

But unless you are writing C code in Ada, you do NOT use Ada
access types "for the same purposes you use C pointer types
for". That's the important point.
>
> The equivalent strito senso--not in the vein above--is of
course attribute
> Address. But if you use Address everywhere where you use & in
the
> equivalent C program, you miss a great part of the gain of
using Ada
> instead of C.

Ah, but what you are missing is that most normally the Ada
approach is to use access types all over the place as required
but almost NEVER to use the 'Access attribute.

Sure if you want to write C code in Ada you can, but you
are also missing a "great part of the gain in writing Ada"
if you create dangerous aliasing all over the place by using
the 'Access attribute and aliased objects and types.

> (Perhaps you read "Address" where it says "Access" in my first
reply?)

No, not at all. The critical point here is that normally, other
than when interfacing to foreign code, or building certain
static data structures, you do not want to use EITHER attribute.
Yes, of course 'Access is preferable to 'Address, but the far
more important point is not to use either in ordinary code
except in rare cases.

When we discussed adding 'Access to the language, we recognized
that, although it was useful in specialized cases, it opened
up a Pandora's box of very bad programming practice, and, sad
to say, I see far too many programmers opening this box! A
C programmer has as much trouble seeing that the use of
pointers needs limiting as an old style Fortran programmer
has in seeing that gotos need limiting

> And surely there is a _lot_ of uses of access types besides
interfacing to
> C: virtually all dynamic data structures (linked lists, trees,
etc.)
> require them.

Yes, of course, but in Ada, you use pointers for these
purposes WITHOUT using the 'Access attribute. If you find
yourself using 'Access to implement linked lists, trees etc,
you are most likely doing something wrong (wrong in the sense
of not taking advantage of Ada).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Pointer function parameter

[Robert Dewar]

In article <cJGH5.335638$i5.5078954@news1.frmt1.sfba.home.com>,
  tmoran@bix.com wrote:
> >virtually all dynamic data structures (linked lists, trees,
etc.)
> >require them.  [access types]
>   No. People were making those structures using array indexing
and not
> access types a long, long time ago.  Look at some old Fortran
code.


Well of course you can do anything in any style, The reason
that Fortran programmers did this was simple, no pointers!
Now of course there are still cases where arrays can be
usefully used instead of pointers (see the front end of
GNAT and the use of the Table abstraction for example), but
the use of pointers is perfectly fine in Ada, and we should
not think otherwise. Almost nothing *requires* anything if
we are strict about the term, Turing machines are pretty
powerful :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Pointer function parameter

[Alejandro Villanueva]

Robert Dewar wrote:

> In article <cJGH5.335638$i5.5078954@news1.frmt1.sfba.home.com>,
>   tmoran@bix.com wrote:
> > >virtually all dynamic data structures (linked lists, trees,
> etc.)
> > >require them.  [access types]
> >   No. People were making those structures using array indexing
> and not
> > access types a long, long time ago.  Look at some old Fortran
> code.
>
> Well of course you can do anything in any style, The reason
> that Fortran programmers did this was simple, no pointers!
> Now of course there are still cases where arrays can be
> usefully used instead of pointers (see the front end of
> GNAT and the use of the Table abstraction for example), but
> the use of pointers is perfectly fine in Ada, and we should
> not think otherwise. Almost nothing *requires* anything if
> we are strict about the term, Turing machines are pretty
> powerful :-)
>

You are right! Turing machines can do ANYTHING, and don't forget that
also in Assembly ;-)


>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
------------------------------------------------------
�Quieres Cobrar por Navegar en Internet?
Visita: http://www.navegana.com/dinero/flintstone.html
------------------------------------------------------
Alejandro Villanueva
190921@cepsz.unizar.es
------------------------------------------------------

Re: Pointer function parameter

[Robert A Duff]

Alejandro Villanueva <190921@cepsz.unizar.es> writes:

> You are right! Turing machines can do ANYTHING, ...

No, they can't!

>... and don't forget that
> also in Assembly ;-)

- Bob

Re: Pointer function parameter

[Ted Dennison]

In article <39F5A744.CB20A0FD@cepsz.unizar.es>,
  Alejandro Villanueva <190921@cepsz.unizar.es> wrote:
> Robert A Duff wrote:
>
> > Alejandro Villanueva <190921@cepsz.unizar.es> writes:
> >
> > > You are right! Turing machines can do ANYTHING, ...
> >
> > No, they can't!
> >
>
> wops! please, explain me that...

I believe any "Undecidable problem" by definition can't be solved using
a Turing machine.

See http://www.britannica.com/seo/t/turing-machine/ for more info on the
subject.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Pointer function parameter

[Lutz Donnerhacke]

* Ted Dennison wrote:
>I believe any "Undecidable problem" by definition can't be solved using
>a Turing machine.

It can be solved but it might take an indefinite time.

Re: Pointer function parameter

[Alejandro Villanueva]

Robert A Duff wrote:

> Alejandro Villanueva <190921@cepsz.unizar.es> writes:
>
> > You are right! Turing machines can do ANYTHING, ...
>
> No, they can't!
>

wops! please, explain me that...


>
> >... and don't forget that
> > also in Assembly ;-)
>
> - Bob

--
------------------------------------------------------
�Quieres Cobrar por Navegar en Internet?
Visita: http://www.navegana.com/dinero/flintstone.html
------------------------------------------------------
Alejandro Villanueva
190921@cepsz.unizar.es
------------------------------------------------------

Re: Pointer function parameter

[Mats Weber]

Alejandro Villanueva wrote:
> 
> Robert A Duff wrote:
> 
> > Alejandro Villanueva <190921@cepsz.unizar.es> writes:
> >
> > > You are right! Turing machines can do ANYTHING, ...
> >
> > No, they can't!
> >
> 
> wops! please, explain me that...

They won't make you coffee. No, seriously, there are problems that
cannot be solved using any Turing machine, which means any computer. One
example is the halting problem: you cannot write a program that, given
any program as input, can tell in finite time whether this program will
exit or continue executing forever.

Re: Pointer function parameter

[Robert A Duff]

Alejandro Villanueva <190921@cepsz.unizar.es> writes:

> Robert A Duff wrote:
> 
> > Alejandro Villanueva <190921@cepsz.unizar.es> writes:
> >
> > > You are right! Turing machines can do ANYTHING, ...
> >
> > No, they can't!
> 
> wops! please, explain me that...

For your amusement, here's a list of some things a Turing machine (TM)
can't do:

A TM cannot calculate, in finite time, the last prime number, nor
produce the full decimal expansion of pi.

A TM cannot handle interrupts.

A TM cannot make a soft-boiled egg.  The machine has no peripheral
devices such as a stove, but more importantly, it has no concept of real
time (which is key for soft-boiled eggs).  In general, a TM can't run
real-time programs.

A TM cannot produce high quality original works of fiction.

A TM cannot convince me I should vote for Pat Buchanan.

A TM cannot write a large, useful, bug-free computer program.
And never will.

A TM cannot drive a GUI interface -- the machine has no bit-mapped
display, but more importantly, it has no concept of doing I/O as it goes
along.  That is, a TM's input is placed on the tape before the machine
starts, and you don't look at the output until it halts.  GUI's don't
fit into that I/O model.

Some computing devices, such as normal computers, and human brains,
*can* do some of these things!

Oh, one last thing: a TM cannot "exist".  (Does that fall under your
definition of "do ANYTHING"?)  A TM has an infinitely long tape, whereas
we can only build machines with finite memories.  (The hardware folks
are getting closer and closer to infinite-sized memories all the time,
but they still have a long way to go.  Besides, the software folks can
use it up faster than it grows.)

;-)

- Bob

Re: Pointer function parameter

[Ken Garlington]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccwveqqrmd.fsf@world.std.com...

: Oh, one last thing: a TM cannot "exist".  (Does that fall under your
: definition of "do ANYTHING"?)  A TM has an infinitely long tape, whereas
: we can only build machines with finite memories.

Glue the ends of the tape together to form a loop? :)

Re: Pointer function parameter

[Florian Weimer]

"Ken Garlington" <Ken.Garlington@computer.org> writes:

> : Oh, one last thing: a TM cannot "exist".  (Does that fall under your
> : definition of "do ANYTHING"?)  A TM has an infinitely long tape, whereas
> : we can only build machines with finite memories.
> 
> Glue the ends of the tape together to form a loop? :)

"an infinitely long tape" /= "an endless tape" ;-)

Re: Pointer function parameter

[Robert Dewar]

In article <87d7gikvnd.fsf@deneb.enyo.de>,
  Florian Weimer <fw@deneb.enyo.de> wrote:
> "Ken Garlington" <Ken.Garlington@computer.org> writes:
>
> > : Oh, one last thing: a TM cannot "exist".  (Does that fall
under your
> > : definition of "do ANYTHING"?)  A TM has an infinitely long
tape, whereas
> > : we can only build machines with finite memories.

It is not true that a TM has an infinitely long tape (that's
a meaningless idea really), it has a sufficiently long tape.

And yes, we can build such a machine, we just keep building
more and more tape as it is needed :-)

That way we can keep the TM computing for as long as we like.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Pointer function parameter

[Ken Garlington]

Robert, we've really got to chip in and get you a new newsreader :)

In addition to the occasional double-post, it also seems to have trouble
keeping the attributions straight. I didn't say any of the text below.

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:8tl8dv$ldu$1@nnrp1.deja.com...
: In article <87d7gikvnd.fsf@deneb.enyo.de>,
:   Florian Weimer <fw@deneb.enyo.de> wrote:
: > "Ken Garlington" <Ken.Garlington@computer.org> writes:
: >
: > > : Oh, one last thing: a TM cannot "exist".  (Does that fall
: under your
: > > : definition of "do ANYTHING"?)  A TM has an infinitely long
: tape, whereas
: > > : we can only build machines with finite memories.
:
: It is not true that a TM has an infinitely long tape (that's
: a meaningless idea really), it has a sufficiently long tape.
:
: And yes, we can build such a machine, we just keep building
: more and more tape as it is needed :-)
:
: That way we can keep the TM computing for as long as we like.
:
:
: Sent via Deja.com http://www.deja.com/
: Before you buy.

Re: Pointer function parameter

[Larry Kilgallen]

In article <m5zL5.1064$pq3.76430@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> writes:
> Robert, we've really got to chip in and get you a new newsreader :)
> 
> In addition to the occasional double-post,

and I had been led to believe those double posts from Robert were a defect
at my site...

...well, I suppose they could be a defect at both Ken's site and my site,
but at least I am not alone in seeing this effect !

Re: Pointer function parameter

[Mats Weber]

Robert A Duff wrote:

> [...]  (The hardware folks
> are getting closer and closer to infinite-sized memories all the time,
> but they still have a long way to go.  [...]

So, you are saying that Inifity - 1 Gig < Infinity - 64 K ? :-)

Re: Pointer function parameter

[Florian Weimer]

Mats Weber <matsw@mail.com> writes:

> Robert A Duff wrote:
> 
> > [...]  (The hardware folks
> > are getting closer and closer to infinite-sized memories all the time,
> > but they still have a long way to go.  [...]
> 
> So, you are saying that Inifity - 1 Gig < Infinity - 64 K ? :-)

In "Structure and Interpretation of Computer Programs", there is an
interesting remark that at some time in the future, garbage collection
(and storage reclamation in general) might become irrelevant because
computers will be shipped with RAM so big that they can't touch every
storage location during their lifetime.  (To be honest, I don't know
if the authors are kidding here, or if they really believe in this
weird idea.)

RAM size, was Re: Pointer function parameter

[tmoran]

> > > are getting closer and closer to infinite-sized memories all the time,
> computers will be shipped with RAM so big that they can't touch every
> storage location during their lifetime.
  For at least the last 40 years the "typical" RAM size of a system has
been fairly close to the amount its CPU can access in one second.