Здравствуйте, Мёртвый Даун, Вы писали:

МД>Я так понимаю, это будет С++17? Ну, крута!

А какие есть еще данные, кроме этой фотографии?

Здравствуйте, Мёртвый Даун, Вы писали:

МД>

МД>

Поддержка C++ модулей в Visual Studio 2015 Update 1

А как это вообще будет реализовано на практике? Это будет некий аналог статической библиотеки (в файл которой будет дополнительно встроен интерфейс модуля в некотором предкомпилированном формате)?

А что будет в случае, когда два модуля зависят друг от друга? При компиляции первого надо будет как-то сослаться на интерфейсную часть второго (который еще не скомпилирован)?

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

BFE>Новые ключевые слова в язык вводить сложно. Что, если есть класс:
BFE>

BFE>class import {...};
BFE>

BFE>тогда
BFE>

BFE>import specialvector; 
BFE>

BFE>это просто глобальная переменная...

Ну и что? Возьмите и сделайте глобальную замену в вашем коде. Займет пару минут от силы.
Это лучше чем строить костыли на костылях из существующих ключевых слов или городить двойные и тройные подчеркивания перед ключевыми словами.

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

BFE>>Новые ключевые слова в язык вводить сложно. Что, если есть класс:
BFE>>

BFE>>class import {...};
BFE>>

BFE>>тогда
BFE>>

BFE>>import specialvector; 
BFE>>

BFE>>это просто глобальная переменная...

XC>Ну и что? Возьмите и сделайте глобальную замену в вашем коде. Займет пару минут от силы.
В своём-то я сделаю, но обычно проблемы возникают с библиотеками.

XC>Это лучше чем строить костыли на костылях из существующих ключевых слов или городить двойные и тройные подчеркивания перед ключевыми словами.
Не факт.
Ну и потом, мне больше не нравится чуждый языку синтаксис, чем введение новых ключевых слов.
Ввели же, например, для лямбды свой синтаксис — и он успешно вписался в язык, а ведь могли бы вместо [y](int a){ return a + y; } ввести ключевое слово lambda(y, int a){ return a + y; }? Могли. Но не ввели же. И это правильно.
Вот и тут так же.

PS Кстати, в пропазле предлагается альтернатива:

using module module-name ;

Так я могу принять. Но не import.

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

BFE>>А типов import, export и module в глобальном пространстве никаких исходников никогда не встречается?

A>если каждый модуль имеет свое пространство имен (а так и должно быть),
И где гарантии, что так и будет?
A>то "import foo.bar;" это не валидный синтаксис
это я не понял. Почему невалидный?
Наименование модулей и их namespace'ов никак не согласованы.

Does a module definition implicitly establish a namespace? No, a module definition
does not establish any namespace; and no particular syntax is needed to
access a name made accessible by an import declaration.

A>и если все директивы import в начале единицы трансляции, то там не будет никаких struct import;

Кстати, почему import может встречаться только в глобальном пространстве? Почему нельзя написать:

namespace Abc
{
  import vector;
};

Зачем этот запрет?

Вот представьте, что я приобрёл два модуля и у них совпадают внутренние имена namespace'ов. И что мне делать?

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

BFE>PS Кстати, в пропазле предлагается альтернатива:
BFE>

BFE>using module module-name ;
BFE>

Кстати, да, так лучше.

Я так понимаю, по скорости от precompiled headers это отличаться не будет

Здравствуйте, Мёртвый Даун, Вы писали:

МД>

МД>

Поддержка C++ модулей в Visual Studio 2015 Update 1

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

S>Я так понимаю, по скорости от precompiled headers это отличаться не будет

будет.
precompiled headers прекомпилируются все вместе, а модули — каждый по отдельности.
в precompiled headers попадает гораздо больше кода, чем в экспортируемую часть модуля

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

1>Так то оно идея и хорошая, но вот какой окажется реализация мы только увидим.

Я совершенно уверен, что идея -- плохая. Вообще не надо ничего трогать в С++ в модулях.

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

A>в precompiled headers попадает гораздо больше кода, чем в экспортируемую часть модуля

Да, например, все #define ... , заданные в заголовках модуля, не будут "видны" в использующем модуль коде (в отличие от pch)

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

1>>Так то оно идея и хорошая, но вот какой окажется реализация мы только увидим.

