OSNews article about C++09 degenerates into C++ vs. D discussion

[Steve Horne]

On Mon, 20 Nov 2006 16:57:36 +0100, xs0 <xs0 at xs0.com> wrote:

>Miles wrote:
>> An extra field will be needed anyway since you need
>> reference count for the array, just put it along with the beginning of
>> the array and only a single pointer will be needed for both reference
>> count and beginning of array.
>
>But with GC, the extra field is not "needed anyway".. Furthermore, you 
>can "slice" an arbitrary region of memory, and it still behaves like any 
>other slice; with malloc, you can only slice regions specifically 
>enabled for slicing (i.e. those that have the reference counter)

I haven't really tried to understand all these extra field and other
bits about slices. I just can't help being reminded about an old COM
criticism.

In COM, you only ever have pointers to interfaces, which are not
considered to equate to the object itself. The object is created when
you get the first interface, and deleted when the reference count
drops to zero.

If you want an object for some reason, but don't want any particular
interface, you acquire the IUnknown interface.

Reference counting is one of the main hassles in COM. It sounds like
GC, but the programmer has to ensure for himself that every increment
is correctly matched by a decrement.

According to one ex-Microsoft guy (sorry, I forget who) he pointed out
the mistake in this before COM was every released, but they had
already committed a lot to it and didn't make the proposed change.

The point is this - instead of reference counting, the programmer
should explicitly create the object once. Then, he should request the
needed interfaces. Requesting and releasing interfaces should not
require reference counting. Its the programmers responsibility to not
use interfaces after the object has been destroyed (though it would be
possible to break the links to the interfaces when the object is
destroyed, so using dead interfaces would trigger an exception).

If this sounds hard work, consider that programmers do exactly this
all the time. You shouldn't use a record lock when the file has been
closed, for instance, or (in Windows) send a message to a window that
has been destroyed.

The same could apply to a slice. The slice is valid only as long as
the sliced object is valid. If the slice will outlive the original
object, you have to make a copy. Call it a 'slice pointer' or 'slice
handle' and it should be understood that it is only valid as long as
the original object is valid.

And there are efficiency arguments to doing this - the original object
isn't artificially kept hanging around when you only need the slice.
Just as there's other efficiency arguments for leaving it to the GC,
of course.

It's horses for courses again. And while I doubt I'd ever really do
slicing like that in D (or rather, I doubt I'd be concerned about
losing the special syntax), it's nice to know that I can opt out of
using the GC if I ever find a special case where I care.

-- 
Remove 'wants' and 'nospam' from e-mail.