Re: weeding out c++ keywords from sys/sys

On Tue, Feb 17, 2009 at 11:13:42AM +0200, Andriy Gapon wrote:
> on 17/02/2009 03:52 Andrew Reilly said the following:
> In general the following hold true:
> 1. temporary objects always have automatic scope which means that they 
> are destroyed as soon as a scope where they were needed is left; 
> compiler generates that code;
> 2. compiler would not allow to assign a pointer to a temporary object; 
> it only allows to initialize a const reference with a temporary object, 
> in which case the scope of the temporary is extended to be the same as 
> the scope of that reference variable.
> 3. constructor of a temporary variable can, of course, allocate 
> something on the heap (e.g. some sort of a buffer); its destructor must 
> deallocate that memory; if it doesn't, then this just buggy code, 
> nothing to do with temporaries.

OK, that seems pretty clear (if quite limited, compared to more
dynamic languages).

> >This issue is, I believe, undecidable at compile time, and
> >goes by the name "escape detection".  It is why *all* modern
> >object-oriented languages require garbage collection.  Some
> >recent JIT runtime systems go to a great deal of effort to prove
> >that references to some objects do not "escape" the block, and
> >so can be stack-allocated and eagerly collected.  That requires
> >whole-program analysis, which is something that a JIT can fudge,
> >but which a C++ compiler doing separate-compilation can't.
> 
> No, no. C++ has stricter and simpler rules. It tries very hard to not 
> allow a programmer to let any pointers/references to temporary objects 
> escape. Of course, a sufficiently good programmer can still manage to 
> make it happen, but then it's a programmer's problem - the temporary 
> object would still not escape and be destroyed, the pointer/reference 
> would point to garbage.
> It's like in C - you can return a pointer to a struct on stack, but that 
> wouldn't make that struct magically be transfered to heap and persist, 
> it would just make the returned pointer point to bad data.

Thanks for that clear explanation.  I hadn't noticed that
the array of Strings was already allocated, so there wasn't
any allocation going on of the temporary.  I guess that
the restriction for const references in these sorts of
situations ensures that any callee that wants to maintain a
pointer/reference to the source has to do a copy.

> I hope I managed to explain at least something, not made too many 
> mistakes (I am not a big C++ expert recently) and not added to the 
> confusion :-)
> 
> -- 
> Andriy Gapon

Thanks very much (both you and Christoph) for the explanation.
I think that I have a much better understanding of where C++
is coming from, now.  It is, of course, not too different
from the sorts of things that one does in C, just with more
under-the-covers magic to help things along.  I don't think that
it's to my taste though, and the incredible complexity and ugly
syntax will ensure that I continue to avoid it as much as I can.
Maybe when the follow-up to C++0x adds garbage collection...

Cheers,

Andrew