xyz::operator xyz &() gets called implicitly. I'm told that it shouldn't. Is this intended behaviour and will it stay? $ LC_ALL=C gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3-20070608/configure --prefix=/opt/unstable/gcc-4.3-20070608 --enable-languages=c,c++ --disable-multilib Thread model: posix gcc version 4.3.0 20070608 (experimental)
Created attachment 13857 [details] File that compiles unexpectedly, without warnings (no #includes)
And why do you think it is not? I don't have access to my copy of the standard but I think this is valid thing to do.
I don't have a copy of the standard at all, unfortunately, but I was referred to [12.3.2/1 p.6]. If I understood correctly, the problem being that implicit conversions shall not take place for the class or a base class of the type.
I should note that I do NOT want to see this bug fixed. I would prefer to hear that you won't "fix" it at all. So I can exploit this behavior as there is no standards-compliant way of achieving the same results.
The standard is unclear about exactly why this is ill-defined. Does the conversion operator take part in overload resolution (and then be rejected, if it is selected), or is it never entered into the overload set. I shall query CWG.
(In reply to comment #4) > I should note that I do NOT want to see this bug fixed. I would prefer to hear > that you won't "fix" it at all. So I can exploit this behavior as there is no > standards-compliant way of achieving the same results. Is it possible that rvalue references will give you an alternative for the desired effect? See the relevant papers linked to from here: http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2291.html
(In reply to comment #6) > (In reply to comment #4) > > I should note that I do NOT want to see this bug fixed. I would prefer to hear > > that you won't "fix" it at all. So I can exploit this behavior as there is no > > standards-compliant way of achieving the same results. > > Is it possible that rvalue references will give you an alternative for the > desired effect? See the relevant papers linked to from here: > > http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2291.html > This would mean that instead of A::A(A &), I wrote A::A(A &&) and passing temporaries would automatically work? (Not sure if I correctly understand the r-value reference proposal.)
(In reply to comment #7) > (In reply to comment #6) > > Is it possible that rvalue references will give you an alternative for the > > desired effect? See the relevant papers linked to from here: > > > > http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2291.html > > > > This would mean that instead of A::A(A &), I wrote A::A(A &&) and passing > temporaries would automatically work? That's correct. Rvalues would bind directly to the 'A&&' parameter; you could even have two ctors: struct A { A(const A&); // copy ctor A(A&&); // move ctor }; ...and when you initialize an 'A' with an rvalue, overload resolution will select the move ctor.
See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939 So it seems you should be able to play with it now.
(In reply to comment #9) > See also: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939 > > So it seems you should be able to play with it now. > Unfortunately, I have to support older GCC version (like 4.0 and 4.1) for now.
Nathan, shall we close this?
This appears resolved. 32658.ii: In function 'void bar()': 32658.ii:12:6: error: invalid initialization of non-const reference of type 'xyz&' from an rvalue of type 'xyz' foo(xyz()); ^~~~~ 32658.ii:9:6: note: initializing argument 1 of 'void foo(xyz&)' void foo(xyz &); ^~~ which looks right to me. Now we have rvalue refs, one can DTRT (doesn't help Aristid thoug).