> Fixing the "include hell" problem would be at the top of my list of
> wants as someone who cares about the performance of a large scale build
> system. I believe there was a C++ modules proposal on the standards
> track at one point. Not sure what it's status is beyond being an
> experimental feature in clang [1]. Of course, by the time all the major
> compilers support this and we're in a position to make use of it, large
> parts of m-c's C++ might be rewritten in Rust, so who knows.
>
> [1] http://clang.llvm.org/docs/Modules.html
The Standards Committee has a study group focusing on modules.
It met briefly last week. Doug Gregor, who's been working on
implementing modules in clang, shared a status update:
- Clang has a working implementation of modules for C and Objective-C,
which is shipping in Xcode 5.
- Implementing the feature in C++ is quite a bit more difficult,
because of things like having to reconcile template instantiations
from different modules (basically, a lot of the same problems that
made 'export' difficult). There is work in progress on a clang
implementation for C++, but it's not usable yet.
The latest version of the proposal looks fairly clean to me from a
user's point of view:
- Modules are simply header files. A file called a "module map"
identifies header files as being modules and gives them a name.
- To import a module, one writes
import modulename;
- From an implementation point of view, modules are just a pre-
parsed representation of a header file's contents. Clang's
work-in-progress implementation represents them as a
serialized AST, but other implementations are possible.
- Modules are parsed without any context. So, if one does
#define EVIL_MACRO
#include <header.h>
then EVIL_MACRO is defined while processing the contents of
<header.h>, but if one does
#define EVIL_MACRO
import header;
then EVIL_MACRO is not defined while building the module
'header'. Obviously this is something that needs to be
considered when porting header files to be modular, you
cannot just blindly replace all inclusions with module
imports.
Naturally, a lot of the details are still subject to change,
particularly about the mechanism for mapping module names to
header files, and about the syntax for importing a module.
In terms of timeframe, I don't think the Committee will
consider standardizing anything until there isn't a complete
implementation, especially in light of what happened with
'export'. So, I'm guessing C++17 at the earliest.
Botond
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
