[gclist] ref-counting performance cost

[Greg Colvin]

From: Boehm, Hans <hans_boehm@hp.com>
> ...
> > Anyway, as to your last point: this technique is not exactly 
> > rare. It's
> > often later optimized with a reference count (to avoid the copy) and
> > copy-on-write (to preserve the un-shared semantics).
> Unfortunately, this brings back memories of the C++ "string" class, in my
> opinion a low point of the C++ standard.
> 
> The C++ string class ("basic_string" really) went this route.  Then the
> standards committee determined that the existing reference counted
> copy-on-write implementations actually didn't satisfy any reasonable
> specifications, and there was no way to fix the implementations.  So they
> attempted to legitimize them. (See 21.3, paragraphs 5 and 6.)  The result is
> just about incomprehensible.  (If s is a string, the expression s[0] ==
> s[1], the most natural way to compare the first two characters, still
> appears to be illegal in some contexts, though not others.  Last I looked at
> it more thoroughly, I convinced myself that the spec is also wrong, and the
> traditional reference counted implementations are still broken.  But I
> wouldn't bet on that one way or the other.)

If you know how it is wrong we(the C++ committee) really would
appreciate defect report.
 
> Things get much worse if you add in threads ...
> 
> The SGI implementation ended up going back to deep copy (for "string", not
> "rope").  I'm unconvinced that any other implementation of the string
> interface is usable in the presence of threads.

Deep copy is the way to go.

> The bottom line is:  If you choose to go here, tread VERY carefully.

Amen.