4 ms·

I'm very familiar with C++, passingly familiar with the modules proposal and unfamiliar with Rust and this article leaves me puzzled exactly what the author exp

I'm very familiar with C++, passingly familiar with the modules proposal and unfamiliar with Rust and this article leaves me puzzled exactly what the author expects / wants a modules proposal to do instead. My perspective as a C++ developer has been that modules have one primary purpose, which is to improve build times by eliminating the need to parse huge amounts of C++ in recursively included header files when compiling a compilation unit. If that's all a modules proposal accomplishes I'm fine with that. A modules proposal that doesn't accomplish that is useless. Build tools generally already parse .cpp files for includes to figure out header file dependencies for a .cpp file and have to combine the filenames extracted with information from the build system on include search paths to turn those into dependencies on specific concrete files. That involves information that lives in the build system and not in the code. Modules will require something similar from build tools but as with parsing includes the rules about imports (must be before actual code, must be alone on a line) parsing out the imports is trivial and cheap compared to recursively parsing the full code in header dependencies. So I guess I don't quite understand the problem. Modules are an improvement over headers for build times but they are not going to do everything that module systems perhaps do in some other languages because they have to be adopted incrementally into the many different existing build systems used in C++ code bases (which live outside the standard). Perhaps my ignorance of Rust means I'm missing what the author wants in C++ that's different from the current proposal.

coliveira 9y ago
The author is just trying to prove that C++ modules cannot be like Java or Python modules, which apparently some people don't get. My view is that C++ programmers already know this, since the language will not change suddenly just because modules have been introduced. The idea that the build system will take care of that is perfectly fine for normal C++ users.
- 1ris 9y ago
  >The author is just trying to prove that C++ modules cannot be like Java or Python modules, which apparently some people don't get. I don't think he trys that and i don't think it's true. The committee doesn't want to that, but I don't see why it would be possible by extending the language. Introducte a module - keyword, that works pretty much like a namespace keyword. Force the file name and path to match the name a la java. Introduce a mechanism a la "using namespace" that does import the namespace (like #include header.h) of the module and tells the build system what to build. Neither needs to become the other to do this if we forbid preprocessor commands and if constexprs around that. Allow attributes to specify visibility. Of course it's going to be a way more complicated, but i can't see how it would be impossible. I think c++ devs just don't want that.
zach43 9y ago
I’m not very familiar with C++ build tools which parse source code for header dependencies, but I know that C++ compilers (the preprocessor specifically) does this. From what I know of cmake and gmake, neither of these build tools automatically parse C++ files to find dependent header files, but both require manual specification of the include directories and include paths.
- mattnewport 9y ago
  Build pipelines I'm familiar with typically parse the includes from a .cpp file (and potentially recursively through the included headers) and resolve the includes to actual files based on include paths specified as part of the build configuration. Sometimes this information is cached in a .dep file or by some other mechanism. This information is then used to determine what actually needs to get built by an incremental build when a header changes. The compiler is usually passed include paths to resolve includes when invoked. The build tool need to track this just to enable minimal incremental builds.
- comex 9y ago
  They require manual specification of include paths, but not of what .cpp files depend on what .h files. However, at least on Unix, this is not typically done by having the build tool parse C++ files. Rather, while compiling a given .cpp file, the compiler is instructed (using -MD or other variants starting with -M) to output a .d file listing all the header files it encounters as it goes, which are then treated as dependencies. The output format is a subset of the Makefile language with just file dependencies (like “a.cpp : b.h”) rather than compilation rules; thus, anything that uses make as a backend (including autotools, cmake in that mode, etc.) can just have the Makefile ‘include’ all .d files, and make will do the right thing. (Alternative backend build tools, such as ninja, have to parse the .d files themselves, typically supporting only that subset rather than reimplementing all of make!) You don’t have them for the first compile, but that’s okay: the dependencies are only used to skip recompiling files if none of their dependencies changed. This design replaced an earlier one where the user had to manually run ‘make depend’, which would pre-scan for dependencies using a separate tool, makedepend(1). First ‘gcc -M’ was added as a straight replacement of makedepend, then -MD and variants were added to write dependency files while compiling each object file rather than requiring a separate invocation (which is slower). But it sounds like modules will complicate things, since it could be mandatory to gather dependency info upfront in order to compile modules before files that depend on them...

coliveira 9y ago

The author is just trying to prove that C++ modules cannot be like Java or Python modules, which apparently some people don't get. My view is that C++ programmers already know this, since the language will not change suddenly just because modules have been introduced. The idea that the build system will take care of that is perfectly fine for normal C++ users.

1ris 9y ago
>The author is just trying to prove that C++ modules cannot be like Java or Python modules, which apparently some people don't get. I don't think he trys that and i don't think it's true. The committee doesn't want to that, but I don't see why it would be possible by extending the language. Introducte a module - keyword, that works pretty much like a namespace keyword. Force the file name and path to match the name a la java. Introduce a mechanism a la "using namespace" that does import the namespace (like #include header.h) of the module and tells the build system what to build. Neither needs to become the other to do this if we forbid preprocessor commands and if constexprs around that. Allow attributes to specify visibility. Of course it's going to be a way more complicated, but i can't see how it would be impossible. I think c++ devs just don't want that.

zach43 9y ago

I’m not very familiar with C++ build tools which parse source code for header dependencies, but I know that C++ compilers (the preprocessor specifically) does this. From what I know of cmake and gmake, neither of these build tools automatically parse C++ files to find dependent header files, but both require manual specification of the include directories and include paths.

mattnewport 9y ago
Build pipelines I'm familiar with typically parse the includes from a .cpp file (and potentially recursively through the included headers) and resolve the includes to actual files based on include paths specified as part of the build configuration. Sometimes this information is cached in a .dep file or by some other mechanism. This information is then used to determine what actually needs to get built by an incremental build when a header changes. The compiler is usually passed include paths to resolve includes when invoked. The build tool need to track this just to enable minimal incremental builds.
comex 9y ago
They require manual specification of include paths, but not of what .cpp files depend on what .h files. However, at least on Unix, this is not typically done by having the build tool parse C++ files. Rather, while compiling a given .cpp file, the compiler is instructed (using -MD or other variants starting with -M) to output a .d file listing all the header files it encounters as it goes, which are then treated as dependencies. The output format is a subset of the Makefile language with just file dependencies (like “a.cpp : b.h”) rather than compilation rules; thus, anything that uses make as a backend (including autotools, cmake in that mode, etc.) can just have the Makefile ‘include’ all .d files, and make will do the right thing. (Alternative backend build tools, such as ninja, have to parse the .d files themselves, typically supporting only that subset rather than reimplementing all of make!) You don’t have them for the first compile, but that’s okay: the dependencies are only used to skip recompiling files if none of their dependencies changed. This design replaced an earlier one where the user had to manually run ‘make depend’, which would pre-scan for dependencies using a separate tool, makedepend(1). First ‘gcc -M’ was added as a straight replacement of makedepend, then -MD and variants were added to write dependency files while compiling each object file rather than requiring a separate invocation (which is slower). But it sounds like modules will complicate things, since it could be mandatory to gather dependency info upfront in order to compile modules before files that depend on them...