🚀 go-pugleaf

In article <1992Sep2.143007.5655@bnrmtl.bnr.ca>, john@bnrmtl.bnr.ca (John Hickin) writes:
|> 
|> 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* );
|>        ...
|>    };
|> 

Making the function that gives the pointer to char a non-const is a mistake.
The function may modify the underlying representation, but it certainly
does not modify the represented character sequence.  There is no
reason that I shouldn't be able to apply it to a const String

|>    String h( "hello " ), w( "world" );
|>    const char* p = h + w;

A careful programmer might have written

	const String h("hello "), w(" world") ;

and be surprised that  (const char*)h isn't allowed.

String with a conversion operator seems to have caught on in this
newsgroup as "the" example for discussing lifetime of temporaries.
It should be noted that because of all the problems associated with
such an operator the x3j16 library working group has decided that
this functionality will be provided by an ordinary member function
and not by a conversion operator.

I believe the use of the implicitly invoked conversion operator
obscures the issue of lifetime of temporaries and that we should 
be writing the above example out in full as.

	const char* p = (h+w).pchar();

  -- Jerry Schwarz