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
