6:40 Если в функции создавать статик который на компайл тайме не посчитать - компилятор возьмет положит переменную в бинарник куда то (bss) проинициализирует 0. потом когда дойдет до вызова этой функции компилятор такой - а, она не проинициализированна, захватит reсursive mutex, проинициализирует, отпустит мутек и вернется.
8:20 Constexpr конструктор если есть и все параметры входные в него constexpr известны - то стандарт говорит о том что эти переменные необходимо статически инициализировать (на этапе компиляции). Получается частично решается проблема порядка инициализации.
Сonstexpr считает фронтенд компилятора - С++ сторона.
Переполнение знакового числа в С++ - UB (неопределенное поведение).
Надо проверить код: (по убирать constexpr):
Consexpr new
New + vector хотят сделать constexpr. С учетом того что new в функции выделенный будет в ней же освобожден.
Они пошли дальше: можно возвращать проаллоцированную память и она как бы смапится (будет выделенна будто статик) сразу в бинарнике. Для реализации подобного функционала компилятор будет "проверять" (будто бы вызывать) деструктор объекта и следить что память вся будет "когда-то" очищена.
На момент С++17 все std::string инициализируются динамически - соотв. медленно. Constexpr new решит это.
20:00 Во многих языках регулярки работают следующим образом: компилятор по регулярному выражению строит огромный (динамически сконфигурированный) недетерминированный конечный автомат. На след. этапе недетерминированный конечный автомат оптимизируется до детерминированного.
В с++ это не может выполнится (пока) на этапе компиляции и получается в рантайме ты тратишь время на его создание, инициализацию переменной regex ( в случае static const один раз за все время),но!
Все изменения static переменных выполняются из под recursive mutex!
С constepxr new регулярки смогут считать так же на этапе компиляции.
26:00 В с++17 добавили поисковые движки. (их минус в том что они конструируются долго, ищут быстро (иногда нет)). С 20 и constexpr должно работать на компиляции.