Re: Reference vs. copy semantics in passing parameters

[sakkinen@jyu.fi (Markku Sakkinen)]

In article <1991May16.135103.1688@software.org> blakemor@software.org (Alex Blakemore) writes:
>In article <2742@sparko.gwu.edu> mfeldman@seas.gwu.edu () writes:
>> In article <jls.666659373@yoda> jls@yoda.Rational.COM (Jim Showalter) writes:
>> In C++, you can declare not only the pointer constant but the pointed
>> to construct constant as well. This allows passing by reference in a
>> read-only manner, which is NOT possible in Ada at present.

I think the original poster has erred here: nothing prevents an Ada
implementation from passing 'in' parameters by reference whenever that
is most convenient or efficient.  (I think Ada's 'in' parameters are
a significant improvement over the value parameters of Algol and Pascal.)
However, the 'pointer to constant' feature of C++ may be
worth discussing in this newsgroup, because its applicability is _not_
restricted to parameter passing.

The meaning of 'const' in C++ should be noted.  If Ada had the same approach
to constants, we could have something like:
   type object;
   type immutable is constant object;
   type ptr_to_object is access object;
   type ptr_to_immutable is access immutable;
An 'immutable' value could be directly assigned to an 'object' variable,
and a 'ptr_to_object' value to a 'ptr_to_immutable' variable.
Thus, types like 'ptr_to_immutable' are, strictly speaking, not
"pointer to constant" types, but rather "non-modifying pointer" types:
the object pointed to may well be modified, but not via this reference.

>This sounds like a nice safety feature but can callers really rely on it ?
>Even if the C++ language prevents updating the object if the pointer is
>declared appropriately, does it prevent assignment to a normal pointer
>which will allow the referenced object to be updated ?

Of course, you cannot _really_ rely on anything in a C-based language:
by fooling around with pointers you can even overwrite _code_ unless
the operating systems protects code segments.  Such things are "illegal"
in principle, although it is difficult to imagine a C or C++ implementation
that could catch them.  --  But indeed, the kind of assignment (or cast)
that you asked about is fully _legal_ C++ according to the most
authoritative definition!

>I know very little about C++, but will attempt to pose an argument
>against this feature in Ada terms.  Perhaps someone with C++ knowledge
>could explain why this feature is really desirable ?
>
>Consider this Ada flavored example, where constant means the referenced
>object may not be updated.
> ...
>procedure look_at_object (p : in CONSTANT ptr_to_object) is
>  temp : ptr_to_object;
>begin 
>  temp := p;  -- is this legal in C++ ?
                  ^^^^^^^^^
>  p.all := anything;
>end;

An assignment corresponding to the above is _not_ legal in C++,
the legal case would correspond ("Adaified") to:
   temp := ptr_to_object (p);
Using my previous type declarations, the procedure header would be:
   procedure look_at_object (p : in ptr_to_immutable)

Actually, this whole example is not very convincing of the need
for such pointer types.
If we take the above C++-like meaning of "non-modifying pointer",
the procedure could just as well be declared as
   procedure look_at_object (o : in object)
If we would like a true "pointer to constant" meaning, then:
   procedure look_at_object (i : in immutable)

>Unless C++ prevents the assignment to another pointer above, then the feature
>can be easily subverted (purposely or accidently).  [...]

Yes, but I think that the feature combined with some programming discipline
is nevertheless useful.  Of course, if this feature were to be
introduced in Ada (or some other language with stronger typing than C++),
one would probably not allow such dangerous conversions.
(They fit the general spirit of C and C++, but not the spirit of Ada.)

> ...
> Of course this argument falls apart if you invent more rules to prevent
>making copies of such pointers in anyway, but can you do that without
>making the language even more complex?  Besides the assignment you'ld have to
>make sure parameters of such modes could only be passed by the same mode
>to other subprograms.

Since "pointer to constant something" is regarded as a distinct type
and not as a specific device for parameter passing, I don't think it
would cause any "cascading" complexity;  existing type rules would
be quite sufficient.

Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)