AT
Все контейнеры?
здесь можно аллокатор свой сделать, который бы позволял сообщать о неудаче
Size: a a a
2021 February 08
D
здесь можно аллокатор свой сделать, который бы позволял сообщать о неудаче
И как же?
АК
здесь можно аллокатор свой сделать, который бы позволял сообщать о неудаче
нельзя, реализация контейнеров внутри завязана на инварианты различных операций
AT
в
Allocator::allocate флаг somethingGoingWrong в true выставлять и проверять после каждого push_back)D
какие части STL не удастся использовать, если сделать
-fno-exceptions? В их числе std::make_unique (легко заменить на свою обёртку с new (std::nothrow)), std::sto* (<charconv>). Что ещё?В связи с чем появилось такое требование?
AT
нельзя, реализация контейнеров внутри завязана на инварианты различных операций
действительно
АК
в
Allocator::allocate флаг somethingGoingWrong в true выставлять и проверять после каждого push_back)но об этом не будет знать контейнер :(
AT
В связи с чем появилось такое требование?
оно свыше. Пока не имеет смысла, кажется
ПК
в
Allocator::allocate флаг somethingGoingWrong в true выставлять и проверять после каждого push_back)После push_back у тебя уже сломан мир будет
AT
После push_back у тебя уже сломан мир будет
уже уяснил
МК
подскажите где можно подробно прочитать про атрибуты в си? желательно на русском
FileInfo *PROCESSES attribute((section ("shared"), shared)) = NULL;
unsigned int CNT_PROC attribute((section ("shared"), shared)) = 0;AB
подскажите где можно подробно прочитать про атрибуты в си? желательно на русском
FileInfo *PROCESSES attribute((section ("shared"), shared)) = NULL;
unsigned int CNT_PROC attribute((section ("shared"), shared)) = 0;В доке компилятора
AB
Атрибутов много, вопрос общий или конкретный?
МК
я хотел прочитать в целом про тему. Но нужно изучить конкретно про shared
МК
читал... нет серьезных примеров... например ограничения shared — windows NT, а есть что либо подобное на линукс?
D
Пусть есть
При вызовах вида
Даже при включенных оптимизациях.
Понимая, что немного оффтопик, сформулирую вопрос так: какие у компилятора могут быть основания не подставлять тело лямбды?
Никаких вызовов по указателю внутри самой лямбды нет.
template<class Callback, class... Types>
void process_data(Callback c, const Types&... args) { ... }
При вызовах вида
process_data([](...){...}) - т.е. от лямбды - в бинаре вижу нечто вида...
call rax;
...
Даже при включенных оптимизациях.
Понимая, что немного оффтопик, сформулирую вопрос так: какие у компилятора могут быть основания не подставлять тело лямбды?
Никаких вызовов по указателю внутри самой лямбды нет.
AB
Пусть есть
При вызовах вида
Даже при включенных оптимизациях.
Понимая, что немного оффтопик, сформулирую вопрос так: какие у компилятора могут быть основания не подставлять тело лямбды?
Никаких вызовов по указателю внутри самой лямбды нет.
template<class Callback, class... Types>
void process_data(Callback c, const Types&... args) { ... }
При вызовах вида
process_data([](...){...}) - т.е. от лямбды - в бинаре вижу нечто вида...
call rax;
...
Даже при включенных оптимизациях.
Понимая, что немного оффтопик, сформулирую вопрос так: какие у компилятора могут быть основания не подставлять тело лямбды?
Никаких вызовов по указателю внутри самой лямбды нет.
Сколько в ней строк?
АК
Пусть есть
При вызовах вида
Даже при включенных оптимизациях.
Понимая, что немного оффтопик, сформулирую вопрос так: какие у компилятора могут быть основания не подставлять тело лямбды?
Никаких вызовов по указателю внутри самой лямбды нет.
template<class Callback, class... Types>
void process_data(Callback c, const Types&... args) { ... }
При вызовах вида
process_data([](...){...}) - т.е. от лямбды - в бинаре вижу нечто вида...
call rax;
...
Даже при включенных оптимизациях.
Понимая, что немного оффтопик, сформулирую вопрос так: какие у компилятора могут быть основания не подставлять тело лямбды?
Никаких вызовов по указателю внутри самой лямбды нет.
он решает не инлайнить, вот и всё