This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] empty base class optimization completed in stl_tree.h


On Jan 10, 2007, at 5:04 AM, Maxim Yegorushkin wrote:

Hi,

It looks like an intended empty base class optimization has not been
finished for struct _Rb_tree_impl in stl_tree.h. If it is so indeed,
this patch completes it.

main trunk:
 sizeof(std::set<int>) == 72
 sizeof(std::set<int, bool(*)(int, int)>) == 72

with patch applied:
 sizeof(std::set<int>) == 64
 sizeof(std::set<int, bool(*)(int, int)>) == 72

Compile tested only.<stl_tree.patch>

I have a question about ABI stability.


Is the reason this is not considered ABI-breaking because std::set is never instantiated within libstdc++? I.e. we can change std::set all we want and it will never impact the compiled lib.

However consider client A who creates a library which uses std::set in its interface, and compiles prior to the change above. Client B compiles after the change above, and links to Client A's library, and say passes a std::set<int> back and forth. Since the two pieces of code have a different layout for std::set<int>, I would guess that there might be some problems.

I'm not saying that the above change should necessarily be rejected. I merely wanting to clarify (at least for myself) our ABI stability policy. Fwiw, I consider reducing the sizeof std::types very important.

Thanks,
Howard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]