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