рыр( auto it = flag ? cont.find(x) : cont.begin(); for ( ; it != cont.end(); ++it) { do_stuff(*it); if (flag) return; } сильно хрень?

была мысль выкинуть ретурн и сделать begin, end = flag ? (find(), find()+1) : (begin(), end()) но понял что влечу в уб, да и как-то читаемость не повышается

рыр( 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); } такой код сопровождать проще, поскольку условие с флагом локализовано в одном месте, а не разбросано в коде

рассмотри вариант: 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); } такой код сопровождать проще, поскольку условие с флагом локализовано в одном месте, а не разбросано в коде

+

Я хоть и не люблю тернарники, но вариант с тернарником лучше. Там один раз вызывается do_stuff, и вообще он короче. Одно не понимаю, зачем внутри цикла ещё раз проверка if(flag) return

Я хоть и не люблю тернарники, но вариант с тернарником лучше. Там один раз вызывается do_stuff, и вообще он короче. Одно не понимаю, зачем внутри цикла ещё раз проверка if(flag) return

чем это он лучше, ну ка

И когда он там выйдет на уровень нормальных компиляторов, хз

Всё, приговорил...

Я хоть и не люблю тернарники, но вариант с тернарником лучше. Там один раз вызывается do_stuff, и вообще он короче. Одно не понимаю, зачем внутри цикла ещё раз проверка if(flag) return

проверка, потому что через флаг эмулируется другое поведение

Я хоть и не люблю тернарники, но вариант с тернарником лучше. Там один раз вызывается do_stuff, и вообще он короче. Одно не понимаю, зачем внутри цикла ещё раз проверка if(flag) return

ну, вот ты даже не понял алгоритм. если флаг, найти и выполнить do_stuff для найденного, иначе выполнить для всех. это говорит о том, что код не понятен и требует рефакторинга

То есть do_stuff потенциально изменяет флаг?

Всё, приговорил...

а что приговаривать? нужно сидеть и писать компилятор ?

и пока что их компилятор говно

То есть do_stuff потенциально изменяет флаг?

нет, просто такой кривой код

Я хоть и не люблю тернарники, но вариант с тернарником лучше. Там один раз вызывается do_stuff, и вообще он короче. Одно не понимаю, зачем внутри цикла ещё раз проверка if(flag) return

Да пусть он хоть 10 раз вызывается...

и пока что их компилятор говно

У них не совсем ИХ компилятор...

В смысле, зачем тогда флаг проверять каждую итерацию

У них не совсем ИХ компилятор...

а чей же?

У них не совсем ИХ компилятор...

м, а чей?

есть два: clang/c2 и msvc

В смысле, зачем тогда флаг проверять каждую итерацию

ОДИН раз флаг проверяется, ты видишь return?

Половина на аутсорсе.

Половина на аутсорсе.

воу воу, это никого не волнует

ОДИН раз флаг проверяется, ты видишь return?

или если не флаг, то на каждой итерации

Половина на аутсорсе.

1) Откуда инфа? 2) А какая мне разница как пользователю?

или если не флаг, то на каждой итерации

а, ну да. но вопрос же не в этом?

1) Откуда инфа? 2) А какая мне разница как пользователю?

1) из сети 2) я не говорил, что для тебя будет какая-то разница.

В смысле, зачем тогда флаг проверять каждую итерацию

чуть выше я описал алгоритм

рассмотри вариант: 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); } такой код сопровождать проще, поскольку условие с флагом локализовано в одном месте, а не разбросано в коде

Мне толин вариант больше нравится

1) из сети 2) я не говорил, что для тебя будет какая-то разница.

второе никак не влияет на принадлежность компилятора компании.

1) из сети 2) я не говорил, что для тебя будет какая-то разница.

если так подходить то половина шланга на БЕСПЛАТНОМ аутсорсе

а первое - пруфца хоть кинь какого-нибудь

ОДИН раз флаг проверяется, ты видишь return?

Return будет если flag == true.

Return будет если flag == true.

ну вот у Анатолия получился код по которому это сразу видно

а по этому видно что "сложнааа"

