Boost logo

Boost :

From: Nathan Myers (ncm_at_[hidden])
Date: 1998-12-07 21:18:23

Sean A Corfield writes:
> Beman Dawes <beman_at_[hidden]> wrote:
> [It would seem that the direct version will generate less code and
> run faster for dereferencing, and more code and run slower for
> argument passing and returns. ... ]
> This sounds more like a QOI issue than anything else. If we
> incorporate this into the Standard Library at some future date we
> can specify it in such a way that implementors can choose either
> method. Personally, I'm more interested in *what* it does than
> *how* it does it.

Boost is a library of implementations, and QoI is a critical
consideration. We can't hide behind standardese any more.

The space vs. locality tradeoff is interesting, because the
relative values depend dramatically on the ratio of number
of pointers to number of objects pointed to.

In my experience this ratio has been fairly low, so the apparently
large space overhead of the direct method ("doubling the size" of the
pointer) is not so large when the total storage associated with the
pointer (pointer, counter, object) are taken into account, and would
be close to zero in common cases.

On the opposite side, touching two pages instead of one for each
indirect-shared-pointer dereference is likely to be keenly felt in
algorithms that operate on a lot of different objects. This overhead
is exacerbated by even advanced optimizers' inability to track
indirect pointer operations. (Many can handle one level pretty well.)

For the increasingly rare environments where the indirect method
is better (and enough so to matter), we don't need to supply an
implementation, because users can specialize to get the same effect.
Thus, I don't see any need to parameterize shared_ptr on the
implementation scheme. Let's just offer a pure "direct" pointer.
Simplicity is a virtue too.

Nathan Myers
Free Web-based e-mail groups --

Boost list run by bdawes at, gregod at, cpdaniel at, john at