Обновить

Комментарии 11

MSVC создали лучшую реализацию модулей и хватит)

А почему она лучшая?

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.

Но вот свои последние проекты уже пишу только на зиге, когда есть нужда в быстром и портируемом коде. Не дождался я рефлексии и пр - стандарты утверждают, но реализаций - нет. А Зиг уже просто язык нового уровня и на нем что-то делать - одно удовольствие.

Только есть нюанс в виде отсутвия 1.0 версии и шансу получить ломающие изменения вместе с условным apt install zig. Для стартаперов/фрилансеров наверное хорошо, для корпораций - без стандарта, без гарантий совместимости хотя бы лет на 5 - не очень.

А потом автор жалуется, что язык отовсюду выкидывают. Ну я не вижу перспектив его развития

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации