|
Boost : |
From: Dan Rosen (dan.rosen_at_[hidden])
Date: 2007-04-30 18:12:43
Hi,
I've come across a circumstance, using boost::regex, where I think the
interface is exposing less flexibility than the underlying
architecture provides. Specifically, I'd like to do a
regex_replace(), but instead of a format string specifying the output
of the transformation, I'd like to provide a functor.
The reason I need this is: the replacement I'd like to do is not a
straighforward text substitution, but rather involves rummaging
through a database to retrieve stored information about the match
results. Aside from that, however, the overall algorithm for finding
matches and outputting the transformed text is identical.
The good news, as far as I can tell, is that the guts of boost::regex
are already structured so as to make this easy. The
basic_regex_formatter<> seems to express a concept that can be
factored out and exposed in the public interface. The end result I'd
hope for are additions something like:
template <class OutputIterator, class Formatter>
OutputIterator match_results::format(OutputIterator out,
Formatter fmt,
match_flag_type flags = format_default) const;
template <class Formatter>
string_type match_results::format(Formatter fmt,
match_flag_type flags = format_default) const;
template <class OutputIterator, class BidirectionalIterator, class
traits, class charT, class Formatter>
OutputIterator regex_replace(OutputIterator out,
BidirectionalIterator first,
BidirectionalIterator last,
const basic_regex<charT, traits>& e,
Formatter fmt,
match_flag_type flags = match_default);
template <class traits, class charT, class Formatter>
basic_string<charT> regex_replace(const basic_string<charT>& s,
const basic_regex<charT, traits>& e,
Formatter fmt,
match_flag_type flags = match_default);
This way, I could specify my custom formatter and use it in place of
the default basic_regex_formatter. My present workaround is to
essentially reinvent regex_replace() in my own code, by cobbling
together a while-loop predicated on regex_search(), but it's not very
elegant.
Does this make sense / need clarification? Is it a desirable design
goal? I'm happy to do the work and provide a patch for review,
particularly if John approves.
Cheers,
dr
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk