Re: [boost] Re: SmartPtr - Exception safety reprise

From: Dave Abrahams (dave_at_[hidden])
Date: 2003-02-06 16:21:27

From: "David B. Held" <dheld_at_[hidden]>

> "Dave Abrahams" <dave_at_[hidden]> wrote in message
> news:008c01c2ce1f$87ca8620$6501a8c0_at_penguin...
> > [...]
> > What do you mean that its *place* in the hierarchy affects the size? If
> > it's in the hierarchy, it's a base.

Sorry, I thought that "it" is "noncopyable", not "ref_counted".

> But if it's not in the smart_ptr hierarchy, it's not a base.  So if it's
not
> a 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.

No, it doesn't.  It can't.  sizeof(ref_counted) is the same no matter where
you measure it.  What changes is the size that gets contributed to its
derived class.

It's clear to me why that could happen.  It could be just a simple-minded
rule to avoid violating the standard requirements, which are written so that
no two objects of the same type can have the same address.  The rule would
be, "if I applied the EBO on this type, add some padding after it in an MI
context so that other bases of the same type can't end up overlapping with
it.  It's a dumb rule, since it's easy enough to lay out empty bases in the
single-inheritance case at the beginning of the object, and since all types
have size > 0, you don't need to do anything other than "not optimize" in
the MI case.

> > 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.

I'm interested in what happens when either of ownership or storage are
themselves empty.  And, of course, the independent tests not based on
smart_ptr.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com