From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!fuug!news.funet.fi!tukki.jyu.fi!sakkinen From: sakkinen@jyu.fi (Markku Sakkinen) Newsgroups: comp.lang.ada Subject: Re: Reference vs. copy semantics in passing parameters Keywords: Ada Message-ID: <1991May17.134420.17669@jyu.fi> Date: 17 May 91 13:44:20 GMT References: <2742@sparko.gwu.edu> <1991May16.135103.1688@software.org> Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen) Organization: University of Jyvaskyla, Finland List-Id: 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@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)