3 ms·

you have completely missed my point. i know full well how much time is spent parsing these things and how the mechanism works - i don't believe this proposal wi

by jheriko 14y ago

you have completely missed my point. i know full well how much time is spent parsing these things and how the mechanism works - i don't believe this proposal will actually improve that. i also don't believe your answers address the point i was trying to make either... namely that whatever preprocessed import module thing is created, it still has to be included into the compilation unit somehow... even if there is some kind of linkage type solution going on with a lightweight interface - that feels functionally equivalent to what most of the standard library headers already are - so i don't understand what could possibly be that much faster or better about it. not to mention that this is not a problem if you encapsulate your use of standard libraries properly... maybe 10-20 compilation units have to use it if you like to split your stuff into files a lot. standard headers are poorly written/designed by including so much crap everywhere. why can't i have specific - per function headers which include minimal stuff? fix the headers, not the preprocessor.

msbarnett 14y ago
> i know full well how much time is spent parsing these things and how the mechanism works - i don't believe this proposal will actually improve that. Well, then you're pretty much 100% wrong in most C++ projects. I honestly don't know what to tell you here. That persisting header ASTs between translation units is faster than re-parsing should be trivially obvious, and if it isn't trivially obvious, then the mere fact that precompiled headers and ccache dramatically speeds up builds ought to make it empirically obvious. The facts just aren't on your side. > namely that whatever preprocessed import module thing is created, it still has to be included into the compilation unit somehow Well, yes, obviously. In the current model the compiler slurps the header into the source file, and parse the entire combination, resulting in the parse tree of the header + the parse tree of the rest of the file. In the proposed model the compiler pulls the parse tree of the header out of cache and just builds the parse tree of the file. Since in C++ header parse trees are often quite expensive to build (since template declarations have to live in the headers and their parse trees are incredibly expensive to build), this ought to be a blindingly obvious win.

by jheriko 14y ago

msbarnett 14y ago

> i know full well how much time is spent parsing these things and how the mechanism works - i don't believe this proposal will actually improve that. Well, then you're pretty much 100% wrong in most C++ projects. I honestly don't know what to tell you here. That persisting header ASTs between translation units is faster than re-parsing should be trivially obvious, and if it isn't trivially obvious, then the mere fact that precompiled headers and ccache dramatically speeds up builds ought to make it empirically obvious. The facts just aren't on your side. > namely that whatever preprocessed import module thing is created, it still has to be included into the compilation unit somehow Well, yes, obviously. In the current model the compiler slurps the header into the source file, and parse the entire combination, resulting in the parse tree of the header + the parse tree of the rest of the file. In the proposed model the compiler pulls the parse tree of the header out of cache and just builds the parse tree of the file. Since in C++ header parse trees are often quite expensive to build (since template declarations have to live in the headers and their parse trees are incredibly expensive to build), this ought to be a blindingly obvious win.