On Mon, 09 Aug 2010 21:52:10 -0400, Michel Fortin
<[email protected]> wrote:
On 2010-08-09 21:20:31 -0400, Andrei Alexandrescu
<[email protected]> said:
clear() would not subvert the type system.
Oh sure it does!
1. You acknowledged yourself one of my argument a few days ago that if
the class has an immutable member it'll be wiped out. Someone else
somewhere could have a reference to that member, and it's value will
change which could cause bad things..
This is a good point. But here is the thing -- when you are calling
clear, you are saying "Nothing in this program is using this data any
more". The point of not actually deleting the memory is to 1) not throw a
monkey wrench into the natural rhythm of the GC, and 2) to ensure any
dangling pointers do not corrupt memory. Essentially, if you clear an
object, and then use that object, the behavior should be undefined.
Note that delete has the same problem, but by the time you reference that
dangling pointer, it may have been reallocated, so you might be corrupting
memory in use.
I think it's fine to have clear break immutability, since to call clear,
and then to access the data should be undefined.
2. If someone somewhere has a reference to an object, clearing that
object is basically the same as replacing that reference with a
reference to a new, uninitialized object. This could break invariants of
any code still using that reference.
As any undefined behavior could. If you don't want to cause this problem
then either ensure your not using it, or don't use clear ;)
In normal times, those invariants could be protected with judicious
usage of 'private', 'protected' or 'package' in the object (or something
more sophisticated), but all that gets subverted by clear().
clear is a replacement for delete. Would you expect delete to keep
invariants of dangling pointers alive?
So clear() can have long-reaching effects (break program invariants) if
used at the wrong place, and it's difficult to protect against people
using it at the wrong place.
I know for one thing that clearing any object used by the D/Objective-C
bridge is a potential crasher (if you call a function on a cleared
wrapper). I would suspect the same for QtD.
Undefined, undefined, undefined :)
-Steve
