QtD is suspended
Steven Schveighoffer
schveiguy at yahoo.com
Fri Sep 17 10:01:08 PDT 2010
On Fri, 17 Sep 2010 12:39:06 -0400, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> On 09/17/2010 09:02 AM, Max Samukha wrote:
>> One example is the semantics of clear() and scoped(). As I understood
>> from one of your posts, you agree that resurrecting the destroyed object
>> by calling its default constructor is objectionable. However, no further
>> action followed. So we are at a loss whether you have a better solution,
>> are still thinking about one, don't have time to change the
>> implementation or don't want to change the thing because it is engraved
>> in TDPL. The same applies to 'scoped' moving the object.
>
> Good point. Also, clear() has been a favorite topic on #d because it's
> good evidence of my incompetence.
One bad decision does not mean incompetence unless you're in politics...
> The intent of clear(obj) is rather simple. It's supposed to put obj in a
> well-defined, destroyable state that does not allocate resources. It's
> the type system's last-ditch effort to preserve safety while at the same
> time releasing all object state.
>
> Currently, clear() works incorrectly for classes, where it invokes the
> default constructor. SVN doesn't assign the blame to me, but the
> decision does originate in discussions I took part in. clear() shouldn't
> call the default constructor of the class because then the class object
> is free to allocate resources once again. What it should do is to blast
> the default initializer for each field in the class. That's a
> well-defined state that doesn't allocate resources - great.
>
> There are two problems with that state. One, the state might fail the
> invariant of the object, but that's expected - once you called clear(),
> you leave an empty shell behind that's unusable unless you reseat
> something into it.
>
> Second, calling the destructor again from that state is problematic
> (because of failing the invariant) and the GC calls the destructor. This
> is also solvable: the GC might memcmp() the state of the object against
> its default state. If comparison comes positive, the destructor is not
> invoked. We need to be careful that doesn't impact collection times.
Slightly OT here, but memcmp isn't necessary. We have a couple easy tools
at our disposal. One I've suggested in the past -- zero out the vtable.
This makes a loud error if you try to use the object again (and I even
think Sean added stack traces to null pointer violations recently), plus
gives no access to the destructor (easily detectable by the GC).
The other I just thought of, each object memory block has a GC flag
(FINALIZE?) that indicates it should run a destructor. Just clear that
flag. This may need some optimization, I think at the moment you need to
take the GC lock.
If you want to continue this discussion, move to D newsgroup probably...
-Steve
More information about the Digitalmars-d-announce
mailing list