C++ modules и системы сборки

Компиляторы уже давно умеют их, например, в clang даже объявили deprecated опцию -fmodules-ts и поддержка модулей автоматически включается при активации стандарта C++20.

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

Собирал через Makefile и Nix, если что.

А стандартная библиотека хотя бы умеет?

В следующем Preview будет(сейчас 17.4 Preview 3 доступен, а появится в 17.5 Preview 1, или самому собирать из github)

https://github.com/microsoft/STL/wiki/Changelog#expected-in-vs-2022-175-preview-1

https://github.com/microsoft/STL/pull/3108

Окей, а в линуксовой? STL от майков тут же не работает.

C++ modules

Не выходит каменный цветочек.

Окей, а в линуксовой?

Пока не реализовано, но какой текущий статус в libc++ и libstdc++ я не знаю.

Тут просто вот в чём штука: модули пропихнули перцы типа Facebook и прочих мегакопрораций, чтобы решить свою проблему со скоростью сборки. И, насколько мне известно, они используют во многом собственные библиотеки, которыми не особо спешат делиться, в том числе и заместо STL. Поэтому есть некоторое подозрение, что вот они свой софт на модули переведут, а впопенсорц по большей части не станет запариваться. И на этом всё заглохнет.

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

А почему ты решил, что смогли?

иначе бы тут был йет эназэр раст трэд

Забавно, что в meson экспериментальная поддержка модулей тоже только для visual studio.

Видео по теме (я пока не смотрел): https://youtu.be/5X803cXe02Y

Cmake 3.25 получил поддержку модулей (правда опять же для MSVC, ибо они там лучше работают)

Это ж насколько черезжопная реализация модулец, что до сих пор не могут систему сборки прикрутить.

А ты реализовал? И вообще смотрел видео?

Ситуация примерно такая:

1. CMake всё поддерживает и выпустил спецификацию что ему нужно от компилятора чтобы поддерживать модули. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1689r5.html

(Спецификация вышла 2022-06-03, достаточно недавно)

2. MSVC всё реализовали

3. GCC есть ветка где всё реализовано: https://github.com/mathstuf/gcc/tree/p1689r5 . Вроде ещё не смержено в GCC, но возможно скоро смержат

4. 7 ноября в Clang заслали патч на ревью с поддержкой p1689r5: https://reviews.llvm.org/D137527

Так что вроде везде норм.

Можешь помочь разработчикам Clang или GCC если хочешь побыстрее.

А ты реализовал?

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

CMake всё поддерживает

И чем они два года занимались после выпуска стандарта?

Это ж насколько черезжопная реализация модулец, что до сих пор не могут систему сборки прикрутить.

Самое смешное, что в том же современном паскале… ну как современном, середины 90-х… :))) Delphi/fpc, короче… благодаря тому, как там сделаны модули, для простых и средних проектов система сборки вообще не нужна, дерево зависимостей раскручивается по uses. Указал компилятору главный модуль, он же файл проекта — вуаля.

Да-да, тот самый «мёртвый язык для обучения, который и для обучения-то не годится».

30 лет спустя. Плюсовики героически продолжают прикручивать модули и систему сборки.

Жизнь прекрасна!

P.S. Пишу на плюсах, без модулей.

И чем они два года занимались после выпуска стандарта?

Прорабатывали спецификацию чтобы потом не менять её десятилетиями.

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

В Open Source так и есть.

То есть ты приходишь не в УК, а к соседям которые пришли после работы домой и говоришь что вы листву не убрали, они тебе могут легко сказать иди сам убирай.

Прорабатывали спецификацию чтобы потом не менять её десятилетиями.

Это нужно делать параллельно работе над стандартом. Без системы сборки модули ни для чего кроме хелловорлдов не пригодны. Странно, что на такую важную часть забили.

То есть ты приходишь не в УК, а к соседям которые пришли после работы домой

Нет. Эти соседи публично и добровольно заявили, что работают над уборкой листвы. Светят своим емайлами в коммитах и участвуют в конференциях, называя себя разработчиками чего-нибудь. А потом возмущаются, что к их работе выдвигают претензии.

В Open Source так и есть.

Комитет стандартизации плюсцов это не попенсорц. Иначе бы там уже всё было.

Комитет стандартизации плюсцов это не попенсорц. Иначе бы там уже всё было.

Дак дело не комитете, а в кодовой базе GCC и LLVM.

