Boost C++ Libraries: Ticket #2058: boost::regex_replace strange behaviour https://svn.boost.org/trac10/ticket/2058 <p> Dear Boost Representative, </p> <p> I have encountered a strange boost::reges_replace behaviour. </p> <p> There is a complete (as small as possible, I think) project to reproduce that error in the attachement. </p> <p> Generally, when the 'in' variable (std::string) exceedes a critical (indefinite) length boost::regex_replace throws an exception: _STL::runtime_error with message: "Exception Object Address...". </p> <p> Some further info on my environment: BOOST VERSION: 1.33.1. Borland C++ Builder 6.0 Professional (Build 10.166). Update Pack 4 applied. Windows XP. SP2 applied. </p> <p> Thank you in advance for any help in this strange matter. </p> <p> Yours sincerely, Piotr. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/2058 Trac 1.4.3 piotr.pydych@… Mon, 30 Jun 2008 13:15:14 GMT attachment set https://svn.boost.org/trac10/ticket/2058 https://svn.boost.org/trac10/ticket/2058 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">Ticket2058_Attachement.ZIP</span> </li> </ul> Ticket John Maddock Thu, 24 Jul 2008 12:31:22 GMT status changed; resolution set https://svn.boost.org/trac10/ticket/2058#comment:1 https://svn.boost.org/trac10/ticket/2058#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">worksforme</span> </li> </ul> <p> I can't reproduce this as I don't have access to Borland C++ at present. </p> <p> However, I believe this is caused by the regular expression used: match a regular expression is in general an NP-complete problem so Boost.Regex will throw a std::runtime_error if the complexity of matching grows to much. </p> <p> The problem appears to be the: </p> <p> (.|<br />s)*? </p> <p> part, the issue is that "." will match all the same characters that "<br />s" will, so the number of possible alternative ways to find a match grows exponentially large - hence the exception thrown. Changing to: </p> <p> .*? </p> <p> will likely solve the problem I believe. </p> <p> HTH, John Maddock. </p> Ticket