Почему этот порядок аргументов в прототипах regex_match? - PullRequest
Новая
       6

Почему этот порядок аргументов в прототипах regex_match?

4 голосов
/ 29 июня 2011

Вот упрощение 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);

Интересно, почему прототипы были разработаны таким образом:

  • Похоже, что и match_results, и flags являются необязательными, но вы должны предоставить один из них. Почему бы не сместить аргумент match_results & рядом с аргументом flags?
  • Аргумент regex & может показаться более интуитивным, чем основной аргумент.

Может ли кто-нибудь объяснить обоснование этих прототипов?

Спасибо.

Ответы [ 2 ]

2 голосов
/ 30 июня 2011

Единственное, о чем я могу думать, - это какая-то стилистическая согласованность с библиотекой алгоритмов. Если вы рассматриваете match_results как своего рода выходной итератор, то он выглядит как копия и т. Д. С диапазоном итератора спереди, выходным итератором после этого и предикатами после этого. Возможность не сохранять match_results превращает их в предикаты, такие как any_of и т. Д.

В библиотеке есть, что сказать о согласованности.

Это мое предположение.

0 голосов
/ 29 июня 2011

Я думаю, что согласен с вами.Ваше предложение будет иметь больше смысла.

Что касается "почему оно было выбрано именно таким", то на этот вопрос нет объективного ответа;конечно, нет никакой очевидной технической причины, которую я могу определить.

Я бы отнес это к проектному комитету.

...