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

[Chris Jefferson]

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.