TDPL: Manual invocation of destructor

[Michel Fortin]

On 2010-08-10 11:12:32 -0400, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> 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.

But is using the collection after calling clear() undefined behaviour 
or not? Please make up your mind.

Seriously, if you're using "clear" to mean "empty that collection" at 
some place and using "clear" to mean "wipe this object's data, I assert 
no one will use it anymore" at others, then you've conflated two 
totally different concepts. The first one is something pretty safe to 
do, the later requires a lot more care, especially since it can break 
the type system and bypasses protection attributes (immutable and 
private members are wiped out too).


>> 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?

Catching bugs early. Calling clear() on any object you share through 
the D/Objective-C bridge will most likely result in a crash later if 
the Objective-C side still holds a reference to it somewhere, or if you 
try to use the object again. The bridge has some expectations about the 
lifetime of the objects it manages, you shouldn't be allowed to break 
those with an innocuous-looking function.

I would assume the same applies to QtD. In fact, any program that wants 
to protect invariants that go beyond the scope of a single object might 
want to disable clear().

So not all objects should be clearable.


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

Indeed.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/