Anyone know where I can read more detail about this proposal? It looks really interesting, but there are a couple of things I'm not clear on from the pdf:
How do you get away from creating a header file for a closed source module? Without a header, how would users of your module know what they can call? Can you perform reflection on a module to inspect it? Is there some kind of tool proposed, like javadoc or pydoc, to generate documentation for a module?
How does this work with C++ templates? If you don't know in advance what types the template will be instantiated with, how can you pre-compile the code?
I'm sure the authors have thought through all these issues and more; I'd love to read about their solutions.
I know nothing about this proposal, but I can make educated guesses on all of these:
Creating header: the module needs only the public information for a closed source module. You could generate it from a .h file if you are a consumer of a closed source module, or if you are the producer of the module, you could potentially ship either pre-generated modules or all the information needed to generate a module.
javadoc, etc. It sounds like you could generate the information directly from the C/C++ source since there is now information about what is public and private in the source
Compiling this:
template <typename Type>
Type max(Type a, Type b) {
return a > b ? a : b;
}
Generates no code, but it does some work in the compiler that can be cached. This is what would be stored in the module.
Thanks, I think you're probably right - the modules would have to have enough information in their compiled form that your compiler could introspect them without needing the source. The proposal wouldn't be much use if that weren't true.
Re: templates, I thought the expensive part of template processing was code generation rather than parsing. Would caching the AST really be that much of a saving? I admit I've never tried profiling it to find out...
Your first stop should be the latest revision of the proposal by Vandevoorde [1]. He also presented the paper at C++Now! [2].
Do answer some of your questions: Instead of compiling directly to object files/libraries and distributing headers with them, you will be able to distribute modules files. Those will be preprocessed and already be transformed to some vendor specific format.
Templates require some (actually a lot) processing before they can be instantiated. This can be done without knowing any of the types used for instantiation and this can be used to speed-up compilation.
It looks like the old #include style will still be available where you can't use packages, and it seemed to me that you only needed the .h files for the generation of the modules, not the source .c files.
How do you get away from creating a header file for a closed source module? Without a header, how would users of your module know what they can call? Can you perform reflection on a module to inspect it? Is there some kind of tool proposed, like javadoc or pydoc, to generate documentation for a module?
How does this work with C++ templates? If you don't know in advance what types the template will be instantiated with, how can you pre-compile the code?
I'm sure the authors have thought through all these issues and more; I'd love to read about their solutions.