Sure, that's why I have the checking first in the while () statement. Was that not enought? while (i < 100 && h1 != h2) { nextPos[i] = (*h1).position(0); h1++; i++; } On 8/10/06, John Maddock <john@johnmaddock.co.uk> wrote:
Winson Yung wrote:
Thanks John, I was going to ask about this magic '1' number thing. I think I found an example somewhere like this, but appearantely it was wrong. I was having so much difficulty using the cregex_iterator, even without the last match flag, the same code was asserting when it was walking through the iterator to get the posistion(0). Here is an example of the calltrace when assert happened:
_assert(void * 0x0067a74c `string', void * 0x0067a758 `string', unsigned int 253) line 256 boost::shared_ptr<boost::regex_iterator_implementation<char const *,char,boost::regex_traits<char,boost::w32_regex_traits<char> > >
operator->() line 253 + 31 bytes boost::regex_iterator<char const *,char,boost::regex_traits<char,boost::w32_regex_traits<char> > operator*() line 129 + 37 bytes CDownloadProgressDlg::ExtractReportKeyStats(unsigned char * 0x02470040, unsigned __int64 1292879, unsigned char 205) line 1386 + 8 bytes CDownloadProgressDlg::ExtractReportKeyStats(const char * 0x010ed664, unsigned char 205) line 1333 + 36 bytes
You are trying to dereference an iterator that doesn't point to anything.
You must ensure it is not equal to the end-of-sequence-iterator before dereferencing it. Same as with any other iterator.
Question here are:
1) do I need to put parensis around like this to instantiate regex obj like the following?
expr("(hello world here)", regex_constants::perl | regex_constants::icase);
Not unless you want a marked sub-expression no.
2) say pBuf has something like the following, will my sample code get the position of the matching on line 1, 3, 5?
hello skjdfskldjf hello world here kjsfsdf w3423422 sfsdfsfs hello hello kjkjkjkjkl world world hello world here 23432423 3333333333333332334234244436435353 hello world here -----------------------------------
It will find three matches, the positions will be relative to the start of the buffer, *not* the start of the current line. Boost.Regex generally isn't interested in lines (other than matching ^ and $), it considers \n as just another character.
John.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users