Почему именованные параметры используются реже?

Мой вопрос в том, почему этот синтаксис больше не используется, перегружая оператор() для реализации именованных параметров.

Потому что это нелогично, неудобочитаемо и, возможно, является плохой практикой программирования. Если вы не хотите саботировать кодовую базу, избегайте этого.

test(( name("Special :-)"), ref<unsigned long>(num) ));

Допустим, я впервые вижу этот фрагмент кода. Мой мыслительный процесс выглядит следующим образом:

1. На первый взгляд это выглядит как пример "самого неприятного синтаксического анализа", потому что вы используете двойной круглые скобки. Итак, я предполагаю, что test является переменной, и должен задаться вопросом, не забыли ли вы написать тип переменной. Затем мне приходит в голову, что эта штука действительно компилируется. После этого я должен задаться вопросом, является ли это экземпляром немедленно уничтоженного класса теста типа, и вы используете имена в нижнем регистре для всех типов классов.
2. Затем я обнаруживаю, что на самом деле это вызов функции. Здорово.
3. Фрагмент кода теперь выглядит как вызов функции с двумя аргументами.
4. Теперь мне становится очевидно, что это не может быть вызов функции с двумя аргументами, потому что вы использовали двойные скобки.
5. Итак, СЕЙЧАС я должен понять, что, черт возьми, происходит внутри ().
6. Я помню, что есть оператор запятая (который я никогда не видел в реальном коде C++ в течение последних 5 лет), который отбрасывает предыдущий аргумент. ТАК СЕЙЧАС я должен задаться вопросом, что это за полезный побочный эффект name() и что такое name() - вызов функции или тип (потому что вы не используете прописные/строчные буквы, чтобы различать класс/функцию (т.е. Test — это класс, а test — функция), и у вас нет префиксов C).
7. После поиска name в исходном коде я обнаружил, что это класс. И что он перегружает оператор ,, так что фактически больше не отбрасывает первый аргумент.

Видите, сколько времени здесь потрачено впустую? Откровенно говоря, написание чего-то подобного может навлечь на вас неприятности, потому что вы используете особенности языка, чтобы сделать ваш код чем-то отличным от того, что он делает на самом деле (вы делаете вызов функции с одним аргументом таким, как будто он имеет два аргумента или что-то вроде этого). это вариационная функция). Это плохая практика программирования, которая примерно эквивалентна перегрузке оператора + для выполнения вычитаний вместо сложений.

Теперь давайте рассмотрим пример QString.

 QString status = QString("Processing file %1 of %2: %3").arg(i).arg(total).arg(fileName);

Допустим, я вижу это впервые в жизни. Вот как проходит мой мыслительный процесс:

1. Есть переменная status типа QString.
2. Он инициализируется временной переменной типа QString().
3. ... после вызова метода QString::arg. (Я знаю, что это метод).
4. Я ищу .arg в документации, чтобы узнать, что он делает. , и обнаружите, что он заменяет записи в стиле %1 и возвращает QString&. Таким образом, цепочка из .arg() вызовов сразу обретает смысл. Обратите внимание, что что-то вроде QString::arg может быть создано по шаблону, и вы сможете вызывать его для различных типов аргументов, не указывая вручную тип аргумента в <>.
5. Этот фрагмент кода теперь имеет смысл, поэтому я перехожу к другому фрагменту.

выглядит более "современно" C++

«Новый и блестящий» иногда означает «глючный и сломанный» (slackware linux был построен на похожей идее). Неважно, выглядит ли ваш код современно. Он должен быть удобочитаемым, он должен делать то, для чего предназначен, и вы должны тратить как можно меньше времени на его написание. т.е. вы должны (личная рекомендация) стремиться «реализовать максимальный объем функций за минимальное время с минимальными затратами (включая обслуживание)», но получить за это максимальное вознаграждение. Также имеет смысл следовать принципу KISS.

Ваш «современный» синтаксис не снижает стоимость разработки, не сокращает время разработки и увеличивает стоимость обслуживания (нелогично). В результате этого синтаксиса следует избегать.

Нет необходимости. Ваша динамическая диспетчеризация (ведет себя по-разному, в зависимости от логического типа аргумента) может быть реализована а) намного проще и б) намного быстрее, используя специализацию шаблона.

И если вам на самом деле требуется различие, основанное на информации, доступной только во время выполнения, я бы попытался переместить вашу функцию test в виртуальный метод типа param и просто использовать динамическую привязку (для этого она и нужна). изобретаешь).

Единственными случаями, когда этот подход был бы более полезным, могут быть сценарии с множественной отправкой, когда вы хотите сократить код и можете найти некоторые шаблоны сходства.