Комментарии 11
Новая фича «Designated initializers» - топ. Столько раз об это спотыкался.

struct X1 { virtual void f() pre(a) post(b); };
а объявления контрактов прибиты к объявлению функции или их можно в месте имплементации писать? типа
// header.hpp
struct X1 { virtual void f(); };
// header.cpp
#include "header.hpp"
void X1::f()
pre(a) post(b)
{
/*implementaion */
}Увы, в месте имплементации так писать не получится. Согласно P2900, в котором были введены контракты:
Any function declaration is a first declaration if no other declarations of the same function are reachable from that declaration; otherwise, it is a redeclaration. The sequence of function contract specifiers on a first declaration of a function introduces the corresponding function contract assertions that apply to that function. It is ill-formed, no diagnostic required (IFNDR) if multiple first declarations for the same function are in different translation units that do not have the same sequence of function contract specifiers. A redeclaration of a function shall have either no function contract specifiers or the same sequence of function contract specifiers as any first declaration reachable from it; otherwise, the program is ill-formed.
А этот пропозал, разрешающий использование контрактов в виртуальных функциях, это положение дел не меняет.
это противоречит смыслу контрактов
Можете раскрыть, почему бы не использовать at() для const std::map в вашем примере? Я понимаю, что он может бросить исключение, но допустим что готов к этому. А накладные расходы на проверку валидности внутри .at() кажется такие же как и у iter != theMap.end()
Вы правы, что можно использовать at(), в пропозале даже представлен пример с его использованием:
double largest = -std::numeric_limits<double>::infinity();
for (int i = 1; i <= 100; ++i)
{
try {
largest = std::max(largest, theMap.at(i));
} catch (const std::out_of_range&) { }
}
Часть с «я уверяю вас, вы не хотите этого делать» я добавил как раз из-за необходимости обработки исключений в этом случае: практически на пустом месте получаем ухудшение производительности.
Писал на С++ 20 лет, сильно радовался ренессансу в виде 11, 17 и 20.
Но вот свои последние проекты уже пишу только на зиге, когда есть нужда в быстром и портируемом коде. Не дождался я рефлексии и пр - стандарты утверждают, но реализаций - нет. А Зиг уже просто язык нового уровня и на нем что-то делать - одно удовольствие.
А потом автор жалуется, что язык отовсюду выкидывают. Ну я не вижу перспектив его развития

Что нового в C++29: итоги июньской встречи в Брно