Re: [boost] [#pragma once]

Subject: Re: [boost] [#pragma once]
From: Sid Sacek (ssacek_at_[hidden])
Date: 2009-04-10 19:53:11

>> ... the #pragma which can do anything at all...
>> Emil Dotchevski

Really? Describe two things that #pragma-once can do?

I can think of only one.

------------------------------------------------------------------------
----------------

Look, large builds take major advantage of the capability of the
#pragma-once statement.
I added the #pragma-once to my company's builds and shaved off %26 from
the build time.
That's pretty significant within large builds. Along with precompiled
headers, the #pragma-
once feature is a very cool thing to have on your side.

In fact, this feature is so cool that its capability was added to the
#ifdef header guards
in some compilers. But that to me is the wrong way to go because it
makes the #ifdef non-
standard. Remember that #define can be un-defined, and then what exactly
does the header
guard do in that case?

#ifndef __BOOST_HEADER_GUARD__
#define __BOOST_HEADER_GUARD__    // this macro can be undefined
#pragma once                      // the pragma-once cannot be turned
off

I'm not going to split hairs over what compilers do with their #define
header-guards, but
the point is that this cool feature is being used by loads of major C++
compilers. In every
case the compiler treats the #pragma-once in exactly the same way.

This is how standards come to be in future versions of products.
shared_ptr<> was a boost
thing and now it's a C++0x thing. The same thing appears to be happening
with #pragma-once
in an undocumented way because it's way too cool.

I mean take a look at this ugly code below:

     #ifndef __BOOST_HEADER_GUARD__
     #define __BOOST_HEADER_GUARD__

     #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 )
     # pragma once
     #endif

First off, it's just plain ugly. It's also error prone since it's got to
be typed in exactly,
but most important, it implies that no compiler other than Microsoft can
take advantage of the
#pragma-once capabilities of our modern day compilers.

Boost libraries are constantly being cleaned up by deprecating stuff no
longer needed, and this
is one those things that needs to be deprecated, even though it's a very
minor thing.

I would be more than happy to perform the deprecation work.

Regards,
-Sid Sacek