"Dave Abrahams" <[EMAIL PROTECTED]> wrote in message 001201c2ce26$533cae40$6501a8c0@penguin">news:001201c2ce26$533cae40$6501a8c0@penguin... > [...] > 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.
So it's actually a pessimization as the result of an optimization? Ouch. > [...] > I'm interested in what happens when either of ownership or > storage are themselves empty. Oddly enough, VC++ gets the size right for destructive_copy (4), but bcc insists the size is 8. In this case, I don't know what's going on, because optimally_inherit only leaves one base class (which can be proven by trying to static_cast to the policies), so there isn't even MI involved. It's just outright EBO failure. > And, of course, the independent tests not based on smart_ptr. I've done some of these. When I first ran across size problems, it was the first thing I did. However, the simplicity of the tests does not give you a good idea of what happens in smart_ptr. That is, a lot of the simple tests pass with the desired results. It's when the tests get more and more smart_ptr baggage that you begin to see different results. Dave _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
