Arseny
А кто-нибудь в курсе, лямбды, которые не копируются в stl уже научились куда-то сохранять?
Vsevolod
да, вот как раз хотел к этой теме привлечь внимание
Vsevolod
семантика копирования будет довольно вредной для таких stack_function
Denis
ну вот такие костыли и пишут, каждый себе сам. был бы с++ для людей, а не для членов комитета — это сразу было бы в stl
Слушал Гора Нишанова про корутины, он там рассказывал, как некоторые в комитете были недовольны словом yield, потому что оно в представляемых ими прикладных областях типа энергетики и сельхоз означало ваще другое.
Vsevolod
ну и проблема с кложурами, которые захватывают movable объекты
Vsevolod
вот типа std::unique_ptr
Vsevolod
и все, std::function ломается нафиг
Arseny
Ага. И еще часто такую лябду нельзя вызывать больше одного раза.
Arseny
Потому что она это unique_ptr куда-то передает, например.
Thorn
Слушал Гора Нишанова про корутины, он там рассказывал, как некоторые в комитете были недовольны словом yield, потому что оно в представляемых ими прикладных областях типа энергетики и сельхоз означало ваще другое.
ну во всех осрв, наверное, есть функция типа чтото_yield(), но это же не причина тормозить корутины, лол. как-нибудь догадаемся не путать с ключевым словом
Vsevolod
выстрелить себе в ногу можно и более простыми способами, чем выкинуть из лямбды куда-то unique_ptr
Denis
C import export им норм.
Denis
Или как там этот ужас, я забыл.
Denis
export import?
🐙 Antony
https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-15-5-and-15-6/
Красота! Жду с нетерпением, когда приступят к C++20 :)
🐙 Antony
Как починят SFINAE - вообще красота будет
Constantine
выстрелить себе в ногу можно и более простыми способами, чем выкинуть из лямбды куда-то unique_ptr
поэтому я уже написал в локальном utilities штуку с названием once_called_function который вызывается через call_once(once_called_function<>&&, arguments&&...)
Constantine
а std::function требует, чтобы функтор был CopyConstructible
Constantine
при этом меня определенно не радует, что у лямбды нельзя поставить operator () &&
Constantine
@antoshkka я даже скинул вам это на stdcpp.ru/proposals
Stanislav
а еще в vcpkg наконец то вмержили модульный буст
Alexander "SonnySlave"
https://godbolt.org/g/3MvQ2B
Alexander "SonnySlave"
кто-нибудь мне пояснит, почему тут такое генерируется?
Alexander "SonnySlave"
Egor
Это будет некорректная оптимизация
Alexander "SonnySlave"
замени на инты
Egor
Потому что, например, NaN.
Egor
Или +inf
Alexander "SonnySlave"
замени на инты и посмотри
Alexander "SonnySlave"
https://godbolt.org/g/SKHZHA
Alexander "SonnySlave"
переполнение - UB. деление на ноль - низя
Alexander "SonnySlave"
всё, оптимизируй на интах как хочешь
Alexander "SonnySlave"
или я что-то упускаю. в случае даюлов полностью согласен - поэтому про инты и упомянул
Egor
Забавно, что он даже не может 2 * x / x с интами соптимизировать
Egor
Кроме, кстати, trunk'а clang
Alexander "SonnySlave"
Забавно, что он даже не может 2 * x / x с интами соптимизировать
я только проверял на таких кейсах - они вообще ничего не могут сделать
Egor
2 * (x / x) — пожалуйста (кроме icc 18), x / x + x / x — пожалуйста (кроме него же)
Viacheslav
Egor
Для даблов будет NaN или inf, для интов вроде будет UB (не уверен)
Viacheslav
Если да, то оптимизация в двойку технически меняет поведение.
Egor
Кстати, да
Alexander "SonnySlave"
либо мы получаем ускорение, либо UB
Egor
Но я скорее подозреваю, что компилятор смотрит на (a * b) / c и решает, что он не имеет права это переписывать в a * (b / c), потому что деление целочисленное. А в случае с даблами, видимо, точно есть проблема с NaN.
Alexander "SonnySlave"
а то, что раньше у тебя было UB, а потом починилось - это не проблемы компилятора
Viacheslav
либо мы получаем ускорение, либо UB
Получить sigfpe в лоб на undefined behaviour уже не тянет.
Egor
Да, но если там _гарантируется_ какое-нибудь исключение или поведение...
Alexander "SonnySlave"
Получить sigfpe в лоб на undefined behaviour уже не тянет.
в Стандарте ясно сказано: деление на ноль и переполнение инта - UB
Alexander "SonnySlave"
остальное не имеет значения
Egor
Надо сказать, что добавить -funsafe-math-optimizations к шлангу помогает ему догадаться до двойки.
Egor
В случае с интами
Egor
https://andrei600.wordpress.com/2016/03/15/gcc-compiler-options-funsafe-math-optimizations-and-ftracer/
Egor
Это пост про даблы, но с int'ами тоже что-то поменялось.
Egor
Хм, видимо, обознался
Alexander "SonnySlave"
https://godbolt.org/g/86rjgu
Egor
Кажется, хороший вопрос для StackOverflow
Alexander "SonnySlave"
Кажется, хороший вопрос для StackOverflow
я сделаю проще - заведу баг
Alexander "SonnySlave"
а там пацаны расскажут, что да как
Alexander "SonnySlave"
подозрительно, что даже gcc таким не занимается
Александр
x = 0 -> division by zero
Alexander "SonnySlave"
Alexander "SonnySlave"
это UB
Александр
а, ну да
Александр
раз UB, можно запросто возвращать двойку
Alexander "SonnySlave"
x+x >int тоже UB
Александр
это я знаю, а вот насчёт / 0 сомневался
Александр
казалось, что там по стандарту что-то вылетает
Vladislav
есть такой код void f(int x) { std::cout << x << " " << double(x) << "\n"; } В аутпуте 864904920 0 загадка: как такое может быть и с каким аргументом вызвали f?
Ioann_
https://godbolt.org/g/86rjgu
А разве фаст мас не должна в случае флоатов оптимайзить до двойки ?
Vsevolod
0/0 - nan
Александр
вообще там int
Alexander "SonnySlave"
А разве фаст мас не должна в случае флоатов оптимайзить до двойки ?
не уверен, что так можно делать в случае даже fast-math, так как у нас там NaN всякие есть
Alexander "SonnySlave"
и да, на интах то не отвертишься)