this month we will celebrate 30 years since the GCC 1.0 release.

Объявлен устаревшим Cilk+, набор расширений для языков Си и Си++ с реализацией предложенной компанией Intel методики параллельного программирования; Хнык-хнык

Слишком тонко

почему?

потому что я не понял)

коммент видимо не читал на пикче?

все прочитал)

т.е. тебя не смутила что вызов этой функции вызвает рейс кондишен и упс?

т.е. тебя не смутила что вызов этой функции вызвает рейс кондишен и упс?

вон, та же pvs studio иногда довольно критичные баги, которые просто в текущий момент не всплывают

ну ее еще купить надо)

Надо сюда затащить посонов из пвс студии и раздать 5-10 ключиков

уже есть http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0259r0.pdf https://github.com/tomazos/fixed_string

уже есть http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0259r0.pdf https://github.com/tomazos/fixed_string

Интересно. Я думал, что понадобится вмешательство в компилятор

_has_ всякие же

Причем тут это? Суть в выделении памяти во время компиляции

Посмотрел реализацию. А как быть, если не хватит заранее выделенного размера? Это уже похоже на костыль

размера чего?

GCC 7.1 релизнулся https://gcc.gnu.org/ml/gcc/2017-05/msg00017.html

Поменять то можно, но это получается неполноценный аллокатор - все контейнеры сразу становятся ограниченными. И ещё вопрос: я фиксирую N = 10000, использую как-то, но к концу компиляции остаётся 1 реально используемый объект. Получается, что остальные 9999 будут висеть и занимать память... где? И не будет ли накладно компилятору таскать все эти N по стеку (или где аллокатор хранит?) и т.д. при реально используемых 10-15? Я себе никак не представляю расширяемую память в компилтайме

А если в два прохода?

А если количество выделяемой памяти зависит от элементов контейнера?

Например?

а есть пруфы спрода

В проде использовать не надо. Оно работает не так как ожидается и требует большой доработки контейнеров. Прототип предназначен для того, чтобы показать что подход жизнеспособен и немного гибче чем предложение от Давиида. Чтобы начать использовать в проде - нужно дорабатывать сам компилятор (а перед этим стоит международному комитету по С++ выбрать какой подход им нравится больше, обсудить идеи, постараться придумать решение получше и т.д.). К 2020 в лучшем случае :)

В проде использовать не надо. Оно работает не так как ожидается и требует большой доработки контейнеров. Прототип предназначен для того, чтобы показать что подход жизнеспособен и немного гибче чем предложение от Давиида. Чтобы начать использовать в проде - нужно дорабатывать сам компилятор (а перед этим стоит международному комитету по С++ выбрать какой подход им нравится больше, обсудить идеи, постараться придумать решение получше и т.д.). К 2020 в лучшем случае :)

Моя хотеть генерить sql.

Моя хотеть DSL в виде читаемого текста. Например вместо магии Boost.Spirit просто писать парсер как EBNF текст: auto parser = std::from_ebnf("some text");