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

[Tim Shen <timshen at google dot com>]

On Tue, Sep 16, 2014 at 2:23 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
> On 15/09/14 09:46 -0700, Tim Shen wrote:
> * basic_regex move constructor/assignment must be noexcept. This
>   implies the traits and NFA must be heap-allocated or must also have
>   non-throwing moves.
>
> * It must be possible to re-populate a basic_regex with assign() or
>   operator= so moving must not leave it in an invalid state.
>
> * Must be able to access and change the locale in a basic_regex, even
>   if it was default-constructed or moved-from.
>
> * The locale is managed by the traits object, so it must be possible
>   to access the traits object of a basic_regex in any state. That
>   would be a problem for my suggestion of putting the traits inside
>   the automaton (because there may not be an automaton for some
>   basic_regex objects).
>
> With those points in mind your original design is a good fit, with the
> traits object stored directly as a member of the basic_regex, and the
> automaton on the heap (but in a unique_ptr not shared_ptr so it is not
> shared by multiple basic_regex objects, and copying the NFA in the
> basic_regex copy constructor). That needs adjusting to avoid dangling
> references. That could be done by replacing the references with
> pointers, and when ownership of the automaton moves from one
> basic_regex to another you would need to update all the pointers to
> point to the traits object of the new owner.

I think we can do both: maintain a locale_type variable in basic_regex
and put a traits variable somewhere on the heap (probably in the NFA).
When imbuing new locale, update both if possible.

shared_ptr can still be used as a "copy-on-write" mechanism, as long
as it does a regex recompile when imbuing. it makes copy
constructing/assigning fast but imbue slow. shared_ptr, however, has
larger overhead, but I think it's affordable; we can make _NFA
intrusively shared to reduce it.

> You also mentioned not storing any references to the traits in the
> automaton and passing it in when it executes, how difficult would that
> be?

Nah, that's too bad; it makes move/copy non trivial, not even O(1).


-- 
Regards,
Tim Shen