Aidar
это к чему?
К тому что то что ты описал невозможно
Igor
тогда я не понял фразу "апгрейдить все" - все 1.55.1 до 1.55.8?
Aidar
Да, и прилоги имеют свойство переходить на новые либы со временем
Aidar
А старые становятся не нужны
Anonymous
Ребята
Anonymous
Что влияет на скорость компиляции
Aidar
Ребята
Да привет
Aidar
Сложность их вычисления
Igor
Да, и прилоги имеют свойство переходить на новые либы со временем
это если они со временем обновляются, а не доведены до логического конца в 2011м
Anonymous
Да у меня обычный helloworld секунд 9 компилится
Igor
но теперь я тебя понял, да
Igor
Ну я такие не юзаю
удачи с переводом остального интернета на твою точку зрения нет, это не сарказм, мне действительно нравится позиция "live at HEAD tag", увы не везде она применима
Berkus
А старые становятся не нужны
для сборки очевидным образом во ВСЕХ нормальных менеджерах используются лок файлы, которые даже коммитятся в репу. Это дает повторяемый билд, а апдейты делаются только при необходимости и вручную/под контролем.
Berkus
Я лучше буду полагаться на разраба либы а не на разраба приложения и юзать последний патч
ТЫ - возможно, многие другие аппы котрые рассчитаны на сборку с boost 1.48.0 лучше собирать именно с ним
Aidar
Если минорная версия совпадает значит апи не изменился
Aidar
Что хуже что лучше решает разраб либы, не зря же он сделал новую версию
Berkus
Если минорная версия совпадает значит апи не изменился
ну она совпадает - 1.48.0 и 1.48.0, вот с ним и собирать
Berkus
Что хуже что лучше решает разраб либы, не зря же он сделал новую версию
разраб либы выпустил 1.66.0, то что собиралось с 1.48 ТОЧНО не соберется с 1.66
Berkus
он про 1.48.0 и 1.48.1, насколько я понимаю
мне решать, с чем я буду собирать - с 1.48.0 или с 1.48.1
Igor
Igor
прошу прощения за скрин, нормально скопировать PDF не смог) почитываю повареную книгу Полухина, наткнулся на эмуляцию move-конструкторов в с++03 вопрос - стоит ли надеяться, что c++11 compliant компилятор сможет вкурить в происходящее, и соптимизировать лишнюю конструкцию и свап?
Berkus
есть простое решение - выкинуть к хуям все что раньше с++11 и жить спокойно
Igor
спасибо, капитан!) мы это уже почти сделали даже ладно, пингану автора @antoshkka
Igor
...а, дошло, спасибо
Ioann_
Или это что то с бустом связано ?
Igor
Простите что туплю. А что за книга, и есть ли где почитать ? (В гугл не лез)
https://www.packtpub.com/application-development/boost-c-application-development-cookbook
🐙 Antony
Или это что то с бустом связано ?
Там в основном буст, но везде рассказывается чем бустовый класс отличается от стандартного (если есть стандартный) и планируется ли включение этого класса в C++
🐙 Antony
https://www.packtpub.com/application-development/boost-c-application-development-cookbook
Есть версия поновее: https://www.packtpub.com/application-development/boost-c-application-development-cookbook-second-edition
Igor
...на секунду я взгрустнул, что на новогодней акции купил старое издание, но оказалось что просто запутался в ссылках а куда можно опечатки скидывать?) в личку, или где-нибудь на сайте саппорт под это дело есть?
🐙 Antony
Кстати, вам может пригодиться: http://apolukhin.github.io/Boost-Cookbook/ Там можно большинство примеров из книги позапускать, код поменять, что-то своё дописать... В общем удобно для экспериментов и освоения
🐙 Antony
Где именно?
Stanislav
cpx чтобы никому обидно не было
Stanislav
похоже его тоже алекс на планшете хостит))
Berkus
без него справился
Vsevolod
надо же, amplifier xe без проблем запустился на крайней убунте
Vsevolod
https://software.intel.com/en-us/intel-vtune-amplifier-xe
Ioann_
Это мега крутая штука
Дмитрий ⬡
Господа, тупой вопрос: можно ли получить std::list::iterator, эквивалентный end(), без самого списка? Ситуация: хочется передать пару итераторов, но если первый end, то второй не интересует. Кажется, я слышал, что для каких-то стандарнтых контейнеров сделали так, чтобы итераторы на конец были доступны без самого контейнера.
Дмитрий ⬡
Не, тут нужны итераторы, в этом и грусть :D
Дмитрий ⬡
Не это. Видимо, придётся дооборачивать в optional или что-то такое.
🐙 Antony
Тоесть можно использовать два std::list::iterator{} для обозначения пустого диапазона
Дмитрий ⬡
Там скорее вложенная индексация. Да, прекрасно, спасибо.
Berkus
+
Stanislav
да не, мысль хорошая, надо бы ее доработать
🦥Alex Fails
да, мне тож норм
Alexander "SonnySlave"
нахер оно такое?
Alexander "SonnySlave"
билдом и линком должна заниматься билд-система, а не ваш код
Surreal
Для модулей мб зашло бы.
Alexander "SonnySlave"
я всё ещё не понимаю, зачем переносить инфу о зависимостях в исходники
Surreal
Для функций\классов\etc. это избыточно на мой взгляд, а вот для модулей могло бы позволить использовать, например, один модуль для разных платформ без пачки макросов внутри модуля (они, правда, перенесутся в секцию импорта). Идея неплохая, только реальных use-case'ов как-то мало получается (ну или я просто не могу их придумать).
🐙 Antony
да не, мысль хорошая, надо бы ее доработать
А мне она как-то разонравилась... Оно хорошо выгладит в терии, но на практике это действительно выльется в depndency hell
Berkus
я всё ещё не понимаю, зачем переносить инфу о зависимостях в исходники
это абсолютный антипаттерн, который прижился у виндоинвалидов, по очевидным причинам - они не знают где либы искать
Berkus
но для этого придумали нормальные билдсистемы и conan/vcpkg
Berkus
Для модулей мб зашло бы.
модули и без этого разберутся с чем линковаться
Berkus
наружу в нормальной системе модулей это вообще не должно торчать
Berkus
ты просто пишешь use std.thread; и ВСЁ
Anton
Допили: https://reviews.llvm.org/D42758
Anatoly
билд инженеры вздохнули с облегчением, добавилось геморроя на их голову.
Igor
но зачем? серьёзно, я даже в вижаке не понимал когда мне это показали - нафига, если есть настройки проекта
Igor
а ещё я не понял про многократное упоминание PS4 в комментариях как будто бы они это вкручивают исключительно ради того, чтобы кланг мог компилировать исходники под пс4, где компилятору нужно общаться с линкером, а не билдсистеме командовать ими обоими derp, поправьте меня пожалуйста, если я сказал бред
Igor
вот этот пассаж » The PS4 compiler uses its linker options mechanism to communicate three different things to the linker, namely #pragma comment(lib, ...) directives, as discussed here, symbols marked with __declspec(dllexport), and symbols marked with __declspec(dllimport) (the latter two requesting the linker explicitly to export/import the decorated symbols).
Igor
а, ну значит я был недалеко от истины
Berkus
там скорее всего сонивские инженеры выдумали кошмарный ад который можно было просто пропустить если бы они смогли в цмак
Дмитрий ⬡
Когда взламывали PS4 для запуска Linux там обнаружился переизобретённый PCI, а вы говорите)