Regarding the timing:
"There's a lot of new things to look forward to in the upcoming versions of the C++ standard. Here's a high-level overview of what transpired in Kona and what I personally think would be nice to see in the next version(s) of C++. I mention versions because the committee has decided that we'll be working on getting a short-term update to the standard tentatively shooting for 2017 (C++1y or C++17) and a long-term update aiming for 2022 (C++22).
. . .
Modules -- not dynamic libraries (although those would be nice to have too) but more on logical grouping of symbols for replacing header files and #include. There are two different proposals on Modules for C++ and there's a Study Group formed to address this particular issue. This looks to be one of the things that might be making it into C++17."
http://www.cplusplus...-libraries.html
4.1 Improved (scalable) build times
Build times on typical evolving C++ projects are not significantly improving as hardware
and compiler performance have made strides forward. To a large extent, this can be
attributed to the increasing total size of header files and the increased complexity of the
code it contains. (An internal project at Intel has been tracking the ratio of C++ code in
“.cpp” files to the amount of code in header files: In the early nineties, header files only
contained about 10% of all that project's code; a decade later, well over half the code
resided in header files.) Since header files are typically included in many other files, the
growth in build cycles is generally superlinear with respect to the total amount of source
code. If the issue is not addressed, it is likely to become worse as the use of templates
increases and more powerful declarative facilities (like concepts, contract programming,
etc.) are added to the language.
Modules address this issue by replacing the textual inclusion mechanism (whose
processing time is roughly proportional to the amount of code included) by a precompiled
module attachment mechanism (whose processing time—when properly implemented—
is roughly proportional to the number of imported declarations). The property that client
translation units need not be recompiled when private module definitions change can be
retained.
Experience with similar mechanisms in other languages suggests that modules therefore
effectively solve the issue of excessive build times.[/quote]
See also:
http://stackoverflow.../modules-in-c0x
http://permalink.gma...st.devel/228346
http://herbsutter.co...ndards-meeting/
