GoingNative 46: [Why you should be trying out] C++ Modules

Sign in to queue

The Discussion

  • User profile image
    Joe CPP

    As a non-native speaker I found it quite hard to understand one of the speakers in this video. Kindly consider closed captioning in the future for those like me.

    Respectfully.

  • User profile image
    Varun

    I have a couple of questions -

    How much compile time implication do we have for including large headers like windows.h? Or STDs for that matter?

    Is this included in latest standards? I mean is it cl specific or will it come to GCC.

    VC++ has a problem with some legacy include dependencies. Are modules expected to resolve the problem.

    It is fun to work with compiler features like
    foo (bar) {
    #include <header.h>
    }
    Can we expect similar features with import?

    Is it really worth moving C++ to a high level language domain? The reason why I am asking this is - to know when to stop. Any language can be "enhanced" only to find it closer to a different higher level language.

  • User profile image
    Orri

    Thanks for this awesome work Garbriel and others. I didn't understand the last part of the video. Are we going to be receiving improvements/bug fixes in Update 2 and then there's also going to be even faster updates somehow? How will that work?

    Also, what tools do you guys use when using modules? Do you use the Visual Studio editor but turn off intellisense? How do you build the project, always manually? Because the modules can have dependencies with other modules so they must be built in the correct order. I'm no expert with c++ build tools so I'm not sure what I can use but I built a small program that scans for imports to build a dependency graph and then builds the modules in the correct order. Are we going to see any better tooling for modules this year?

  • User profile image
    David_Hunter

    You mention that VS 2015 Update 2 won't provide modules for the standard library. Is there an ETA for this Update 3 perhaps! Also will you be providing modules for other things like DirectX, or how about "import windows" rather than #include "windows.h"

    I have also asked in a number of places if it is possible to generate old style headers from modules. I would love to use modules in our internal development but our customers may still want header files. 

    Also do you have any docs on the performance improvement in compilation times?

  • User profile image
    gdr

    @Varun: We have not modularized <windows.h> yet; that header is owned by Windows folks and they have started work on modularizing Windows code base, but they are just at beginning of that titanesque work. 

    The C++ Module design was approved by the C++ Evolution Working Group at the Fall 2015 meeting in Kona.  The formal wording is being reviewed by the C++ Core Working Group (in Kona, and early December 2015); I expect another review next month (March 2016) in Jacksonville, Florida.  Each C++ compiler has its own priority list of features to implement and bugs to fix.  I would expect that as we are advancing in the standardization process, various levels of conformance will start showing up in C++ compilers until the feature is completely implemented -- just like for any C++ feature. 

    Could you be more specific about the "legacy include dependencies" you have in mind?

    file inclusion at function scope isn't for modularization.  The only time it ever makes sense to do that is if one is generating text (e.g. some kind of data in table), and that scenario isn't a module scenario.  Note however that you can use file include in your module; you just can't say an import at function scope.

    Yes, it is worth having modules in C++.  C++ is already a high level programming language, so it is not the case that we are moving it to a high level language domain: it is already there.  Its beauty and attractivenes is that it offers affordable abstractions at unbeatable price, following a zero-overhead abstraction principle.

  • User profile image
    gdr

    @Orri: Yes, that is correct: VS2015 Update 2 will containt bug fixes to the module preview.  And we are also considering biweekly releases of previews of preview, if I may.  More on this later.  Andrew Pardoe has all the details.  We want to leverage the C++ community's feedback in a fast turnaround, with a focus on quality.

    It is true that we don't have IntelliSense support for modules yet, but be assured that plans are in the work on that.  We will also share dedicated GN videos/blogpost on interaction with VS IDE-integrated build support later.  Yes, we are hoping to release some tooling for modules this year.

  • User profile image
    tivadj

    Garbriel, seems like "using namespace std" statement is redundant after one already typed "import" directive?

  • User profile image
    gdr

    @David_Hunter:Modularizing the standard library is high on our stack of things to do -- and the stack is deep with lot of contenders for the top.  At this point in time, I do not have an ETA to share, but we will be keeping the community informed of our progress, either through GN videos or VC blogs.

    Headers such as <windows.h> are owned by the Windows division who is also heavily investing in modularizing.  Again, no ETA yet.  We will keep you informed of important milestones, naturally.

    Generation of header files out of module IFC is possible in principle, but why would you want to go that route if you already have a compiler that understands module?  There is a viable migration strategy that consists of having a wrapper header file containing essentially "import My.Module;" -- see the migration story by Pavel Curtis and myself.

     

  • User profile image
    gdr

    @tivadj: modules are orthonogal to namespaces.  The reason is that in existing C++ (C++14), namespaces span across translation units.  Consequently, an early design choice was that namespace should also span modules. 

    The corollary is that, unlike some programming languages, an import does not implicitly perform any using directive of any sort.  It only makes available to the compiler the declarations that were exported by the nominated module. In particular, an import does not imply a using directive that wasn't already there. 

    So, the "using namespace std;" was not redundant.  The alternative was to quality every single name that was made available by the standard facilities.

    It is good to know that an import declaration does not imply namespace pollution :)

  • User profile image
    David_Hunter

    @gdr:The reason to generate header files from modules is to support older compilers. We, my company that is, sell libraries to third parties. We would love to internally move our development to modules mostly for compilation speed. However we do not control when our clients upgrade compilers and in many cases they are fairly slow, we just managed to get the last off VS 2010. Ideally for them we would generate a reasonable set of header files and not even mention modules, other than as yet another reason to upgrade to newer versions.

  • User profile image
    golnazal

    @Joe CPP: This now has closed captioning :)

Add Your 2 Cents