TDPL: Manual invocation of destructor
schveiguy at yahoo.com
Tue Aug 10 08:12:32 PDT 2010
On Tue, 10 Aug 2010 10:48:06 -0400, Michel Fortin
<michel.fortin at michelf.com> wrote:
> On 2010-08-10 10:19:25 -0400, "Steven Schveighoffer"
> <schveiguy at yahoo.com> said:
>> On Tue, 10 Aug 2010 10:11:21 -0400, Michel Fortin
>> <michel.fortin at michelf.com> wrote:
>>> On 2010-08-10 08:11:21 -0400, "Steven Schveighoffer"
>>> <schveiguy at yahoo.com> 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.
More information about the Digitalmars-d