“Ask Me Anything” interview is now live on Channel 9

9 thoughts on ““Ask Me Anything” interview is now live on Channel 9”

1. Very informative as usual talk Herb. Thanks !

2. I think you are right. The lack of “symbolic #includes” is almost as embarrassing as the error messages STL spits out. If I had to choose between concepts and modules.. I might just go for modules.

3. Oops; this commenting system didn’t allow me to say what I wanted. Here are the corrections:

   “every time you include, for example, ‘vector’ in a file, you must recompile it.”

   “Because the contents of ‘vector’ may depend on everything that was included in the .cpp file *before* ‘vector’. You could include some #define which would control how ‘vector’ gets compiled in one .cpp file vs. another within the same project.”

   “The contents of ‘vector’ ought to be invariant with the contents of anything you include before it.”

4. I was actually rather surprised by Herb’s response on modules. It’s clear that he wasn’t very close to the proposal, because the idea really has very little to do with DLLs. Certainly not at this point.

   The idea also doesn’t require cross-platform implementation either. That is, being able to use modules generated by compiler X on compiler Y. They want to make sure that interop is *possible*, but it isn’t the focus of the idea.

   The core idea of modules in C++ is to remove the need to compile header files. If you’re compiling C++ code, every time you include, for example, in a file, you must recompile it. *Every* time. Why?

   Because the contents of may depend on everything that was included in the .cpp file *before* . You could include some #define which would control how gets compiled in one .cpp file vs. another within the same project.

   That’s a huge waste of time, simply because you will not be doing that. The contents of ought to be invariant with the contents of anything you include before it. And that’s the core, fundamental purpose of a module: to be invariant to previously included stuff.

   Obviously, there will be different builds with different #defines. Debug vs. release. Etc. But within a particular build, each module can be built with only references to the other modules that it includes (and the modules that they include).

   So basically, modules are like precompiled headers, only with a lot fewer restrictions. You can include more than one in a .cpp file. There can be dependencies between modules (forming a directed-acyclic graph). And so forth. The format of a module can be whatever is most convenient for the compiler architecture.

   Indeed, when a compiler builds a library, it could generate a single module file that contains all of the submodules (one each from each .cpp file). That way, you don’t have to do disk seeking for each individual header file when you want to include that library; you just include the module in question and the compiler loads the entire thing as a single pre-processed blob. Your “import” command would simply select which part of it to use.

   This would *dramatically* improve compile times for large C++ applications. To me, that is the primary impetus in getting modules out there ASAP. I’d love to see some enterprising developer implement modules for Clang or GCC, just as a proof-of-concept.

5. TR2 doesn’t have to be only library changes. It is possible for it to include language changes, if the C++ committee so desires.

6. Look at how D does modules.
   D’s feature set is very similar to C++0x. Even with c++-style templates, D sports a great module system.

   The modules are basically stripped down header files that are produced while compiling. The templates are copied pretty much word for word. Class sizes are recorded and all private members are stripped. Also file private methods and variables are not placed in the module either.

   It’s nothing super fancy like exported templates. But it works well.

7. Thank you for a great talk! I am glad my modules/templates question made it in :)

   So, the proposed module would allow people to expose basically “C with classes” code, which is far from what can be done with the complete modern C++. You briefly mentioned template instantiation – is there something I can read about that idea? I am just trying to understand – how could you ever expose something like standard containers from a module (or instantiate it beforehand)? That code is parameterized to the the concrete type and then machine code (or some intermediate representation) is emitted. In either case, I think the compiler will need source code, or else you are talking about some kind of separately and completely compiled “generic” that lives in a lib and gets dynamically linked (ie not part of this compilation).

   Does this make sense or am off?

   Thanks!

8. I can atleast say, that things like polymorphic lambdas aren’t going to be in TR2, because the Technical Report is solemnly based on *library* extensions, at least as far as I understand it. Polymorphic lambdas require *language* support, so it would be a new standard.

9. One further comment/question on polymorphic lambdas.

   Implicit template parameters cut from regular functions for various reasons.
   auto parameters cut from lamdba because they’d already been cut for regular functions.

   However, there is an unresolved issue. C++ provides syntax to explicitly create template functions. However, C++11 does not provide syntax to explicitly create template lambda functions.

   When I need a polymorphic functor, lambdas are not an options. Worse still if I need a polymorphic functor that captures state I have to forego the concise, error resistant lambda capture lists.

   I don’t expect this to be resolved with c++11 but I hope the argument can be raised for the TR2 and ensure polymophic lambda even if implicit templates don’t make it.

Comments are closed.