#pragma

uunet!ai.mit.edu!rms uunet!ai.mit.edu!rms
Mon Aug 13 14:33:12 PDT 1990


Because #pragma was put forward as a mechanism for extending C in
various ways, people are constantly tempted to use it.  It is best to
resist the temptation, because #pragma is a very bad solution to most
problems.

The reason it is bad is that it cannot be used inside a macro
expansion.  Nearly anything useful is useful inside macro definitions
as well as outside.  Therefore, nearly anything useful should not be
done with #pragma.  It is much better to define an extension that is
"forbidden" by ANSI C but is clean design.

Some people think that #pragma must be better because the ANSI
standard makes provisions for it.  If you look at the practical
advantages and disadvantages, it turns out that this makes no
difference.

Consider: a #pragma that changes the semantics of a program will be
implemented only by certain compilers.  The program will work
incorrectly on other ANSI C systems.

By contrast, a non-standard extension of another sort will be
implemented only by certain compilers.  The program will work
incorrectly on other ANSI C systems.

Where is the practical advantage for #pragma?

#pragma is superior in one way: it enables the implementor to state
that the implementation conforms to the standard.  In a useless way,
of course, since the implementation is nonetheless incompatible with
others.  And in no circumstance is it more useful to a user than the
alternative compiler which does not conform.  People concerned with
practical use will not care about this difference.

However, sometimes there are users who care about official labels
rather than practicalities.  If you are forced to try to please such
people, you can do it by defining an option to disable the new
extension.  Then the compiler will conform when the option is used.




More information about the Numeric-interest mailing list