SE
19.27 уже
Size: a a a
2020 August 14
SE
operator() у лямбды по умолчанию const, а насчёт констэкспра ничего нет
constexpr: explicitly specifies that the function call operator is a constexpr function. When this specifier is not present, the function call operator will be constexpr anyway, if it happens to satisfy all constexpr function requirements
с++17
с++17
ПК
constexpr: explicitly specifies that the function call operator is a constexpr function. When this specifier is not present, the function call operator will be constexpr anyway, if it happens to satisfy all constexpr function requirements
с++17
с++17
Ну там вроде нет satisfied
ПК
Это же баг MSVC? Вроде бы да, но в такое время суток я в себе уже не уверен
https://godbolt.org/z/Wze5oc
(обновил ссылку, исправил глупость, ошибка не поменялась)
А остальные компиляторы ругаются на "non-constant condition for static assertion", тоже не понимаю, почему, ведь лямбда по умолчанию constexpr?
https://godbolt.org/z/Wze5oc
(обновил ссылку, исправил глупость, ошибка не поменялась)
А остальные компиляторы ругаются на "non-constant condition for static assertion", тоже не понимаю, почему, ведь лямбда по умолчанию constexpr?
Если ты про то что он якобы I не видит, то тут баг только в сообщении об ошибке видимо, потому что в коде, который должен компилироваться он нормально I видит
O
Корректен ли данный пример кода, есть ли в стандарте где-то гарантия, что этот код должен компилироваться?
а
Корректен ли данный пример кода, есть ли в стандарте где-то гарантия, что этот код должен компилироваться?
в C++ можно завтипы делать?
O
в C++ можно завтипы делать?
Зависит от того, что подразумевается под зависимыми типами. У меня недостаточно понимание этой концепции и я не уверен, относится ли этот вопрос к моему
Но, тем не менее, на уровне моего понимания — в общем случае нельзя, в частном — можно попытаться
Но, тем не менее, на уровне моего понимания — в общем случае нельзя, в частном — можно попытаться
SB
Привет всем
SB
кто умеет верстать сайты отпишите пожалуйста в лс, нужна консультация на пару вопросов.
МЧ
Здрасте, вопрос такой: кто какой ide пользуется и какую посоветуете для начала работы с плюсами?
AZ
Здрасте, вопрос такой: кто какой ide пользуется и какую посоветуете для начала работы с плюсами?
A
19.27 уже
у меня в 19.27 то же самое
A
Короче, эта шляпа точно не может компилироваться, потому что ни K, ни I не constexpr
Такая шляпа у меня отлично компилируется по всему проекту в шаблонах static_for.
Я даже больше скажу, ошибка в MSVC повторяется, если I и K сделать шаблонными параметрами шаблонной лямбды, которые, очевидно, не могут не быть compile-time.
Я даже больше скажу, ошибка в MSVC повторяется, если I и K сделать шаблонными параметрами шаблонной лямбды, которые, очевидно, не могут не быть compile-time.
A
Вот так точно должно работать. Но не работает, причём нигде
https://godbolt.org/z/j1hnxe
https://godbolt.org/z/j1hnxe
A
А вот так работает. Проблема именно во вложенной лямбде. Когда будто при вложенности теряются constexpr атрибуты???
https://godbolt.org/z/njx69z
https://godbolt.org/z/njx69z
DS
есть некий сервис на С++, который состоит из множества частей. Хотелось бы понимать в разные моменты времени, какие части приложения сколько выжрали оперативной памяти. То есть организовать достаточно детализированный профайлинг памяти для приложения.
Сейчас регулярно снимается стастика с аллокатора (jemalloc), но понятное дело, что это говорит только о ситуации для всего приложения.
Есть идеи, как подобное организовать?
Первое, что мне приходит в голову - разным частям приложения раздать разные аллокаторы и зафорсить по крайней мере для начала административно их использование в различных подсистемах приложения. Ну или свой аллокатор с какими-то метками для каждой части приложения, которые при аллоках\деаллоках будет заниматься подсчётом нужной статистики.
Почему не используются готовые утилиты профайлинга - они не дают нужной точности.
Если важно - С++14
Сейчас регулярно снимается стастика с аллокатора (jemalloc), но понятное дело, что это говорит только о ситуации для всего приложения.
Есть идеи, как подобное организовать?
Первое, что мне приходит в голову - разным частям приложения раздать разные аллокаторы и зафорсить по крайней мере для начала административно их использование в различных подсистемах приложения. Ну или свой аллокатор с какими-то метками для каждой части приложения, которые при аллоках\деаллоках будет заниматься подсчётом нужной статистики.
Почему не используются готовые утилиты профайлинга - они не дают нужной точности.
Если важно - С++14
Я делал на основе pmr, singlton registry именованных ресурсов, которые просто прокси в default resource со счётчиками. Всю инфу по счётчикам можно получить через registry. Уровень детализации тут на вкус, хоть до каждого класса. При этом не обязательно делать контейнеры pmr, можно сделать stateless allocator параметризуемый singlton-ресурсом, который может выглядеть примерно так:
struct my_resource {
static memory_resource* get() {
static auto* mem = get_counted_memory_resource("My-memory");
return mem;
}
};
Ну и таким образом можно ещё повозиться с type_info и для контейнеров вообще это дело зашаблонить, using vector<T> = std::vector<T, counted_alloc<T, vector_alloc_resource<T>>>.АК
Вот так точно должно работать. Но не работает, причём нигде
https://godbolt.org/z/j1hnxe
https://godbolt.org/z/j1hnxe
Ни один из этих примеров не должен работать. Аргумент функции/лямбды никогда не является constexpr. Если где-то это работает, значит в компиляторе баг.
АК
Единственный более-менее нормальный способ это обойти - хотя сам аргумент не constexpr, у него может быть constexpr конвертация в значение. Например, при передаче
std::integral_constant<int, 1> в функцию, можно потом достать constexpr значение из аргумента