3 ms·
That's incorrect. Optimizing the guard macros works in all cases as long as you use the standard pattern and the C Preprocessor memorizes the name of the guard
by cjensen 14y ago
That's incorrect. Optimizing the guard macros works in all cases as long as you use the standard pattern and the C Preprocessor memorizes the name of the guard macro.
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- jlgreco 14y agoHow does this happen then? "The construction of a single C++ binary at Google can open and read hundreds of individual header files tens of thousands of times."
- cjensen 14y agoAn excellent question which deserved an answer in the paper.
- deleted 14y ago[deleted]
- georgemcbay 14y agoWalter Bright (who created D to solve some of the same problems Go aims to solve) wrote something a few years back which touches on this topic: http://www.drdobbs.com/cpp/c-compilation-speed/228701711 http://www.drdobbs.com/cpp/c-compilation-speed/228701711
- JulianMorrison 14y agoOff hand, I can imagine problems with: multiple guarded blocks at the top level, things outside guards, things that look like guards but aren't (#IFDEF conditional sections, perhaps), things that don't look like guards that are, things that affect which guards are switched on in a dynamic way (detect a feature and enable a lib)... Some of those could be non issues. There could be other issues I lack the experience to guess. It's no use saying "so don't do that" - not all code is under your control. Honestly if it were simple, it would be solved.
- cjensen 14y agoAs I mentioned, the cpp needs to recognize the standard pattern and act on it. If you have multiple guards at the top level, you are trying to do something clever which cannot be optimized -- and also cannot be expressed in Go.
- agentS 14y agoYou mean it cannot be expressed using Go's (non-existent) preprocessor. I am relatively confident that you'd be able to express it in Go (perhaps sacrificing speed, in the process).