Boost logo

Boost :

From: Alberto Barbati (abarbati_at_[hidden])
Date: 2004-03-09 00:41:23


Thorsten Ottosen wrote:

> "Alberto Barbati" <abarbati_at_[hidden]> wrote in message
> news:c2hhhi$lgs$1_at_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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk