问题
When defining macros that headers rely on, such as _FILE_OFFSET_BITS
, FUSE_USE_VERSION
, _GNU_SOURCE
among others, where is the best place to put them?
Some possibilities I've considered include
- At the top of the any source files that rely on definitions exposed by headers included in that file
- Immediately before the include for the relevant header(s)
- Define at the
CPPFLAGS
level via the compiler? (such as-D_FILE_OFFSET_BITS=64
) for the:- Entire source repo
- The whole project
- Just the sources that require it
- In project headers, which should also include those relevant headers to which the macros apply
- Some other place I haven't thought of, but is infinitely superior
A note: Justification by applicability to make, autotools, and other build systems is a factor in my decision.
回答1:
If the macros affect system headers, they probably ought to go somewhere where they affect every source file that includes those system headers (which includes those that include them indirectly). The most logical place would therefore be on the command line, assuming your build system allows you to set e.g. CPPFLAGS to affect the compilation of every file.
If you use precompiled headers, and have a precompiled header that must therefore be included first in every source file (e.g. stdafx.h for MSVC projects) then you could put them in there too.
For macros that affect self-contained libraries (whether third-party or written by you), I would create a wrapper header that defines the macros and then includes the library header. All uses of the library from your project should then include your wrapper header rather than including the library header directly. This avoids defining macros unnecessarily, and makes it clear that they relate to that library. If there are dependencies between libraries then you might want to make the macros global (in the build system or precompiled header) just to be on the safe side.
回答2:
Well, it depends.
Most, I'd define via the command line - in a Makefile or whatever build system you use.
As for _FILE_OFFSET_BITS
I really wouldn't define it explicitly, but rather use getconf LFS_CFLAGS
and getconf LFS_LDFLAGS
.
回答3:
I would always put them on the command line via CPPFLAGS
for the whole project. If you put them any other place, there's a danger that you might forget to copy them into a new source file or include a system header before including the project header that defines them, and this could lead to extremely nasty bugs (like one file declaring a legacy 32-bit struct stat
and passing its address to a function in another file which expects a 64-bit struct stat
).
BTW, it's really ridiculous that _FILE_OFFSET_BITS=64
still isn't the default on glibc.
回答4:
Most projects that I've seen use them did it via -D
command line options. They are there because that eases building the source with different compilers and system headers. If you were to build with a system compiler for another system that didn't need them or needed a different set of them then a configure script can easily change the command line arguments that a make file passes to the compiler.
It's probably best to do it for the entire program because some of the flags effect which version of a function gets brought in or the size/layout of a struct and mixing those up could cause crazy things if you aren't careful.
They certainly are annoying to keep up with.
回答5:
For _GNU_SOURCE
and the autotools in particular, you could use AC_USE_SYSTEM_EXTENSIONS
(citing liberally from the autoconf manual here):
-- Macro:
AC_USE_SYSTEM_EXTENSIONS
This macro was introduced in Autoconf 2.60. If possible, enable extensions to C or Posix on hosts that normally disable the extensions, typically due to standards-conformance namespace issues. This should be called before any macros that run the C compiler. The following preprocessor macros are defined where appropriate:
_GNU_SOURCE
Enable extensions on GNU/Linux.
__EXTENSIONS__
Enable general extensions on Solaris.
_POSIX_PTHREAD_SEMANTICS
Enable threading extensions on Solaris.
_TANDEM_SOURCE
Enable extensions for the HP NonStop platform.
_ALL_SOURCE
Enable extensions for AIX 3, and for Interix.
_POSIX_SOURCE
Enable Posix functions for Minix.
_POSIX_1_SOURCE
Enable additional Posix functions for Minix.
_MINIX
Identify Minix platform. This particular preprocessor macro is obsolescent, and may be removed in a future release of Autoconf.
For _FILE_OFFSET_BITS
, you need to call AC_SYS_LARGEFILE
and AC_FUNC_FSEEKO
:
— Macro:
AC_SYS_LARGEFILE
Arrange for 64-bit file offsets, known as large-file support. On some hosts, one must use special compiler options to build programs that can access large files. Append any such options to the output variable
CC
. Define_FILE_OFFSET_BITS
and_LARGE_FILES
if necessary.Large-file support can be disabled by configuring with the
--disable-largefile
option.If you use this macro, check that your program works even when
off_t
is wider thanlong int
, since this is common when large-file support is enabled. For example, it is not correct to print an arbitraryoff_t
valueX
withprintf("%ld", (long int) X)
.The LFS introduced the
fseeko
andftello
functions to replace their C counterpartsfseek
andftell
that do not useoff_t
. Take care to useAC_FUNC_FSEEKO
to make their prototypes available when using them and large-file support is enabled.
If you are using autoheader
to generate a config.h
, you could define the other macros you care about using AC_DEFINE
or AC_DEFINE_UNQUOTED
:
AC_DEFINE([FUSE_VERSION], [28], [FUSE Version.])
The definition will then get passed to the command line or placed in config.h
, if you're using autoheader. The real benefit of AC_DEFINE
is that it easily allows preprocessor definitions as a result of configure checks and separates system-specific cruft from the important details.
When writing the .c
file, #include "config.h"
first, then the interface header (e.g., foo.h
for foo.c
- this ensures that the header has no missing dependencies), then all other headers.
回答6:
I usually put them as close as practicable to the things that need them, whilst ensuring you don't set them incorrectly.
Related pieces of information should be kept close to make it easier to identify. A classic example is the ability for C to now allow variable definitions anywhere in the code rather than just at the top of a function:
void something (void) {
// 600 lines of code here
int x = fn(y);
// more code here
}
is a lot better than:
void something (void) {
int x;
// 600 lines of code here
x = fn(y);
// more code here
}
since you don't have to go searching for the type of x
in the latter case.
By way of example, if you need to compile a single source file multiple times with different values, you have to do it with the compiler:
gcc -Dmydefine=7 -o binary7 source.c
gcc -Dmydefine=9 -o binary9 source.c
However, if every compilation of that file will use 7, it can be moved closer to the place where it's used:
source.c:
#include <stdio.h>
#define mydefine 7
#include "header_that_uses_mydefine.h"
#define mydefine 7
#include "another_header_that_uses_mydefine.h"
Note that I've done it twice so that it's more localised. This isn't a problem since, if you change only one, the compiler will tell you about it, but it ensures that you know those defines are set for the specific headers.
And, if you're certain that you will never include (for example) bitio.h
without first setting BITCOUNT
to 8, you can even go so far as to create a bitio8.h
file containing nothing but:
#define BITCOUNT 8
#include "bitio.h"
and then just include bitio8.h
in your source files.
回答7:
Global, project-wide constants that are target specific are best put in CCFLAGS in your makefile. Constants you use all over the place can go in appropriate header files which are included by any file that uses them.
For example,
// bool.h - a boolean type for C
#ifndef __BOOL_H__
#define BOOL_H
typedef int bool_t
#define TRUE 1
#define FALSE 0
#endif
Then, in some other header,
`#include "bool.h"`
// blah
回答8:
Using header files is what I recommend because it allows you to have a code base built by make files and other build systems as well as IDE projects such as Visual Studio. This gives you a single point of definition that can be accompanied by comments (I'm a fan of doxygen which allows you to generate macro documentation).
The other benefit with header files is that you can easily write unit tests to verify that only valid combinations of macros are defined.
来源:https://stackoverflow.com/questions/3384741/macro-definitions-for-headers-where-to-put-them