Поддержка C++ модулей в Visual Studio 2015 Update 1
На конференции CppCon, которая проходит прямо сейчас, команда разработчиков компилятора Visual C++ заявила, что в следующем обновлении (Visual Studio 2015 Update 1) в компилятор С++ от Microsoft будет добавлена экспериментальная возможность из нового (ещё не утверждённого) стандарта С++ — поддержка модулей!
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, fdn721, Вы писали:
F>Поменяли шило на мыло. Да и чую проблем будет вагон и маленькая тележка. Особенно в реализации от индусов из Microsoft.
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Я так понимаю, это будет С++17? Ну, крута! МД>На конференции CppCon, которая проходит прямо сейчас, команда разработчиков компилятора Visual C++ заявила, что в следующем обновлении (Visual Studio 2015 Update 1) в компилятор С++ от Microsoft будет добавлена экспериментальная возможность из нового (ещё не утверждённого) стандарта С++ — поддержка модулей!
Такая поспешность и внезапность для такой серьёзной вещи чревата костыльной реализацией, которая через 5-10 лет будет приносить большие проблемы.
Так то оно идея и хорошая, но вот какой окажется реализация мы только увидим.
Re: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, Abyx, Вы писали:
A>Есть N4465, какая разница кто его реализует.
Что-то я сомневаюсь, что это вообще надо реализовывать.
На вскидку. Зачем нужен этот новый синтаксис:
import std.vector; // #include <vector>
?
Что это за убожество? Зачем import без диеза? Зачем 'std.' префикс?
Почему нельзя написать, например, так:
#include {vector}
Или, если вам, таки, надо префикс (зачем?), так:
#include {std.vector}
Это же относится к "export" и "module".
Там есть ровно две заслуживающие внимания здравые идеи:
1. включение файла изолированного от распространения макросов.
2. Template explicit specializations. Это верный шаг в направлении поддержки шаблонных виртуальных функций.
Всё остальное — либо лажа, либо внутренняя кухня компилятора, которая может быть реализована в рамках текущего стандарта.
И каждый день — без права на ошибку...
Re[2]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, B0FEE664, Вы писали:
BFE>И что? Из-за этого надо вводить чуждый синтаксис?
Почему он чуждый? Обычное ключевое слово. Новое, но рядовое ключевое слово. Почему вложенные модули через точку, а не через двойное двоеточие? Ну, наверное, чтобы как-то указать, что модули это не пространства имен, а вещи, им перпендикулярные.
BFE>Препроцессору ничто не мешает игнорировать эту конструкцию.
Директива препроцессора (визуально), которая игнорируется препроцессором? При том, что остальные новые ключевые слова диез не подразумевают?
Но в целом я с вами солидарен. Предложенное решение выглядит подозрительно. А если учесть, какой длинный путь такому решению потребуется до внедрения в массы, то вообще труба. Параллельно конкурирующие друг с другом модули и инклуды, боюсь, вообще мозги выносить будут. Слишком длинный это шаг, слишком много он поломает.
Здравствуйте, Went, Вы писали:
BFE>>И что? Из-за этого надо вводить чуждый синтаксис? W>Почему он чуждый? Обычное ключевое слово. Новое, но рядовое ключевое слово.
Новые ключевые слова в язык вводить сложно. Что, если есть класс:
class import {...};
тогда
import specialvector;
это просто глобальная переменная...
W>Почему вложенные модули через точку, а не через двойное двоеточие? Ну, наверное, чтобы как-то указать, что модули это не пространства имен, а вещи, им перпендикулярные.
Я думаю, авторы просто списывали синтаксис с другого языка. Не подумав.
BFE>>Препроцессору ничто не мешает игнорировать эту конструкцию. W>Директива препроцессора (визуально), которая игнорируется препроцессором? При том, что остальные новые ключевые слова диез не подразумевают?
Может не игнорироваться, может включать модуль (чтобы это действие не означало). Не суть.
W>Но в целом я с вами солидарен. Предложенное решение выглядит подозрительно. А если учесть, какой длинный путь такому решению потребуется до внедрения в массы, то вообще труба. Параллельно конкурирующие друг с другом модули и инклуды, боюсь, вообще мозги выносить будут. Слишком длинный это шаг, слишком много он поломает.
Мне вообще идея модулей кажется несколько странной в том виде, в котором она предложена. Это слишком сильно похоже на систему управления precompiled хеадерами. Ну, а если это precompiled хеадер'ы, то к чему весь этот огород? Скомпилируйте h-файл в промежуточный формат и сделайте изолированное от макросов подключение. Будет ровно то же самое.
И каждый день — без права на ошибку...
Re[8]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, B0FEE664, Вы писали: BFE>Мне вообще идея модулей кажется несколько странной в том виде, в котором она предложена. Это слишком сильно похоже на систему управления precompiled хеадерами. Ну, а если это precompiled хеадер'ы, то к чему весь этот огород? Скомпилируйте h-файл в промежуточный формат и сделайте изолированное от макросов подключение. Будет ровно то же самое.
Да, не сильно вдумываясь в детали, мне тоже кажется, что достаточно было ввести новый формат "модуль", в котором будет либа + скомпилированные заголовоки. И чтобы этот модуль можно было подключать как статически, так и динамически. То есть:
1. Таргет компилятора "модуль". Модуль может быть как полностью скомпилированным в машинный код, так и "кроссплатформенным", содержащим "сырой код" в какой-то удобной для компилятора форме.
2. Более мощная система изолирования реализаций в заголовочных файлах. Чтобы можно было указать что именно экспортирует этот модуль, а что он вытянул для своей реализации.
3. Директива препроцессора #import "blablalba.cm" — раскрывается во включение необходимых (скомпилированных) заголовков + некий аналог #pragma comment(lib...), подключающий тело модуля при линковке.
4. Директива препроцессора #include "blablalba.cm" — раскрывается только во включение заголовоков без подключения, давая возможность подключить указанный модуль через какой-то вызов стандартной библиотеки std::import("blablalba.cm"). Также вынести в стандарт поиск функций в модулях по именам. Например:
void main()
{
auto module = std::import("module.cm");
auto create_object = module.function<Object(void)>("create_object");
auto object = create_object();
}
5. Новые скобки для включения, например #import [stl.vector], если потребуется новый способ искать модули в каком-то "стандартизированном" менеджере пакетов. Позволяющий писать и #include [stl.vector], если хочется подключить заголовок по-старинке без затягивания кода.
Хотя, все это выходит довольно похожим на предложенное Майкрософтом
Re[4]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, B0FEE664, Вы писали:
A>>Есть N4465, какая разница кто его реализует.
BFE>Что-то я сомневаюсь, что это вообще надо реализовывать. BFE>На вскидку. Зачем нужен этот новый синтаксис: BFE>
BFE>import std.vector; // #include <vector>
BFE>
BFE>? BFE>Что это за убожество? Зачем import без диеза? Зачем 'std.' префикс?
#import сломает существующие препроцессоры (препроцессор бывает внешним, а не встроенным в компилятор).
директива import к препроцессору отношения не имеет, ей незачем иметь #
'std.' нужен очевидно потому что это пространство имен (в широком смысле слова).
чтобы не путать std.vector с boost.vector, llvm.adt.vector, mylib.vector и т.п.
BFE>Почему нельзя написать, например, так: BFE>[ccode] BFE>#include {vector}
почему фигурные скобки? что за убожество? нравится шифт нажимать?
In Zen We Trust
Re[9]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, Went, Вы писали:
W>Хотя, все это выходит довольно похожим на предложенное Майкрософтом
это не "предложенное Майкрософтом", а результат работы всей SG2.
это всеравно что сказать что С++11/14/1z придумала майкрософт, потому что Саттер — председатель комитета по стандартизации.
In Zen We Trust
Re[5]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, Abyx, Вы писали:
BFE>>Что это за убожество? Зачем import без диеза? Зачем 'std.' префикс?
A>#import сломает существующие препроцессоры (препроцессор бывает внешним, а не встроенным в компилятор). A>директива import к препроцессору отношения не имеет, ей незачем иметь #
А типов import, export и module в глобальном пространстве никаких исходников никогда не встречается?
A>'std.' нужен очевидно потому что это пространство имен (в широком смысле слова). A>чтобы не путать std.vector с boost.vector, llvm.adt.vector, mylib.vector и т.п.
Это не пространство имён, а название модуля. Зачем std. префикс, если у стандартных инклюдов его нет:
Смотрите, никакой путаницы нет:
#include <array>
#include <boost/array>
BFE>>Почему нельзя написать, например, так: BFE>>[ccode] BFE>>#include {vector} A>почему фигурные скобки?
Фигурные скобки, потому, что сейчас они не могут там встречаться, а значит не поломают синтаксис. По смыслу подходят.
A>что за убожество?
Предложите лучше.
A>нравится шифт нажимать?
Французы, например, правый альт жмут, чтобы фигурные скобки набрать — и ничего, не жалуются.
И каждый день — без права на ошибку...
Re[6]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, B0FEE664, Вы писали:
BFE>А типов import, export и module в глобальном пространстве никаких исходников никогда не встречается?
если каждый модуль имеет свое пространство имен (а так и должно быть), то "import foo.bar;" это не валидный синтаксис
и если все директивы import в начале единицы трансляции, то там не будет никаких struct import;
A>>'std.' нужен очевидно потому что это пространство имен (в широком смысле слова). A>>чтобы не путать std.vector с boost.vector, llvm.adt.vector, mylib.vector и т.п.
BFE>Это не пространство имён, а название модуля. Зачем std. префикс, если у стандартных инклюдов его нет: BFE>Смотрите, никакой путаницы нет: BFE>
Поддержка C++ модулей в Visual Studio 2015 Update 1
А как это вообще будет реализовано на практике? Это будет некий аналог статической библиотеки (в файл которой будет дополнительно встроен интерфейс модуля в некотором предкомпилированном формате)?
А что будет в случае, когда два модуля зависят друг от друга? При компиляции первого надо будет как-то сослаться на интерфейсную часть второго (который еще не скомпилирован)?
Re[8]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, B0FEE664, Вы писали:
BFE>Новые ключевые слова в язык вводить сложно. Что, если есть класс: BFE>
BFE>class import {...};
BFE>
BFE>тогда BFE>
BFE>import specialvector;
BFE>
BFE>это просто глобальная переменная...
Ну и что? Возьмите и сделайте глобальную замену в вашем коде. Займет пару минут от силы.
Это лучше чем строить костыли на костылях из существующих ключевых слов или городить двойные и тройные подчеркивания перед ключевыми словами.
Re[9]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, 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; }? Могли. Но не ввели же. И это правильно.
Вот и тут так же.
Здравствуйте, 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'ов. И что мне делать?
И каждый день — без права на ошибку...
Re[10]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, swingus, Вы писали:
S>Я так понимаю, по скорости от precompiled headers это отличаться не будет
будет.
precompiled headers прекомпилируются все вместе, а модули — каждый по отдельности.
в precompiled headers попадает гораздо больше кода, чем в экспортируемую часть модуля
In Zen We Trust
Re[2]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, MasterZiv, Вы писали:
1>>Так то оно идея и хорошая, но вот какой окажется реализация мы только увидим.
MZ>Я совершенно уверен, что идея -- плохая. Вообще не надо ничего трогать в С++ в модулях.
Я хоть и плохо отношусь ко ряду нововведений в C++, но потихоньку надо двигаться дальше.
Ну и сборка проектов с модулями (C#, Java) это я скажу здорово. Немного удобней, немного быстрей, чуть более внятные ошибки. Разница вроде и не особо критичная, но это как вывод ошибок gcc и clang — две большие разницы.
Re[8]: Поддержка C++ модулей в Visual Studio 2015 Update 1
А смысл так писать? модули не добавляют ничего к правилам разрешения имен.
BFE>Вот представьте, что я приобрёл два модуля и у них совпадают внутренние имена namespace'ов. И что мне делать?
Ровно тоже, что ты делал раньше, приобретя два хидера с совпадающими именами. Делаешь третий модуль, в котором маскируешь интерфейс второго
Re[3]: Поддержка C++ модулей в Visual Studio 2015 Update 1
BFE>>Зачем этот запрет? E>А смысл так писать? модули не добавляют ничего к правилам разрешения имен.
Вот именно, что не добавляют, а иногда хочется добавить.
BFE>>Вот представьте, что я приобрёл два модуля и у них совпадают внутренние имена namespace'ов. И что мне делать? E>Ровно тоже, что ты делал раньше, приобретя два хидера с совпадающими именами.
У меня есть хедеры с совпадающими именами, но у них разные пути, так что проблемы нет.
E>Делаешь третий модуль, в котором маскируешь интерфейс второго
Каким образом, если я не могу обернуть модуль в namespace ?
И каждый день — без права на ошибку...
Re[10]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, B0FEE664, Вы писали:
BFE>Вот именно, что не добавляют, а иногда хочется добавить.
Ну собственно идут маленькими шагами Сначала просто модули, затем еще что-нить
BFE>>>Вот представьте, что я приобрёл два модуля и у них совпадают внутренние имена namespace'ов. И что мне делать? E>>Ровно тоже, что ты делал раньше, приобретя два хидера с совпадающими именами. BFE>У меня есть хедеры с совпадающими именами, но у них разные пути, так что проблемы нет.
Я имел в виду совпадающие имена верхнего уровня в самих хидерах. Вроде одинаковых имен namespace. Что касается модулей с одинаковыми именами — то хз, как сделают. Может быть будет возможность добавить путь. А может просто запретят и будет как в яве — com.mycompany.mymodule
E>>Делаешь третий модуль, в котором маскируешь интерфейс второго BFE>Каким образом, если я не могу обернуть модуль в namespace ?
Пусть модули A и B имеют функцию с именем f(). Делаешь модуль C, импортишь в него модуль B, пишешь там функцию С_f(), в реализации которой зовешь f() из B. Собственно если в двух разных хидерах будет одно имя функции — поведение аналогично...
Здравствуйте, Abyx, Вы писали:
A>'std.' нужен очевидно потому что это пространство имен (в широком смысле слова). A>чтобы не путать std.vector с boost.vector, llvm.adt.vector, mylib.vector и т.п.
Как модули будут разворачиваться, подключаться и распространяться ты в курсе? Что там будет с АБИ? Как будет с crt, версионностью?
Sic luceat lux!
Re[6]: Поддержка C++ модулей в Visual Studio 2015 Update 1
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Abyx, Вы писали:
A>>'std.' нужен очевидно потому что это пространство имен (в широком смысле слова). A>>чтобы не путать std.vector с boost.vector, llvm.adt.vector, mylib.vector и т.п. K>Как модули будут разворачиваться, подключаться и распространяться ты в курсе? Что там будет с АБИ? Как будет с crt, версионностью?
стандарт ничего из этого не специфицирует.
в реализации от MS используется что-то вроде сериализованного AST.
и если что, ни о каких динамических модулях речь не идет. не надо путать модули С++ и dll/so
.jpg)
