Topic: #define a #pragma?


Author: kaih=7NRQ$K$Hw-B@khms.westfalen.de (Kai Henningsen)
Date: 1999/08/23
Raw View
geoffk@discus.anu.edu.au (Geoffrey KEATING)  wrote on 20.08.99 in <t8so5fhz51.fsf@discus.anu.edu.au>:

> David R Tribble <david@tribble.com> writes:
>
> > (Q. Does gcc use pragmas, and if so, does it use '#pragma GNU ...'?
> > I know that Stallman despised pragmas, a least as of a few years
> > ago, so I doubt that gcc does this.)
>
> It does use pragmas, and it doesn't have any #pragma GNU pragmas.
>
> Most of the pragmas it implements are for compatibility with other C
> compilers, so the spelling used is the same as in the other compiler.

And the docs argue that __attribute__((something)) is a far superior way
of doing things. (Why does this look a lot like _Pragma?)

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: David R Tribble <david@tribble.com>
Date: 1999/08/24
Raw View
Geoffrey KEATING wrote:
>
> David R Tribble <david@tribble.com> writes:
>
> > (Q. Does gcc use pragmas, and if so, does it use '#pragma GNU ...'?
> > I know that Stallman despised pragmas, a least as of a few years
> > ago, so I doubt that gcc does this.)
>
> It does use pragmas, and it doesn't have any #pragma GNU pragmas.
>
> Most of the pragmas it implements are for compatibility with other C
> compilers, so the spelling used is the same as in the other compiler.

What about all those gcc command line options - can they be coded as
#pragmas?  If so, why not spell them '#pragma GNU ...'?  At least
gcc wouldn't be stepping on any other vendor's toes.

-- David R. Tribble, david@tribble.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Geoffrey KEATING <geoffk@discus.anu.edu.au>
Date: 1999/08/20
Raw View
David R Tribble <david@tribble.com> writes:

> (Q. Does gcc use pragmas, and if so, does it use '#pragma GNU ...'?
> I know that Stallman despised pragmas, a least as of a few years
> ago, so I doubt that gcc does this.)

It does use pragmas, and it doesn't have any #pragma GNU pragmas.

Most of the pragmas it implements are for compatibility with other C
compilers, so the spelling used is the same as in the other compiler.

--
Geoff Keating <Geoff.Keating@anu.edu.au>


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1999/08/16
Raw View
eggert@twinsun.com (Paul Eggert) writes:

>David R Tribble <david@tribble.com> writes:
>
>>(Q. Does gcc use pragmas, and if so, does it use '#pragma GNU ...'?
>>I know that Stallman despised pragmas, a least as of a few years
>>ago, so I doubt that gcc does this.)
>
>GCC does not use #pragma GNU.
>
>I believe Stallman disliked #pragma because it couldn't be the output
>of macros.  The C9x committee attacked this problem with _Pragma.
>Unfortunately, _Pragma has its own problems.

Namely?

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: nmm1@cus.cam.ac.uk (Nick Maclaren)
Date: 1999/08/16
Raw View
In article <7p8aie$c4t$1@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
>
>eggert@twinsun.com (Paul Eggert) writes:
>
>>David R Tribble <david@tribble.com> writes:
>>
>>>(Q. Does gcc use pragmas, and if so, does it use '#pragma GNU ...'?
>>>I know that Stallman despised pragmas, a least as of a few years
>>>ago, so I doubt that gcc does this.)
>>
>>GCC does not use #pragma GNU.
>>
>>I believe Stallman disliked #pragma because it couldn't be the output
>>of macros.  The C9x committee attacked this problem with _Pragma.
>>Unfortunately, _Pragma has its own problems.
>
>Namely?

123456789 * _Pragma("ignore overflow in the preprocessor") * 123456789 \
    * 123456789 * 123456789 * 123456789

And so on.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: eggert@twinsun.com (Paul Eggert)
Date: 1999/08/16
Raw View
fjh@cs.mu.OZ.AU (Fergus Henderson) writes:

>eggert@twinsun.com (Paul Eggert) writes:
>>I believe Stallman disliked #pragma because it couldn't be the output
>>of macros.  The C9x committee attacked this problem with _Pragma.
>>Unfortunately, _Pragma has its own problems.

>Namely?

Sorry, I don't have time to go into it right now.  Perhaps later.
_Pragma does not invalidate existing software, so its defects are lower
priority.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: eggert@twinsun.com (Paul Eggert)
Date: 1999/08/13
Raw View
David R Tribble <david@tribble.com> writes:

>(Q. Does gcc use pragmas, and if so, does it use '#pragma GNU ...'?
>I know that Stallman despised pragmas, a least as of a few years
>ago, so I doubt that gcc does this.)

GCC does not use #pragma GNU.

I believe Stallman disliked #pragma because it couldn't be the output
of macros.  The C9x committee attacked this problem with _Pragma.
Unfortunately, _Pragma has its own problems.  I don't know whether
Stallman knows about _Pragma, or whether he has an opinion about it.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: David R Tribble <david@tribble.com>
Date: 1999/08/13
Raw View
Jerry Leichter wrote:
>
>| Here's how to achieve the desired effect [a conditionally-include
>| pragma]
>|
>| whatever.h:
>|     #if defined some_compiler_name
>|          #pragma vendor specific pragma
>|     #else
>|          #pragma different vendor pragma
>|     #endif
>
> Unfortunately, there are plenty of compilers out there that will issue
> a warning about unknown pragmas even if they appear in ifdef'ed out
> code.  While this doesn't prevent compilation, it can be annoying
> (you can lose warnings you wanted to see among the resulting bunch
> of useless stuff) and may not fit in with "must compile clean"
> policies for some projects.

The draft C (C9X) standard defines the pragma "namespace" STDC to be
reserved for ISO, e.g., '#pragma STDC xxx'.  It would have been nice
if vendors had adopted a similar "namespacing" approach for pragmas,
so that each vendor staked out its own name, e.g.,
'#pragma VENDOR xxx'.  (It would be nice if C9X recommended this
kind of practice, too.)

Alas, this is typically not the case, so we're stuck with the
pragma name collision problem for a while, perhaps forever.

(Q. Does gcc use pragmas, and if so, does it use '#pragma GNU ...'?
I know that Stallman despised pragmas, a least as of a few years
ago, so I doubt that gcc does this.)

[Originally from news:comp.std.c++, cross-posted to news:comp.std.c.
-drt]

-- David R. Tribble, david@tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Jerry Leichter <jerrold.leichter@smarts.com>
Date: 1999/08/07
Raw View
| Here's how to achieve the desired effect [a conditionally-include
| pragma]
|
| whatever.h:
|         #if defined some_compiler_name
|                 #pragma vendor specific pragma
|         #else
|                 #pragma different vendor pragma
|         #endif

Unfortunately, there are plenty of compilers out there that will issue a
warning about unknown pragmas even if they appear in ifdef'ed out code.
While this doesn't prevent compilation, it can be annoying (you can lose
warnings you wanted to see among the resulting bunch of useless stuff)
and may not fit in with "must compile clean" policies for some projects.

One thing that *will* work for all compilers - though it requires more
effort to set up and maintain - is:

 #if defined(compiler_name_A)
 #include "compiler_A_pragmas.h"
 #elif defined(compiler_name_B)
 #include "compiler_B_pragmas.h"
 ...
 #endif

Each compiler_x_pragmas.h file contains just the pragmas that are
appropriate to the x compiler.  (It's possible - and sometimes
necessary, though it's better to look for some way to avoid the issue)
to define some macros *before* this #if nest that act as "arguments" to
the compiler_x_pragmas file.  For example, you might define a macro
names NEED_PACKED_STRUCTS and then let the compiler_x_pragma.x file test
it and insert the compiler x pragma that says structs should be packed.

You can go even further and eliminate the #if nest completely:  Use just
#include "compiler_pragmas.h".  Then have your build environment select
the right compiler_pragmas.h file by setting the include path (using -I
for Unix compilers) to point to a compiler-dependent directory.  It's
possible to build code with no visible system dependencies at all this
way - a major improvement over piles of #ifdef's.  But it does take
quite a bit of discipline and work.
       -- Jerry
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: postmast.root.admi.gov@iname.com (blargg)
Date: 1999/08/07
Raw View
In article <37AB268D.4605@smarts.com>, Jerry Leichter
<jerrold.leichter@smarts.com> wrote:

> | Here's how to achieve the desired effect [a conditionally-include
> | pragma]
> |
> | whatever.h:
> |         #if defined some_compiler_name
> |                 #pragma vendor specific pragma
> |         #else
> |                 #pragma different vendor pragma
> |         #endif
>
> Unfortunately, there are plenty of compilers out there that will issue a
> warning about unknown pragmas even if they appear in ifdef'ed out code.
> While this doesn't prevent compilation, it can be annoying (you can lose
> warnings you wanted to see among the resulting bunch of useless stuff)
> and may not fit in with "must compile clean" policies for some projects.
>
> One thing that *will* work for all compilers - though it requires more
> effort to set up and maintain - is:
>
>         #if defined(compiler_name_A)
>         #include "compiler_A_pragmas.h"
>         #elif defined(compiler_name_B)
>         #include "compiler_B_pragmas.h"
>         ...
>         #endif

Except if the #pragma affects the current file (as #pragma once would do).
In this case, one can do the above.

For this case, in a common include file I have this:

    #if __COMPILER_A // vendor-defined macro
        #define pragma_include_once once
    #elif __COMPILER_B
        #define pragma_include_once
        // nothing - compiler doesn't support once
    #endif

This way, if the compiler doesn't support the pragma, I can #define it to
some pragma (or nothing, as above) that has no effect. Then, in header
files I use it like this:

    #pragma pragma_include_once

Anyone know of any compilers that *don't* expand preprocessor macros used
in #pragmas before processing the #pragma? This has worked on the few
compilers I've tried it on.

