В V2019 почти завезли долгожданные модули. Даже как-то работает, но не всё. IntelliSense все черкает красным, go to definition не всегда итд по мелочи. Но главное что не понял, это как должны работать type alias'ы с учетом модулей? Задумано, что избавляемся от инклудов, переходим на модули. А у меня много где используются using'и для удобства. Так-то они в инклудах были. Например:

// инклуд MyTypes.h
using VectrorInt = std::vector<int>;

Вставляем инклуд, где требуется. А теперь как быть?

Попробовал:

// модуль MyTypes.ixx
export module MyTypes;
import <vector>;
export using VectrorInt = std::vector<int>;

// main.cpp
import MyTypes;
int main()
{
    VectorInt vec{ 42 };
}

Не видит, сыплет ошибками.
Я делаю что-то не так? Не допилили? Или вообще теперь невозможно using'и вытащить наружу?

XOO>import MyTypes;
XOO>int main()
XOO>{
XOO> VectorInt vec{ 42 };
XOO>}
XOO>[/ccode]
XOO>Не видит, сыплет ошибками.
XOO>Я делаю что-то не так? Не допилили? Или вообще теперь невозможно using'и вытащить наружу?
Попробуй добавить имя модуля: MyTypes::VectorInt...

Здравствуйте, LaptevVV, Вы писали:

LVV>Попробуй добавить имя модуля: MyTypes::VectorInt...

Модуль не неймспейс, это ортогональные сущности.

Ошибка    C2653    MyTypes: не является именем класса или пространства имен    TEST 0130    D:\WORK\VS\TEST 0130\TEST 0130.cpp

ЗЫ. Почитал пропозал, который принят, модулей — все делаю правильно, export using бла-бла-бла и должен быть. Значит не допилили, получается.

XOO>ЗЫ. Почитал пропозал, который принят, модулей — все делаю правильно, export using бла-бла-бла и должен быть. Значит не допилили, получается.
Ну, я хотел проверить — микрософт жеж. Они могли и по-своему запилить.
Значит не допилили.

Здравствуйте, LaptevVV, Вы писали:

LVV>Ну, я хотел проверить — микрософт жеж. Они могли и по-своему запилить.

Не думаю, что они поперек стандарта пойдут. Чем-нибудь дополнить, это да.
Например, имена и расширения файлов модулей не оговариваются и микрософт сделал жесткую привязку к .ixx, хотя какая разница, какое расширение делать?

Здравствуйте, XOOIOOX, Вы писали:

XOO>Я делаю что-то не так? Не допилили? Или вообще теперь невозможно using'и вытащить наружу?

У тебя опечатка в слове "VectrorInt" (лишняя "r").

Здравствуйте, bnk, Вы писали:

bnk>У тебя опечатка в слове "VectrorInt" (лишняя "r").

Этот пример сначала руками в сообщении набрал. В тестовом коде идентично алиасу.

Здравствуйте, XOOIOOX, Вы писали:

XOO>Этот пример сначала руками в сообщении набрал. В тестовом коде идентично алиасу.

У меня все компилируется (VS 16.8.5)

	Перепроверь

Еще вариант — ты как .ixx добавлял? (File -> Add New .. -> Module?) Или переименовал .h? В смысле у тебя этот файл из компиляции случайно не исключен?

Здравствуйте, bnk, Вы писали:

bnk>У меня все компилируется (VS 16.8.5)

Аналогичная студия.

bnk>Еще вариант — ты как .ixx добавлял? (File -> Add New .. -> Module?)

Да, через добавление модуля.

Все убрал, добавил заново. Не хочет.



Может какие-то дополнительные ключи компиляции нужны помимо /std:c++latest и /experimental:module ?

Здравствуйте, XOOIOOX, Вы писали:

XOO>Может какие-то дополнительные ключи компиляции нужны помимо /std:c++latest и /experimental:module ?

Я только C++ latest поставил:

http://files.rsdn.org/11344/2021_01_00_15_55_29_ConsoleApplication1.zip

Здравствуйте, bnk, Вы писали:

bnk>http://files.rsdn.org/11344/2021_01_00_15_55_29_ConsoleApplication1.zip

Ага, у меня было выставлено "Компилировать как код модуля (/interface)". Вернул "По умолчанию",
сработало. Спасибо!

Осталось дождаться, пока Интелисенс перестанет черкать красным все. Наверное в 16.9 исправят.

Здравствуйте, XOOIOOX, Вы писали:

