Xref: utzoo comp.lang.c++:12000 comp.std.c++:675 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!ugle.unit.no!nuug!ifi!jar From: jar@ifi.uio.no (Jo Are Rosland) Newsgroups: comp.lang.c++,comp.std.c++ Subject: Re: distinguishing operator[] on left and right Message-ID: Date: 4 Mar 91 14:11:17 GMT References: <1991Feb28.212419.20920@ndl.com> <1991Mar2.000705.3496@mathcs.sjsu.edu> Sender: jar@ifi.uio.no (Jo Are Rosland) Organization: University of Oslo, Norway Lines: 68 In-Reply-To: horstman@mathcs.sjsu.edu's message of 2 Mar 91 00:07:05 GMT In article <1991Mar2.000705.3496@mathcs.sjsu.edu> horstman@mathcs.sjsu.edu (Cay Horstmann) writes: Surely I am not the first one to propose this one, but here goes anyway. Just as pre- and postincrement operator++ are distinguished by a hidden int argument, could this not be done for lvalue and rvalue operator[]? As someone else already pointed out, the lvalue/rvalue distinction is already achievable within the current language, through the use of an intermediate value returned from operator[]. The problem with this, is optimization. You probably want something like operator[] to be as fast as possible, and to do this in C++ today, you have to create an interface based on separate, inlined, get/set operations. A related example of something that's achievable, but not efficient, is a string concatenation operator. An interface like: String s1 = "foo"; String s2 = "bar"; String s3; s3 = s1 + s2; would probably be a nice way to handle string concatenation, but this can't be done efficiently. Instead you'll probably have to do something like: String s1 = "foo"; String s2 = "bar"; String s3; s3 = s1; s3 += s2; To me, this use of intermediate values -- both compiler generated and as part of class interface implementations -- is a serious problem with C++, due to the performance degradation it leads to. I mean, a very popular first project (and perhaps second and third :-)) after having learned C++, is to create some kind of string class. But how many of those string classes are actually in use? After one realizes one have to choose between a significant performance hit, or a counterintuitive interface, I think many programmers go back to the traditional strdup/strcpy/strcat way of handling strings. It's not really that much to gain by renaming these as operator=, operator+= and so on, since you (and the maintainers of your code) would have to look up the implementations of these operators to make sure there are no hidden surprises concerning things like copying. Which brings me to another problem with C++, and probably the whole OOP paradigm. We're badly in need of some way of precisely specifying interfaces to modules/classes. This specification should include performance of methods, as well as all the interesting parts of their behaviour (sp?). In practice, this should be something halfway between a C++ class header file, and its implementation. Specifications should be standardized and powerfull enough to allow browse/search tools that can aid in finding classes that match criteria like language, a set of operations needed, and performance. Only after this is achieved, can we hope to meet the "software ic" goal of OOP, including things like interchangable software modules. -- Jo Are Rosland jar@ifi.uio.no