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

[xs0]

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)


> Cyclic references is a problem only when using GC. If the programmer
> wants to use a malloc-based allocation, he knows he should handle cyclic
> references himself. Not a problem.

Cyclic references are a problem only when using reference counting. And 
you can't just say it's not a problem, because one knows it needs to be 
dealt with.. That's like saying it's really not a problem to win a 
lottery, because you know you need to have the right numbers on your ticket.


> As for synchronization, I think this is more a problem when GC is used
> than when it is not. Malloc-based allocation needs synchronization, of
> course, but I think GC-based does also. 

Well, for allocation it depends on implementation in both cases, but 
with reference counting you also need to synchronize on every reference 
count update, which can be very often.


> GC-based, OTOH, needs to freeze the whole application (not just the
> threads doing allocation) in order to collect.

It's not strictly necessary, though the current implementation does..


xs0