Re: [boost] regex_split

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-03-20 13:50:37

> >What I don't get is the reason why it [regex_split] does it this way, eating the 
> >input string. 

[snip]

> It's done that way, because that's the way that perl does it.  You can also
> specify an upper limit to the number of items to be split, in which case
> some text may be left in the string.  BTW the return value is the number of
> *items* split out, not the number of characters removed, so there is no way
> of knowing how much input has been processed unless you erase processed
> text from the input.

That perl does it that way is IMHO a good reason to supply a function 
which does it perl's way, but not a good reason not to also have one 
which does it the other way, especially when you can be more efficient 
in a fairly large set of circumstances. There are two points here. The 
first is a const correctness issue, something which perl doesn't even 
have the concept of. The second is a potential efficiency cost; in perl 
I can well believe that perl-style is faster than the non-destructive 
version, but that is certainly not true with our current 
implementation. I think a C++ library should be easily useable in 
const-correct C++-style, and hew as close as reasonably possible to the 
standard library principle of not paying for a feature you're not 
using. Both of these ideas the current interface of regex_split 
violates.

Am I alone in this opinion? If so I'll shut up and go away. :)

> BTW it's not that hard to role your own function that does what you want -
> really all you need is a custom functor to pass to regex_grep.

Of course it's not hard. But to do it right, one winds up duplicating 
98% of
the code in regex_split. For the library writer, on the other hand, it 
is easy to do it instead with a helper function which returns a pair of 
(items, characters) in the library, and have that used by both eating 
and non-eating functions.

I'm a little stuck on a good distinguishable name for a non-eating 
version, though. regex_tokenize might be okay, I guess, but it doesn't 
make the difference clear on the name. OTOH, neither does regex_split, 
so maybe we could ignore the issue.

George Heintzelman
georgeh_at_[hidden]