我应该如何编写我的C ++为C ++ 17模块做好准备？ [英] How should I write my C++ to be prepared for C++17 modules?
问题描述
已有两个支持C ++模块的编译器
There are already two compilers that support C++ modules
- clang：http://clang.llvm.org/docs/Modules.html
- MS VS 2015：http://blogs.msdn.com/b/vcblog/ archive / 2015/12/03 / c-modules-in-vs-2015-update-1.aspx
- clang: http://clang.llvm.org/docs/Modules.html
- MS VS 2015: http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx
现在开始一个新项目时，我应该注意什么，以便能够采用模块功能，当它最终在我的编译器中发布？
When starting a new project now, what should I pay attention to in order to be able to adopt the modules feature when it is eventually released in my compiler?
是可能使用模块并仍然保持与不支持它的旧编译器的兼容性？
Is it possible to use modules and still maintain compatibility with older compilers that do not support it?
推荐答案
已有两个支持C ++模块的编译器
There are already two compilers that support C++ modules
clang： http：// clang.llvm.org/docs/Modules.html
MS VS 2015： http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update -1.aspx
Microsoft方法似乎是最吸引人的，主要是因为微软抛出更多的资源在他们的实施比目前任何ang民。请参见 https://llvm.org/bugs/buglist.cgi ？list_id = 100798& query_format = advanced& component = Modules& product = clang 我的意思是，在C ++的模块中有一些大的showstopper错误，而C模块或特别是Objective C看起来更实用世界代码。 Visual Studio最大和最重要的客户微软正在努力为模块，因为它解决了一吨内部构建可扩展性问题，微软的内部代码是一些最难的C ++编译任何地方存在，所以你不能抛出任何编译器而不是MSVC在它（例如好运气得到ang或GCC编译40k线功能）。因此，Google等使用的clang构建技巧对Microsoft不可用，他们有一个巨大的迫切需要得到它固定的更早，而不是后来。
The Microsoft approach appears to be the one gaining the most traction, mainly because Microsoft are throwing a lot more resources at their implementation than any of the clang folk currently. See https://llvm.org/bugs/buglist.cgi?list_id=100798&query_format=advanced&component=Modules&product=clang for what I mean, there are some big showstopper bugs in Modules for C++, whereas Modules for C or especially Objective C look much more usable in real world code. Visual Studio's biggest and most important customer, Microsoft, is pushing hard for Modules because it solves a whole ton of internal build scalability problems, and Microsoft's internal code is some of the hardest C++ to compile anywhere in existence so you can't throw any compiler other than MSVC at it (e.g. good luck getting clang or GCC to compile 40k line functions). Therefore the clang build tricks used by Google etc aren't available to Microsoft, and they have a huge pressing need to get it fixed sooner rather than later.
不要说在实际应用于大型真实世界代码库时，Microsoft提案没有一些严重的设计缺陷。但是Gaby认为你应该重构你的模块代码，虽然我不同意，我可以看到他来自哪里。
This isn't to say there aren't some serious design flaws with the Microsoft proposal when applied in practice to large real world code bases. However Gaby is of the view you should refactor your code for Modules, and whilst I disagree, I can see where he is coming from.
现在开始一个新项目时，我应该注意什么，以便能够采用模块功能，当它最终在我的编译器中发布？
When starting a new project now, what should I pay attention to in order to be able to adopt the modules feature when it is eventually released in my compiler?
在Microsoft的编译器目前应该实现模块，你应该确保你的库可以使用所有这些形式：
In so far as Microsoft's compiler is currently expected to implement Modules, you ought to make sure your library is usable in all of these forms:
- 动态库
- 静态库
- 仅标头库
很多人非常惊讶的是，目前预期实现的C ++模块保持这些区别，所以现在你得到一个C ++模块变体所有三个第一个看起来像人们期望的C ++模块，最后看起来最像一个更有用的预编译头。你应该支持这些变体的原因是，你可以重用大多数相同的预处理器机制，也支持C ++模块，只需很少的额外工作。
Something very surprising to many people is that C++ Modules as currently expected to be implemented keeps those distinctions, so now you get a C++ Module variant for all three of the above, with the first most looking like what people expect a C++ Module to be, and the last looking most like a more useful precompiled header. The reason you ought to support those variants is because you can reuse most of the same preprocessor machinery to also support C++ Modules with very little extra work.
稍后Visual Studio将允许将模块定义文件（.ifc文件）作为资源链接到DLL中。这将最终消除在MSVC上的.lib和.dll区别的需要，你只是提供一个单一的DLL给编译器，它所有的只是工作模块导入，没有标题或任何其他需要。这当然有点像COM，但没有COM的好处。
A later Visual Studio will allow linking of the module definition file (the .ifc file) as a resource into DLLs. This will finally eliminate the need for the .lib and .dll distinction on MSVC, you just supply a single DLL to the compiler and it all "just works" on module import, no headers or anything else needed. This of course smells a bit like COM, but without most of the benefits of COM.
可以使用模块单个代码库，并仍然保持与不支持它的旧编译器的兼容性？
Is it possible to use modules in a single codebase and still maintain compatibility with older compilers that do not support it?
意味着上面插入的粗体文本。
I'm going to assume you meant the bold text inserted above.
答案一般是肯定的，甚至更多的预处理器宏有趣。 #include< someheader> 可以变成一个 import someheader ，因为预处理器仍然照常工作。因此，您可以使用C ++模块支持沿着类似以下行的标记单个库头文件：
The answer is generally yes with even more preprocessor macro fun. #include <someheader> can turn into an import someheader within the header because the preprocessor still works as usual. You can therefore mark up individual library headers with C++ Modules support along something like these lines:
// someheader.hpp
#if MODULES_ENABLED
# ifndef EXPORTING_MODULE
import someheader; // Bring in the precompiled module from the database
// Do NOT set NEED_DEFINE so this include exits out doing nothing more
# else
// We are at the generating the module stage, so mark up the namespace for export
# define SOMEHEADER_DECL export
# define NEED_DEFINE
# endif
#else
// Modules are not turned on, so declare everything inline as per the old way
# define SOMEHEADER_DECL
# define NEED_DEFINE
#endif
#ifdef NEED_DEFINE
SOMEHEADER_DECL namespace someheader
{
// usual classes and decls here
}
#endif
您的main.cpp或任何，你只需要做：
Now in your main.cpp or whatever, you simply do:
#include "someheader.hpp"
...如果编译器有/ experimental：modules / DMODULES_ENABLED，那么你的应用程序会自动使用你的库的C ++ Modules版本。如果没有，您就会像以前一样做内联包含。
... and if the compiler had /experimental:modules /DMODULES_ENABLED then your application automagically uses the C++ Modules edition of your library. If it doesn't, you get inline inclusion as we've always done.
我估计这些都是您的源代码的最小可能的更改集，以使您的代码模块 - 现在就绪。你会注意到我没有说过构建系统，这是因为我仍然在调试我编写的cmake工具，以使所有这些东西无缝工作，我期望调试它几个月了。期望看到它也许在明年或一年后的C ++会议：）
I reckon these are the minimum possible set of changes to your source code to make your code Modules-ready now. You will note I have said nothing about build systems, this is because I am still debugging the cmake tooling I've written to get all this stuff to "just work" seamlessly and I expect to be debugging it for some months yet. Expect to see it maybe at a C++ conference next year or the year after :)
这篇关于我应该如何编写我的C ++为C ++ 17模块做好准备？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
