On Wed, 13 Jul 2005 19:00:12 +0200, "Jan Hermelink" <Jan.Hermelink@metalogic.de> wrote:
It looks more like a bug than by design if you ask me.
I don't think so - this behaviour is specified in the standardization proposal. To quote from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1429.htm, Chapter "RE.8.2 Template class regex_token_iterator":
"If the end of sequence is reached (regex_search returns false), the iterator becomes equal to the end-of-sequence iterator value, unless the sub-expression being enumerated has index -1: In which case the iterator enumerates one last string that contains all the characters from the end of the last regular expression match to the end of the input sequence being enumerated, provided that this would not be an empty string."
!!! "provided that this would not be an empty string" !!!
How about this string: "/abc/abc". Would this result in "", "abc", "abc"? Yet "abc/abc/" would result in "abc", "abc"? That seems terribly unbalanced to me, and this is not the behavior I would expect.
I don't agree. I think this is counterintuitive, both for string_algo and regex
May be, but the above described behaviour has a good change to be standardized, and boost::split() should do the same thing.
I still don't agree based on that argument. Two wrongs don't make a right. I'd like to know the reason why the empty string is explicitly excluded in the paragraph above, though. -- Be seeing you.