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

["Maxim Yegorushkin" <maxim dot yegorushkin at gmail dot com>]

On 10/01/07, Chris Jefferson <chris@bubblescope.net> wrote:
> 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.

That's an interesting use case I would not have dared to think about ;)

I wonder whether deriving both allocator and key compare functor when
they both inherit virtually the same base class contradicts the
standard in some way. If it is an example of implementation specific
behavior, it could be commented as such in the header file, couldn't
it?