а что, есть безгрешные компиляторы?
ну про мсвц шутки уровня "просто он плохо понимает с++" а это уже диагноз
Berkus
Anatoly
ну про мсвц шутки уровня "просто он плохо понимает с++" а это уже диагноз
не, это уровень баек, сейчас они очень выросли
Anatoly
Я не спросил версию. Может это 2012-ая была.
любые такие вещи должны сразу становится баг репортом
Berkus
не, это уровень баек, сейчас они очень выросли
то есть до слов "но они стараются" ты не дочитал? окей
Berkus
буду делать предложения покороче
Alexander "SonnySlave"
msvc стал лучше, но всё равно говно
Alexander "SonnySlave"
И когда он там выйдет на уровень нормальных компиляторов, хз
Igor
auto iter = std::find(container.begin(), container.end(), elem) + 1
если найдётся end, его инкремент приведёт к UB?
Evgenii
да
Igor
рыр(
auto it = flag ? cont.find(x) : cont.begin();
for ( ; it != cont.end(); ++it) {
do_stuff(*it);
if (flag)
return;
}
сильно хрень?
Igor
была мысль выкинуть ретурн и сделать
begin, end = flag ? (find(), find()+1) : (begin(), end())
но понял что влечу в уб, да и как-то читаемость не повышается
Anatoly
рыр(
auto it = flag ? cont.find(x) : cont.begin();
for ( ; it != cont.end(); ++it) {
do_stuff(*it);
if (flag)
return;
}
сильно хрень?
рассмотри вариант:
if( flag ) {
auto it = std::find(std::begin(cont), std::end(cont), x);
if( it != std::end(cont) ) do_stuff(*it);
} else {
std::for_each(std::begin(cont), std::end(cont), do_stuff);
}
такой код сопровождать проще, поскольку условие с флагом локализовано в одном месте, а не разбросано в коде
Ivan
Я хоть и не люблю тернарники, но вариант с тернарником лучше. Там один раз вызывается do_stuff, и вообще он короче. Одно не понимаю, зачем внутри цикла ещё раз проверка if(flag) return
Berkus
Berkus
Я хоть и не люблю тернарники, но вариант с тернарником лучше. Там один раз вызывается do_stuff, и вообще он короче. Одно не понимаю, зачем внутри цикла ещё раз проверка if(flag) return
проверка, потому что через флаг эмулируется другое поведение
Anatoly
Я хоть и не люблю тернарники, но вариант с тернарником лучше. Там один раз вызывается do_stuff, и вообще он короче. Одно не понимаю, зачем внутри цикла ещё раз проверка if(flag) return
ну, вот ты даже не понял алгоритм. если флаг, найти и выполнить do_stuff для найденного, иначе выполнить для всех. это говорит о том, что код не понятен и требует рефакторинга
Ivan
То есть do_stuff потенциально изменяет флаг?
Alexander "SonnySlave"
а что приговаривать? нужно сидеть и писать компилятор 😊
Alexander "SonnySlave"
и пока что их компилятор говно
Ivan
В смысле, зачем тогда флаг проверять каждую итерацию
Alexander "SonnySlave"
а чей же?
Berkus
м, а чей?
Alexander "SonnySlave"
есть два: clang/c2 и msvc
Berkus
В смысле, зачем тогда флаг проверять каждую итерацию
ОДИН раз флаг проверяется, ты видишь return?
Berkus
воу воу, это никого не волнует
Alexander "SonnySlave"
1) Откуда инфа?
2) А какая мне разница как пользователю?
Alexander "SonnySlave"
второе никак не влияет на принадлежность компилятора компании.
Berkus
если так подходить то половина шланга на БЕСПЛАТНОМ аутсорсе
Alexander "SonnySlave"
а первое - пруфца хоть кинь какого-нибудь
Berkus
а по этому видно что "сложнааа"
Igor
Return будет если flag == true.
если условие выполнено, то действие выполняется только над одним найденным элементом, если нет то над всеми
Anatoly
если условие выполнено, то действие выполняется только над одним найденным элементом, если нет то над всеми
ну вот, как проговорил так и пиши, не надо экономить на читаемости
Berkus
ну вот, как проговорил так и пиши, не надо экономить на читаемости
+, всё равно компилятор найдет способ это соптимизировать еще лучше
Igor
вообще для полноты картины, такой цикл встречается в двух функциях, и хотя condition одинаковый, do_stuff делает принципиально разные вещи, а код - чужого авторства в ревью-доске
вроде как и хочется предложить вынести какой-то for_all_or_found(bool condition, Func action) + bool do_stuff1(pair<>&); bool do_stuff2(pair<>&);, но присутствует чувство, что начинаю городить огород на пустом месте 9_6
Igor
+, всё равно компилятор найдет способ это соптимизировать еще лучше
об оптимизациях
насколько хорошо оптимизируются лямбды без захвата в гцц пятилетней давности?
Berkus
лишний огород, лучше do_stuff вынеси в отдельный метод
Berkus
об оптимизациях
насколько хорошо оптимизируются лямбды без захвата в гцц пятилетней давности?
меня мало волнует гцц пятилетней давности, я только что переключил проект с 5.5 на 7.2 чего и вам желаю
Igor
меня мало волнует гцц пятилетней давности, я только что переключил проект с 5.5 на 7.2 чего и вам желаю
проект кроссплатформенный?
Berkus
конечно, но гцц он собирается только под линукс, андроид иос и мак собираются шлангом
Berkus
линукс тоже надо вжухнуть на шланг, но потом
Дмитрий ⬡
а зачем?
А зачем не? Кажется, он куда более дружелюбен по части сообщений об ошибках, и на максимум оптимизирует так, что вполне может и выиграть. Выигрывает не всегда, но пробовать можно.
Igor
хотеть переехать с 4.4 на trunk( ещё бы это не подразумевало пересборку всех тулсетов под три ARM(
Alexander "SonnySlave"
Berkus
хотеть переехать с 4.4 на trunk( ещё бы это не подразумевало пересборку всех тулсетов под три ARM(
ну то есть непонятно зачем тебе вопрос про оптимизацию лямбд - без захвата они эквивалентны указателю на функцию же
Alexander "SonnySlave"
в большинстве случаев выигрывает gcc
Alexander "SonnySlave"
но надо смотреть под задачу именно
Berkus
Примерно одинаково ведь, не?
плюс-минус, там разница больше в имплементации стдлибы, которая у кланга конформинг но медленней
Igor
ну то есть непонятно зачем тебе вопрос про оптимизацию лямбд - без захвата они эквивалентны указателю на функцию же
неправильно выразился, но спасибо
🐙 Antony
линукс тоже надо вжухнуть на шланг, но потом
Есть проект по переносу ядра линукс на clang https://lwn.net/Articles/734071/
Из плюсов - другие варнинги, другие санитайзеры. Из минусов - пока что clang плохо умеет некоторые фишки GCC и плохо работает с inline asm
Alexander "SonnySlave"
потмоу что бывает, что и шланг шустрее
Danil
Вроде не так давно они были сравнимы, где то один, гле то другой лучше
Berkus
Есть проект по переносу ядра линукс на clang https://lwn.net/Articles/734071/
Из плюсов - другие варнинги, другие санитайзеры. Из минусов - пока что clang плохо умеет некоторые фишки GCC и плохо работает с inline asm
да, проект есть, а freebsd уже по дефолту его для всего используют. такой вот план.
Кирилл
Alexander "SonnySlave"
@berkus ну так зачем на шланг уезжаешь?)
Berkus
Есть проект по переносу ядра линукс на clang https://lwn.net/Articles/734071/
Из плюсов - другие варнинги, другие санитайзеры. Из минусов - пока что clang плохо умеет некоторые фишки GCC и плохо работает с inline asm
насколько я знаю линуксовое едро уже могут собрать но не все драйверы (да и работает пока так себе)
Danil
Я бы пересел на шланг ради быстрых компиляшек
Berkus
да и сообщения об ошибках в последних гцц весьма достойные
Igor
А ещё в 4.4 нет лямбд
малость озадачился, потом вспомнил, что там где видел у нас лямбды, они использовались под линух с 4.8 😓
Danil
Видеть бы последние гцц, мы скромго сидим на 4.6((
🐙 Antony
Меня больше интресует линуксовое ядро собранное с lto. Пока вроде не собирают. Кто нибудь знает какие проблемы там всплывают (помимо нежелания Линуса)?
🐙 Antony
об оптимизациях
насколько хорошо оптимизируются лямбды без захвата в гцц пятилетней давности?
Так же хорошо, как статические функции. Проблем быть не должно
Berkus
Меня больше интресует линуксовое ядро собранное с lto. Пока вроде не собирают. Кто нибудь знает какие проблемы там всплывают (помимо нежелания Линуса)?
так там половина функций получается unreferenced без загруженных модулей и просто из ядра вылетает
Berkus
еще где-нибудь аналогичная магия с лд скриптами ломается еще
Arseny
О, привет!
Alex
Alexander "SonnySlave"
А хз, не смотрел. Думаю, что куда-то в program files