This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: error: no matching function for call to `Anton::Anton(Anton)`
- From: Eljay Love-Jensen <eljay at adobe dot com>
- To: e dot karge at struction dot de, gcc-help at gcc dot gnu dot org
- Date: Wed, 08 Oct 2003 13:31:32 -0500
- Subject: Re: error: no matching function for call to `Anton::Anton(Anton)`
Hi Eric,
You should put a copy constructor in your Anton class.
"Anton(Anton& a)" isn't a copy constructor. You need an "Anton(Anton const& a)".
If Anton objects cannot be used in a copy constructor, then there are certain operations which Anton objects cannot perform.
It appears that you hit upon one of them.
If the "some code which _needs_ to modify a" is doing so in such a way that the LOGICAL state of the object is not affected, then those data members which are being modified should be marked as "mutable" in the class itself. For example, certain reference counting schemes. Another example is the std::string's c_str() method, which is a const method.
If the "some code which _needs_ to modify a" does modify the LOGICAL state of the Anton object being copied from, then that's not kosher for use in a copy constructor. C'est la vie.
The Standard C++ Library auto_ptr<> is an example of a template class which modifies the state of the copied-from object. That's one of the reasons that auto_ptr<>'s and STL don't mix (by-and-large).
Or to say it another way, auto_ptr<> doesn't satisfy the contract requirements of STL containers. Generally speaking. If someone is REALLY careful, they may be able to use auto_ptr<> in a STL container... but I tend to recommend against it. The BOOST <www.boost.org> folks have some smart pointer classes that are STL friendly.
HTH,
--Eljay