I just discovered this old C++0x draft about modules in C++0x.

The idea was to get out of the current .h/.cpp system by writing only .cpp files which would then generate module files during compilation, which would then in turn be used by the othe开发者_如何转开发r .cpp files.

This looks like a really great feature.

But my question is: why did they remove it from C++0x? Was it because of too many technical difficulties? Lack of time? And do you think they will consider working on it for an ulterior version of C++?

C++ Modules draft (Technical Specification after C++17)

A draft and several updated revisions for the C/C++ module specification have been published by WG21 on open-std.org. I will link only to the latest documents here:

• Working Draft, Extensions to C++ for Modules N4610 (October 2016).
• Fourth revision published as P0142R0 (March 2016).
• Wording for Modules published as P0143R2 (March 2016).
• The clang team has published a second revision of their changes: P0273R1 (October 2016).

The following blog posts contain a summary of the standards meetings and in particular a summary of the current status of the modules draft:

• Trip Report: C++ Standards Meeting in Lenexa (May 2015).
• Trip Report: C++ Standards Meeting in Kona (October 2015).
• Trip Report: C++ Standards Meeting in Jacksonville (February 2016).
• Trip Report: C++ Standards Meeting in Oulu (June 2016).
• Trip Report: C++ Standards Meeting in Issaquah (November 2016).

Update: As explained in the Kona trip report that I linked to above, there are currently two competing proposals, one from Microsoft and one from Clang. The proposed solution from Microsoft does not allow to export Macros, while the solution from the Clang team would support exporting Macros. So far only Microsoft has formally submitted a draft for a module specification.

Module specification as proposed by Microsoft

Here is a quick overview of the most important concepts that this proposal contains. As its a draft this might possibly still change. The new modules standard will among other things consist of the following:

A module keyword to declare a module, multiple files can declare this to build one module (but for each module only one compilation-unit can contain an export {} section):

module M;

An import keyword to import modules, instead of import it might also be decided to use using module instead, so a new import keyword could be avoided.

import std.io;
import module.submodule;

An export syntax, which defines the public declarations that are part of this module, non-interface declarations that should not be exported as part of the module will be defined outside the export block. Declarations can be any kind of declaration in C/C++, that is, not only functions but also variables, structs, templates, namespaces and classes:

export {
    int f(int);
    double g(double, int);

    int foo;

    namespace Calc {
         int add(int a, int b);
    }        
}

void not_exported_function(char* foo);

An important change of modules will be that macros and preprocessor definitions will be local to modules and will not be exported. Thus macros do not have any impact on imported modules:

#define FILE "my/file"
import std.io;   //will not be impacted by the above definition

Its important note that the both the current preprocessor system and modules will be able to co-exist and headers can still be used for example to include macros.

For more detailed information I suggest to read the draft.

Clang Modules

Clang has been working on a modules implementation which can be found at the clang modules page. However clang does currently not implement a concrete syntax for modules, that is, none of the above mentioned syntax has been implemented by Clang. To explain this the page contains the following statement:

At present, there is no C or C++ syntax for import declarations. Clang will track the modules proposal in the C++ committee. See the section Includes as imports to see how modules get imported today.

The main part that is currently implemented by Clang is the "Module Map Language" which allows write module maps for existing code that still uses header files.

Macro Exports from Modules

As mentioned above it is still unclear if macro exports will be part of the final Modules TS. In P0273R1 the following syntax was proposed for the export of macros:

#export define MAX(A,B) ((A) > (B)) ? (A) : (B);

From the State of C++ Evolution (Post San Francisco 2008), the Modules proposal was categorized as "Heading for a separate TR:"

These topics are deemed too important to wait for another standard after C++0x before being published, but too experimental to be finalised in time for the next Standard. Therefore, these features will be delivered by a technical report at the earliest opportunity.

The modules proposal just wasn't ready and waiting for it would have delayed finishing the C++0x standard. It wasn't really removed, it was just never incorporated into the working paper.

Clang is the first compiler to start working on modules even before the standardization is complete. There is not much of a documentation yet, but example code could be found here:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/

Some comments from Douglas Gregor (the developer implementing them):
http://clang-developers.42468.n3.nabble.com/C-modules-td3619936.html

In theory, you can define a bunch of helper macros like begin_module, end_module, import_module to shield yourself from any likely changes to the syntax that will come in the future.

EDIT 1:
Douglas Gregor has released a presentation about his implementation:
http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf?=submit

EDIT 2:
The module support in clang have been documented here:
http://clang.llvm.org/docs/Modules.html

EDIT 3:
Modules are now supported in Microsoft's C++ compiler as well: http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx

1. Because it is very big conceptual change.
2. There is no real need of it as separation of the sources to h/cpp does the job
3. Because C++ does not define how actual "modules" libraries are build. It leaves it to compiler developer and to linker.
4. "Modules" are sometimes quite platform dependent, for example DLLs quite different from shared objects. So it is not so trivial to merge between these concepts.