标题的宏定义,放在哪里?

如果宏影响系统头,它们可能应该影响包含这些系统头的每个源文件(包括间接包含它们的源文件)。因此,最合乎逻辑的位置应该在命令行上,假设您的构建系统允许您设置CPPFLAGS来影响每个文件的编译。

对于影响自包含库(无论是第三方的还是由您编写的)的宏,我将创建一个包装头来定义宏,然后包含库头。然后,项目中对库的所有使用都应该包含包装器头,而不是直接包含库头。这避免了不必要地定义宏,并清楚地表明它们与该库相关。如果库之间存在依赖关系,那么为了安全起见,可能需要将宏设置为全局的(在生成系统或预编译头中)。

那要看情况了。

大多数情况下,我会通过命令行定义-在Makefile或任何您使用的构建系统中。

至于 _FILE_OFFSET_BITS 我真的不会明确地定义它,而是使用 getconf LFS_CFLAGS getconf LFS_LDFLAGS

我总是通过 CPPFLAGS 整个项目。如果将它们放在任何其他位置,则有可能忘记将它们复制到新的源文件中,或在包含定义它们的项目头之前包含系统头,这可能会导致极其严重的错误(例如一个文件声明了遗留的32位文件) struct stat 并将其地址传递给另一个需要64位的文件中的函数 结构状态 ).

_FILE_OFFSET_BITS=64

我见过的大多数使用它们的项目都是通过 -D 命令行选项。它们之所以存在,是因为这样可以轻松地用不同的编译器和系统头构建源代码。如果要使用系统编译器为另一个不需要它们或需要不同系统集的系统构建,那么配置脚本可以轻松地更改make文件传递给编译器的命令行参数。

最好对整个程序都这样做,因为有些标志会影响函数的哪个版本或结构的大小/布局,如果不小心,把它们混在一起可能会导致疯狂的事情。

为了 _GNU_SOURCE AC_USE_SYSTEM_EXTENSIONS (这里大量引用autoconf手册):

--宏:
这个宏是在Autoconf 2.60中引入的。如果可能,启用 在通常禁用 扩展,通常是由于标准一致性命名空间 问题。这应该在运行C语言的任何宏之前调用 编译器。以下预处理器宏定义在

_GNU源 在GNU/Linux上启用扩展。

__EXTENSIONS__

_POSIX_PTHREAD_SEMANTICS 在Solaris上启用线程扩展。

_TANDEM_SOURCE 为HP NonStop平台启用扩展。

_ALL_SOURCE

_POSIX_SOURCE 为Minix启用Posix函数。

_POSIX_1_SOURCE 为Minix启用其他Posix函数。

_MINIX 识别Minix平台。这个特殊的预处理器宏 已过时,可能在将来的版本中删除

为了 _FILE_OFFSET_BITS ,你需要打电话 AC_SYS_LARGEFILE 和 AC_FUNC_FSEEKO

空调系统大文件

CC . 定义 _文件\偏移量\位 _LARGE_FILES 如有必要。

可以通过配置来禁用大文件支持 --disable-largefile 选项。

如果使用此宏,请检查您的程序即使在 off_t 宽度大于 long int 关闭 X 具有 printf("%ld", (long int) X)

LFS引进了 fseeko 和 ftello fseek 和 ftell 关闭 . 小心使用 ACèu FUNCèu FSEEKO公司 使原型在使用时可用,并启用了大文件支持。

autoheader 生成一个 config.h ,您可以定义其他需要使用的宏 AC_DEFINE 或 AC_DEFINE_UNQUOTED :

AC_DEFINE([FUSE_VERSION], [28], [FUSE Version.])

然后将定义传递到命令行或放置在 配置h AC\U定义 它很容易允许预处理器定义作为配置检查的结果,并将系统特定的错误与重要的细节分离开来。

.c 文件, #include "config.h" 首先,然后是接口头(例如。, foo.h 对于 foo.c -这样可以确保头没有丢失的依赖项,然后是所有其他头。

相关信息 应该

void something (void) {
    // 600 lines of code here
    int x = fn(y);
    // more code here
}

这比:

void something (void) {
    int x;
    // 600 lines of code here
    x = fn(y);
    // more code here
}

因为你不必去寻找 x

举个例子,如果您需要用不同的值多次编译单个源文件,那么 有

gcc -Dmydefine=7 -o binary7 source.c
gcc -Dmydefine=9 -o binary9 source.c

但是,如果该文件的每个编译都将使用7,则可以将其移到使用它的位置:

source.c:
    #include <stdio.h>

    #define mydefine 7
    #include "header_that_uses_mydefine.h"

    #define mydefine 7
    #include "another_header_that_uses_mydefine.h"

请注意,我已经做了两次,所以它更本地化。这不是一个问题,因为如果您只更改一个,编译器会告诉您,但它确保您知道这些定义是为特定的头设置的。

如果你确定你会 包括(例如) bitio.h BITCOUNT 到8,您甚至可以创建一个 bitio8.h 只包含以下内容的文件:

#define BITCOUNT 8
#include "bitio.h"

在源文件中。

全局的、项目范围的、特定于目标的常量最好放在makefile的CCFLAGS中。到处使用的常量可以放在适当的头文件中,这些头文件包含在任何使用它们的文件中。

// bool.h - a boolean type for C
#ifndef __BOOL_H__
#define BOOL_H
typedef int bool_t
#define TRUE 1
#define FALSE 0
#endif

然后,在另一个标题中,

`#include "bool.h"`
// blah

我推荐使用头文件,因为它允许您使用make文件和其他构建系统以及IDE项目(如visualstudio)构建代码库。这给了你一个单一的定义,可以伴随着评论(我是一个球迷的 doxygen 它允许你生成 macro documentation

头文件的另一个好处是,您可以轻松地编写单元测试,以验证是否只定义了宏的有效组合。