ben@duttnph.tudelft.nl (Ben Verwer) (12/19/89)
This really makes me angry. A new language comes out. A book describing the language is written. You start to use the language in accordance with the book. On some pages optimalizations are advised, e.g. page 165, Stroustrup. "This implies that two allocation operations are necessary to create such objects on the free store and that every access to stored information will involve an extra indirection. (...) this is not necessary." You use the optimization. 3 years later a new version of the language comes out. Your "old" code does not compile anymore. You begin to suspect the worse and yes, Jonathan Shapiro writes: > (...) > First, this object cannot be built on a stack, because it's length > isn't known to the compiler. The semantic implications of a heap-only > object aren't clear. > Second, the implementation of such objects tends to be convoluted to > later readers. > Finally, the savings obtained tends to be *very* small. > (...) Optimization was useless, throw it out, too bad for the users... ----------------------------------------------------------------------------- Ben Verwer Lorentzweg 1 Pattern Recognition Group 2628 CJ Delft Faculty of Applied Physics The Netherlands Delft University of Technology +31(15)783247
bs@alice.UUCP (Bjarne Stroustrup) (12/19/89)
Ben Verwer @ Delft University of Technology, The Netherlands writes > This really makes me angry. > A new language comes out. > A book describing the language is written. > You start to use the language in accordance with the book. > On some pages optimalizations are advised, e.g. page 165, Stroustrup. > "This implies that two allocation operations are necessary to create > such objects on the free store and that every access to stored > information will involve an extra indirection. (...) this > is not necessary." > You use the optimization. > > 3 years later a new version of the language comes out. > Your "old" code does not compile anymore. > You begin to suspect the worse and yes, Jonathan Shapiro writes: > > > (...) > > First, this object cannot be built on a stack, because it's length > > isn't known to the compiler. The semantic implications of a heap-only > > object aren't clear. > > Second, the implementation of such objects tends to be convoluted to > > later readers. > > Finally, the savings obtained tends to be *very* small. > > (...) > > Optimization was useless, throw it out, too bad for the users... There is a couple of inaccuracies here. First - and probably most importantly - feed your code to the latest AT&T C++ compiler and you will find that the example of page 165 and equivalent examples compile and run exactly as it did using the original version. Secondly, the mechanism that is used ``assignment to the `this' pointer'' is only supported for compatibility reasons. There is a new mechanism that in almost all cases is surperior. Most programs using the ``assignment to the `this' pointer'' can be easily recoded to use the new mechanism. The explanation of the problems with the ``assignment to the `this' pointer'' and how to cope with them was described in a paper presented to the C++ conference in Santa Fe in November 1987 (B. Stroustrup: The Evolution of C++: 1985-1987), a revised paper appeared in the USENIX quarterly ``Computer Systems'' this year and is part of the C++ documentation shipped by AT&T, Apple, Sun, and others. As I pointed out in my book and as Jonathan again pointed out, the optimization you mention can be applied only for objects allocated on the heap. Jonathan does not consider the savings worth while and the resulting code ``messy.'' He also consider not being able to allocate objects on the stack a serious deficiency. He may be right. However, it is very hard to judge what optimizations are worthwhile. I included that example in my book because it was a variant of a trick C programmers were very proud of and I felt demonstrating that it could be done in C++ was relevant. Variants of the trick will remain possible in C++ even if we don't consider the technique quite as clean as some of its alternatives. Finally, I think it is naive to expect every detail of a programming language to remain unchanged during the first years (and C++ has just entered its 5th year as a publicly available language). Unless a language is dead it develops. This is true for all languages; the early years of Fortran and Pascal springs to mind. Naturally, as time goes by the the degree of stability increases (for languages with significant numbers of users.
shap@delrey.sgi.com (Jonathan Shapiro) (12/28/89)
In article <1040@dutrun.UUCP> ben@duttnph.tudelft.nl (Ben Verwer) writes: >This really makes me angry. >... >Optimization was useless, throw it out, too bad for the users... First, the book didn't advocate the approach. It presented it as an alternative. Second, it wasn't optimization that went away. It was an ill-considered feature that went away, namely, assignment to 'this'. Jonathan Shapiro Silicon Graphics, Inc.