On Thu, 15 Jul 2010 00:33:15 +0300, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
All classes have a state where all members are default initialized.
How is that state normally reached (for classes without a default
constructor)?
It is my understanding that you are trying to add something to the
language which would destroy an object without deallocating it (and
deprecate everything that involves on-the-spot deallocation), in order
to allow creating simpler and more efficient garbage collectors.
I'm not adding anything. I am removing a mistake that C++ made (i.e.
conflating destruction with deallocation). And the purpose is not to
assuage or help GCs. The only purpose is memory safety.
The
only correct solution seems to be to call the destructor, and mark the
object instance as invalid. The release version needn't do anything, the
debug version can stomp on the object's memory to make sure that any
code that attempts to access the object crashes quickly. (This is
practically the same as deallocation, as far as the user can see - the
difference lies in that the GC doesn't do anything immediately.)
For safety there's no debug and release. It's either safe or unsafe.
So your goal is to prevent new objects from being allocated at the same
address for the sake of memory safety?
If so, then something like this belongs in SafeD *only*, in my opinion. We
have tools (stomping, valgrind, etc.) to allow catching bugs like these.
"Memory safety", especially at the cost of performance, does not belong in
a compiled language that allows pointer arithmetics.
Adding a Boolean to each object to tell whether it was destroyed or not
complicates matters without bringing a palpable benefit.
I meant "mark the object instance as invalid" figuratively, not using a
flag anywhere. ("Marking" would mean stomping on the object in the debug
version to prevent further use of the object.) Now I understand that your
goal is not to allow programmers to catch bugs, it's to stop the
programmers from doing anything that might involve shooting themselves in
the foot.
Your approach has the following problems:
1) As discussed, the objects are left in an abnormal state (T.init without
any work done by constructors). I don't think you can construct such
objects normally.
2) When an object was deallocated via "delete", assuming it didn't have a
destructor that accessed the object instance, the object's memory was not
being accessed. This means that if an object was swapped out, it wouldn't
need to be swapped back in just to destroy it. Your solution undoes this.
(Does performance actually count as a factor at all in your design
decisions?)
However, I also noticed that your approach has an interesting advantage:
after an object's memory is clobbered with T.init, it can be added to a
free list for fast construction (when the GC doesn't detect any references
if you want safety).
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
