Re: std::regex: inserting std::wregex to std::vector loses some std::wregex values

[Jonathan Wakely <jwakely at redhat dot com>]

On 14/09/14 20:29 +0200, Paolo Carlini wrote:
> Hi,
>
> On 09/14/2014 08:12 PM, Tim Shen wrote:
> > On Sun, Sep 14, 2014 at 3:16 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> > > Thus, are you going to send an actual patch? I'm wondering if we could
> > > arrange it in such a way not to break the binary compatibility in the
> > > release branch (thus fix the bug there too) perhaps by not removing any data
> > > members, simply leaving them unused?! In mainline I suppose we are going to
> > > stabilize the ABI for the 5.0 release, thus we can do that. While we are at
> > > it, check that the order of the final remaining data members is still
> > > optimal size-wise.
> > I've made a patch that changes basic_regex's member only, by making
> > basic_regex::_M_traits heap allocated.
> Thanks. Maybe Jon can have a closer look to it...

Sure.

> > I believe that I didn't get it, but I'm still a little bit confused,
> > since we haven't instantiated and exported any regex class (except
> > regex_error, I suppose) to the binary, right?
> >
> > Anyway, the patch is bootstrapped and tested with debug flag. Can it
> > be modified slightly to keep the binary compatibility?
> Probably yes, but then, as described here:
>
>    https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
>
> under <prohibited changes>, you cannot add or remove the basic_regex 
> data members. This doesn't have much to do with the exported symbols, 
> the mental model is somebody including the old <regex> compiling an 
> a.o, then including the new <regex> and compiling a b.o, then linking 
> together a.o and b.o: things must work fine in every case.

Yes, it should be possible to compile a.o with GCC 4.9.x and b.o with
GCC 4.9.y and link them together. That means we are limited in the
kinds of changes we can make to the 4.9 branch now.

Because we haven't finalised the C++11 ABI yet, it is not supported to
compile a.o with GCC 4.9.x and b.o with 5.y, so it's OK to make your
suggested changes on the trunk, but to fix it for 4.9 we will need a
different change (maybe just disable move semantics so that we always
do copies instead of moving).