Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2003-02-06 16:07:38

"Dave Abrahams" <dave_at_[hidden]> wrote in message
> [...]
> What do you mean that its *place* in the hierarchy affects the size? If
> it's in the hierarchy, it's a base.

But if it's not in the smart_ptr hierarchy, it's not a base. So if it's not
base, it's at the top (or bottom) of the hierarchy, with noncopyable as a
base. And that's my point. Being a base changes its size.

> [...]
> BTW, these are not the kind of tests I was thinking of. I was more
> interested in simple tests with SI and MI using dummy classes with
> zero or more data members and trivial/non-trivial ctors/dtors.

Yes, like what Jason Shirk did. It's just that I did a diff of the version
that was the right size and the one that wasn't, and saw that change,
so I wanted to test it right away. The weird thing is, the storage policy
also has an empty base for the policy adaptor, and yet, it doesn't
seem to affect the size of smart_ptr. Go figure. But like Jason also
pointed out, the order of bases makes a difference, so maybe the
fact that storage_policy comes first affects the size. I noticed that
this is actually the case on bcc, and I suspect, on most compilers.

Anyway, non-copyable doesn't really convey the right concept
anyway, since ref_counted defines copy c'tors! I just wanted to hide
the assignment operator, and doing that "manually" works fine.


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