* Re: Ada access vs C/C++ pointers and references
2004-08-18 22:27 Ada access vs C/C++ pointers and references Keith H Duggar
@ 2004-08-19 0:21 ` Nick Roberts
2004-08-19 11:42 ` Marin David Condic
2004-08-19 0:29 ` Jim Rogers
` (3 subsequent siblings)
4 siblings, 1 reply; 17+ messages in thread
From: Nick Roberts @ 2004-08-19 0:21 UTC (permalink / raw)
On 18 Aug 2004 15:27:47 -0700, Keith H Duggar <duggar@mit.edu> wrote:
> [re array indexing]
> As you can see, method two saves one instruction by storing
> and manipulating a memory address directly.
In a loop, there is well known optimisation known (for reasons which
mystify me) as 'strength reduction', which allows a loop such as:
for (i=0;i<n;i++) { ... a[i] ... };
to be transformed into the equivalent of:
for (p=&a[0];p<&a[n];p++) { ... *p ... };
before emitting machine code. So an Ada loop such as:
for i in 1..N loop
... A(i) ...
end loop;
can be expected to be compiled into machine code which is as
efficient as the code that could be produced by using direct address
manipulation.
> First, is it correct to say that Ada access types are more
> similar to C++ references (T&) than they are to C/C++
> pointers (T*) ?
No. Ada access types are very similar to C and C++ pointers, and are
typically implemented and used in (almost) exactly the same way.
The rough Ada equivalent of C++ references are 'aliased objects'.
> Second, does Ada provide any facilities for direct and raw
> memory access by memory address and pointer arithmetic?
Yes it does. There are standard packages System.Storage_Elements and
System.Address_To_Access_Conversions, which provide facilities for
converting between access types and addresses, and performing integer
arithmetic on addresses, as well as Interfaces.C and
Interfaces.C.Pointers which enable Ada programs to access C strings,
arrays, and pointers.
> Third, if Ada does not provide arithmetic pointers do you
> know if this has played any part in acceptance of Ada for
> systems programming or efficiency critical applications?
I don't know (sorry).
> Fourth, have you experienced or can you think of any cases
> where pointer arithmetic has helped to solve a problem that
> would have been more difficult with Ada access types alone?
Not that I can recall.
--
Nick Roberts
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-19 0:21 ` Nick Roberts
@ 2004-08-19 11:42 ` Marin David Condic
0 siblings, 0 replies; 17+ messages in thread
From: Marin David Condic @ 2004-08-19 11:42 UTC (permalink / raw)
Nick Roberts wrote:
>
>> Third, if Ada does not provide arithmetic pointers do you know if
>> this has played any part in acceptance of Ada for systems
>> programming or efficiency critical applications?
>
>
> I don't know (sorry).
>
Ada 83 missed address arithmetic and modular types and while it is hard
to tell what impact that had, I know it did not thrill people who had to
do bare-machine type of jobs. However, Ada 95 has this and it doesn't
seem to be creating a groundswell of support in the embedded world. Note
that C and C++ tend to lack the really great low-level representation
capabilities of Ada and I frankly don't know how the poor guys who use
those languages for embedded systems can get along without them.
Nevertheless, they do & Ada has only a small smidgen of the embedded
systems market.
I suspect that you can't point at any one feature or lack of it (Like
the infamous "+=" debate?) and say "This causes Language X to be
popular/unpopular" I think it just has more to do with what people know
and their resistance to change without some perceived major benefit.
People got used to programming with C because it was readily available
and interfaced to the OS. Ada comes along and so people start thinking:
"Well, its not C and it doesn't even look remotely like C, so let me
start dreaming up reasons why its bad so I won't have to learn how to
use it..."
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm
Send Replies To: m o d c @ a m o g
c n i c . r
"Power corrupts. Absolute power is kind of neat"
-- John Lehman, Secretary of the Navy 1981-1987
======================================================================
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-18 22:27 Ada access vs C/C++ pointers and references Keith H Duggar
2004-08-19 0:21 ` Nick Roberts
@ 2004-08-19 0:29 ` Jim Rogers
2004-08-19 5:19 ` Ludovic Brenta
` (2 subsequent siblings)
4 siblings, 0 replies; 17+ messages in thread
From: Jim Rogers @ 2004-08-19 0:29 UTC (permalink / raw)
duggar@mit.edu (Keith H Duggar) wrote in news:b47de02.0408181427.25d82fe1
@posting.google.com:
> I'm simply asking four things.
>
> First, is it correct to say that Ada access types ore more
> similar to C++ references (T&) than they are to C/C++
> pointers (T*) ?
Not really. C++ references are always implemented as const
pointers. Ada access types are assignable, just like C/C++
pointers.
>
> Second, does Ada provide any facilities for direct and raw
> memory access by memory address and pointer arithmetic?
Yes, but not directly through access types. The package
System.Storage_Elements provides the ability to perform
integer arithmetic on addresses.
Note that the package contains functions for converting between
addresses and Integer_Address. This allows Ada to work correctly
on systems without linear addressing schemes, such as the old
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-18 22:27 Ada access vs C/C++ pointers and references Keith H Duggar
2004-08-19 0:21 ` Nick Roberts
2004-08-19 0:29 ` Jim Rogers
@ 2004-08-19 5:19 ` Ludovic Brenta
2004-08-19 6:21 ` Martin Dowie
2004-08-19 7:19 ` j
2004-08-19 7:59 ` Ole-Hjalmar Kristensen
2004-08-19 8:11 ` Dmitry A. Kazakov
4 siblings, 2 replies; 17+ messages in thread
From: Ludovic Brenta @ 2004-08-19 5:19 UTC (permalink / raw)
(Keith H Duggar) writes:
> Third, if Ada does not provide arithmetic pointers do you
> know if this has played any part in acceptance of Ada for
> systems programming or efficiency critical applications?
Ada does provide for pointer arithmetic, but the fact that one can
avoid pointers altogether for most things does help with verification
and certification of safety-critical software. Pointer arithmetic is
usually confined to a few low-level device drivers.
(I work in avionics)
--
Ludovic Brenta.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-19 5:19 ` Ludovic Brenta
@ 2004-08-19 6:21 ` Martin Dowie
2004-08-19 11:55 ` Marin David Condic
2004-08-19 18:01 ` Ludovic Brenta
2004-08-19 7:19 ` j
1 sibling, 2 replies; 17+ messages in thread
From: Martin Dowie @ 2004-08-19 6:21 UTC (permalink / raw)
"Ludovic Brenta" <ludovic.brenta@insalien.org> wrote in message
news:87657fso10.fsf@insalien.org...
> (Keith H Duggar) writes:
> > Third, if Ada does not provide arithmetic pointers do you
> > know if this has played any part in acceptance of Ada for
> > systems programming or efficiency critical applications?
>
> Ada does provide for pointer arithmetic, but the fact that one can
> avoid pointers altogether for most things does help with verification
> and certification of safety-critical software. Pointer arithmetic is
> usually confined to a few low-level device drivers.
>
> (I work in avionics)
I also work in avionics (have done for 16 years now) and I've
_never_ needed pointer arithmatic - there's usually a 'better'
Ada way that produces acceptably fast results. But YMMV :-)
Cheers
-- Martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-19 6:21 ` Martin Dowie
@ 2004-08-19 11:55 ` Marin David Condic
2004-08-19 18:01 ` Ludovic Brenta
1 sibling, 0 replies; 17+ messages in thread
From: Marin David Condic @ 2004-08-19 11:55 UTC (permalink / raw)
Pretty much the same story here. Note that "needing" pointer arithmetic
is probably a purely perceptual thing. "I'm used to doing it this way
and my particular C compiler gets rid of half of an instruction per
million by doing so and now I believe my code is ultra-fast and I
*can't* live without it in some slow, inefficient language that won't
let me march blindly through memory..."
Computers are actually pretty good at doing their own address
arithmetic, so I choose not to try to take on their job and leave them
unemployed, out on the street, stealing hubcaps and smoking marajuana.
In *some* raw bootstrap code where you are doing health checks (making
sure address lines work, memory parity checks work, etc.) you do some
direct address manipulation. (You also do a *lot* of other things you
wouldn't normally do in the application software!) Typically, you dip
into assembler to do this anyway because a) you can't get there directly
in Ada (or most other languages I know of) without writing machine code
routines anyway and b) Ada's elaboration rules often get in the way when
you're coming up from a raw power-up.
MDC
Martin Dowie wrote:
>
>
> I also work in avionics (have done for 16 years now) and I've
> _never_ needed pointer arithmatic - there's usually a 'better'
> Ada way that produces acceptably fast results. But YMMV :-)
>
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm
Send Replies To: m o d c @ a m o g
c n i c . r
"Power corrupts. Absolute power is kind of neat"
-- John Lehman, Secretary of the Navy 1981-1987
======================================================================
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-19 6:21 ` Martin Dowie
2004-08-19 11:55 ` Marin David Condic
@ 2004-08-19 18:01 ` Ludovic Brenta
1 sibling, 0 replies; 17+ messages in thread
From: Ludovic Brenta @ 2004-08-19 18:01 UTC (permalink / raw)
"Martin Dowie" writes:
> "Ludovic Brenta" wrote in message
>> Ada does provide for pointer arithmetic, but the fact that one can
>> avoid pointers altogether for most things does help with
>> verification and certification of safety-critical software.
>> Pointer arithmetic is usually confined to a few low-level device
>> drivers.
>>
>> (I work in avionics)
>
> I also work in avionics (have done for 16 years now) and I've
> _never_ needed pointer arithmatic - there's usually a 'better' Ada
> way that produces acceptably fast results. But YMMV :-)
Yes, usually, representation clauses and arrays work wonders.
Occasionally, we do use System.Address, but I can't recall, off the
top of my head, that we ever used "+" or "-" on addresses.
--
Ludovic Brenta.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-19 5:19 ` Ludovic Brenta
2004-08-19 6:21 ` Martin Dowie
@ 2004-08-19 7:19 ` j
2004-08-19 7:42 ` Martin Dowie
2004-08-19 12:03 ` Marin David Condic
1 sibling, 2 replies; 17+ messages in thread
From: j @ 2004-08-19 7:19 UTC (permalink / raw)
Hey avionics guys, please share your knowledge and experience,
I am starting a new job - Ada in avionics.
Any suggestions or recommendations for: what to know, first thing to study
if you don't know, training books, pitfalls to watch for, 'soft' skills?
Thanks for your help.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-19 7:19 ` j
@ 2004-08-19 7:42 ` Martin Dowie
2004-08-19 12:03 ` Marin David Condic
1 sibling, 0 replies; 17+ messages in thread
From: Martin Dowie @ 2004-08-19 7:42 UTC (permalink / raw)
j wrote:
> Hey avionics guys, please share your knowledge and experience,
>
> I am starting a new job - Ada in avionics.
>
> Any suggestions or recommendations for: what to know, first thing to
> study if you don't know, training books, pitfalls to watch for,
> 'soft' skills?
Here's 5 off the top of my head:
KISS (Keep It Simple, Stupid). Try and avoid the more esoterique corners of
the language (e.g. I can't imagine myself every using ATC). Investigate
SPARK - this will certainly keep it KISS! :-) Also, check out the
"Ravenscar" profile for tasking programs (SPARK can support this now).
Never be tempted to export variables instead of using an access routine
(pragma Inline is your friend).
If you can, make sure _you_ have input to the ICD so that you ensure message
have nice field boundaries.
Avoid 'holey' enumerations, other than at the boundary and always convert
them to a 'plain' enumeration.
Avoid 'types packages' - by this I mean enormous packages that hold every
type required by a system.
Cheers
-- Martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-19 7:19 ` j
2004-08-19 7:42 ` Martin Dowie
@ 2004-08-19 12:03 ` Marin David Condic
1 sibling, 0 replies; 17+ messages in thread
From: Marin David Condic @ 2004-08-19 12:03 UTC (permalink / raw)
Study Chapter 13 of the ARM.
Most Ada books - while being good with the general language features -
tend to blip over all the things about Ada that make it great for
embedded work. Reading the ARM is difficult and tedious, but if you root
out all the interesting features you'll find it is far more friendly for
embedded programming than most people make it out to be.
MDC
j wrote:
> Hey avionics guys, please share your knowledge and experience,
>
> I am starting a new job - Ada in avionics.
>
> Any suggestions or recommendations for: what to know, first thing to study
> if you don't know, training books, pitfalls to watch for, 'soft' skills?
>
> Thanks for your help.
>
>
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm
Send Replies To: m o d c @ a m o g
c n i c . r
"Power corrupts. Absolute power is kind of neat"
-- John Lehman, Secretary of the Navy 1981-1987
======================================================================
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-18 22:27 Ada access vs C/C++ pointers and references Keith H Duggar
` (2 preceding siblings ...)
2004-08-19 5:19 ` Ludovic Brenta
@ 2004-08-19 7:59 ` Ole-Hjalmar Kristensen
2004-08-19 15:33 ` Keith H Duggar
2004-08-19 8:11 ` Dmitry A. Kazakov
4 siblings, 1 reply; 17+ messages in thread
From: Ole-Hjalmar Kristensen @ 2004-08-19 7:59 UTC (permalink / raw)
>>>>> "KHD" == Keith H Duggar <duggar@mit.edu> writes:
KHD> In the "ADA Popularity Discussion Request" thread, the topic
KHD> of C/C++ pointers and Ada access types came up. Here are the
KHD> related quotes
KHD> Keith H Duggar writes :
>> Or are there simply missing features that preclude some
>> efficient coding idioms (does Ada have pointers?).
KHD> Ludovic Brenta writes :
>> Yes, Ada does have pointers. They're called
>> "access types" in Ada.
KHD> Dmitry A. Kazakov writes :
>> Yes, Ada has pointers, and interestingly, because that
>> wasn't design intent, richer than C++ has.
>> ...
>>
>> 5. Ada pointers are transparent to member extraction and
>> array indexing. I.e. in Ada "->" and "." are same.
KHD> Before I raise my examples and questions please keep in mind
KHD> that I do not know Ada. Therefore, I'm purely seeking
KHD> knowledge and all my statements about Ada should be regarded
KHD> as questions rather than statements.
KHD> It seems to me that Ada access types are more akin to C++
KHD> references than there are to C/C++ pointers. For by pointer
KHD> I literally mean an integral type supporting integer
KHD> arithmetic which can be interpreted as a memory address.
Not really. C++ references are constant, Ada access types can be
changed.
Ada access types are *very* similar to C++ pointers.
KHD> In reference to point 5. above, pointer arithmetic is partly
KHD> why C++ has both "->" and "."
No. This is just syntax. "." would have worked just fine for
dereferencing C/C++ pointers. I suspect the reason for using "->" was
just to make it more visible that you are using a pointer.
KHD> In C/C++ such pointer arithmetic allows for a number of
KHD> idioms intended to produce faster or more efficient code.
KHD> For example, consider array subscript access:
KHD> C++ : x[i]
KHD> Ada : x(i)
KHD> Since both languages allow subscripting by integers that
KHD> may not be available until runtime, both C++ and Ada
KHD> compilers must produce machine code that effectively:
KHD> 1) computes the location in memory of x[i] from the location
KHD> of x and the value of i
KHD> 2) "dereferences" that location for either read or write (by
KHD> loading into a register, etc)
KHD> Pointer arithmetic in C/C++ sometimes allows you to skip
KHD> step 1 by keeping and updating the address directly. For
KHD> example, consider the following two examples which both
KHD> process all the characters of a null terminated array.
KHD> char buffer[80]
KHD> // read in some contents into buffer
KHD> // method one
KHD> for ( int i = 0 ; buffer[i] != '\0' ; ++i ) { ... }
KHD> // method two
KHD> for ( char * cp = buffer ; *cp != '\0' ; ++cp ) { ... }
KHD> Here are the operations performed during each pass of the
KHD> loop
KHD> method one : increment i
KHD> compute address of buffer[i]
KHD> dereference address of buffer[i]
KHD> compare to null '\0'
KHD> method two : increment address (pointer) cp
KHD> dereference address cp
KHD> compare to null '\0'
KHD> As you can see, method two saves one instruction by storing
KHD> and manipulating a memory address directly.
Except that the Ada construct "for i in buffer'range loop ... end
loop" will typically be optimized to yield the most efficient code.
The use of explicit pointer arithmetic may even prevent compilers from
generating the most efficient code, because you give them no choice in
strategy. I have even seen C++ compilers generate faster code for
your method one than your method two. But as usual, it all depends on
your compiler and hardware.
KHD> Here is an example of saving space using pointer arithmetic
KHD> in a doubly linked list
KHD> http://c2.com/cgi/wiki?TwoPointersInOneWord
Yes, an old trick. You save some space, but I doubt you save time, and
it is utterly unreadable to someone who does not know the trick.
KHD> Now please don't misunderstand me. I'm not advocating these
KHD> techniques. Nor do I mean to imply that they are practically
KHD> important. Furthermore, allowing pointer arithmetic creates
KHD> a host of problems of which I'm sure you are aware.
KHD> I'm simply asking four things.
KHD> First, is it correct to say that Ada access types ore more
KHD> similar to C++ references (T&) than they are to C/C++
KHD> pointers (T*) ?
See above.
KHD> Second, does Ada provide any facilities for direct and raw
KHD> memory access by memory address and pointer arithmetic?
Yes. If you really want it, it's in System.Storage_Elements
KHD> Third, if Ada does not provide arithmetic pointers do you
KHD> know if this has played any part in acceptance of Ada for
KHD> systems programming or efficiency critical applications?
KHD> Fourth, have you experienced or can you think of any cases
KHD> were pointer arithmetic has helped to solve a problem that
KHD> would have been more difficult with Ada access types alone?
KHD> Keith
As Ada does provide pointer arithmetic your two last questions are
somewhat hypothetical, but in my experince, the answer is no.
--
C++: The power, elegance and simplicity of a hand grenade.
P.S. I do most of my programming in C++. It's fun, it's powerful, but
not my first choice to build large, reliable systems.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-19 7:59 ` Ole-Hjalmar Kristensen
@ 2004-08-19 15:33 ` Keith H Duggar
2004-08-19 21:32 ` Ludovic Brenta
2004-08-20 7:52 ` Ole-Hjalmar Kristensen
0 siblings, 2 replies; 17+ messages in thread
From: Keith H Duggar @ 2004-08-19 15:33 UTC (permalink / raw)
> No. This is just syntax. "." would have worked just fine for
> dereferencing C/C++ pointers. I suspect the reason for using "->" was
> just to make it more visible that you are using a pointer.
Originally in C "x->" was shorthand for "(*x)."
However, in C++ "->" serves the very useful purpose of
(via operator overloading) allowing smart pointer types
and iterator types to have the same semantics of raw
pointers in addition to allowing the usual member access.
Thus
iterator->f() //access f() in object "pointed" to
smart_pointer->f() //access f() in object "pointed" to
iterator.f() //access f() in iterator object
smart_pointer.f() //access f() in smart pointer object
Otherwise, if the pointed to type had a function named f
and the iterator had a function named f which function would
interator.f() access?
How is this resolved in Ada?
Also, I'm sure there were C compatibility constraints as well.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-19 15:33 ` Keith H Duggar
@ 2004-08-19 21:32 ` Ludovic Brenta
2004-08-19 22:18 ` Hyman Rosen
2004-08-20 7:52 ` Ole-Hjalmar Kristensen
1 sibling, 1 reply; 17+ messages in thread
From: Ludovic Brenta @ 2004-08-19 21:32 UTC (permalink / raw)
Keith H Duggar writes:
>> No. This is just syntax. "." would have worked just fine for
>> dereferencing C/C++ pointers. I suspect the reason for using "->" was
>> just to make it more visible that you are using a pointer.
>
> Originally in C "x->" was shorthand for "(*x)."
>
> However, in C++ "->" serves the very useful purpose of
> (via operator overloading) allowing smart pointer types
> and iterator types to have the same semantics of raw
> pointers in addition to allowing the usual member access.
> Thus
>
> iterator->f() //access f() in object "pointed" to
> smart_pointer->f() //access f() in object "pointed" to
> iterator.f() //access f() in iterator object
> smart_pointer.f() //access f() in smart pointer object
This is the kind of thing that is really very appealing to gurus, but
after trying to use them for a while I turned away from C++. If one
overloads "new", "delete", "->" and "()", one quickly gets into a
maintenance nightmare. For example, suppose I have:
smart_pointer* p;
Then you can easily find yourself writing:
p->f(); // [1]
(*p).f(); // [2]
p.f(); // illegal, I think
(*p)->f(); // [3]
And I'm not even sure anymore what each of these mean :)
> Otherwise, if the pointed to type had a function named f and the
> iterator had a function named f which function would interator.f()
> access?
>
> How is this resolved in Ada?
Resoved? You mean, like a problem? Ada does not have a problem in
this respect, and so does not need to resolve it.
On the left of ".", you have either a record, or an access to a
record. On the right of ".", you have one of the members of the
record, or "all" to mean the entire record. Ada does not allow you to
override the meaning of ".", so you always know exactly what you're
doing.
procedure Proc is
type Object is ...;
type Object_Access is access all Object;
procedure P (O : in out Object) is separate;
type Iterator is record
Pointed_To : Object_Access;
end record;
procedure P (I : in out Object) is separate;
type Iterator_Access is access Iterator;
It : Iterator_Access is new Iterator (Pointed_To => new Object);
begin
P (It.all);
P (It.Pointed_To.all); -- implicit dereference of It
P (It.all.Pointed_To.all); -- explicit dereference of It
end Proc;
As you can see, none of the calls is ambiguous.
--
Ludovic Brenta.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-19 15:33 ` Keith H Duggar
2004-08-19 21:32 ` Ludovic Brenta
@ 2004-08-20 7:52 ` Ole-Hjalmar Kristensen
1 sibling, 0 replies; 17+ messages in thread
From: Ole-Hjalmar Kristensen @ 2004-08-20 7:52 UTC (permalink / raw)
>>>>> "KHD" == Keith H Duggar <duggar@mit.edu> writes:
>> No. This is just syntax. "." would have worked just fine for
>> dereferencing C/C++ pointers. I suspect the reason for using "->" was
>> just to make it more visible that you are using a pointer.
KHD> Originally in C "x->" was shorthand for "(*x)."
Yes, but strictly speaking, since the compiler *knows* x is a pointer,
it could just have two versions of ".", one which works on records,
and one which works on pointers. So the shorthand for "(*x)." could
just as well have been "x." But i'm completely happy with "->"
KHD> However, in C++ "->" serves the very useful purpose of
KHD> (via operator overloading) allowing smart pointer types
KHD> and iterator types to have the same semantics of raw
KHD> pointers in addition to allowing the usual member access.
KHD> Thus
iterator-> f() //access f() in object "pointed" to
smart_pointer-> f() //access f() in object "pointed" to
KHD> iterator.f() //access f() in iterator object
KHD> smart_pointer.f() //access f() in smart pointer object
KHD> Otherwise, if the pointed to type had a function named f
KHD> and the iterator had a function named f which function would
KHD> interator.f() access?
If C++ had allowed dispatching on the return value of a function
(operator) you could use a cast to resolve the ambiguity.
KHD> How is this resolved in Ada?
By not allowing you to overload "." :-)
Which means that smart pointers do not look so similar to normal
pointers in Ada, of course.
KHD> Also, I'm sure there were C compatibility constraints as well.
--
C++: The power, elegance and simplicity of a hand grenade.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada access vs C/C++ pointers and references
2004-08-18 22:27 Ada access vs C/C++ pointers and references Keith H Duggar
` (3 preceding siblings ...)
2004-08-19 7:59 ` Ole-Hjalmar Kristensen
@ 2004-08-19 8:11 ` Dmitry A. Kazakov
4 siblings, 0 replies; 17+ messages in thread
From: Dmitry A. Kazakov @ 2004-08-19 8:11 UTC (permalink / raw)
On 18 Aug 2004 15:27:47 -0700, Keith H Duggar wrote:
> First, is it correct to say that Ada access types ore more
> similar to C++ references (T&) than they are to C/C++
> pointers (T*) ?
I wouldn't say so. References in C++ have three major uses:
1. Parameter passing mode specification:
T& Foo (T& X);
2. Aliasing:
T& X = *Y [123].Z ()->Baz;
3. Mix-in:
class Y
{
T& X;
In Ada only 3 is customary implemented using access types:
1. Some types are always by-copy, some are always by-reference, and for the
rest the compiler is free to choose the best.
2. Aliasing is achieved by renaming:
X : T renames Y(123).Z().Baz.all;
3. Only for mix-in one usually uses anonymous access types:
type Y (X : access T) is ...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 17+ messages in thread