reveal.js: HTML-презентации

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

По поводу кода, соглашусь, всегда следует максимально упрощать код для слайда, желательно до тех самых 4-5 строчек, однако это не всегда возможно:

• Например, если речь заходит про метапрограммирование в C++, то тут 5 строчками никак не обойтись

• Может быть важен контекст, т.е. еще 5-6 срок помимо тех, на которых концентрируется внимание

По поводу печати, я пробовал только сохранять в pdf (возможно это и имелось в виду), сохраняет вполне сносно, есть какая-никакая кастомизация: фрагменты можно сохранить или "все сразу видимые" или же "по одному на слайд".

Ну а локальное сохранение(хранение) выглядит аналогично сохранённой локально веб-странице: .html-страница + папка со скриптами/изображениями/...

P.S. Сам в LaTeX никогда не верстал, лишь запланировал попробовать такой подход.

reveal.js: HTML-презентации

Спасибо, добавил в пост.

Производительность компилятора при работе с концептами в C++20

Согласен, но если использовать "настоящие файлы", то невозможно отследить влияние той или иной конструкции на компиляцию. Было решено для начала посмотреть на одиночные, они же синтетические, варианты, а затем протестировать что-то из реальной жизни. Например, вариант библиотеки из C++17 VS он же, но из C++20.

Производительность компилятора при работе с концептами в C++20

Если именно применительно к концептам, то для компилятора разницы между вариантом со static_cast и вариантом с конструктором нет. Иными словами:

template<typename T>
concept SignedIntegral_v1 = std::integral<T> && T(-1) < T(0);

template<typename T>
concept SignedIntegral_v2 = std::integral<T> && static_cast<T>(-1) < static_cast<T>(0);

void foo(SignedIntegral_v1 auto const &) {}
void foo(SignedIntegral_v2 auto const &) {}

void later() {
    foo(int32_t { 1 }); // call of overloaded 'foo(int)' is ambiguous
}

Производительность компилятора при работе с концептами в C++20

С одной стороны да, мы довольно много подсказали компилятору сами. С другой стороны мы написали довольно много кода, который компилятору нужно прочитать, к тому же добавили несколько enable_if, наследований, которые необходимо обработать и т.д. Так что тут, вроде, более выигрышным выглядит вариант с концептами. Сложно ответить «почему», не зная деталей реализации, но мы попытались)

Про концепты — соглашусь. Логичнее было бы Big, однако в угоду старых привычек назвал IsBig, каюсь, грешен:)

Касаемо msvc: его отсутствие никак не связано с ужасными/отличными результатами. Дело в том, что уже порядка трёх лет не компилируюсь msvc, вот он и не пришёл на ум сразу (компилируюсь, что не удивительно, gcc/clang на Ubuntu). А когда большую часть замеров выполнил, то пришёл к выводу, что будет справедливо сравнивать gcc/clang выполняемые на Ubuntu (WSL) с msvc на Windows (Host). Так что пока только gcc/clang. Думаю, msvc стоит протестировать обособленно, или, может, с тем же clang, но уже на windows.

Прошу прощения, не заметил дополнения с вопросом про signed_integral.
В данном примере, на мой взгляд, разницы между static_cast и вызовом конструктора нет. (Откуда пример, кстати?)
Уточните, пожалуйста, что вы понимаете под более/менее жестким требованием?

Производительность компилятора при работе с концептами в C++20

Да, ошибки копи-паста.
Все template<> явно лишние.
Спасибо, пофиксил!

Производительность компилятора при работе с концептами в C++20

Спасибо за идею, обязательно проверим.

Пока что могу сказать, что основываясь на сравнении с optional (тоже один из примеров в статье Андрея), вариант с trailing requires clause работает значительно медленнее классической реализации с использованием прокси/базовых классов. Но, как уже обещал, обязательно проверю отдельно pair в следующей статье по концептам.

Производительность компилятора при работе с концептами в C++20

Скопирую сюда сниппет, о котором идёт речь. Или godbolt.org.

template <class> void foo() {} //1
void useFirst()
{
    foo<void>();// call 1 - instantiate "void foo<int>()"
}

template <class> void foo() requires true {} //2
void useSecond()
{
    foo<void>();// call 2 - instantiate "void foo<int>() requires true"
}

// error example: definition with same mangled name '_Z3fooIvEvv' as another definition

Выглядит как довольно специфичный баг компилятора: нужно, чтобы шаблон без ограничения инстанциировался до того, как будет объявлен шаблон с ограничением, такое в своей практике видел один или два раза. Обычно есть условный .hpp, где все шаблоны объявляются, и есть .h/.cpp, где инстанциируются и используются шаблоны из .hpp.
Конечно, досадно, что не всё работает так, как надо, но это всего лишь 1-5% случаев.

Производительность компилятора при работе с концептами в C++20

DELETED