Единственная известная мне причина, как Предложение модулей в настоящее время находится в силе, предназначено для обработки циклических зависимостей интерфейса.
Если программа состоит из модулей и не отделяет объявления функций от определений, все файлы модулей будут интерфейсами модулей (в отличие от реализаций модулей). Если вы хотите сравнить их с файлами заголовка и кода, интерфейсы модулей можно рассматривать как файл заголовка (.hpp), а реализации модулей — как файлы кода (.cpp).
К сожалению, предложение модулей не допускает циклических зависимостей интерфейса модуля. И поскольку ваша программа теперь полностью состоит из интерфейсов модулей, вы никогда не сможете иметь два модуля, которые каким-либо образом зависят друг от друга (это может быть улучшено объявлением proclaimed ownership в будущем, но в настоящее время это не поддерживается). ). Единственный способ разрешить зависимости интерфейса циклического модуля — это разделить объявления и определения и поместить циклический импорт в файлы реализации модуля, в отличие от зависимостей интерфейса циклического модуля, зависимости реализации циклического модуля разрешены.
Следующий код представляет собой пример ситуации, которую невозможно скомпилировать без разделения объявлений и определений:
Foo module file
export module Foo;
import module Bar;
export namespace Test {
class Foo {
public:
Bar createBar() {
return Bar();
}
};
}
Bar module file
export module Bar;
import module Foo;
export namespace Test {
class Bar {
public:
Foo createFoo() {
return Foo();
}
};
}
В этой статье показан пример решения этой проблемы, если бы proclaimed ownership декларация доступна. По сути, все сводится к разделению объявлений и определений.
В идеальном мире компилятор смог бы справиться с этим сценарием, но, увы, насколько мне известно, текущая предлагаемая реализация модулей его не поддерживает.
person
Qub1
schedule
19.07.2018
