gcc version 3.3.2 20030908 (Debian prerelease) and gcc version 3.4 20031005 (experimental) accept this invalid code (it's invalid because the copy-constructor is inaccessible): class foo { private: foo(const foo &); public: foo(); }; const foo &bar = foo();
Not invalid code because the copy-constructor is not needed for this case, only the constructor that takes no arguments because bar is "const foo&".
the standard says (in 8.5.3p5): "If the initializer expression is an rvalue with T2 a class type and "cv1/T1" is reference-compatible with "cv2/T2" the reference is bound in one of the following ways (the choice is implementation defined): - The reference is bound to the object represented by the rvalue (see 3.10) or to a sub-object within that object - A temporary of type "cv1/T2" [sic] is created, and a constructor is called to copy the entire rvalue object into the temporary. The reference is bound to the temporary or to a sub-object within the temporary The constructor that would be used to make to copy shall be available whether or not the copy is actually done." I think it's about the copy constructor. If I'm not mistaken, the posted code is invalid according to this quote (although I can't really see the rationale behind it).
Compaq's compiler says this when enabling strict ANSI mode: cxx: Warning: test.cc, line 8: "foo::foo(const foo &)", required for copy that was eliminated, is inaccessible const foo &bar = foo(); -----------------^ So it is not invalid because the copy was eliminated, which to do the compiler is allowed. Maybe we could modify this to a low priority warning request for something similar.
Not really. The code is still invalid (it doesn't matter whether the function call eliminated or not). Consider this: class foo { public: foo(foo &); foo(); }; const foo &bar = foo(); Here, the compiler had to eliminate a function call to a function which doesn't exist. So Compaq's compiler is wrong too: it's not a warning, but an error. Although it's not a serious error :)
Reopening based on the standard.
This is a dup of bug 12226. *** This bug has been marked as a duplicate of 12226 ***