А что если в модуле есть экспорт функции, которая принимает в качестве аргумента незаэкспорченный класс? Этот класс ведь по идее должен тоже подсасываться автоматом...

// lib1.cpp

export module lib1;

struct point { // не экспортируем этот класс
    int x, y;
};

export void scale(point & pt, int factor) {
    // что-то делаем с pt, скалируем
}

// main.cpp

import lib1;

int main() {
    point pt = {10, 10};
    scale(pt, 2);
    return 0;
}

Кто может проверить/пояснить?

Здравствуйте, XOOIOOX, Вы писали:

XOO>В V2019 почти завезли долгожданные модули.
Ещё вопрос по модулям, но уже по архитектуре. Почитал описание у микрософт и они пишут о создании разных файлов интерфейса и реализаций. Чем это мотивировано? Правильно ли делать реализацию и интерфейс в одном файле? Не увеличит ли это время компиляции?

Здравствуйте, Sm0ke, Вы писали:

S>А что если в модуле есть экспорт функции, которая принимает в качестве аргумента незаэкспорченный класс? Этот класс ведь по идее должен тоже подсасываться автоматом...

Наружу то, что не проэкспортировано, не протекает. Класс point не виден.
То же касается макросов и типов из добавленных в модуль инклудов, если они не проэкспортированы явно.

Здравствуйте, PavelCH, Вы писали:

PCH>Ещё вопрос по модулям, но уже по архитектуре. Почитал описание у микрософт и они пишут о создании разных файлов интерфейса и реализаций. Чем это мотивировано? Правильно ли делать реализацию и интерфейс в одном файле? Не увеличит ли это время компиляции?

Можно и так и сяк. Время компиляции не должно увеличиться, т.к. экспортируются имена, а не реализации. То есть при импорте реализация не имеет значения, ищутся только имена, которые импортируются. Реализация обрабатывается при компиляции единицы трансляции соответствующего модуля.

XOO>В V2019 почти завезли долгожданные модули. Даже как-то работает, но не всё.
Вы уж извините что в вашу тему, но вопрос по модулям.
Кто-то знает как экспортировать макросы из модуля? Совсем никак?

Здравствуйте, PavelCH, Вы писали:

PCH>Кто-то знает как экспортировать макросы из модуля? Совсем никак?

К счастью, никак.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0955r0.pdf

Здравствуйте, XOOIOOX, Вы писали:

XOO>В V2019 почти завезли долгожданные модули.
Еще тогда вопрос по модулям, кто может знает
Вот есть код трех файлов:

// File test1.ixx
export module test1;
void foo() {
}

// File test2.ixx
export module test2;
/*static*/ void foo() {
}

// File main.ixx
export module main;
import test1;
import test2;

Кто-то знает какая будет принципиальная разница если в test2.ixx раскоментить static? Это одно и то же? Или есть ньюансы?

Здравствуйте, XOOIOOX, Вы писали:

XOO>Здравствуйте, Sm0ke, Вы писали:

S>>А что если в модуле есть экспорт функции, которая принимает в качестве аргумента незаэкспорченный класс? Этот класс ведь по идее должен тоже подсасываться автоматом...

XOO>Наружу то, что не проэкспортировано, не протекает. Класс point не виден.
XOO>То же касается макросов и типов из добавленных в модуль инклудов, если они не проэкспортированы явно.

А если такое:

// lib1.cpp
export module lib1;

struct point {
    int x, y;
};

export struct shape {
    point pos;
};

// main.cpp
import lib1;

int main() {
    shape s1;
    s1.pos.x = 10; // "point" то по идее не виден ...
    return 0;
}

Здравствуйте, PavelCH, Вы писали:

PCH>Кто-то знает какая будет принципиальная разница если в test2.ixx раскоментить static? Это одно и то же? Или есть ньюансы?

В общем случае у foo будет либо module linkage, либо internal linkage. Соответственно, foo будет либо общей на модуль, либо уникальной для TU.

Тут, как и в С++ без модулей, хорошим стилем будет следование правилу, что все внутренние сущности должны быть либо помечены static, либо помещены в anonymous namespace ([1][2][3]), чтобы форсировать внутреннее связывание. Это не только позволяет компилятору не заниматься лишней работой и ловить ошибки с неиспользуемыми функциями и переменными, но и упрощает чтение кода: при виде static void foo() {} сразу понятно, что эта локальная функция и за пределами TU не используется (например, это значит, что её можно смело менять, не боясь сломать какой-то внешний код, который мог бы её вызывать).