Home » Blog » 2012 » December » Modules update video available -- Doug Gregor

Modules update video available -- Doug Gregor

By Blog Staff | Dec 5, 2012 12:43 PM | Tags: experimental advanced

MP4 video of Doug Gregor's talk on Modules is now available via llvm.org. Combining links here:

Modules (MP4 video) (PDF slides)

Doug Gregor - Apple

The C preprocessor has long been a source of problems for programmers and tools alike.

Programmers must contend with widespread macro pollution and #include-ordering problems due to ill-behaved headers. Developers habitually employ various preprocessor workarounds, such as LONG_MACRO_PREFIXES, #include guards, and the occasional #undef of a library macro to mitigate these problems.

Tools, on the other hand, must cope with the inherent scalability problems associated with parsing the same headers repeatedly, because each different preprocessing context could effect how a header is interpreted – even though the programmer rarely wants it.

Modules seeks to solve this problem by isolating the interface of a particular library and compiling it (once) into an efficient, serialized representation that can be efficiently imported whenever that library is used, improving both the programmer’s experience and the scalability of the compilation process.

 

Add a Comment

Comments are closed.

Comments (1)

0 0

Sektor said on Dec 7, 2012 07:18 AM:

For a good module system, please take a look at Tcl modules (added in version 8.5). There are several important things to consider, I think:

1. This must be a module system not only for system modules, but also for users, so that they can create and distribute their modules. It means that this system, I think, must have:
- easy way to create it and prepare a distribuable single file (Tcl modules consist of one *.tm file that is just "sourced", and the interpreter must just know the search path to find it)
- module versioning (Tcl modules just use the existing package system)
- namespace transparency (Although Tcl modules can have "paths", these have nothing to do with namespaces)
- easy way for transition from #include + *.a/*.so
- module parameters (actually Tcl module system doesn't have anything like that, however you can do it merely similar way as with #include/#define: set some variables to some values before "package require" instruction, and the code in the module file will pick them up and do some conditional things) - important thing for module parameters is also to detect the situation of using one module with different parameters in two source files linked together; the linker should fail in this case (I actually mean the situation that happens today when you compile with -DSOME_FLAG=1 in one file and -DSOME_FLAG=2 in the other)

Also one of the important problems to solve is the problem of dynamic libraries; most likely C++ will have to have its own, more-less system independent dynamic module loading system, which will be also capable of instatiating templates when doing dynamic linking.

Currently C++ is just "reusing" the C module system; the new module system doesn't have to continue using them. It just must somehow compose together with the rest of the system, so it may be that it will be using them at least partially (also in order to be able to make use of existing C libraries). These things on lower level are strictly system dependent; the new module system for C++ must provide a _portable_ way of defining the module contents, while still dealing with system-related things (for example, showing which library the module user should link to).