[C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies

[David Abrahams]

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 19 Sep 2003 at 10:57, David Abrahams wrote:
>
>> > My main bugbear with GCC is it forces const temporaries. This makes
>> > destructive copy construction semantics severely castrated, so much
>> > so you usually must #ifdef hack in a copy constructor taking a const
>> > reference just on GCC :(
>> >
>> > I know all the usual arguments about temporaries should be const. I
>> > strongly disagree. 
>> 
>> Disagree all you want.  A C++ compiler should conform to the standard
>> or it isn't C++.  Which compiler is correct in this regard is not open
>> to debate.
>
> My 1996 draft (which is all I can afford) 

$18 is beyond your means?

> doesn't say all temporaries are const. 

Neither does the C++98 standard.  What they *both* say is that
a non-const reference won't bind to an rvalue (8.5.3/5) and that
temporaries are rvalues (3.10/5,6)

> I take it this has changed?

No change.

> I don't get why this was done. Sure making temporaries created from a 
> conversion cast const is a good idea but temporaries returned from a 
> function

user-defined conversion operators are functions.

> or produced through the action of an operator are quite different
> beasts - there is no danger of state changes getting lost in an
> unintended way.  And besides, some objects you use clearly can have
> only one instance.

Read D&E if you want to know, and don't ask me because I had nothing
to do with it ;-)

>> > where that rope /could/ be used for something useful and no other
>> > better way is available for doing it. And destructive copy
>> > construction is clearly implied when it takes a non-const reference.
>> 
>> Maybe you would be interested in a proposal I co-authored:
>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm
>
> I support that document. My only concern is that using && as the 
> token is a bad idea because if the proposed extension to permit 
> taking references of references goes through

It already went through.

> this might cause confusion in the debugger.

There's no confusion possible.  && is already a token and unless &&
gets the additional meaning we proposed X&& will be a syntax error
when X is a type.

> I would suggest ~& is much better. The ~ says it's destructive/move 
> and the & denotes a reference. Much clearer.

~& was my idea but there are problems with it according to the
compiler implementors (I forget what; ask EDG).


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com