Например, об этом написал Герб Саттер. Типа в C++ теперь есть и рефлексия, и контракты, и даже уменьшено число UB. Уж теперь-то точно заживем.
У меня, однако, отношение к данному событию весьма равнодушное.
Ну вот не отношусь к счастливчикам, которые пилят один проект для одной платформы на одном компиляторе. Посему не могу сидеть на самом свежем GCC (или clang-е, или MSVC) под самой-самой свежей ОС и наслаждаться плюшками самого свежего C++. До меня эти нововведения доходят спустя годы. Так что если смогу задействовать C++26 в продакшене году эдак в 2029-ом, то и хорошо.
Кроме того, в современный C++ завозят, вроде бы, крайне полезные вещи, но в таком виде, что оторопь берет.
Например, синтаксис для рефлексии. Повторял, повторю и буду повторять, что сочетания [: и :] -- это, наверное, худшее из того, что можно было придумать. Настолько плохо это различимо в коде, что просто караул.
Ну или взять контракты. В Eiffel-е -- это одна из самых классных фич языка, можно сказать киллер-фича. Тогда как в C++26 я что-то не вижу возможности использования old в постусловиях. Такое ощущение, что в C++ных контрактах мне не получится написать что-то вроде:
void push_back(T v) post(this->size() == old this->size() + 1)
{...}Если я ошибаюсь, то буду признателен за подсказку о том, как такой фокус в C++ных контрактах осуществить.
В общем, для кого-то C++ в очередной раз стал лучше. Но пока что не для меня, т.к. моя основная рабочая лошадка -- это C++17 и, местами, C++20. Однако тех, кому нововведения в C++26 нравятся и кто сможет начать их применять в ближайшее время, можно поздравить.
мне кажется вы слишком требовательны..
ОтветитьУдалить> Ну или взять контракты. В Eiffel-е -- это одна из самых классных фич языка, можно сказать киллер-фича. Тогда как в C++26 я что-то не вижу возможности использования old в постусловиях. Такое ощущение, что в C++ных контрактах мне не получится написать что-то вроде:
Я неоднократно слышал о том что контракты добавляют в минимальной комплектации, а потом будут дорабатывать. Это неизбежно в такой системе стандартизации и с таким размером фичи.
Могу ошибаться, но где-то видел предложения захватывать к контракты переменные как в лямбды. Что-то вроде `pre [size = this->size()] (this->size() == size + 1)`
А синтаксис рефлексии... какая разница вообще. Чтобы они не выбрали, всем не угодишь. Важнее то что дает эта фича, а не то какие символы использует синтаксически. Кстати, какие у вас варианты?
> Что-то вроде `pre [size = this->size()] (this->size() == size + 1)`
УдалитьКакой ужас... :(
> А синтаксис рефлексии... какая разница вообще.
Большая. Код нужно читать, а если при чтении приходится напрягаться чтобы рассмотреть [:и-что-то-еще-внутри:], то это будет утомлять сильнее, чем нужно.
> Чтобы они не выбрали, всем не угодишь.
Это да. Но когда недовольных всего 2%, то это лучше, чем когда таковых 20%.
Касательно синтаксиса рефлексии вымораживает то, что нет нормального объяснения почему был выбран синтаксис ^^ и почему в обсуждении синтаксиса для [: :] было всего четыре не сильно отличающихся друг от друга вариантов (т.е. больше похоже, что это сравнение сделали "на отвали").
> Важнее то что дает эта фича, а не то какие символы использует синтаксически.
Ну вот в Rust-е задействовали апостроф для обозначения времени жизни. И вопросительный знак для скрытой проверки на успешность и преждевременный return. Из-за чего читать Rust-овский код сложно -- при беглом взгляде легко прозевать что в середине выражения есть знак вопроса.
Т.е. плохой эргономикой можно ухудшить полезную фичу.
> Кстати, какие у вас варианты?
Я бы вынес на большое голосование кучу сочетаний разных символов и остановился бы на тех, которые набрали больше голосов. Но если говорить о том, что вызывало бы меньше отторжения у меня, то что-то вроде:
@T и [@ что-то-там @]
или хотя бы
^^T и [^ что-то-там ^]