On Sat, Jun 28, 2014 at 2:48 AM, Jonathan Wakely wrote:
> OK for trunk, thanks.
Committed.
Thanks!
--
Regards,
Tim Shen
On Sat, Jun 28, 2014 at 2:48 AM, Jonathan Wakely wrote:
> I wonder if it would be better to use a sorted
> vector> instead of a map, for improved
> memory footprint and runtime speed, but that can be changed later.
In this case, we keep inserting (__m[__u] = __id) and looking up
(__m.count()) the
On 27/06/14 09:53 -0700, Tim Shen wrote:
On Fri, Jun 27, 2014 at 12:37 AM, Paolo Carlini
wrote:
The actual patch is missing.. ;)
Sigh...every time. Sorry.
PS: sorry for being distracted by other issues: what happened to the other
regex issue? I think we are simply going to apply, when ready
Hi,
On 06/27/2014 06:53 PM, Tim Shen wrote:
PS: sorry for being distracted by other issues: what happened to the other
regex issue? I think we are simply going to apply, when ready, your more
complete fix, right?
The problem given in the other PR (PR 61582) is also solved by this
patch (but I f
On Fri, Jun 27, 2014 at 12:37 AM, Paolo Carlini
wrote:
> The actual patch is missing.. ;)
Sigh...every time. Sorry.
> PS: sorry for being distracted by other issues: what happened to the other
> regex issue? I think we are simply going to apply, when ready, your more
> complete fix, right?
The
Hi,
On 06/27/2014 05:56 AM, Tim Shen wrote:
The limit can be customized by defining a macro
_GLIBCXX_REGEX_STATE_LIMIT. The default value is 10.
The testcase can be handled if we optimize consecutive quantifiers
(collapse them to one). But cases like "(a{100}b){100}" can't be
handled still.
The limit can be customized by defining a macro
_GLIBCXX_REGEX_STATE_LIMIT. The default value is 10.
The testcase can be handled if we optimize consecutive quantifiers
(collapse them to one). But cases like "(a{100}b){100}" can't be
handled still.
We implement range quantifier "(foo){n}" by c
