It seems to me the outer #ifdef works for MSVC as well. What's the extra benefit of embedding an inner #pragma once in this case? 在 2011-06-24五的 04:22 -0400，boost-request@lists.boost.org写道：
Message: 1 Date: Thu, 23 Jun 2011 21:43:02 +0000 From: "Stephan T. Lavavej" <stl@exchange.microsoft.com> To: "boost@lists.boost.org" <boost@lists.boost.org> Subject: Re: [boost] numeric_cast Message-ID:
Actually, the best thing to do is this:
#ifndef MYPROJECT_MYDIRECTORY_FOOBAR_HPP #define MYPROJECT_MYDIRECTORY_FOOBAR_HPP
#ifdef _MSC_VER #pragma once #endif // _MSC_VER
meow;
#endif // MYPROJECT_MYDIRECTORY_FOOBAR_HPP
This way, all compilers get the portable idempotency guard. Because it's on the outside, GCC (and possibly other compilers) will magically recognize it and avoid opening the header file twice. And the #pragma once for MSVC also instructs it to avoid opening the header file twice, which can improve build perf and can't hurt.
Stephan T. Lavavej Visual C++ Libraries Developer
2011/6/24 Tom Tan <ttan@husky.ca>:
It seems to me the outer #ifdef works for MSVC as well. What's the extra benefit of embedding an inner #pragma once in this case?
In case there is no pragma in header, compiler will open header file again when it is included and will parse it till include guards. If there is a pragma, compiler will not open and parse the file again. So pragma can reduce compilation time. Best regards, Antony Polukhin
On 24/06/11 11:46, Antony Polukhin wrote:
2011/6/24 Tom Tan<ttan@husky.ca>:
It seems to me the outer #ifdef works for MSVC as well. What's the extra benefit of embedding an inner #pragma once in this case?
In case there is no pragma in header, compiler will open header file again when it is included and will parse it till include guards. If there is a pragma, compiler will not open and parse the file again. So pragma can reduce compilation time.
Do you mean Visual C++ specific behaviour? Is location of #pragma relevant? Meaning, having #pragma nested in #ifndef include guard vs. placing it in outer scope, makes difference or not? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
[Mateusz Loskot]
Is location of #pragma relevant? Meaning, having #pragma nested in #ifndef include guard vs. placing it in outer scope, makes difference or not?
VC doesn't care where the #pragma once is, but as I recall, other compilers care where the #ifndef is - they prefer it to be on the outside of everything else, except comments. Stephan T. Lavavej Visual C++ Libraries Developer
On 6/27/2011 12:59 PM, Stephan T. Lavavej wrote:
[Mateusz Loskot]
Is location of #pragma relevant? Meaning, having #pragma nested in #ifndef include guard vs. placing it in outer scope, makes difference or not?
VC doesn't care where the #pragma once is, but as I recall, other compilers care where the #ifndef is - they prefer it to be on the outside of everything else, except comments.
I doubt if any compiler cares where the #ifndef ( or #if !defined ) is. It is just C++ after all and the preprocessor should handle it according to the C++ standard. It has just become conventional to write: #ifndef SOME_MACRO #define SOME_MACRO // header code #endif to include the header code just once in a translation unit. Surely compilers do not process this any differently when the #ifndef is placed at the beginning of a header file than anywhere else.
On Mon, Jun 27, 2011 at 04:42:43PM -0400, Edward Diener wrote:
On 6/27/2011 12:59 PM, Stephan T. Lavavej wrote:
[Mateusz Loskot]
Is location of #pragma relevant? Meaning, having #pragma nested in #ifndef include guard vs. placing it in outer scope, makes difference or not?
VC doesn't care where the #pragma once is, but as I recall, other compilers care where the #ifndef is - they prefer it to be on the outside of everything else, except comments.
I doubt if any compiler cares where the #ifndef ( or #if !defined ) is.
I would reckon that compilers and preprocessor implementations may have fast-paths that they go into if they detect something that looks like an include guard very early in the file, where they can cheaply reject it if already included with a minimum of work, if they guarantee correctness. After, all, it's a very common operation, it's most probably very beneficial for cutting preprocessing costs.
It is just C++ after all and the preprocessor should handle it according to the C++ standard.
As long as you have the proper semantics, optimizing such a case would be quite allowed. -- Lars Viklund | zao@acc.umu.se
On Jun 27, 2011, at 5:03 PM, Lars Viklund wrote:
On Mon, Jun 27, 2011 at 04:42:43PM -0400, Edward Diener wrote:
I doubt if any compiler cares where the #ifndef ( or #if !defined ) is.
I would reckon that compilers and preprocessor implementations may have fast-paths that they go into if they detect something that looks like an include guard very early in the file, where they can cheaply reject it if already included with a minimum of work, if they guarantee correctness.
After, all, it's a very common operation, it's most probably very beneficial for cutting preprocessing costs.
http://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html
On 6/27/2011 6:01 PM, Kim Barrett wrote:
On Jun 27, 2011, at 5:03 PM, Lars Viklund wrote:
On Mon, Jun 27, 2011 at 04:42:43PM -0400, Edward Diener wrote:
I doubt if any compiler cares where the #ifndef ( or #if !defined ) is.
I would reckon that compilers and preprocessor implementations may have fast-paths that they go into if they detect something that looks like an include guard very early in the file, where they can cheaply reject it if already included with a minimum of work, if they guarantee correctness.
After, all, it's a very common operation, it's most probably very beneficial for cutting preprocessing costs.
http://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html
I stand corrected.
On 27/06/11 21:42, Edward Diener wrote:
On 6/27/2011 12:59 PM, Stephan T. Lavavej wrote:
[Mateusz Loskot]
Is location of #pragma relevant? Meaning, having #pragma nested in #ifndef include guard vs. placing it in outer scope, makes difference or not?
VC doesn't care where the #pragma once is, but as I recall, other compilers care where the #ifndef is - they prefer it to be on the outside of everything else, except comments.
I doubt if any compiler cares where the #ifndef ( or #if !defined ) is. It is just C++ after all and the preprocessor should handle it according to the C++ standard. It has just become conventional to write:
#ifndef SOME_MACRO #define SOME_MACRO
// header code
#endif
My question was if related to #pragma once specifically and previous comments on why to use it together with include guards. So, I asked if Visual C++ handles these two in the same or different manner: 1) #ifndef SOME_MACRO #define SOME_MACRO #pragma once // header code #endif 2) #pragma once #ifndef SOME_MACRO #define SOME_MACRO // header code #endif Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
participants (7)
-
Antony Polukhin -
Edward Diener -
Kim Barrett -
Lars Viklund -
Mateusz Loskot -
Stephan T. Lavavej -
Tom Tan