clear bug?

[Steven Schveighoffer]

On Mon, 05 Sep 2011 22:05:56 -0400, Dan Olson <zans.is.for.cans at yahoo.com>  
wrote:

> Jonathan M Davis <jmdavisProg at gmx.com> writes:
>
>> On Tuesday, September 06, 2011 02:12:11 Andrej Mitrovic wrote:
>>> On 9/6/11, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>> > Why would you
>>> > ever try and use an object that had been cleared?
>>>
>>> TDPL, that's why. Things might have changed but how would someone new
>>> to D know that?
>>
>> I really don't pay much attention to clear, since I rarely use it, and  
>> I don't
>> know why you'd ever actually want to try and use an object that you  
>> cleared. I
>> do remember discussions about making it clear out the vtable, since you  
>> _want_
>> it to blow up after it's been cleared rather than have an invalid  
>> object work
>> on some level. Rereading the relevant section in TDPL though, it does  
>> look
>> like it describes a different situation than seems to have been  
>> ultimately
>> settled on. So, I guess that I don't know exactly what the situation  
>> currently
>> is or what it's supposed to be. But I wouldn't have expected clear to  
>> result
>> in a valid object. But clearing out the vtable at least makes it blow up
>> nicely instead of doing who knows what with memory when you try and call
>> functions on an invalid object. So, if the ultimate goal is just to  
>> make it
>> memory safe, then both clearing out the vtable and the situation that  
>> TDPL
>> describes do the trick, though deleting the vtable actually helps tell  
>> you
>> that you've used an object when you shouldn't, whereas TDPL's  
>> description
>> results in using the object succeeding, which probably isn't a good  
>> thing.
>>
>> - Jonathan M Davis
>
> Thanks for the clearification.
>
> It was based on TDPL 6.3.5 that I thought the idea of clear() was to
> clean up but leave the thing in an initialized state.  And because
> clear() on dynamic arrays and other types seems to be be intended to
> leave you with a valid and initialized object.  Or is that not true?

There is a large issue with leaving a class in a "valid state".  A class's  
valid state only occurs after a constructor is called.  The same is not  
true for structs.

So we have problems:

1. what if the class has no default constructor?  What to use as  
parameters?
2. if it does have a default constructor, what if that default constructor  
is costly, or allocates more resources?  Didn't we just designate it for  
destruction?

The point of clear is to call the *destructor*, not the constructor, and  
not deallocate the memory.  We could have left the object data in its init  
state (i.e. before any ctor is called), but that would leave the false  
impression that it's valid.  By clearing out the vtable, we guarantee it's  
not valid and that any usage will create a huge noticeable error.

Basically, if you clear an object, or an array, or anything, you are  
saying "I no longer need this, GC, collect this when you can" you  
shouldn't use it again unless you reinitialize it.  All dtors are called,  
and it's invariant may be invalid.  The only thing that's left is a  
placeholder to ensure you cannot corrupt anything else.

However, you can reassign it to a newly initialized struct or object, and  
you can continue to use it after that.

-Steve