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

Hi Andriy,

I'm responding to this again in the hope that someone with a
better grasp of C++ than me will be able to explain to me how
this situation is avoided.  This is one of the big reasons why
I rejected C++ after some seven or so years of exclusive use.
That was back in about 1996 or so, so I admit that things might
have changed or improved in the meantime.)  This is almost
certainly off-topic for -current, so please ignore the rest of
this thread if it doesn't interest you...

On Mon, Feb 16, 2009 at 10:57:12AM +0200, Andriy Gapon wrote:
> on 16/02/2009 07:56 Andrew Reilly said the following:
> This is the first time in my life that I hear about temporary objects on 
> the heap and/or memory leaks through temporary objects. Either you are 
> remembering a bug in some ancient C++ compiler or you are referring to 
> some buggy code.

Well, code that results in a memory leak (or dangling reference)
is buggy by definition, but how to avoid it, in general?  I'm
not about to write some examples for the purpose of this
discussion, so google searches will have to do.

The first google search that I did for "C++ argument promotion
temporary objects" came up with this link:
http://www.icce.rug.nl/documents/cplusplus/cplusplus09.html

If you skip down to the StringArray example, you can see that
a new String object is automatically constructed to cast the
char* to fit the String &operator[](size_t idx) method.  Now,
in this instance the constructed object has somewhere to go: a
reference is being stored in the array.  So the temporary object
must have been constructed on the heap.  But other methods on
other objects may require String arguments, invoking the same
constructor, but they might not record the reference and so it
won't be cleaned up later.  Or will it?

Conversely (and perhaps you will see my confusion): this other
paper:
http://codewrangler.home.comcast.net/~codewrangler/tech_info/cpp_compiler_tips.html
Under the section "Lifetime of Temporary Unnamed Objects" there
is a discussion about such temporary objects being reclaimed by
the language runtime as they go out of scope of the expression
in which they were created.  So that sounds like either stack
allocation or heap allocation with explicit destructors inserted
when leaving scope.  Either way, that would appear to render the
StringArray example above comprehensively broken, no?  (The
array would contain a dangling reference when the temporary
String object is reclaimed at the end of the expression scope.)

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.

> As to the conversions through constructors, conversion operators and 
> implicit type promotions - I personally had much less incidents because 
> of that than I had incidents in C with passing/casting something 
> incorrect via void*. This is to say that C++ is far from perfect and 
> there are languages that are much better than it, but C is even (much) 
> less perfect.
> And of all languages out there, I think, that C++ comes closest to a 
> definition of "enriched", "better", "fortified" C. Which implies much 
> lower entry barrier (and possibility for limited/gradual introduction).

I think that C++ was a noble try at an improvement in 1985, but
has far too many warts and sharp edges for general use, and has
been comprehensively superceded by languages that use garbage
collection.  Yes, C has sharp edges too, but it also has less
magic: it is much (much) closer to assembly language in that
regard.  Sometimes that is appropriate (I think that it is,
where operating systems are concerned), and sometimes not.  When
I'm not writing in C, I use python or scheme (or Matlab), not C++.

Luckily, hardly anyone cares what I think :-)

Cheers,

-- 
Andrew