Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!att!dptg!ulysses!andante!alice!bs
From: bs@alice.UUCP (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: Variables sized objects
Message-ID: <10253@alice.UUCP>
Date: 19 Dec 89 00:25:05 GMT
References: <1040@dutrun.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 67



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.