lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] C++11 regex ctor arg inaccessible?


From: Vadim Zeitlin
Subject: Re: [lmi] C++11 regex ctor arg inaccessible?
Date: Sun, 15 May 2016 19:09:32 +0200

On Sun, 15 May 2016 16:55:48 +0000 Greg Chicares <address@hidden> wrote:

GC> While I was reviewing this:
GC>   https://github.com/vadz/lmi/pull/16/
GC>   Allow matching exception message substrings in BOOST_TEST_THROW
GC> it occurred to me that if matching substrings is good, then matching
GC> regular expressions would be better, e.g.:
GC> 
GC>   BOOST_TEST_THROW
GC>     (throw (std::runtime_error("abc DEF ghi")
GC>     ,std::runtime_error
GC>     ,std::regex("DEF"));

 I think the possibility to use regexes was mentioned in the original
discussion, but we decided to not do it until it is really needed.

GC> Implementation seems trivial:
GC> 
GC>   bool it_matches(std::string const& observed, std::regex const& expected)
GC>   {return regex_search(observed, expected);}

 With the current PR this is not how it would be implemented nor used
because the idea is that BOOST_TEST_THROW() can be passed either a matcher
object or, for compatibility (and also, admittedly, ease of use, as this is
by far the most common case), a string which is implicitly converted to the
matcher checking for the exact string match.

 So to use it you would need to write

        BOOST_TEST_THROW
            (throw (std::runtime_error("abc DEF ghi")
            ,std::runtime_error
            ,match_regex("DEF"));

 And to implement this you would have a new "matcher" subclass called
match_regex which would implement both matches() method (using
regex_search() or regex_match()) and print().

GC> except for one thing: how can I print an informative error message if
GC> the regex doesn't match?

 With my approach this is trivial: match_regex would simply store the
string passed to its ctor and use it in print(). If you'd like, I could
quickly update a patch to do it.

GC> Even more surprisingly, I've tried web searches for "regex" plus various
GC> terms like "extractor", "ostream", "pattern string", and I can't even
GC> find evidence that anyone has ever asked about this; surely I'm not the
GC> first? Am I missing something obvious?

 There is indeed no way to retrieve the pattern used to construct the regex
object, AFAICS, but this doesn't really surprise me: a regex doesn't need
the pattern as it compiles it into (whatever)FA it uses in its ctor, so why
should it store it on an off chance that somebody wants to get it back
later? It would be akin to a file stream storing the name of the file which
was used to open it instead of just the file descriptor. As it is, when you
do want to store the pattern, it's trivial to do it outside of std::regex,
but you don't pay for storing it if you do not need it. If std::regex
stored it, it would make the former a tiny bit simpler, but the latter
impossible, which doesn't seem like a good compromise, so, again, I think
the standard committee made the right choice here.

 And in our particular case it's definitely simple to store the pattern
outside of the regex, in the match_regex object that we'd need anyhow.

 Again, please let me know if you'd like me to make this more concrete by
providing the updated version of the patch.

 Thanks,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]