Exception to the "Big 3"?

Here's a question:

Take a class for which the default destructor is adequate (the constructor allocated dynamic memory, but uses a member object, like std::auto_ptr, to manage the deletion of the memory)However, this data member should not be shallow copied (that would be bad karma).

To this end, the class tries to explicity disallow any kind copying, by implementing both a copy constructor and an assignment operator (which do nothing), but makes them private (so nobody outside the class can use them).

Normally, the "Big 3" states that if you need any of a custom copy constructor, custom assignment operator, and custom (nontrivial) destructor, you need all of them. Does that still apply here?

Someone said the answer is "yes", but why?

Related question: Now the 2 operators become public, and they are implemented as deep copies (each allocates memory, deep copies, and gives it to the object to manage). Does it need a destructor now?

(Assuming the class won't be derived from, thus doesn't need a virtual destructor.)

#1) I don't think it does apply. You can get by with a copy constructor and not an assignment operator (i think).
#2) As long you know what you're doing (and you seem to), no.

I'm not sure on my answers...

Quote:

---

Originally posted by Cat
Normally, the "Big 3" states that if you need any of a custom copy constructor, custom assignment operator, and custom (nontrivial) destructor, you need all of them. Does that still apply here?

---

Note that the wording is that the class "generally needs all 3 if it needs one of them"....so no hard and fast rule applies

You need the copy constructor and the assignment operator because the compiler will produce one if you dont. These functions will assign and copy using bitwise operations - they will copy a member pointer but not the memory, and will copy auto_ptr members and therefore mess them up.....therefore if you want copy or assignment, implement both, if you want neither you should declare them private and dont implement them

The defined destructor is probably not needed if you are just storing data in an auto_ptr as that member's destructor will sort out the resource management without your intervention. Though if there is the slightest chance of a class inheriting from yours, you of course need a virtual destructor

Maybe this Thread on comp.lang.c++ gives you an answer.

Ahhhhh, that thread I think explained the reason the person I know said a destructor was needed:

Quote:

---

But usually we'll have a std::auto_ptr<Imp> where Imp is an incomplete (not yet defined) class, and hence we'll still have to declare the destructor and define it in the .cc file to enforce that it be non-inline.

---

Essentially, the problem is the default constructor will be inlined, and thus put in client code. But in the client code which actually uses it, the auto_ptr points to an incomplete type, which means the destructor can't operate upon it (after all, it doesn't know HOW to destroy an object based only on a forward declaration).

In thinking about it, that makes sense in the scope of the conversation that the point occured in; I believe that was exactly what he meant.