CODEWITHSUNDEEP
c++pragmainclude-guards
thb
thb

Reputation: 14454

Since other abusable but useful features have been standardized, why not #pragma once?

The nonstandard #pragma once feature is implemented on practically all C++ compilers, but the C++ standard excludes it.

The usual explanation of why #pragma once, or some language construct that does what #pragma once does, has been excluded from the C++ standard is that hard links and copied header files either break #pragma once or provoke the compiler to heuristics. Fair enough, heuristics are normally incompatible with the C++ philosophy anyway, but regarding plain breakage: there are many useful language features you can break, not only #pragma once. The normal C++ way to manage such breakage is to let the compiler issue an optional warning in doubtful instances. After all, C++ is purposely designed to let one program unsafely and/or unportably when one wishes to do so. Besides, the unsafety and/or unportability of #pragma once is pretty minimal. It just isn't that easy to abuse.

Why is #pragma once excluded from the standard when other abusable but useful language features are typically included? Is there something special about #pragma once?

Also, where can one read the recent deliberations of the standards committee in the matter? Has some committee member, or committee follower, published a recent summary of the debate?

Upvotes: 3

Views: 175

Answers (2)

Dietmar Kühl
Dietmar Kühl

Reputation: 153955

There are a few simple reasons:

  1. It is harder than generally assumed to implement and specify it. The argument that it is implemented doesn't hold much water as the implementations generally do not deal with approaches to subvert the feature.
  2. Committee time is much more reasonably spent on working on modules which make most of the preprocessor unnecessary than trying to improve something we want to get rid of.
  3. There is a simple work-around around (include guards) for the absence of #pragma once, i.e., it isn't considered a problem.
  4. It seems, existing implementations actually do behave different which seems to be the root of one of the recent discussions. Of course, this means that standardization would be good but then it immediately starts conflicting with 2. and the discussions won't be simple because different parties would want their respective behavior to be retained.
  5. I didn't do a too thorough search but I didn't see a proposal, either: if nobody writes a proposal [and lobbies it through the process] nothing will be standardized. That said, I'd fully expect the reasons given above to stop a proposal to add #pragma once have a sufficient majority for it to be stopped quite quickly.

There was a recent discussion on the proposals mailing list (see isocpp.org for how to sign up; I can't get to this site at the moment, though). I didn't follow it too thoroughly, though. Quickly browsing over it I saw the four reasons given above (the forth I added after browsing).

Here are some references from the recent mailing list discussion:

  1. Is #pragma once part of the standard?
  2. Why isn't C/C++s #pragma once standard?
  3. modules proposal

Upvotes: 3

gmas80
gmas80

Reputation: 1268

From my understanding, #pragma once is an implementation specific instance of the standard #pragma directive as described in Section §16.6 of the Standard (draft):

16.6 Pragma directive [cpp.pragma]

A preprocessing directive of the form

# pragma pp-tokens opt new-line causes the implementation to behave in an implementation- defined manner. The behavior might cause translation to fail or cause the translator or the resulting program to behave in a non-conforming manner. Any pragma that is not recognized by the implementation is ignored.

Having pragma once standardized would introduce quite a bit of complexity. Give also a look here: https://stackoverflow.com/a/1696194/2741329

Upvotes: 2

Related Questions