From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-02-11 15:18:44
David Abrahams wrote:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>
>> This behavior is perfectly safe and reasonable, _provided that_ the
>> auto_ptr loophole does not exist. It was never intended to
>> exist. Everything that is based on it goes against the core logic of
>> the language.
>>
>> Does it make sense?
>
> I guess so. I still don't know what the loophole is. I knew once,
> but that knowledge is ghostly and flits away quickly.
The auto_ptr loophole enables two user defined conversions in a row,
something that is usually forbidden. The reason, as I understand it, is that
when the source and target types are the same, parts of the standard are
written under the unspoken assumption that a copy constructor will perform
the copy; however, other parts (past the "check for two UDC" point) simply
apply the usual overload resolution rules, choosing the X -> ref -> X
sequence due to the copy constructor being nonviable.
>> Once we are on the topic. As I understand it, 8.5.3 is intended to
>> allow compilers to place ROM-able temporaries in ROM. Consider:
>>
>> void f(int const & x);
>>
>> int main()
>> {
>> f(5);
>> }
>>
>> The compiler can place a temporary of type "int const" and value 5
>> in ROM, and pass its address to f. Similarly, in:
>>
>> struct X
>> {
>> int i;
>> X(int i): i(i) {}
>> };
>>
>> void f(X const & x);
>>
>> int main()
>> {
>> f( X(5) );
>> }
>>
>> the compiler is allowed to construct a "X const" with a value of
>> X(5) at compile time and place it in ROM.
>
> OK. Relevance?
I seem to recall attempts to strike down that second bullet of the first
bullet of the second bullet of 8.3.5/5 :-) and demand that the reference be
bound to the object represented by the rvalue. At the time, this seemed a
reasonable idea, but then I came up with the ROM example. Maybe it's already
widely known and I'm just reinventing the wheel.