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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ra!uvaarpa!software.org!blakemor From: blakemor@software.org (Alex Blakemore) Newsgroups: comp.lang.ada Subject: Re: Reference vs. copy semantics in passing parameters Keywords: Ada Message-ID: <1991May16.135103.1688@software.org> Date: 16 May 91 13:51:03 GMT References: <2725@sparko.gwu.edu> <2742@sparko.gwu.edu> Organization: Software Productivity Consortium, Herndon, Virginia List-Id: 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. 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 ? 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); 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; Unless C++ prevents the assignment to another pointer above, then the feature can be easily subverted (purposely or accidently). that means callers have to a. trust that the body really obeys the implication in the parameter mode to not update the referenced object or b. examine the body to make sure. Since the new mode cannot be really trusted (as defined above), it doesnt really aid in reasoning about a program's behavior. It can prevent some simple errors that are relatively easy to spot (e.g. p.anything on lhs of assignemnt) but can't prevent the more tricky types of errors. It can even do harm by giving a false sense of assurance. 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. -- --------------------------------------------------------------------- Alex Blakemore blakemore@software.org (703) 742-7125 Software Productivity Consortium 2214 Rock Hill Rd, Herndon VA 22070