Boost logo

Boost Users :

From: John Maddock (john_at_[hidden])
Date: 2003-12-29 07:54:49

> What I really wanted to do was a regex_merge, but I also needed to know
> many matches had been detected. Is there a particular reason that
> regex_merge doesn't provide that information? It's there for the
> because regex_merge calls regex_grep (at least that's what the docs
> suggest), and regex_grep returns how many matches were found.

I guess it just didn't quite fit with the interface - I happen to think that
you're unusual in wanting this information, or at least you're the first to
ask for it :-)

> Second, in learing to use regex_grep, I was struck by what appears to be
> asymmetry in the division of responsibility between the functor passed to
> regex_grep and regex_grep's caller. To perform a full search and replace
> over a string (say), the functor is responsible for copying everything
> the beginning of the string to the end of the final match (performing
> replacements as it goes), but regex_grep's caller is responsible for
> copying everything from the end of the final match to the end of the
> string. This strikes me as really odd, but it's what's done in the
> DDJ article, so I assume that this is the right way to do it. Would it
> have been reasonable for regex_grep to pass an additional bool to the
> indicating whether the call was not for a match but was instead for a
> after-the-last-match call? That way the functor could have done all the
> copying.

Good point, but the last call to the functor then wouldn't be a match - and
I think that this would cause as many if not more problems than it solves.
In any case regex_grep is being deprecated in favor of an iterator based
interface in the next revision.

Sorry for the delay,


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at