On 27 September 2013 13:32, Paolo Carlini wrote: > On 9/27/13 4:34 AM, Jonathan Wakely wrote: >> >> On 27 September 2013 03:15, Tim Shen wrote: >>> >>> POSIX ERE says that escaping an ordinary char, say R"\n" is not >>> permitted, because 'n' is not a special char. However, they also say >>> that : "Implementations are permitted to extend the language to allow >>> these. Conforming applications cannot use such constructs." >>> >>> So let's support it not to make users surprised. >>> >>> Booted and tested under -m32 and -m64 >> >> I'm wondering whether we want to have a stricter mode that doesn't >> allow them, to help users avoid creating non-portable programs. We >> could check the value of the preprocessor macro __STRICT_ANSI__, which >> is set by -std=c++11 but not by -std=gnu++11, although that's not >> really the right flag. We want something more like the GNU shell >> utils' POSIXLY_CORRECT. > > Indeed. I think that for now __STRICT_ANSI__ can do, it's important to > manage to accept those otherwise, as we discovered yesterday, we easily > reject quite a few rather sensible regex users can write or find in > examples: this started when Tim, upon my suggestion, tried the examples in > the new edition of Nicolai Josuttis book and found in one those an escaped > closed curly bracket (note, closed, open are definitely fine), which > apparently most of the other implementations do not reject.
Ah I see. I definitely agree it's good to accept that instead of being unnecessarily strict, but other people will want the option of strict conformance, so I think we can please everyone with something like: else { #ifdef __STRICT_ANSI__ __throw_regex_error(regex_constants::error_escape); #else _M_token = _S_token_ord_char; _M_value.assign(1, __c); #endif }