Re: [boost] "boost cold shoulder" (was proposal for #pragmaoncesupport)

Subject: Re: [boost] "boost cold shoulder" (was proposal for #pragmaoncesupport)
From: Christopher Jefferson (chris_at_[hidden])
Date: 2009-06-11 15:18:05

On 11 Jun 2009, at 19:53, Peter Bindels wrote:

> 2009/6/11 Sid Sacek <ssacek_at_[hidden]>
>
>>> Your forgetting about the natural impulse to not want to clutter the
>>> code with unnecessary workarounds.  Make no mistake, that's all it  
>>> is,
>>> since #pragma once is the wrong feature to add to a compiler if you
>>> want to speed up header inclusion.
>>>
>>> It might be acceptable in proprietary code that never moves  
>>> outside of
>>> Windows, but since Boost will still have to have normal include
>>> guards, #pragma once is just noise, semantically.
>> <snip>
>> I think you can figure out what that means in compiler terms. But  
>> since
>> that is not possible at this point in time, a compromise should be  
>> made; one
>> that respects both Microsoft compiler users, and the non-Microsoft  
>> compiler
>> users. I don't believe that Microsoft has the only compiler that  
>> improves
>> its compile-times using #pragma once. So other compilers can also  
>> benefit
>> from the #pragma usage as well. My personal experience with large  
>> projects
>> is that #pragma once cuts the build time by 26%. Every little bit  
>> counts
>> when you're working on very large applications.
>>
>
> A compiler that has a choice between #pragma once or #ifdef XXXXX  
> should see
> that excluding parsing of the header could be done exactly the same  
> on both,
> with the difference that the pragma is not generally supported and
> nonstandard. Any portable code will have to include the latter,  
> making the
> first one completely pointless. Any speed benefit it gets you is the
> compiler builder not doing his/her job.

Except it's a little trickier than that, as the compiler has to  
remember the guard, as it could get undefined in another file.

Also, in C++ we have to be pragmatic. boost has huge amounts of  
infrastructure dedicated to get around quirks in different versions of  
different compilers.

The real question is, will it improve real code? I suspect it might  
not, as I don't think compiling boost is slow because of opening  
files, it's slow because compilers have to chew their way through huge  
numbers of templates. Of course, real numbers are the only answer to  
this.

Chris