This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [patch] empty base class optimization completed in stl_tree.h
On Jan 11, 2007, at 4:02 AM, Maxim Yegorushkin wrote:
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?
Fwiw, use of boost::compressed_pair is relatively simple and fool
proof (this is why compressed_pair was invented in the first place).
Just pair each possibly-empty type with a type known not to be empty.
Something like:
__compressed_pair<_Rb_tree_node_base, _Node_allocator> _;
__compressed_pair<size_type, _Key_compare> __;
_Rb_tree_node_base& _M_header() {return _.first();}
const _Rb_tree_node_base& _M_header() const {return _.first();}
_Node_allocator& _M_node_allocator() {return _.second();}
const _Node_allocator& _M_node_allocator() const {return _.second();}
size_type& _M_size() {return __.first();}
const size_type& _M_size() const {return __.first();}
_Key_compare& _M_key_compare() {return __.second();}
const _Key_compare& _M_key_compare() const {return __.second();}
Of course this is relatively major surgery and ABI-breaking.
-Howard