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

[Miles]

Frits van Bommel wrote:
> Array slicing, for one.
> While technically possible with malloc, it would require maintaining a
> reference count and an extra pointer to the start of the allocated
> memory area to call free() on. And that still doesn't solve the problem
> of cyclic references (if the array doesn't just contain primitive data),
> as well as requiring synchronization in multi-threaded applications.

Ok, I see.

But looking at the problem, being someone from algorithms, I think it is
possible and feasible to implement array slicing using malloc
allocation. 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.

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.

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. Deallocation is very atomic and
can be implemented without synchronization and still be thread-safe.
GC-based, OTOH, needs to freeze the whole application (not just the
threads doing allocation) in order to collect.