C++ "Идиома именованного параметра" против Boost:: Библиотека параметров
Я посмотрел на идиому именованных параметров и библиотеку Boost::Parameter. Какие преимущества у каждого из них перед другим? Есть ли веская причина всегда выбирать один над другим, или каждый из них может быть лучше другого в некоторых ситуациях (и если да, то в каких ситуациях)?
6 ответов
Реализация идиома именованного параметра действительно проста, почти так же проста, как использование Boost::Parameter, так что все сводится к одной основной точке.
-У вас уже есть буст-зависимости? Если вы этого не сделаете, Boost:: параметр не является достаточно специальным, чтобы заслуживать добавления зависимости.
Лично я никогда не видел Boost::parameter в рабочем коде, 100% времени это была пользовательская реализация именованных параметров, но это не обязательно хорошо.
Обычно я большой поклонник Boost, но я бы не стал использовать библиотеку Boost.Parameter по нескольким причинам:
- Если вы не знаете, что происходит, вызов выглядит так, как будто вы присваиваете значение переменной в области видимости вызывающей функции перед выполнением вызова. Это может быть очень запутанным.
- Слишком много стандартного кода, необходимого для его настройки.
Еще один момент, хотя я никогда не использовал идиому именованных параметров, я использовал параметр повышения для определения до 20 необязательных аргументов. И мои времена компиляции безумны. То, что раньше занимало пару секунд, теперь занимает 30 секунд. Это складывается, если у вас есть библиотека вещей, которые используют ваше маленькое приложение, которое вы написали с использованием параметра boost. Конечно, я могу реализовать это неправильно, но я надеюсь, что это изменится, потому что кроме этого мне действительно нравится это.
Идиома Именованного Параметра НАМНОГО проще. Я не вижу (сейчас), почему нам нужна сложность библиотеки Boost::Parameter. (Даже предполагаемая "особенность" выведенных параметров, похоже на способ введения ошибок кодирования;))
Вы, вероятно, не хотите Boost.Parameter для общей логики приложения так сильно, как если бы вы хотели, чтобы он разрабатывался для кода библиотеки, который вы разрабатываете, где он может значительно сэкономить время для клиентов библиотеки.
Никогда не слышал об этом, но, просматривая ссылки, именованный параметр НАДО и проще для понимания. Я бы выбрал это в мгновение ока над реализацией повышения.