Hi! > > > (a) the traditional include guard optimization HAS NO HIDDEN SEMANTIC > > > MEANING. It's a pure optimization that doesn't actually change > > > anything else. If you don't do the optimization, absolutely nothing > > > changes. > > > > And if the parser is well written the optimisation is probably > > irrelevant compared to the compile time. > > That's actually surprisingly not even remotely true. > > People always think that the optimization phases of a compiler are the > expensive ones. And yes, there are certain optimizations that can be > *really* expensive, and people just don't even do them because they > are _so_ expensive and are exponential in time. Well, linux kernel can be compiled in two _seconds_ if you take compiler optimized for fast parsing... and quick code generation. See "SUSE Labs Conference 2018 - Compiling the Linux kernel in a second (give or take)" on youtube. So yes, gcc's frontend may be slow, but that does not mean job can not be done quickly by suitable compiler. Best regards, Pavel -- http://www.livejournal.com/~pavelmachek
Attachment:
signature.asc
Description: Digital signature
