|
Boost Users : |
From: Scott Meyers (Usenet_at_[hidden])
Date: 2003-12-15 00:04:39
On Sat, 13 Dec 2003 12:12:46 -0000, John Maddock wrote:
> Not directly, but you could:
>
> repeated search through the string finding each match, then for each match
> found replace the matched section with the result of regex_format, and
> restart the search from the appropriate place.
I got this working, but I'm curious about a design decision, or perhaps
about a couple of related design decisions.
What I really wanted to do was a regex_merge, but I also needed to know how
many matches had been detected. Is there a particular reason that
regex_merge doesn't provide that information? It's there for the plucking,
because regex_merge calls regex_grep (at least that's what the docs
suggest), and regex_grep returns how many matches were found.
Second, in learing to use regex_grep, I was struck by what appears to be an
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 from
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 not
have been reasonable for regex_grep to pass an additional bool to the functor
indicating whether the call was not for a match but was instead for a final
after-the-last-match call? That way the functor could have done all the
copying.
Thanks for both the library and for any enlightment on the above you'd
care to shed.
Scott
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net