Boost logo

Boost :

From: John Maddock (john_at_[hidden])
Date: 2005-05-19 05:14:04

>> This one applies to Boost.RegEx, too, but I'll ask you: Why have
>> both regex_match() and regex_search() when the latter can behave
>> like the former by adding two anchors?
> This is true. I'm following the lead of the regex std proposal here, but
> I've never felt comfortable with regex_match, to be honest. A common
> noobie mistake is to use regex_match instead of regex_search. Perl, for
> instance, doesn't distinguish between "search" and "match" operations, and
> "search" is the default. What makes it worse is that in Perl circles, the
> semantic equivalent of regex_search is called /matching/, hence the
> disconnect. Not sure what to do. Perhaps John could comment.

If I remember correctly the original terminology was inherited from the GNU
regex package, and later got refined as a result of user feedback. But
Eric's correct it is a major source of confusion *for those migrating from

The aim was that the code should be quite explicit about what it's doing: a
programmer that sees regex_match would know that the code is looking to
match all of the text and not just some part of it.

>> Why does the regex_token_iterator<> ctor use a magic number like
>> -1 to indicate behavior rather than a named value? (I just
>> clicked through to the reference and see that it takes a
>> regex_constants::match_flag_type, but
>> shows passing -1 -- with an explanatory comment -- instead. This
>> leads to confusion.)
> Again, I'm just following the standard here, but providing a named
> constant would be a nice addition. The -1 is an optional 4th parameter,
> and the match_flag_type is an optional 5th parameter -- so there should be
> no confusion.

The -1 means "the thing before 0" and 0 is the whole of what matched, so -1
is the string before the bit that matched. Well that's the logic anyway.
Doesn't seem to have caused any confusion in practice, but there's no harm
in adding a named constant.

> The regex std proposal has match flags match_not_bol and match_not_eol, so
> I'm reusing this terminology. Boost.Regex also has match_not_bob for
> "beginning of buffer". This is not proposed for standardization, and I
> don't think the term "buffer" is appropriate anyway. You like "input" but
> I prefer "sequence". I dislike "input" becauase it might suggest to people
> that input iterators are acceptable to the regex algorithms, where as a
> bidirectional sequence is what is required.

Historically, those terms (or very similar) are used by GNU regex and the
BSD (Henry Spencer) packages. Renaming them would probably start a
bicycle-shed style discussion I guess. Good names are hard, especially if
the answer isn't immediately obvious!



Boost list run by bdawes at, gregod at, cpdaniel at, john at