Thorsten Ottosen wrote:
"Alberto Barbati" <abarbati@iaanus.com> wrote in message news:c2hhhi$lgs$1@sea.gmane.org...
Thorsten Ottosen wrote:
[snip]
The cases where a call to a destructor is actually important beacuse it
does
some non-trivial work, one really need to ensure not even temporary objects of the type exists. That's one of
the
capabilities my smart containers will allow, ie, "overwriting" really
means
destructing and replacing.
I'm sorry, I don't understand what you are trying to say here. I started my sentence with "For primitive types"...
yeah, I could have said it better :-) What I meant was that copy-behavior is ususally incompatible with non-trivial destructors. What I mean by non-trivial destructors is that eg. a file is closed or a connection is closed. In those cases making temporaries and copies is not good: you want more explicit control over when the destructor is called. (hence you need a container of heap-allocated objects and not something like vector<Socket> ) For most value-like objects we have the opposite situation and we don't mind if an object is overwritten by assignment of if destructors are called.
I learned that good programming practice is that if a class requires a non-trivial destructor it should either implement both the copy constructor and the assignment operator or declare them private and leave them unimplemented. Moreover, if either the copy constructor or the assignment operator is defined, both of them should. I never found a case where it was worth violating this practice, maybe you have such an example? Fact is that I still fail to understand why a class that has a meaningful copy constructor cannot implement a meaningful assignment operator with the same semantic as dtor+copy ctor, but more efficiently. Alberto