Пока это не продакшен и ещё 10 раз всё поменяют.

Обычно через 5 лет оно реально стабильное делается на основных платформах. Вот сейчас пора на C++ 17 писать. Поди все фичи прикрутили наконец.

Самая популярная система сборки в мире C/C++ - CMake

autotools

Вот сейчас пора на C++ 17 писать

Давно уж как пора. Другое дело, что на седьмой центоси далеко не уедешь с такими запросами.

17 стандарт скучный. В 20 хотя бы концепты и корутины. Есть смысл обновляться.

Ну да, ну да. Модули в паскале настолько хороши, что после паскаля Вирт сделал целый язык Модула. «Основным нововведением Модулы является модульная система, используемая для объединения множества зависимых объявлений в программные единицы» (с).

Даже такое как в паскале всё равно лучше чем в си и (пока ещё) в с++.

Подозреваю, что hobbit имеет в виду модули из Turbo Pascal 5.0. Которые, если я правильно помню, были как раз позаимствованы из Modula-2. Ну и семейство Turbo Pascal появилось когда Вирт уже давно забросил свой Паскаль в пользу Modula-2 и Oberon-а. Именно в Вирт-овском Паскале модулей, емнип, не было от слова совсем.

Он потом ещё и Оберон создал, если на то пошло.

Только я не про виртовский паскаль писал, а про современный, который с турбопаскаля начала 90х идёт, специально же подчеркнул. И это всё без Вирта уже было.

А Модула появилась раньше, и модули в ней были несколько по-другому сделаны.

Которые, если я правильно помню, были как раз позаимствованы из Modula-2.

Не-а, ничего даже близко похожего. В Модуле и синтаксис другой, и разделение модуля на два файла.

А турбопаскалевский подход ушёл потом сначала в Delphi, потом в fpc.

Тогда надо сравнивать не паскаль и си++, а турбопаскаль и вижуалсиплюсплюс.

С чего это обязательно вижуал? Я пишу кроссплатформенное ПО. Несколько компиляторов плюсов для меня есть, fpc тоже есть. «Вижуалсиплюсплюса» нет. «Шпака не брал».

Потому что модули в паскале, как выяснилось - вендорозависимая фича и не была представлена в стандарте. Будь добр предоставить равные требования при сравнении чего-либо. Иначе не объективно.

Не-а, ничего даже близко похожего. В Модуле и синтаксис другой, и разделение модуля на два файла.

Да, спасибо. Освежил в памяти.

Тем не менее, там ключевая идея общая: модуль делится на интерфейсную часть и часть реализации. Только в Turbo Pascal это довели до возможности указывать обе части в одном исходном файле (плюс в Turbo Pascal, насколько помню, в implementation-части свои uses можно писать, которые не будут видны при импорте этого модуля).

А турбопаскалевский подход ушёл потом сначала в Delphi

Как по мне, так Delphi, это просто очередная версия в линейке Turbo Pascal. Странно считать их отдельными языками, хотя вроде как многим так привычнее.

Ну эта фича представлена в совместимом по синтаксису виде как минимум у трёх «вендоров» (Borland/Embarcadero, PascalABC.Net и Freepascal). А других живых я сегодня что-то и не припомню.

Ну, чтобы совсем честное сравнение было, можно сравнить конкретные реализации. Например, из открытых и кроссплатформенных — fpc vs clang или fpc vs gcc. Судя по тому, что я читаю в этой теме, современные плюсовые решения по части модулей всё ещё не догоняют паскалевские.

Ну то есть на твоё «30 лет спустя. Плюсовики героически продолжают прикручивать модули» можно ответить так: «спустя 20 лет разработки паскаля модули всё ещё не были стандартизированы. Но кто-то из борланд решил сделать их (но не так, как задумывал автор языка - Вирт). В целом получилось неплохо».

Признай, что просто хотел набросить.

30 лет спустя. Плюсовики героически продолжают прикручивать модули

спустя 20 лет разработки паскаля модули всё ещё не были стандартизированы. Но кто-то из борланд решил сделать их (но не так, как задумывал автор языка - Вирт). В целом получилось неплохо

Именно так. И несмотря на отсутствие стандарта ISO, все известные реализации модули поддерживают, поддерживают одинаково и всё работает.

Я считаю, это успех. А плюсовики героически продолжают прикручивать модули.

