Size: a a a

2021 February 03

AV

Aleksey Verkholat in pro.cxx
Переслано от Aleksey Verkholat
как в мейке заэскейпить = ?
надо чето типа такого

Params += P1=val1
Params += P2=val2
$(MAKE) ... $(Params) target_name
источник

AN

Alexander N in pro.cxx
Я бы вообще в контексте драйверов не использовал исключения наверное. Но тогда придется контейнеры использовать non-stl. Типа без кидания bad alloc
источник

AZ

Alexander Zaitsev in pro.cxx
Переслано от Ekaterina Sokolova
Коллеги, тут в MSVC коварный баг со swap не хотят фиксить, говорят, голосов мало. Можете поддержать? https://developercommunity2.visualstudio.com/t/optimizer-wrongly-removing-active-code/924863?fbclid=IwAR2rDoq9afWOVinVkVA4n6prBaC5GupFHcK50qExJRPzr_IjW9L1AcC6St8
источник

NY

Nikita Yankovskii in pro.cxx
Alexander N
Я бы вообще в контексте драйверов не использовал исключения наверное. Но тогда придется контейнеры использовать non-stl. Типа без кидания bad alloc
Можно использовать noexcept версии
источник

AN

Alexander N in pro.cxx
Правда я вот не знаю, драйвер может "выйти"(выгрузиться?) если что-то пошло не так. Просто в C вроде делается longjmp и происходит зачистка как я понял всего и выход, но это в программах в юзерспейсе, не знаю какие там правила для драйверов думаю похожие, только выход драйвера может не убивать систему, а например девайс сделать неработоспособным(у меня такое на линуксе наблюдалось с видеокартой).
источник

m

magras in pro.cxx
Alexander N
Правда я вот не знаю, драйвер может "выйти"(выгрузиться?) если что-то пошло не так. Просто в C вроде делается longjmp и происходит зачистка как я понял всего и выход, но это в программах в юзерспейсе, не знаю какие там правила для драйверов думаю похожие, только выход драйвера может не убивать систему, а например девайс сделать неработоспособным(у меня такое на линуксе наблюдалось с видеокартой).
На сколько я помню, longjump не может прыгать через конструкторы/деструторы по очевидным причинам. В си нет ни того ни другого, поэтому там его проще использовать.
источник

DF

Dollar Føølish in pro.cxx
longjmp просто проигнорирует это все
источник

DF

Dollar Føølish in pro.cxx
деструкторы там, скопгарды
источник

m

magras in pro.cxx
Dollar Føølish
longjmp просто проигнорирует это все
Ну вообще это UB. На практике вероятно действительно просто проигнорирует.
источник

VK

Valentin Kornienko in pro.cxx
Dollar Føølish
longjmp просто проигнорирует это все
Не уверен, что это хорошая идея, MISRA такие штуки не рекомендует применять
источник

АП

Андрей Пушков(Стеняе... in pro.cxx
Alexander Zaitsev
Переслано от Ekaterina Sokolova
Коллеги, тут в MSVC коварный баг со swap не хотят фиксить, говорят, голосов мало. Можете поддержать? https://developercommunity2.visualstudio.com/t/optimizer-wrongly-removing-active-code/924863?fbclid=IwAR2rDoq9afWOVinVkVA4n6prBaC5GupFHcK50qExJRPzr_IjW9L1AcC6St8
done
источник

MK

Mikhail Kalugin in pro.cxx
+
источник

DS

Dmitry Sokolov in pro.cxx
Андрей Руссков
если упорядоченный контейнер отсортирован по Compare1, а мы делаем transparent операции по Compare2, где упорядоченность по Compare1 гарантирует упорядоченность по Compare2, но не наоборот, то сохраняются ли все наши гарантии?
Ну изначально то таки не transparent был компаратор, так что результат то корректный для key_type. А я вот чот раньше думал что equal_range это реально пара upper/lower bound и местами "оптимизировал" через lower+iterate while equal. А оно оказывается не от корня пляшет же для upper внутри. Модно.
источник

AN

Alexander N in pro.cxx
Dollar Føølish
longjmp просто проигнорирует это все
Ну ему класть на всё по-идее. И это не знаю к каким последствиям привести может )
источник

АР

Андрей Руссков... in pro.cxx
Dmitry Sokolov
Ну изначально то таки не transparent был компаратор, так что результат то корректный для key_type. А я вот чот раньше думал что equal_range это реально пара upper/lower bound и местами "оптимизировал" через lower+iterate while equal. А оно оказывается не от корня пляшет же для upper внутри. Модно.
самое смешное - если бы стандарт прописал что стандартные контейнеры и алгоритмы могут использовать <=> напрямую, а не в качестве <, то lower/upper bound'ы не было бы смысла так оптимизировать
источник

DS

Dmitry Sokolov in pro.cxx
Андрей Руссков
самое смешное - если бы стандарт прописал что стандартные контейнеры и алгоритмы могут использовать <=> напрямую, а не в качестве <, то lower/upper bound'ы не было бы смысла так оптимизировать
А вот не факт. Например тот же find сэкономит на последнем сравнении, но получит три ветки в  цикле.
источник

DS

Dmitry Sokolov in pro.cxx
Андрей Руссков
самое смешное - если бы стандарт прописал что стандартные контейнеры и алгоритмы могут использовать <=> напрямую, а не в качестве <, то lower/upper bound'ы не было бы смысла так оптимизировать
Ну и сам по себе <=> тяжелей.
источник

АР

Андрей Руссков... in pro.cxx
это при условии что компилятор не справляется
источник

АР

Андрей Руссков... in pro.cxx
простейший пример: вычисление эквивалентности для std::string получается:
x.compare(y) < 0 && y.compare(x) < 0;
а могло бы быть просто x.compare(y)
источник

DS

Dmitry Sokolov in pro.cxx
Андрей Руссков
простейший пример: вычисление эквивалентности для std::string получается:
x.compare(y) < 0 && y.compare(x) < 0;
а могло бы быть просто x.compare(y)
Ну для string понятно что будет ок, сложней со всякими чиселками. Хотя да, тут вопрос в эффективности перевода результата сравнения в ordering.
источник