Re: Slightly less trivial clean-up patch for stl_tree

[Gawain Bolton <gp dot bolton at computer dot org>]

Paolo Carlini wrote:

> Hi Gawain,
>
> >    * iterator _M_insert_equal(iterator __position, const value_type&
> >      __x) and
> >      const_iterator _M_insert_equal(const_iterator __position, const
> >      value_type& __x) replaced with
> >      iterator _M_insert_equal(const_iterator __position, const
> >      value_type& __x)
>
>
> I don't think this kind of change is safe for the current "ABI" (in 
> the wide sense). In different objects (using old and new stl_tree.h) 
> we may have both weak symbols
>
>    const_iterator
>    _M_insert_equal(const_iterator __position, const value_type& __x)
>
> and
>
>    iterator
>    _M_insert_equal(const_iterator __position, const value_type& __x)
>
> which differ only for the return type. Which one is picked by the linker?

You're implying that the linker sees objects produced from different 
versions of GCC.  It's not realistic to maintain arbitrary object level 
compatibility across different versions of the compiler, and I would 
hope that libraries contain all template instatiations so that this type 
of internal change is not a problem for third party libraries.

In this particular case the problem could be circumvented by renaming 
_M_insert_equal() and _M_insert_unique() and changing stl_map.h, 
stl_multimap.h, stl_set.h and stl_mutlset.h to use the new function.  
Since I will certainly not provide such a horrid patch, when will 
changes be allowed?

> For v7-branch, on the other hand, this is exactly the kind of approach 
> I was looking for... If you like, you can be even more aggressive...

I have, nor could find, any info on the v7-branch.  I have other ideas 
for changes but not related to this particular issue.   So what do you 
have in mind when you say "more agressive"?

Cheers,

Gawain