Can somebody give me some examples of some pragma in C. Any compiler that he or she is using). If possible gcc,because I am using a gcc compiler.
And how its useful in a C code ??
I can't give you the exact version of my compiler cause I am in office and dont remember it
I believe C99 only recognizes 3 pragmas (6.10.6) (all of them related to floating point)
#pragma STDC CX_LIMITED_RANGE ... /* (7.3.4) */
#pragma STDC FENV_ACCESS ... /* (7.6.1) */
#pragma STDC FP_CONTRACT ... /* (7.12.2) */
Any pragma without STDC has implementation defined behaviour (6.10.6) and, therefore, should best NOT BE USED
An unrecognized STDC pragma invokes Undefined Behaviour.
Why not just check the documentation?
This is the list of GCC's supported pragmas, sorted into various categories.
For example:
#pragma GCC optimize ("string"...)
This pragma allows you to set global optimization options for functions defined later in the source file. One or more strings can be specified. Each function that is defined after this point will be as if attribute((optimize("STRING"))) was specified for that function. The parenthesis around the options is optional. See Function Attributes, for more information about the optimize attribute and the attribute syntax.
The `#pragma GCC optimize' pragma is not implemented in GCC versions earlier than 4.4.
Related
Consider this code:
/* t0.c */
#pragma STDC FENV_ACCESS ON
#include "t0.h"
Then in t0.h how to check the state of STDC FENV_ACCESS?
/* t0.h */
/* how to check the state of STDC FENV_ACCESS? */
/* something like: #if STDC FENV_ACCESS == ON */
If not possible, then:
Why not possible?
Will it be useful to add this feature to the C standard?
(1) Why not possible?
It is possible with a custom cpp as rryker's answer mentioned. Otherwise, I would have said "no" because the compiler uses the pragmas and that comes after the cpp pass/stage.
(2) Will it be useful to add this feature to the C standard?
No, probably not. For the above mentioned reason.
And, because, drawing a leaf from what is already common (e.g. autoconf), we can reverse the problem to get the desired results without changing existing compilers.
Define (e.g.) a features.h:
#ifdef STDC_FENV_ACCESS_ON
#if STDC_FENV_ACCESS_ON
#pragma STDC FENV_ACCESS ON
#else
#pragma STDC FENV_ACCESS OFF
#endif
#endif
UPDATE:
Re: "custom cpp as rryker's answer mentioned": hm, where is the rryker's answer? I don't see it. –
pmor
I wrote that before rryker deleted his answer [partly] because of critique/comments from HolyBlackCat that couldn't be addressed immediately. My inference was rryker would be able to improve his answer and undelete it, so I left up the reference.
The link rryker based his answer on was specific extensions provided by clang: https://clang.llvm.org/docs/LanguageExtensions.html The features that rryker's answer referred to were: the __has_feature and __has_extension macros [since version 10].
That's the reference. However, with a bit of conjecture on my part, I'll try to summarize.
IIRC, clang's cpp is not a separate program that is only loosely connected to the compiler [e.g. like it is with gcc].
With clang, the preprocessor is a [more] tightly integrated stage within the compiler itself. My presumption is that this was [initially] done for speed and code reuse.
But, as a "side effect" of that:
clang's cpp can have much more intimate knowledge of the compiler's inner workings.
And, if it's more efficient/desirable, clang's cpp stage could also do more of the early (e.g.) pragma processing.
And, cpp could have access to (e.g.) all the -f* arguments/options the compiler sees.
So, it has all of the tools that make #if/#ifdef on the above __has_* macros feasible.
In addition to the other answers, and if t0.c is actually under your control, you may define appropriate macros whenever a #pragma is used.
/* t0.c */
#pragma STDC FENV_ACCESS ON
#define PRAG_FENV_ACCESS_ON
#include "t0.h"
This works independently of toolchain vendor. It's a variation of the same theme used to check the presence of typedefs in the preprocessor.
I'd like gcc to process pack pragmas such as the following:
#define _CTR_PACKING 4
#pragma pack(push, _CRT_PACKING)
MSVC allows this kind of construction by default.
Clang enabled this behavior via -fms-extensions.
Searching for a gcc equivalent, I found references to macros HANDLE_PRAGMA_PACK_PUSH_POP and HANDLE_PRAGMA_PACK_WITH_EXPANSION, but even after adding them via -DHANDLE_PRAGMA_PACK_WITH_EXPANSION=1 or as environment variables, gcc still does nothing.
How can I make gcc behave as MSVC and Clang with -fms-extensions?
The gcc macro HANDLE_PRAGMA_PACK_WITH_EXPANSION is a macro used by gcc target to indicate whether it supports expansion of macros in pragma directive, it's not a switch to enable on the fly.
Instead, you can use standard C's _Pragma operator, it translate into the compiler's pragma directives, and it supports macro expansion since it's part of the language. This is an example:
#define STR(s) #s
#define _CTR_PACKING 1
#define PACKSTR(x) STR(pack(x))
_Pragma(PACKSTR(_CTR_PACKING))
What is the replacement of __attribute__ in ISO C standard?
I want to port my software which is compiler independent.
There isn't one.
One solution is to abstract the attributes behind macros. e.g.:
#ifdef __GNUC__
#define UNUSED __attribute((unused))__
#else
#define UNUSED
#endif
...
void function(void) UNUSED;
There is no general replacement for the wide range of facilities that this gcc extension offers. Most other compilers that are not gcc compatible use #pragma to achieve similar goals. Since C99, C has the _Pragma operator that allows you to spew pragmas in the middle of your code (not only on proper lines) and to compose the contents of a pragma with macros. But then you still have to do specific "translations" of individual features to the corresponding pragma syntax of your target compiler.
When I use __attribute__ ((weak)) like in this post I get warnings from gcc about redeclaring the symbol, while all I do is adding an attribute. Can the attribute be attached differently? The warnings I get look like this:
threads.c:53: warning: redundant redeclaration of ‘pthread_once’
/usr/include/pthread.h:478: note: previous declaration of ‘pthread_once’ was here
Yes - GCC allows you to use #pragma weak to declare symbols as weak, so you can do this instead:
#include <pthread.h>
#pragma weak pthread_create
#pragma weak pthread_mutex_init
#pragma weak pthread_mutex_lock
#pragma weak pthread_mutex_unlock
#pragma weak pthread_mutex_destroy
/* ... code ... */
(Documented here.)
You can use a pthread stub library like the one from http://cgit.freedesktop.org/xcb/pthread-stubs/ which avoids the need to create your own stubs.
If you only need to run on fairly modern systems, either libc will provide a set of stubs for most commonly used functions for making things thread-safe or libpthread is integrated into libc. Note that stubs for pthread_once may not call the passed function ever. (Some libraries use this to detect if they are in the threaded or unthreaded programming environment.)
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
#pragma once vs include guards?
When should I use #pragma once?
When should I use #ifndef HEADER_H_INCLUDED?
The #ifndef/#define/#endif trick works on any C compiler, and on some of them it speeds up the compilation process. The #pragma trick is non-standards, and only works on few C compilers, and may result in different semantics in those that do not support it.
The difference is that the latter is C and the former is not. Never use #pragma once; always use #ifndef.
One other thing to note when using the #ifndef method is that any preprocessor symbol beginning with two underscores or an underscore followed by a capital letter is reserved and cannot be used. You should use things like #ifndef MYHEADER_H and not #ifndef _MYHEADER_H.
The construct
myfoo.h
#ifndef MYFOO_H
#define MYFOO_H
/* header information for myfoo.h */
#endif
belongs in every header-file. The trick is: you can include a header file (accidentally) more than once without thinking abaout double declarations. so this is for the preprocessor.
The #pragma is for the compiler, and a preprocessor should ignore pragmas it does not understand.
Use #pragma when you are addressing a specific compiler (or set of compatible compilers) to guide its code generation or if you are using a standardized #pragma like FP_CONTRACT or -CX_LIMITED_RANGE- that any standards-compliant compiler is going to support.
Use #ifndef and ilk if you are addressing the standard C (or C++) pre-processor and wish to have your code rendered portable across all standards-compliant compilers.
Use of any #pragma that is not defined in the C (or C++) standard renders your code non-portable. #pragma once is a bit of an exception in that it is one of the most commonly-implemented of the non-standard #pragma constructs. Its implementation, however, is not universal across standards-compliant compilers. #ifndef is.