[gclist] ref-counting performance cost
Wed, 11 Oct 2000 10:57:47 -0600
From: Boehm, Hans <firstname.lastname@example.org>
> > 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 ==
> s, 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.