<spanclass="bold"><strong>Q.</strong></span> I can't get regex++ to work with escape
characters, what's going on?
</p>
<p>
<spanclass="bold"><strong>A.</strong></span> If you embed regular expressions in C++
code, then remember that escape characters are processed twice: once by the
C++ compiler, and once by the Boost.Regex expression compiler, so to pass
the regular expression \d+ to Boost.Regex, you need to embed "\d+"
in your code. Likewise to match a literal backslash you will need to embed
"\\" in your code.
</p>
<p>
<spanclass="bold"><strong>Q.</strong></span> No matter what I do regex_match always
returns false, what's going on?
</p>
<p>
<spanclass="bold"><strong>A.</strong></span> The algorithm regex_match only succeeds
if the expression matches <spanclass="bold"><strong>all</strong></span> of the text,
if you want to <spanclass="bold"><strong>find</strong></span> a sub-string within
the text that matches the expression then use regex_search instead.
</p>
<p>
<spanclass="bold"><strong>Q.</strong></span> Why does using parenthesis in a POSIX
regular expression change the result of a match?
</p>
<p>
<spanclass="bold"><strong>A.</strong></span> For POSIX (extended and basic) regular
expressions, but not for perl regexes, parentheses don't only mark; they
determine what the best match is as well. When the expression is compiled
as a POSIX basic or extended regex then Boost.Regex follows the POSIX standard
leftmost longest rule for determining what matched. So if there is more than
one possible match after considering the whole expression, it looks next
at the first sub-expression and then the second sub-expression and so on.
So...
</p>
<p>
"(0*)([0-9]*)" against "00123" would produce $1 = "00"
$2 = "123"
</p>
<p>
where as
</p>
<p>
"0*([0-9])*" against "00123" would produce $1 = "00123"
</p>
<p>
If you think about it, had $1 only matched the "123", this would
be "less good" than the match "00123" which is both further
to the left and longer. If you want $1 to match only the "123"
part, then you need to use something like:
</p>
<p>
"0*([1-9][0-9]*)"
</p>
<p>
as the expression.
</p>
<p>
<spanclass="bold"><strong>Q.</strong></span> Why don't character ranges work properly
(POSIX mode only)?
</p>
<p>
<spanclass="bold"><strong>A.</strong></span> The POSIX standard specifies that character
range expressions are locale sensitive - so for example the expression [A-Z]
will match any collating element that collates between 'A' and 'Z'. That
means that for most locales other than "C" or "POSIX",
[A-Z] would match the single character 't' for example, which is not what
most people expect - or at least not what most people have come to expect
from regular expression engines. For this reason, the default behaviour of
Boost.Regex (perl mode) is to turn locale sensitive collation off by not
setting the <codeclass="computeroutput"><spanclass="identifier">regex_constants</span><spanclass="special">::</span><spanclass="identifier">collate</span></code>
compile time flag. However if you set a non-default compile time flag - for
example <codeclass="computeroutput"><spanclass="identifier">regex_constants</span><spanclass="special">::</span><spanclass="identifier">extended</span></code> or <codeclass="computeroutput"><spanclass="identifier">regex_constants</span><spanclass="special">::</span><spanclass="identifier">basic</span></code>,
then locale dependent collation will be enabled, this also applies to the
POSIX API functions which use either <codeclass="computeroutput"><spanclass="identifier">regex_constants</span><spanclass="special">::</span><spanclass="identifier">extended</span></code>
or <codeclass="computeroutput"><spanclass="identifier">regex_constants</span><spanclass="special">::</span><spanclass="identifier">basic</span></code> internally. [Note - when <codeclass="computeroutput"><spanclass="identifier">regex_constants</span><spanclass="special">::</span><spanclass="identifier">nocollate</span></code> in effect, the library behaves
"as if" the LC_COLLATE locale category were always "C",
regardless of what its actually set to - end note].
</p>
<p>
<spanclass="bold"><strong>Q.</strong></span> Why are there no throw specifications
on any of the functions? What exceptions can the library throw?
</p>
<p>
<spanclass="bold"><strong>A.</strong></span> Not all compilers support (or honor)
throw specifications, others support them but with reduced efficiency. Throw
specifications may be added at a later date as compilers begin to handle
this better. The library should throw only three types of exception: [boost::regex_error]
can be thrown by <ahref="../ref/basic_regex.html"title="basic_regex"><codeclass="computeroutput"><spanclass="identifier">basic_regex</span></code></a> when compiling a regular
expression, <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">runtime_error</span></code> can be thrown when a call
to <codeclass="computeroutput"><spanclass="identifier">basic_regex</span><spanclass="special">::</span><spanclass="identifier">imbue</span></code> tries to open a message catalogue
that doesn't exist, or when a call to <ahref="../ref/regex_search.html"title="regex_search"><codeclass="computeroutput"><spanclass="identifier">regex_search</span></code></a> or <ahref="../ref/regex_match.html"title="regex_match"><codeclass="computeroutput"><spanclass="identifier">regex_match</span></code></a> results in an "everlasting"
search, or when a call to <codeclass="computeroutput"><spanclass="identifier">RegEx</span><spanclass="special">::</span><spanclass="identifier">GrepFiles</span></code>
or <codeclass="computeroutput"><spanclass="identifier">RegEx</span><spanclass="special">::</span><spanclass="identifier">FindFiles</span></code> tries to open a file that cannot
be opened, finally <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">bad_alloc</span></code> can be thrown by just about any
of the functions in this library.
</p>
<p>
<spanclass="bold"><strong>Q.</strong></span> Why can't I use the "convenience"
