Here is the problem:
I want to find a simple regular _expression something like
\\d\\d\\d\\d\\d\\d in a large file (15 mb) using VC++ 7.1 .
I use Spirit's File Iterator as the input iterator for the search algorithm.
After some seven thousands hits the match algo throughs the memory exhausted exception.
So I cought the exception and moved the iterator by one, printed the location it points to in my searched file to view the problematic section for the regex find algorithm.
After the "problematic section" of some 300 chars ends the algorithm keeps working fine.
here is the code.
//-------------------------------------------------------------------------------------------
void TheFunction()
{
//print the problematic section here
ofstream of;
of.open("d:\\err1.txt");
boost::spirit::file_iterator< > begin("d:\\log1.txt");
boost::spirit::file_iterator<> beginning_saved(begin); //save the beginning in order to compare later
boost::spirit::file_iterator< > ending;
ending= begin.make_end();
boost::match_results
After some seven thousands hits the match algo throughs the memory exhausted exception. So I cought the exception and moved the iterator by one, printed the location it points to in my searched file to view the problematic section for the regex find algorithm. I have noticed that the problem happens not with all large files, but with quite a bit of them. After I have received the problematic section in my file, I ran the program on it and it did not raise any exceptions. Please , help me I have a Graduate project to complete within 3 weeks from now, and this is one of the major bugs I have not resolved.
You don't say *exactly* what the regex is that's causing the problem - it makes a difference - problems like this are usually caused by an expression that behaves badly with specific input (because regexes are NP-Hard to match in the general case). Boost.Regex will throw an exception rather than go on thrashing forever trying to find a match, but to determine whether this is the case here, you need to trap the exception at the point it's being thrown, and see if the regex lib is indeed the culprit, if it is, then refactoring the expression that you're using so that it's less ambiguous is usually the answer. John.
participants (2)
-
John Maddock -
Kosta Adarchenko