Incredibuild (xoreax) and other parallel compilation systems have problems with pragma once
Graham wrote:
Incredibuild (xoreax) and other parallel compilation systems have problems with pragma once
Thanks, Graham! (We're using IncrediBuild very much, at LKEB.) Now I see, it's at their FAQ: "When a source file includes one or more header files that are also included by the precompiled header and use the '#pragma once' directive, these header files may be #included more than once despite the #pragma once directive" http://xoreax.com/support_faq.htm#q122 Bo Persson wrote:
The #pragma once depends on the compiler being able to correctly parse the include paths for all possibly attached file systems. If it fails, it might include the same file twice from seemingly different paths.
I guess that's what typically might go wrong when using IncrediBuild, or other parallel compilation systems. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
Niels Dekker - address until 2010-10-10 wrote:
Graham wrote:
Incredibuild (xoreax) and other parallel compilation systems have problems with pragma once
Thanks, Graham! (We're using IncrediBuild very much, at LKEB.) Now I see, it's at their FAQ: "When a source file includes one or more header files that are also included by the precompiled header and use the '#pragma once' directive, these header files may be #included more than once despite the #pragma once directive" http://xoreax.com/support_faq.htm#q122
Bo Persson wrote:
The #pragma once depends on the compiler being able to correctly parse the include paths for all possibly attached file systems. If it fails, it might include the same file twice from seemingly different paths.
I guess that's what typically might go wrong when using IncrediBuild, or other parallel compilation systems.
Kind regards, Niels
You've clipped a lot of caveats there. To stop this over-generalization from propagating here's the full FAQ entry: Q: I'm getting the following warning: "File includes the following header files that are also included by the precompiled header, and use the '#pragma once' directive. This may cause interoperability problems when using IncrediBuild to build the precompiled-header and MSVC to build source files that use it, or vice versa. Refer to the FAQ section in the documentation for more details and possible workarounds." What's wrong? A: When a source file includes one or more header files that are also included by the precompiled header and use the '#pragma once' directive, these header files may be #included more than once despite the #pragma once directive. This will happen only in .NET builds, in one of the following 2 scenarios: 1. When the PCH was compiled using IncrediBuild and the source files compiled without IncrediBuild. 2. When the PCH was compiled without IncrediBuild and the source files compiled using IncrediBuild. There are 2 possible workarounds for this issue: 1. Remove the explicit #include directive for these header files from cpp files that use the PCH (the file will be included through the PCH). 2. Replace the #pragma once directive in the header file with the following preprocessor code: #ifndef __HEADER_NAME__ #define __HEADER_NAME__ <header file contents>
Incredibuild (xoreax) and other parallel compilation systems have
[ Graham wrote: ] problems with pragma once I'm not sure what the "problems with pragma once" are by Graham's statement above. So far, I have heard that #pragma once doesn't work right on some platforms. That tells me the programmer cannot rely on it, but that doesn't indicate that it cannot be used in the program. What is clear is that #pragma once works on some platforms. Also, for the platforms that it doesn't work on, the use of #ifndef is absolutely required. Boost is a cross-platform library, so that means cross-platform programs needs to look something like this: #ifndef HEADER_FILE_GUARD #define HEADER_FILE_GUARD #pragma once If the above code gives a pragma warning, the warning can be turned off or simply be ignored. I have not yet heard any objections for the above code. If that's still not good enough for every compiler that's out there, the variation below - which was already proposed to boost - should be good enough. Each platform can decide what to do with their version of the BOOST_ONCE macro. #ifndef HEADER_FILE_GUARD #define HEADER_FILE_GUARD #pragma BOOST_ONCE I'm starting to feel like the people in charge of the boost libraries aren't even listening in on this conversation. I would like to hear some opinions and some votes about the above code, especially opinions from the boost heavy-weights. I need to know I'm not just wasting everybody's time here. If something like the above code was acceptable to the boost custodians, I would be happy to make the appropriate changes myself. I realize that this topic has already been discussed for the C++ language in general and, for the most part, has been ignored. However, I'm going to add a twist to the pragma-once statement that was never brought up in discussion. What should solve all of the issues concerning the header guards is the following variation to #pragma once: #pragma once( HEADER_FILE_GUARD ) The above line of code includes both the pragma-once statement, but is also protected by the unique HEADER_FILE_GUARD token. Its meaning is clear and concise. This implies that the #ifndef, #define, and #endif are no longer required, and satisfies everybody's compiling needs. It would be great if the current preprocessor could be used to implement that, but I don't think it can. The current existing alternative within the boost code is just plain hideous. Just to remind you all, here it is one more time: #ifndef __BOOST_HEADER_GUARD__ #define __BOOST_HEADER_GUARD__ #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Sincerely, -Sid Sacek
Sid Sacek wrote:
Incredibuild (xoreax) and other parallel compilation systems have
[ Graham wrote: ] problems with pragma once
I'm not sure what the "problems with pragma once" are by Graham's statement above.
So far, I have heard that #pragma once doesn't work right on some platforms. That tells me the programmer cannot rely on it, but that doesn't indicate that it cannot be used in the program.
#if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif
The thing is that it works for "platforms" where _MSC_VER is 1020, or somewhat higher than that. On platforms where _MSC_VER isn't defined, or where its value is significally higher that 1020, the include guards work just as well. How much effort should we put into potentially optimizing compile time for some ancient compilers? Bo Persson
On Mon, Apr 13, 2009 at 2:22 PM, Bo Persson <bop@gmb.dk> wrote:
Sid Sacek wrote:
Incredibuild (xoreax) and other parallel compilation systems have
[ Graham wrote: ] problems with pragma once
I'm not sure what the "problems with pragma once" are by Graham's statement above.
So far, I have heard that #pragma once doesn't work right on some platforms. That tells me the programmer cannot rely on it, but that doesn't indicate that it cannot be used in the program.
#if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif
The thing is that it works for "platforms" where _MSC_VER is 1020, or somewhat higher than that. On platforms where _MSC_VER isn't defined, or where its value is significally higher that 1020, the include guards work just as well.
How much effort should we put into potentially optimizing compile time for some ancient compilers?
To answer this question, you must first measure the reduction in compile time you get for those ancient compilers. If nobody cares to do this, then it's a non-issue. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
The silence about this topic is deafening. Ouch! I did offer to do any work that would be involved... But I guess I'm to assume the boost mediators don't care about this topic in the slightest and would prefer me to drop it. If you guys change your minds down the road, I'll still be available to do any work involved. Regards, -Sid Sacek
Sid Sacek wrote:
The silence about this topic is deafening. Ouch!
I did offer to do any work that would be involved... But I guess I'm to assume the boost mediators don't care about this topic in the slightest and would prefer me to drop it.
If you guys change your minds down the road, I'll still be available to do any work involved.
If you could post some benchmark numbers showing an obvious benefit, along with a patch or two, I'm sure there will be response. :) Cheers, /Marcus
Sid Sacek wrote:
The silence about this topic is deafening. Ouch!
I did offer to do any work that would be involved... But I guess I'm to assume the boost mediators don't care about this topic in the slightest and would prefer me to drop it.
If you guys change your minds down the road, I'll still be available to do any work involved.
Regards, -Sid Sacek
Let me make a guess (or two): - A lot of people might have been celebrating the Easter holiday for the last couple of days. :-) - The latest versions of the most widely used compilers don't benefit from the change. Bo Persson
participants (7)
-
Bo Persson -
Emil Dotchevski -
Graham -
Jeff Flinn -
Marcus Lindblom -
Niels Dekker - address until 2010-10-10 -
Sid Sacek