Return будет если flag == true.

если условие выполнено, то действие выполняется только над одним найденным элементом, если нет то над всеми

если условие выполнено, то действие выполняется только над одним найденным элементом, если нет то над всеми

ну вот, как проговорил так и пиши, не надо экономить на читаемости

ну вот, как проговорил так и пиши, не надо экономить на читаемости

+, всё равно компилятор найдет способ это соптимизировать еще лучше

вообще для полноты картины, такой цикл встречается в двух функциях, и хотя condition одинаковый, do_stuff делает принципиально разные вещи, а код - чужого авторства в ревью-доске вроде как и хочется предложить вынести какой-то for_all_or_found(bool condition, Func action) + bool do_stuff1(pair<>&); bool do_stuff2(pair<>&);, но присутствует чувство, что начинаю городить огород на пустом месте 9_6

+, всё равно компилятор найдет способ это соптимизировать еще лучше

об оптимизациях насколько хорошо оптимизируются лямбды без захвата в гцц пятилетней давности?

лишний огород, лучше do_stuff вынеси в отдельный метод

об оптимизациях насколько хорошо оптимизируются лямбды без захвата в гцц пятилетней давности?

меня мало волнует гцц пятилетней давности, я только что переключил проект с 5.5 на 7.2 чего и вам желаю

меня мало волнует гцц пятилетней давности, я только что переключил проект с 5.5 на 7.2 чего и вам желаю

проект кроссплатформенный?

конечно, но гцц он собирается только под линукс, андроид иос и мак собираются шлангом

линукс тоже надо вжухнуть на шланг, но потом

линукс тоже надо вжухнуть на шланг, но потом

а зачем?

а зачем?

А зачем не? Кажется, он куда более дружелюбен по части сообщений об ошибках, и на максимум оптимизирует так, что вполне может и выиграть. Выигрывает не всегда, но пробовать можно.