Признай, что просто хотел набросить.

А что делать, если констатация факта для кого-то получается похожей на наброс?

Ситуация гротескная. С одной стороны имеем стандарт без качественных реализаций. С другой стороны — успешно «выстрелившую» реализацию фичи с модулями, воспроизведённую тремя независимыми командами. Но без стандарта. Думаю, Croco будет рад.

Нет, я не считаю паскаль языком своей мечты. Если бы это было так, я бы DoubleContact писал на лазарусе, а не на плюсах. Но весомые преимущества для прикладной разработки у него есть, модульность — возможно, главное из них.

Но подождём, времени с принятия C++20 действительно прошло не так много. Вот если ещё через 3 года воз будет по-прежнему там — будет грустно.

Разве в паскалях модуль (unit) не должен быть одной единицей трансляции? Это всё сильно облегчает. В C++20 разные единицы трансляции могут экспортировать в один и тот же модуль. Из-за этого и проблемы с поддержкой C++20 модулей у систем сборки. Становится важен порядок трансляции единиц.

В C++20 разные единицы трансляции могут экспортировать в один и тот же модуль. Из-за этого и проблемы с поддержкой C++20 модулей у систем сборки.

Ну стало быть сами себе всё накрутили в минус.

Мне именно этот подход a la Java и не нравится. В паскале было просто и гениально.

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

Почему в C++ такая реализация модулей и подмодулей оказалась, что там что-то нужно иметь в компиляторе дополнительное, чтобы это реализовали в cmake и других, непонятно.

В паскале было просто и гениально.

Только вот в С++ при использовании подхода из Паскаля не получилось бы сделать import std;, пришлось бы выписывать:

import std.set;
import std.filesystem;
import std.unordered_map;
...

Я в общем-то, с инклудами так всегда и делаю, перечисляю заголовочники от реально нужных классов. :)

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

Да, в том видео разраб CMake говорил какой ужас Fortran,

https://youtu.be/5X803cXe02Y?t=1124

В частности https://youtu.be/5X803cXe02Y?t=1231 , что им пришлось добавлять парсер Fortran в CMake, и с C++ они такого делать не хотят, поэтому и нужно было всё согласовать со всеми разработчиками компиляторов. https://youtu.be/5X803cXe02Y?t=1289

Так модули-то – это не заголовочные файлы, там же еще и реализация. А иметь один файл со 100500 строк реализации в C++ так себе идея, т.к. практически любой компилятор будет падать по internal compiler error с вероятностью в 99.9(9)%.

PS. Я сам не в восторге от того, что в C++ с модулями придумали. Да и более того, имхо, C++ с модулями расколет C++ на много лет так же, как это было с Python2/Python3.

либо

import std, only : set, filesystem, unordered_map;
...

Да, в том видео разраб CMake говорил какой ужас Fortran

И это говорят криворукие дебилы, которые придумали CMake? Да уж, и эти люди запрещают мне ковыряться в носу (c)

О да, зато разработчикам компиояторов теперь есть чем заняться. Главное свою работу на других переложить.

Напомни, сколько всего существует актуальных компиляторов C++?

Ну так все парсеры и добавляют.

То есть помимо ограничений на версию cmake для его же использования нужен компилятор определённой версии.

Суть не в том, как взять что-то из модуля. Суть в том, как указать что должно быть в модуле.

В Паскале просто: один файл – один модуль. Причем появилось это все тогда, когда на Турбо Паскале больших проектов то и не было.

В C++ нужно суметь засунуть в один модуль код, который располагается в нескольких файлах (а поместить весь этот код в один файл не получится, т.к. либо компилятор поломается, либо для компиляции потребуется 128GiB RAM).

Другой вопрос почему придумали такое сложное решение, а не сделали что-то проще.

Но, с учетом того, что там сражались два совершенно разных говна (вроде Google насмерть срался с Microsoft, т.к. у каждого был свой подход), по вообще удивительно, что какой-то консенсус нашли.

ну все так и есть. Какие нерешаемые проблемы решают модули, зачем они нужны кроме усложнения спецификации? Скорость сборки? Так это решается рефакторингом, вон в ядре линукс сейчас этим занимаются. Видимость символов и так далее? В сишке это уже сейчас можно вертеть как угодно без всяких модулей, то что жабаскрипт и раст-макаки чего-то там (ничего) не знают - проблемы жабаскрипт и раст-макак.