https://svn.boost.org/trac10/ticket/2340 <p> I have the following code:- </p> <p> std::cout &lt;&lt; "BUILD REGEX" &lt;&lt; std::endl; try { </p> <blockquote> <p> boost::u32regex uregex= boost::make_u32regex ( "(.*?)(<br />b?<br />s?)(<br />w*?)&amp;(<br />w+?)(<br />b<br />s?&amp;?)(.*)" , boost::regex::perl ); </p> </blockquote> <p> } catch ( boost::regex_error x ) { </p> <blockquote> <p> std::cout &lt;&lt; "REGEX ERROR <a class="missing wiki">&lt;&lt; x.what() &lt;&lt;</a>" &lt;&lt; std::endl; return false; </p> </blockquote> <p> } std::cout &lt;&lt; "REGEX BUILT" &lt;&lt; std::endl; return false; </p> <p> When I compile this code and then run it, it throws an exception and prints this message:- </p> <p> REGEX ERROR [Invalid preceding regular expression] </p> <p> When I use this line instead </p> <blockquote> <p> boost::u32regex uregex= boost::make_u32regex ( "(.*?)(<br />b<br />s?)(<br />w*?)&amp;(<br />w+?)(<br />b<br />s?&amp;?)(.*)" , boost::regex::perl ); </p> </blockquote> <p> It does work. </p> <p> Both regular expressions compile and run as I expect in Perl. Is it a bug that this regex does not work in Boost? </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/2340 Trac 1.4.3 John Maddock Thu, 18 Sep 2008 16:15:35 GMT https://svn.boost.org/trac10/ticket/2340#comment:1 https://svn.boost.org/trac10/ticket/2340#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> In a strict sense this is a bug (in the sense that Perl accepts it and we don't), but the problematic part of the original regular expression is meaningless: </p> <p> \b? </p> <p> means "maybe match a word boundary, or maybe don't bother", so either way it consumes zero characters and will *always* succeed. The alternative form (which is also an error in Boost.Regex): </p> <p> \b+ </p> <p> Is also rather meaningless and exactly equivalent to </p> <p> \b </p> <p> My gut feeling at present, is that these almost always represent errors in the regular expression, and are generally best diagnosed as such. But... please do reopen if you can think of a legitimate use case :-) </p> <p> HTH, John. </p> Ticket