This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Re: [patch] empty base class optimization completed in stl_tree.h
On 10/01/07, Maxim Yegorushkin <maxim.yegorushkin@gmail.com> wrote:
On 10/01/07, Chris Jefferson <chris@bubblescope.net> wrote:
> On 10/01/07, Maxim Yegorushkin <maxim.yegorushkin@gmail.com> 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.
>
> Unfortunatly I don't have a working compile of g++ right now to check
> this. The only thing in this patch which worries me is this line:
>
> + struct _Rb_tree_impl : _Node_allocator, _Key_compare
>
> As multiple inheritance is known to occasionally cause annoying
> problems. I would advise trying to make a key_compare with all the
> methods a _Node_allocator should have, and also give the
> _Node_allocator could have.
Could you please elaborate on what is the problem.
My worry was that at some point member functions of _Node_allocator or
_Key_compare could be accessed through _Rb_tree_impl, but private
discussions with Maxim have convinced me this can't happen.
> I wonder, if someone wanted to be really insane, if they could make
> the allocator and the key compare exactly the same type?
Does it make sense to protect from it by checking if allocator and
key_comp are the same type?
However this is a more major problem I think. Even more serious is if
_Node_allocator and _Key_compare have a common virtual base type, they
will get combined. This can I think be fixed, it will just require
doing two EBC optimisations instead of trying to do two at once.