On 2010-08-10 11:12:32 -0400, "Steven Schveighoffer"
<[email protected]> said:
On Tue, 10 Aug 2010 10:48:06 -0400, Michel Fortin
<[email protected]> wrote:
On 2010-08-10 10:19:25 -0400, "Steven Schveighoffer"
<[email protected]> said:
On Tue, 10 Aug 2010 10:11:21 -0400, Michel Fortin
<[email protected]> wrote:
On 2010-08-10 08:11:21 -0400, "Steven Schveighoffer"
<[email protected]> 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
[email protected]
http://michelf.com/
