> Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а
> не переписывать, чем занята другая группа.Вот те раз. А я то думал изначальный смысл - оценить технологию, по возможности объективно и непредвзято. И в этом смысле меня таки как кастомщика и кернелбилдера в контексте сабжа беспокоит потенциал для обвала скорости компила в разы.
Да, C++ позволяет более выразительные конструкции. Если б еще наслоения легаси выкинуть, и оформить более безопасный subset дефолтов "для чайников" - был бы наверное неплохой яп так то. Но в случае с проектом размером с кернел есть много разных аспектов. Время компила напрямую влияет на допустим степень протестированности кода, да и скорость разработки якорит.
Не, коду который "haven't seen compiler" я не доверяю. Never had, and never will.
> Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные.
Времена билда кернела могут напрячь и на таких. Помножить эти времена на эн - очень так себе идея. К тому же это все создает entry level barrier там где его быть не должно, отсеивая всяких студентов и ко. Зачем нам это проект без студентов и энтузиастов, где только мегакорпы?
> Но случаи бывают разные. Банально что то поправить, и собрать не дома.
> Есть ещё командировки. И студенты в конце концов.
Ну дык. Чем злее требования к конфиге - тем меньше народа это все будет делать. Это идет вразрез с идеями опенсорса - и куда это заведет? К тому что пилить будут полтора корпората с билдфермами? Так что совсем игнорить этот топик имхо не стоит.
>>>плюсовые проекты заметно тормознее билдить.
> Плюсовые, да, там же тупо язык сложнее. Но не такая редкость когда
> по сути си проекты, с минимумом фич от с++, или их
> отсутствием, собирают с++ компилятором.
Это в основном майкрософтовские кодеры таким страдают, как и юзежом си++ в режиме "чуть улучшеный си". Вызвано убогостью MSVS как си компилера, но в случае сабжа не аргумент ибо - unsupported config.
> И тут, взависимости от стиля исходника, бинарник может получиться и лучше,
С фига ли вдруг?
> и контроль типов получше,
Да вообще-то в сях он весьма даже. А если кто думал что знает о типах все, пусть попробует -Wconversion поюзать. И таки - компилер то может. А вот сможете ли вы с этим жить, если вам на pre-existing проекты вот такие жесткие проверки влепить...
> Вообще, если не рассматривать ядро, то гораздо чаще сборку проекта можно ускорить
> не заменой компилятора, а его реорганизацией проекта, зависимостей, и правилами сборки,
Ну да, давайте искать не там где ключ потеряли, а под фонарем, потому что там светло. Вон то все же похоже на костыль или неизбежное зло, которым занялись от отличной скорости сборки плюсоты. Это конечно не оправдание для совсем уж хреновых подходов.
> а то именно на мощных компах проекты "начинающих" и "консерваторов" не
> используют все ресурсы компа, и даже на мощной машине собираются неспешно.
Да вообще-то при пинке в кучу потоков процы оно нормально жрет и как раз упирается в именно проц. Вот особенно - плюсота как раз. Там именно g++ плотно проц грузит надолго, в остальное захочешь не упрешься. На сях там еще может быть всякий оверхед, io и проч, т.к. относительно резво билдует. Но в плюсах это как раз намного меньшая проблема.
