Зачем начинать с std:: placeholders:: _ 1 вместо _0?

Ответ 1

Потому что, как это делает boost::bind, и автор Boost.Bind написал предложение, чтобы добавить его в TR1 и который был скопирован в стандарт.

Что касается того, почему Boost.Bind делает это именно так, я не знаю, но я бы поставил под угрозу, что он может соответствовать std::bind1st и std::bind2nd по стандарту 1998 года, который пришел из STL. В этом контексте "1-й", то есть "первый", является правильным (даже в системе индексирования с нулевым значением элемент с нулевым индексом является первым, а не нулевым элементом.)

Поэтому, возможно, заполнители должны быть _1st, _2nd, _3rd, _4th и т.д., но для неанглийских ораторов, которые не знают несогласованных суффиксов на порядковые номера, вероятно, легче запомнить _1, _2 и т.д.

Просто дикая догадка. Этот вопрос никогда не приходил мне в голову, так что теперь мне тоже любопытно: -)

Ответ 2

Соглашение, вероятно, было перенесено с предшественника Boost.bind.

Что касается выбора библиотеки Boost, начинающейся с 1: связующие, которые были частью С++ 03, использовали first_argument и second_argument как имена типов.

Стандартная библиотека С++ имела bind1st() и bind2nd(), поэтому естественное обобщение на n-арные функции было "bind 3rd", "bind 4th" и т.д.

Ни одна из них не является реальной причиной, но дает вероятное объяснение.

Ответ 3

Преимуществом этого является работа std::is_placeholder. Результат не просто истинный или ложный, это значение самого заполнителя.

std::is_placeholder<_1>::value == 1
std::is_placeholder<_2>::value == 2
std::is_placeholder<_7>::value == 7

но все, что не является заполнителем, будет оцениваться как 0 (что, конечно, ложно). Если заполнители начинаются с _0, это не сработает.

Ответ 4

Дизайнеры библиотеки связывания boost были поклонниками пакетного синтаксиса MSDOS.

В пакетном синтаксисе %1 ссылается на первый аргумент, %2 второй, %3 третий и т.д. Но поскольку % не является допустимым идентификатором С++, он заменил его на _.

В пакетном синтаксисе MSDOS %0 ссылается на имя командного файла. В этом случае _0 будет привязан к функции, которую вы называете _1, _2, _3 и т.д..

Собственно, нет, не совсем.