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