хотеть переехать с 4.4 на trunk( ещё бы это не подразумевало пересборку всех тулсетов под три ARM(

А зачем не? Кажется, он куда более дружелюбен по части сообщений об ошибках, и на максимум оптимизирует так, что вполне может и выиграть. Выигрывает не всегда, но пробовать можно.

в плане оптимизаций clang хуже

хотеть переехать с 4.4 на trunk( ещё бы это не подразумевало пересборку всех тулсетов под три ARM(

ну то есть непонятно зачем тебе вопрос про оптимизацию лямбд - без захвата они эквивалентны указателю на функцию же

в плане оптимизаций clang хуже

Примерно одинаково ведь, не?

Примерно одинаково ведь, не?

неа

в большинстве случаев выигрывает gcc

но надо смотреть под задачу именно

Примерно одинаково ведь, не?

плюс-минус, там разница больше в имплементации стдлибы, которая у кланга конформинг но медленней

ну то есть непонятно зачем тебе вопрос про оптимизацию лямбд - без захвата они эквивалентны указателю на функцию же

неправильно выразился, но спасибо

линукс тоже надо вжухнуть на шланг, но потом

Есть проект по переносу ядра линукс на clang https://lwn.net/Articles/734071/ Из плюсов - другие варнинги, другие санитайзеры. Из минусов - пока что clang плохо умеет некоторые фишки GCC и плохо работает с inline asm

потмоу что бывает, что и шланг шустрее

Вроде не так давно они были сравнимы, где то один, гле то другой лучше

Есть проект по переносу ядра линукс на clang https://lwn.net/Articles/734071/ Из плюсов - другие варнинги, другие санитайзеры. Из минусов - пока что clang плохо умеет некоторые фишки GCC и плохо работает с inline asm

да, проект есть, а freebsd уже по дефолту его для всего используют. такой вот план.

неправильно выразился, но спасибо

А ещё в 4.4 нет лямбд

@berkus ну так зачем на шланг уезжаешь?)

Есть проект по переносу ядра линукс на clang https://lwn.net/Articles/734071/ Из плюсов - другие варнинги, другие санитайзеры. Из минусов - пока что clang плохо умеет некоторые фишки GCC и плохо работает с inline asm

насколько я знаю линуксовое едро уже могут собрать но не все драйверы (да и работает пока так себе)

@berkus ну так зачем на шланг уезжаешь?)

я никуда не уезжаю, прочитай внимательно

ERROR: S client not available

Я бы пересел на шланг ради быстрых компиляшек

Я бы пересел на шланг ради быстрых компиляшек

нет там большой разницы

да и сообщения об ошибках в последних гцц весьма достойные

А ещё в 4.4 нет лямбд

малость озадачился, потом вспомнил, что там где видел у нас лямбды, они использовались под линух с 4.8 ?

Видеть бы последние гцц, мы скромго сидим на 4.6((

Меня больше интресует линуксовое ядро собранное с lto. Пока вроде не собирают. Кто нибудь знает какие проблемы там всплывают (помимо нежелания Линуса)?

об оптимизациях насколько хорошо оптимизируются лямбды без захвата в гцц пятилетней давности?

Так же хорошо, как статические функции. Проблем быть не должно

Меня больше интресует линуксовое ядро собранное с lto. Пока вроде не собирают. Кто нибудь знает какие проблемы там всплывают (помимо нежелания Линуса)?

так там половина функций получается unreferenced без загруженных модулей и просто из ядра вылетает

еще где-нибудь аналогичная магия с лд скриптами ломается еще

О, привет!

ну то есть непонятно зачем тебе вопрос про оптимизацию лямбд - без захвата они эквивалентны указателю на функцию же

На inline функцию...

Ну Conan-ы и названьице придумали... Искать что-то запаришься... Всё какие-то игры и левые картинки суёт...

О, привет!

привет)

@zamazan4ik , не знаешь, куда сам conan ставиться (на Шинде лучше бы)

@zamazan4ik , не знаешь, куда сам conan ставиться (на Шинде лучше бы)

А хз, не смотрел. Думаю, что куда-то в program files

К тому же, наверное, если через pip ставить, то поставится куда-то в пиповское

Он ставится в пакеты в <DISK>:/Python<VER>/

@zamazan4ik ты кажется на хабре статьи по поводу использования конана писал. Можешь ещё раз сюда ссылки скинуть ?

Т.е. туда, куда поставился Python.

А хз, не смотрел. Думаю, что куда-то в program files

Уже нашёл, $PREFIX\Python27\Lib\site-packages\conans

@zamazan4ik ты кажется на хабре статьи по поводу использования конана писал. Можешь ещё раз сюда ссылки скинуть ?

https://m.habrahabr.ru/post/342982/

Благодарю

The second release candidates for the 1.66.0 release are now available at: <https://dl.bintray.com/boostorg/prerelease/> The in progress release notes are: <http://www.boost.org/users/history/in_progress.html> Library documentation is available at: <http://www.boost.org/doc/libs/1_66_0/> The SHA256 checksums are as follows: 596389389c005814ecb2a6b64c31dccd2c3e6fbc5a802b4dfada999ae5844628 boost_1_66_0_rc2.7z 5721818253e6a0989583192f96782c4a98eb6204965316df9f5ad75819225ca9 boost_1_66_0_rc2.tar.bz2 bd0df411efd9a585e5a2212275f8762079fed8842264954675a4fddc46cfcf60 boost_1_66_0_rc2.tar.gz e1c55ebb00886c1a96528e4024be98a38b815115f62ecfe878fcf587ba715aad boost_1_66_0_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. ___________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

+, всё равно компилятор найдет способ это соптимизировать еще лучше

Если это конечно не msvc :}

Если это конечно не msvc :}

???

Если это конечно не msvc :}

не надо тут. MSVC зачастую не хуже clang-а оптимизирует код.

не надо тут. MSVC зачастую не хуже clang-а оптимизирует код.

Ну-ну :)

Начиная с самой последней версии - поверю, то не очень

Самая последняя - 15.5

Можно сколько угодно снисходительно улыбаться с видом мудрецов познавших все тонкости компиляторов, но без обширных пруфов любые утверждения, о том что кто-то кого-то хуже — голословны.