🚀 go-pugleaf

It seems to me that much of the trouble comes from exporting the details of an
object's internal representation from a function that the compiler can apply
automatically to a temporary ojbect.  Simple prevention can avoid most of the
problems:

   1. Avoid exporting the details of an object's internal representation,
      especially when the offending function can be applied automatically by
      the compiler such as the famous String :: operator const char*().
      It is interesting to note that the ANSI String proposal renames this
      function to const char* String :: cStr().

   2. Try to write your code to avoid the generation of temporaries.  

Of course one can always generate cases where recommendation 2 will fail you
and I personally don't like the idea a lot as it can really cramp your style.
So here is a modest proposal:

   Make temporaries const objects
   Avoid problems due to their early destruction by making dangerous
   value taking operations non-const.

A compiler using the const temporary approach and a thoughtful programmer
can combine to make code like that of the String example safer:

   class String { public:
       operator const char*(); // NON-const
       String( const char* );
       ...
   };

   String h( "hello " ), w( "world" );
   const char* p = h + w;
   //
   //  compiler flags this statement:
   //     Error: non-const member function applied to (const) temporary object.

Of course this could break a lot of existing code.

-- 
John Hickin      Bell-Northern Research, Montreal, Quebec
(514) 765-8888   bnrmtl!john@larry.mcrcim.mcgill.edu