Поддержка 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>
