From: "David B. Held" <[EMAIL PROTECTED]> > "Dave Abrahams" <[EMAIL PROTECTED]> wrote in message > 008c01c2ce1f$87ca8620$6501a8c0@penguin">news:008c01c2ce1f$87ca8620$6501a8c0@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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
