Поддержать P1427R0 (Concerns about module toolability)

Сергей Прейс
Сергей Прейс

Вкратце смысл P1427R0 таков:

Для следующих проблем должны быть так или иначе предложены решения в стандарте на C++ модули.

1. Мапирование модулей на исходный код. Система сборки должна иметь возможность быстро и однозначно понять где расположен импортируемый модуль в файловой системе. Без этого будет очень сложно сделать эффективное перестроение по зависимостям. Как пример плохих модулей (как в C++ сейчас приводится FORTRAN 90 [1]). Хорошие модули, например, в Go.

2. Производительность параллельной сборки. Хотя кажется, что модули улучшают время компиляции в больших проектах, где без параллельной компиляции не обойтись, модули могут замедлять сборку. Сборка С/С++ сейчас очень хорошо масштабируется, с модулями это свойство теряется. Небольшое исследование этой проблемы есть в [2]

3. Импорт или иклуд: из-за нетривиальных требований к структуре модуляризированного кода и отличии этой структуры от обычного (legacy) кода системе сборки очень сложно понять есть ли у файла модульные (не текстовые) зависимости. Системе сборки придётся обрабатывать худший случай и прекомпилировать код, даже если это полностью обычный (legacy) код.

Предлагается:

- Ревью модулей в SG-15 (the Tooling Study group ))

- Стандартизация связывания модулей с файлами

- Упрощение синтаксиса импортов

- Дать возможность производителям инструментов попробовать поддержать модули и прислушаться к их мнению

0
рейтинг
1 комментарий
yndx-antoshkka

1. Эта проблема обсуждалась. Она лежит за пределами стандарта C++, как и маппирование заголовочных файлов на их идентификаторы. Другими словами - да, это проблема, но многие подобные случаи не описываются стандартом C++. Ревью в SG-15 Tooling возможно позволит многие implementation-defined вещи связанные со сборкой перенести в стандарт, и унифицировать часть флагов сборки. Но это случится явно не к C++20.

2. Модули надо трактовать как некое подобие shared library. Тоесть разработчик в билд системах сам укажет как и из чего формаировать модули, после чего будет ставить их зависимостями к проектам. Вся ответственность за организацию правильных модулей ложится на разработчика. Стандарт C++ может помочь разве что примерами, но со стороны стандарта больше сделать ничего нельзя.

3. Опять таки, смотрите выше - модуль, это shared library. Пользователь сам должен указать зависимости, магии и автоматики тут не будет. Более того, системы сборки не могут его в принципе сами прекомипилировать, так как не знают на какое поведение макросов закладывается автор legacy файла. Другими словами, это 3 совершенно различных поведения:

#include <legacy.hpp>
import <legacy.hpp>
import legacy;

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

 

> Дать возможность производителям инструментов попробовать поддержать модули и прислушаться к их мнению

Именно для этого модули и смержили в стандарт C++ пораньше. Чтобы производители инструментов осознали, что модули готовы, но у них всё ещё было 2 года на проверку и коментарии к ним.

yndx-antoshkka
Другие идеи
Группа создана, чтобы собирать предложения к стандарту C++, организовывать их внутренние обсуждения, помогать готовить их для отправки в комитет и защищать на общих собраниях в рабочей группе по С++ Международной организации по стандартизации (ISO).
Все предложения