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.
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?
A hook to indicate "hey object, clear is being called, not a GC collection
cycle" may be useful for other purposes as well.
-Steve
