David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> 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.