Предположим, у меня есть функция, которая принимает два аргумента,
void f(int x, int y);
и я хочу связать одного из них. я могу использовать std::bind
следующее:
auto partiallyBoundF = std::bind(f, 10, _1);
partiallyBoundF
принимает только один аргумент, но я могу назвать его более чем одним. Аргументы за пределами первого даже не должны быть такого типа, который имеет какой-либо смысл:
partiallyBoundF(20, 0);
partiallyBoundF(0, 44, -99, "Hello", 4.5, true, []{});
Какова цель разрешения объектов, возвращаемых из bind
быть переданы дополнительные аргументы? Это позволяет вызывать ошибки для компиляции, которые будут отклонены в любом другом месте.
Игнорирование дополнительных аргументов намного проще в реализации и может быть полезным.
В типичной реализации, например, libstdc ++ (g ++), подход заключается в сборе operator()
аргументы в кортеж, а затем пусть std::placeholder
аргументы связывания извлекают их по мере необходимости. Для принудительного подсчета аргументов потребовалось бы подсчитать количество используемых заполнителей, что было бы довольно сложно. Обратите внимание, что вызываемая привязка может быть функтором с несколькими или шаблонными operator()
шаблоны вызовов, поэтому объект связывания operator()
не может быть сгенерировано с одной «правильной» подписью.
Также обратите внимание, что вы можете написать:
std::bind(&foo, std::placeholders::_1, std::placeholders::_3);
то есть явно игнорирует второй аргумент объекта привязки. Если bind
для принудительного подсчета аргументов вам понадобится дополнительный способ указать это, например четвертый аргумент также должен был быть проигнорирован.
Что касается полезности, рассмотрим привязку обработчика сигнала элемента к сигналу:
sig.connect(std::bind(&C::on_sig, this, param, std::placeholders::_1));
Если sig
имеет дополнительные параметры нежелательных излучений, то они просто игнорируются bind
объект; в противном случае привязка одного и того же обработчика к нескольким сигналам потребует написания нескольких упаковщиков перенаправления без реальной цели.
Других решений пока нет …