If I define a copy constructor as T(T&) rather than the correct T(const T&), I'll end up with messages of the form:
| > keyed_obj.hh:159: error: no matching function for call to 'CxnIndex::CxnIndex(CxnIndex)' | > Indeces.hh:150: note: candidates are: CxnIndex::CxnIndex(CxnIndex&) which is baffling to most users because usually an argument of type T& is acceptable for a call with a type T argument. It doesn't help that there isn't a call in the source code -- the compiler generated a copy constructor reference, for reasons that may not be obvious from reading the source. It would be helpful if the compiler could guide the user to the fix, perhaps by doing one or both of the following: a. Warn on the declaration of T(T&) with a message along the lines of "that looks like a copy constructor, but it really should be T(const T&)" b. In the message I quoted above, mention that a T(const T&) is needed and was not supplied. -- Summary: Diagnostic for misdefined copy constructor is not particularly clear Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pkoning at equallogic dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-netbsd GCC host triplet: i386-netbsd GCC target triplet: mipsel-netbsdelf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21631