> Each compiler_x_pragmas.h file contains just the pragmas that are
> appropriate to the x compiler.  (It's possible - and sometimes
> necessary, though it's better to look for some way to avoid the issue)
> to define some macros *before* this #if nest that act as "arguments" to
> the compiler_x_pragmas file.  For example, you might define a macro
> names NEED_PACKED_STRUCTS and then let the compiler_x_pragma.x file test
> it and insert the compiler x pragma that says structs should be packed.
>
> You can go even further and eliminate the #if nest completely:  Use just
> #include "compiler_pragmas.h".  Then have your build environment select
> the right compiler_pragmas.h file by setting the include path (using -I
> for Unix compilers) to point to a compiler-dependent directory.  It's
> possible to build code with no visible system dependencies at all this
> way - a major improvement over piles of #ifdef's.  But it does take
> quite a bit of discipline and work.

Actually, I have multiple include files:

    optimizations_on.h
    optimizations_reset.h

    profiler_off.h
    profiler_reset.h

    interrupt_func_begin.h
    interrupt_func_end.h

    etc.

// optimizations_on.h:

    // note: *no* include guard!

    #if __COMPILER_A
        #pragma optimizer ...
    #elif __COMPILER_B
        // ...
    #endif

// user code

    #include "optimizations_on.h"

    // code that always needs to be optimized

    #include "optimizations_reset.h"

Inside these I have whatever is necessary for each compiler. Since these
are used fairly rarely, the overhead of file inclusion isn't a problem.
They really make the client code simpler to read, and prevent it from
having any maintenance issues.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Beman Dawes <spamless@esva.net>
Date: 1999/07/30
Raw View
Is it possible achieve the effect of the following (which doesn't
actually work)?

   #  if defined some_compiler_name
   #    define WHATEVER #pragma vendor specific pragma
   #  elif defined other_compiler_name
   #    define WHATEVER #pragma different vendor pragma
   #  endif

   ...

   WHATEVER        // replaced by the defined #pragma

The Phases of translation portion of the standard doesn't say anything
about pragmas.

Thanks,

--Clueless in Virginia


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Valentin Bonnard <Bonnard.V@wanadoo.fr>
Date: 1999/07/30
Raw View
Beman Dawes wrote:

> Is it possible achieve the effect of the following (which doesn't
> actually work)?
>
>    #  if defined some_compiler_name
>    #    define WHATEVER #pragma vendor specific pragma
>    #  elif defined other_compiler_name
>    #    define WHATEVER #pragma different vendor pragma
>    #  endif

You have to use C9X' _Pragma(value) instead of the
traditionnal #pragma value.

>    WHATEVER        // replaced by the defined #pragma
>
> The Phases of translation portion of the standard doesn't say anything
> about pragmas.

Actually they say that the result of macro expansion is
_not_ considered for preprocessing directives so #pragma
is not allowed there.

--

Valentin Bonnard


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: "James Kuyper Jr." <kuyper@wizard.net>
Date: 1999/07/31
Raw View
Beman Dawes wrote:
>
> Is it possible achieve the effect of the following (which doesn't
> actually work)?
>
>    #  if defined some_compiler_name
>    #    define WHATEVER #pragma vendor specific pragma
>    #  elif defined other_compiler_name
>    #    define WHATEVER #pragma different vendor pragma
>    #  endif
>
>    ...
>
>    WHATEVER        // replaced by the defined #pragma
>
> The Phases of translation portion of the standard doesn't say anything
> about pragmas.

Sure it does; section 2.1 p4 covers all preprocessing directives,
including #pragma.

Here's how to achieve the desired effect:

whatever.h:
 #if defined some_compiler_name
  #pragma vendor specific pragma
 #else
  #pragma different vendor pragma
 #endif

Then, wherever you wanted to put 'WHATEVER', put #include "whatever.h"
instead.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: "Andrew F. Vesper" <avesper@wn.net>
Date: 1999/07/31
Raw View
Beman Dawes wrote:

> Is it possible achieve the effect of the following (which doesn't
> actually work)?
>
>    #  if defined some_compiler_name
>    #    define WHATEVER #pragma vendor specific pragma
>    #  elif defined other_compiler_name
>    #    define WHATEVER #pragma different vendor pragma
>    #  endif
>
>    ...
>
>    WHATEVER        // replaced by the defined #pragma

Try something like:

#if defined (xxx)
    # define PRAGMA_ARGS    sequence of PP tokens
#else
    # define PRAGMA_ARGS    second sequence
#endif

# pragma PRAGMA_ARGS

This isn't guaranteed, but you might get lucky.

I haven't tried it, so I may be all wet.
--
Andy V (OpenGL Alpha Geek)
"In order to make progress, one must leave the door to the unknown ajar."
Richard P. Feynman, quoted by Jagdish Mehra in _The Beat of a Different Drum_.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: "Darin Adler" <darin@bentspoon.com>
Date: 1999/07/31
Raw View
Beman Dawes <spamless@esva.net> wrote:

> Is it possible achieve the effect of the following (which doesn't
> actually work)?
>
>    #  if defined some_compiler_name
>    #    define WHATEVER #pragma vendor specific pragma
>    #  elif defined other_compiler_name
>    #    define WHATEVER #pragma different vendor pragma
>    #  endif

Sadly, no.

The most compiler-dependent feature, #pragma, is also harder than most other
features to control with macros.

I think C9X might be doing something to help with this?

This is why I prefer compiler vendors that use identifiers that begin with
"__" to create extensions to the language and compiler-specific controls
rather than using pragmas.

    -- Darin
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]