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