MZ>Я совершенно уверен, что идея -- плохая. Вообще не надо ничего трогать в С++ в модулях.

Я хоть и плохо отношусь ко ряду нововведений в C++, но потихоньку надо двигаться дальше.
Ну и сборка проектов с модулями (C#, Java) это я скажу здорово. Немного удобней, немного быстрей, чуть более внятные ошибки. Разница вроде и не особо критичная, но это как вывод ошибок gcc и clang — две большие разницы.

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

BFE>

BFE>namespace Abc
BFE>{
BFE>  import vector;
BFE>};
BFE>

BFE>Зачем этот запрет?

А смысл так писать? модули не добавляют ничего к правилам разрешения имен.

BFE>Вот представьте, что я приобрёл два модуля и у них совпадают внутренние имена namespace'ов. И что мне делать?

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

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

MZ>Я совершенно уверен, что идея -- плохая. Вообще не надо ничего трогать в С++ в модулях.

как можно тронуть то, чего (практически) нет? А почему идея плохая?

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

BFE>>

BFE>>namespace Abc
BFE>>{
BFE>>  import vector;
BFE>>};
BFE>>

BFE>>Зачем этот запрет?
E>А смысл так писать? модули не добавляют ничего к правилам разрешения имен.
Вот именно, что не добавляют, а иногда хочется добавить.

BFE>>Вот представьте, что я приобрёл два модуля и у них совпадают внутренние имена namespace'ов. И что мне делать?
E>Ровно тоже, что ты делал раньше, приобретя два хидера с совпадающими именами.
У меня есть хедеры с совпадающими именами, но у них разные пути, так что проблемы нет.

E>Делаешь третий модуль, в котором маскируешь интерфейс второго
Каким образом, если я не могу обернуть модуль в namespace ?

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

BFE>Вот именно, что не добавляют, а иногда хочется добавить.

Ну собственно идут маленькими шагами Сначала просто модули, затем еще что-нить

BFE>>>Вот представьте, что я приобрёл два модуля и у них совпадают внутренние имена namespace'ов. И что мне делать?
E>>Ровно тоже, что ты делал раньше, приобретя два хидера с совпадающими именами.
BFE>У меня есть хедеры с совпадающими именами, но у них разные пути, так что проблемы нет.

Я имел в виду совпадающие имена верхнего уровня в самих хидерах. Вроде одинаковых имен namespace. Что касается модулей с одинаковыми именами — то хз, как сделают. Может быть будет возможность добавить путь. А может просто запретят и будет как в яве — com.mycompany.mymodule

E>>Делаешь третий модуль, в котором маскируешь интерфейс второго
BFE>Каким образом, если я не могу обернуть модуль в namespace ?

Пусть модули A и B имеют функцию с именем f(). Делаешь модуль C, импортишь в него модуль B, пишешь там функцию С_f(), в реализации которой зовешь f() из B. Собственно если в двух разных хидерах будет одно имя функции — поведение аналогично...

Недавно выпустили update1, заодно и в статье расписали немного о текущей реализации: C++ Modules in VS 2015 Update 1.

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

BFE>>

BFE>>using module module-name ;
BFE>>

W>Кстати, да, так лучше.

IMO, это Стокгольмский синдром. using уже сильно перегружен, а с таким синтаксисом будет совсем жесть

using namespace std;
using std::vector;
using something = std::vector<int>;
using module std.vector;

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

A>'std.' нужен очевидно потому что это пространство имен (в широком смысле слова).
A>чтобы не путать std.vector с boost.vector, llvm.adt.vector, mylib.vector и т.п.
Как модули будут разворачиваться, подключаться и распространяться ты в курсе? Что там будет с АБИ? Как будет с crt, версионностью?

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

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

A>>'std.' нужен очевидно потому что это пространство имен (в широком смысле слова).
A>>чтобы не путать std.vector с boost.vector, llvm.adt.vector, mylib.vector и т.п.
K>Как модули будут разворачиваться, подключаться и распространяться ты в курсе? Что там будет с АБИ? Как будет с crt, версионностью?

стандарт ничего из этого не специфицирует.

в реализации от MS используется что-то вроде сериализованного AST.
и если что, ни о каких динамических модулях речь не идет. не надо путать модули С++ и dll/so