clear bug?

[Dan Olson]

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?

Dan