Нет, я с вами не соглашусь, модули это идея противоположная юнити билдам) Я бы скорее его выразил как «каждый хедер- прекомпилируемый».
Офисную сеть для разработчиков делать целиком на вайфае — омг) Ну у нас есть те кто с ноутбуков компилят, ускорение все равно значительное.
«скорость инкрементного билда их не раздражает» — какие спокойные разработчики! Лично меня цикл сборка-запуск больше 5 секунд начинает заметно напрягать, а 15 — откровенно раздражать.
Модули еще по идее и линковку должны ускорять нехило, т.к. не будет определений одного и того же в каждой оттранслированной единице.
Я думаю идеальный вариант для меня через пять лет — модули + распределённая сборка.
Ну и компоновка всего проекта как кучи статичных либ — вообще сомнительное удовольствие)
С юнити билдами кроме скорости сборки, повторюсь, лично для нас основная проблема — конфликт имен (и иногда хедеров). Считай, прощай уютный анонимный неймспейс.
По хедерам — допустим есть либа, которая оборачивает два сторонних API, предоставляя общий интерфейс. По отдельности хедеры собираются норм, а когда компилишь вместе — хедеры реализаций начинают конфликтовать.
Ах да, еще замечательное — т.к. все файлы идут вместе, начинает теряться необходимый набор хедеров в каждой единице трансляции. Начинаются вещи вроде «убрали один cpp файл — все отвалилось», а файл этот может исключаться из сборки какой-то опцией, т.е. нужно тестировать все комбинации опций при вообще любой правке, даже не в хедерах.
В общем, в плане поддержки это очень тяжело. От распределённой сборки все же треба только железо/сеть, ты никак не думаешь о каком-то специфичном коде.
Я вообще когда только начал знакомиться с constexpr, был крайне раздосадован, что они как раз не ведут себя «всегда constexpr!»., если бы можно было вернуть время вспять, я бы предложил constexpr и maybe_constexpr какой-нибудь (соответствующий сегодняшему)
Из того как работает zapcc, я так понимаю, модули его не сильно и ускорят, он и так каждый файл препроцессированным держит? Можно интересно считать, что то ускорение, которое дает zapcc- оценка сверху для ускорения от модулей?
Юнити билды становится адово использовать в случае локальной разработки. Скажи разработчику что каждый инкрементный билд будет по полминуты занимать (вместо 1-2 секунд) — он криво на тебя посмотрит.
Да и на сервере, не так чтобы сильно ускоряется сборка. Я делал такую штуку — в cmake делал автоматическое объединение cpp всей цели для одной либы. Ускорение — не больше, чем в два раза. И плюс мы получаем тьму неудобств от необходимости следить за анонимными неймспейсами и т.п.
Если еще и локально одна схема, а на билде другая — это вообще адъ.
Пока лично для меня самая эффективная схема — распределенная сборка) Железо докупить оказывается дешевле. Когда сборка параллелится на 100+ ядер — ускорение налицо. Понятно, что и там есть ограничение сверху (возможность параллелить, возможности сети), но зато эффектом можно пользоваться и на CI, и на дев машине.
Я пока раздумываю как в свою систему распределённой сборки модули прикручивать. Получается, что по сети не только единицу трансляции гонять придется, но и все используемые скомпиленные модули.
Вот я с одной стороны с вами согласен, что пора уже выкидывать везде поддержку ХР, но сам производитель ОС до сих пор сохранил поддержку деплоя на ХР для msvc2017.
Что-то ваша информация неточная, 5.6 еще поддерживает XP, мы с ним проекты на XP деплоим вполне успешно. Вот с 5.7 и выше, да, облом (там еще и с макосью тоже беда с поддержкой).
Есть одна проблема с этой программой — человек должен целенаправленно хотеть писать скрипты. Сажал за нее младшего двоюродного брата — прошел практически всю игру, не написав ни строчки кода (это реально).
Собирали ядро для MOXA 7110 16 мб на борту, busybox+linux занимают 6 Мб после загрузки. Т.е. в теории оно бы там и с 8 загрузилось, но на оставшиеся 2 мб не разгуляешься с учетом того что shared либ нет. Хотя думаю на девайсе с нормальным контролем памяти это можно было решить. Ядро там правда 2.6.18 было.
lair не врет, допустим я формат такой сам специфицировал (и получил за него премию от IEEE):
8 бит — числитель
8 бит — знаменатель
никакой экспоненты.
пишут 1 в num, 1010 в denum, вуаля, я представил ТОЧНО 0.1 в двоичном коде. Что не так?
#define true (rand() % 20 > 0)
Да я вообще всегда когда комменты на хабре читаю, себя каким-то конченным дауном чувствую.
Офисную сеть для разработчиков делать целиком на вайфае — омг) Ну у нас есть те кто с ноутбуков компилят, ускорение все равно значительное.
«скорость инкрементного билда их не раздражает» — какие спокойные разработчики! Лично меня цикл сборка-запуск больше 5 секунд начинает заметно напрягать, а 15 — откровенно раздражать.
Модули еще по идее и линковку должны ускорять нехило, т.к. не будет определений одного и того же в каждой оттранслированной единице.
Я думаю идеальный вариант для меня через пять лет — модули + распределённая сборка.
Ну и компоновка всего проекта как кучи статичных либ — вообще сомнительное удовольствие)
С юнити билдами кроме скорости сборки, повторюсь, лично для нас основная проблема — конфликт имен (и иногда хедеров). Считай, прощай уютный анонимный неймспейс.
По хедерам — допустим есть либа, которая оборачивает два сторонних API, предоставляя общий интерфейс. По отдельности хедеры собираются норм, а когда компилишь вместе — хедеры реализаций начинают конфликтовать.
Ах да, еще замечательное — т.к. все файлы идут вместе, начинает теряться необходимый набор хедеров в каждой единице трансляции. Начинаются вещи вроде «убрали один cpp файл — все отвалилось», а файл этот может исключаться из сборки какой-то опцией, т.е. нужно тестировать все комбинации опций при вообще любой правке, даже не в хедерах.
В общем, в плане поддержки это очень тяжело. От распределённой сборки все же треба только железо/сеть, ты никак не думаешь о каком-то специфичном коде.
Да и на сервере, не так чтобы сильно ускоряется сборка. Я делал такую штуку — в cmake делал автоматическое объединение cpp всей цели для одной либы. Ускорение — не больше, чем в два раза. И плюс мы получаем тьму неудобств от необходимости следить за анонимными неймспейсами и т.п.
Если еще и локально одна схема, а на билде другая — это вообще адъ.
Пока лично для меня самая эффективная схема — распределенная сборка) Железо докупить оказывается дешевле. Когда сборка параллелится на 100+ ядер — ускорение налицо. Понятно, что и там есть ограничение сверху (возможность параллелить, возможности сети), но зато эффектом можно пользоваться и на CI, и на дев машине.
Я пока раздумываю как в свою систему распределённой сборки модули прикручивать. Получается, что по сети не только единицу трансляции гонять придется, но и все используемые скомпиленные модули.
Что-то я прям загорелся от этой фразы, это вы про что рассказываете? про какую-то будущую 6 ветку? т.к. в текущем релизе я ничего такого не наблюдаю:
github.com/qt/qtbase/blob/5.11/src/corelib/thread/qthread_win.cpp
github.com/qt/qtbase/blob/5.11/src/corelib/thread/qthread.cpp
Юпитер 139 822 km
в десять раз = во много раз, что не так. Откуда вы два взяли?
8 бит — числитель
8 бит — знаменатель
никакой экспоненты.
пишут 1 в num, 1010 в denum, вуаля, я представил ТОЧНО 0.1 в двоичном коде. Что не так?