Re: More questions...

[Hyman Rosen <hymie@prolifics.com>]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> writes:
> int&   r = i;      // r and i are the same object

> Now, the example above seems a little confusing.
> It claims that r and i are the same object.

It is not confusing at all. In fact, r and i *are* the same object.

> At the same time it is true that references such as r are
> implemented using pointers.

The fact that *in some cases* a pointer to the referenced object may
be created by the implementation is completely irrelevant to the C++
concept that a reference is an alias of the referenced object.

> C++ simply provides a cleaner and safer way to use a pointer when it
> is declared as a reference.  The statement above would lead you to
> believe that r is merely an alias for i.

In C++, references are not pointers. They are aliases for objects.
A reference always refers to the same object from the moment it is
created. It is true that careless programming can leave a reference
dangling by destroying its aliased object out from under it, since,
as has been mentioned here before, C++ defaults to "unsafe".

> Ada does not have a direct equivalent to references.  In fact, Ada
> access types are as safe as C++ references while also being useful
> in all Ada data structures.

C++ reference types have little to do with safety, and much to do with
operator overloading. Their main purpose is to permit the return value
of a function to be the alias of an existing object, so that further
operations may be performed on it, and to avoid copying of possibly
large objects as function parameters.

	template <typename T, int N> class fixed_array
	{
		T theArray[N];
	public:
		T &operator[] (int n) { return theArray[n]; }
	};
	fixed_array<double, 6> b;
	b[3] = 7.9;

> C++ references are always constants.  A reference cannot change the object
> it references. The reference object may or may not be constant.
> C++ reference types cannot be elements of an array because references must
> be initialized, while arrays cannot be initialized in C++.

A much better analogy is to compare C++ references with Ada procedure
parameters. The compiler must (I believe) implement pass-by-reference
for at least certain kinds of parameters. In Ada, you certainly would
not expect to be able to reseat a procedure parameter to refer to some
object other than the one passed, nor would you expect to be able to
have an array of in out parameters!


> As far as how readable the two languages are, try the following
> test.  Find a person who does not know Ada or C++.  Show that person
> the following code fragments.

This is a straw man. Certainly no programming language is designed to
be understood by people who do not know it!

>       cout << Count << endl;
>       Ada.Text_Io.Put_Line(Integer'Image(Count));
> 
> Ask this person what each code fragment does.

I suspect that the person would wonder where the forgotten close quote
goes in the Ada code. If he wanted to print two numbers on the same line,
he might wonder what to call, assuming he even realized that put_line
appended the terminator. Once he knew C++, he might wonder why he had to
name the type of Count when trying to print it.

> C++ needs constructors for all classes because C++ requires dynamic
> allocation and deallocation of objects to achieve polymorphism.  Ada
> allows the programmer to decide whether or not to use dynamic
> allocation and deallocation. Ada can achieve polymorphism with or
> without dynamic allocation. This means that Ada does not always need
> a destructor.

Once again, this is vastly confused. First, C++ does *not* need
constructors for all classes. Constructors and destructors are
used to appropriately initialize and clean up objects. When no
such work is needed the construct does not need to appear. And
one can have either a constructor or destructor without the other.
Second, it is false as well that dynamic allocation is required
for polymorphism. Objects may be created dynamically on the heap,
automatically on the stack, or statically in fixed memory, and
they will all act polymorphically if they are part of a polymorphic
hierarchy.

> Robert Dewar was warning against the use of Controlled types because they
> impose an overhead which may not be necessary.  If your design uses no
> dynamic allocation you may not need the facilities of Controlled types.

I don't remember that thread, but I assume that he is correct.
I also assume that he may at this moment be writing to correct
your mistakes just as I am!