TDPL: Manual invocation of destructor

[Steven Schveighoffer]

On Tue, 10 Aug 2010 10:48:06 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2010-08-10 10:19:25 -0400, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> On Tue, 10 Aug 2010 10:11:21 -0400, Michel Fortin   
>> <michel.fortin at michelf.com> wrote:
>>
>>> On 2010-08-10 08:11:21 -0400, "Steven Schveighoffer"   
>>> <schveiguy at yahoo.com> said:
>>>
>>>> Undefined, undefined, undefined :)
>>>  So we agree on that. That's exactly what I was trying to prove to   
>>> Andrei. Using clear() can break program invariants, break the type   
>>> system (immutable members) and so on, even though I admit it can be   
>>> useful at times.
>>>  **** So why give it a so innocuous-looking name such as "clear" !!  
>>> ****
>>  I think that book has shipped.
>
> That's not really an answer to the question. The answer I expected was  
> more that it seemed innocuous at the time, even though now it appears  
> more harmful. To me it's the C++ copy constructor all over again...
>
> Can we really not fix it before every one start using it? In other  
> words, which is worse: having something in the book deprecated just a  
> few months after publication? or having hundreds of programers using  
> clear() thinking it is innocuous?

I guess I don't agree that it's badly named, or I don't really care what  
it's named.  Clear sounds fine to me.  I use clear to clear out the data  
in a collection, seems about the same.

> At the very least I'd like to have a way to disable it for certain  
> classes (by throwing an exception when you try).

Hm... do you have a good use case?

A hook to indicate "hey object, clear is being called, not a GC collection  
cycle" may be useful for other purposes as well.

-Steve