Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk