Geek Answers Handbook

Why is this argument ordered in regex_match prototypes?

Here is a simplification of 6 std::tr1::regex_match

 regex_match(iterator1, iterator2, match_results&, regex&, flags = some_default); regex_match(iterator1, iterator2, regex&, flags = some_default); regex_match(Elem*, match_results&, regex&, flags = some_default); regex_match(Elem*, regex&, flags = some_default); regex_match(string, match_results&, regex&, flags = some_default); regex_match(string, regex&, flags = some_default);

I wonder why the prototypes were designed this way:

  • It seems that both match_results and flags should be optional, but you should be able to provide one of them. Why not slide match_results & next to flags ?
  • The regex & argument seems more intuitive as the main argument.

Can someone explain the rationale for these prototypes?

Thanks.

+4
source share
2 answers

The only thing I can think of is some kind of stylistic sequence with a library of algorithms. If you think of match_results as some kind of output iterator, then it looks like a copy, etc. With an iterator range at the front, an output iterator after that, and predicates after that. The ability to not save match_results turns them into predicates like any_of, etc.

The library has something to say for consistency.

This is my hunch.

+2
source

I think I agree with you. Your suggestion will make more sense.

As for “why it was chosen in this way,” there is no objective answer to this question; there, of course, there is no obvious technical reason that I can notice.

I would put it aside on a step-by-step committee.

0
source

More articles:


All Articles