[boost] Re: Formal Review: Circular Buffer

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