我应该如何编写C ++为C ++模块做准备? [英] How should I write my C++ to be prepared for C++ modules?

问题描述

已经有两个支持C ++模块的编译器:

There are already two compilers that support C++ modules:

• C语: 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

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的方法似乎是最受关注的方法，这主要是因为Microsoft在其实现上投入的资源比目前任何使用clang语言的人都要多.参见 https://llvm.org/bugs/buglist.cgi我的意思是?list_id = 100798& query_format = advanced& component = Modules& product = clang ，C ++模块中有一些大型的showtopper错误，而C或特别是Objective C的模块看起来更实用世界代码. Visual Studio最大和最重要的客户Microsoft一直在努力争取Modules，因为它解决了很多内部构建可伸缩性问题，并且Microsoft的内部代码是最难在现有任何位置进行编译的C ++，因此您不能抛出任何编译器除了MSVC以外(例如，获得clang或GCC来编译40k行函数的运气很好).因此，Microsoft等无法使用Google等使用的clang构建技巧，因此迫切需要尽快解决此问题.

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认为您应该为Modules重构代码，尽管我不同意，但我可以看到他来自哪里.

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:

1. 动态库
2. 静态库
3. 仅标头库

令很多人感到惊讶的是，目前期望实现的C ++模块保持了这些区别，所以现在您可以得到上述所有三个的C ++ Module变体，其中第一个看起来最就像人们期望的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 ++模块版本.如果没有，您将像往常一样获得内联包含.

... 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 ++模块做准备?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！