的 main.c中

Question

我在 flag.h 中定义了一些常量，因此 link.c 和 linkedlist.h 可以使用它。但是当我编译：

clang -Wall main.c link.c linkedlist.c

我得到以下

/tmp/linkedlist-o2mcAI.o :(。rodata + 0x0）：“ VARIABLE_NAME ”的多重定义

/tmp/link-oXhyfE.o :(。rodata + 0x0）：首先在这里定义

用于 link.c 和 linkedlist.c 中使用的 flag.h 的所有变量，最后：

clang：错误：链接器命令失败，退出代码为1（使用-v查看调用）

示例代码 main.c ， flag.h ， link.h ， link.c ， linkedlist.h 和 linkedlist.c ：

的 main.c中

#include <stdio.h>
#include "linkedlist.h"

int main(void) {
    LinkedList* list = LinkedList_new();
}

的 flag.h

#ifndef FLAG_H_
#define FLAG_H_

#include <limits.h>

#define FALSE 0
#define TRUE 1

const int OK = 1;
const int ERROR = -1;
const int FLAG = 0;

// other constants

#endif

的 link.h

#ifndef LINK_H_
#define LINK_H_

typedef struct Link {
    int value;
    struct Link* next;
} Link;

Link* Link_new(int value);

int useExample(int value);

// other methods

#endif

的 link.c

#include <stdio.h>
#include <stdlib.h>

#include "link.h"
#include "flag.h"

Link* Link_new(int value)
{
    Link* link = malloc(sizeof(Link));
    link->value = value;
    link->next = NULL;
    return link;
}

useExample(int value)
{
    if (value == 0) {
        return OK; // defined in flag.h
    } else {
        return FLAG; // defined in flag.h
    }
}

// other methods

的 linkedlist.h

#ifndef LINKEDLIST_H_
#define LINKEDLIST_H_

#include "link.h"

typedef struct LinkedList {
    Link* first;
    unsigned int size;
} LinkedList;

LinkedList* LinkedList_new();

int anotherUseExample(int value);

// other methods

#endif

的 linkedlist.c

#include <stdio.h>
#include <stdlib.h>

#include "linkedlist.h"
#include "flag.h"

LinkedList* LinkedList_new() {
    LinkedList* list = malloc(sizeof(LinkedList));
    list->first = NULL;
    list->size = 0;
    return list;
}

anotherUseExample(int value)
{
    if (value == 0) {
        return FLAG; // defined in flag.h
    } else {
        return ERROR; // defined in flag.h
    }
}

// other methods

那么如何在 link.c 和 linkedlist.c 中使用 flag.h 而不会出现多重定义？

和... 我编写头文件和编译的方式是正确的吗？

-v的完整输出：

clang version 3.3 (tags/RELEASE_33/rc3)
Target: i386-redhat-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple i386-redhat-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -target-linker-version 2.23.52.0.1 -v -resource-dir /usr/bin/../lib/clang/3.3 -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.3/include -internal-externc-isystem /usr/include -internal-externc-isystem /usr/lib/gcc/i686-redhat-linux/4.8.1/include -Wall -fdebug-compilation-dir /home/jharvard/Desktop/Code/LinkedList -ferror-limit 19 -fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/main-JmZTmN.o -x c main.c
clang -cc1 version 3.3 based upon LLVM 3.3 default target i386-redhat-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/bin/../lib/clang/3.3/include
 /usr/include
 /usr/lib/gcc/i686-redhat-linux/4.8.1/include
End of search list.
 "/usr/bin/clang" -cc1 -triple i386-redhat-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name link.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -target-linker-version 2.23.52.0.1 -v -resource-dir /usr/bin/../lib/clang/3.3 -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.3/include -internal-externc-isystem /usr/include -internal-externc-isystem /usr/lib/gcc/i686-redhat-linux/4.8.1/include -Wall -fdebug-compilation-dir /home/jharvard/Desktop/Code/LinkedList -ferror-limit 19 -fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/link-FtygcZ.o -x c link.c
clang -cc1 version 3.3 based upon LLVM 3.3 default target i386-redhat-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/bin/../lib/clang/3.3/include
 /usr/include
 /usr/lib/gcc/i686-redhat-linux/4.8.1/include
End of search list.
 "/usr/bin/clang" -cc1 -triple i386-redhat-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name linkedlist.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -target-linker-version 2.23.52.0.1 -v -resource-dir /usr/bin/../lib/clang/3.3 -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.3/include -internal-externc-isystem /usr/include -internal-externc-isystem /usr/lib/gcc/i686-redhat-linux/4.8.1/include -Wall -fdebug-compilation-dir /home/jharvard/Desktop/Code/LinkedList -ferror-limit 19 -fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/linkedlist-n0zF1a.o -x c linkedlist.c
clang -cc1 version 3.3 based upon LLVM 3.3 default target i386-redhat-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/bin/../lib/clang/3.3/include
 /usr/include
 /usr/lib/gcc/i686-redhat-linux/4.8.1/include
End of search list.
 "/usr/bin/ld" --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o a.out /usr/lib/gcc/i686-redhat-linux/4.8.1/../../../crt1.o /usr/lib/gcc/i686-redhat-linux/4.8.1/../../../crti.o /usr/lib/gcc/i686-redhat-linux/4.8.1/crtbegin.o -L/usr/lib/gcc/i686-redhat-linux/4.8.1 -L/usr/lib/gcc/i686-redhat-linux/4.8.1/../../.. -L/lib -L/usr/lib /tmp/main-JmZTmN.o /tmp/link-FtygcZ.o /tmp/linkedlist-n0zF1a.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-redhat-linux/4.8.1/crtend.o /usr/lib/gcc/i686-redhat-linux/4.8.1/../../../crtn.o
/tmp/linkedlist-n0zF1a.o:(.rodata+0x4): multiple definition of `ERROR_indexOutOfBounds'
/tmp/link-FtygcZ.o:(.rodata+0x4): first defined here
/tmp/linkedlist-n0zF1a.o:(.rodata+0x8): multiple definition of `ERROR_invalidArgument'
/tmp/link-FtygcZ.o:(.rodata+0x8): first defined here
/tmp/linkedlist-n0zF1a.o:(.rodata+0x10): multiple definition of `FLAG_notFound'
/tmp/link-FtygcZ.o:(.rodata+0x10): first defined here
/tmp/linkedlist-n0zF1a.o:(.rodata+0xc): multiple definition of `FLAG_undefined'
/tmp/link-FtygcZ.o:(.rodata+0xc): first defined here
/tmp/linkedlist-n0zF1a.o:(.rodata+0x0): multiple definition of `OK'
/tmp/link-FtygcZ.o:(.rodata+0x0): first defined here
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Answer 1

C中的#include指令只是复制头文件中的文本。这意味着当您编译link.c和linkedlist.c时，flag.h中的常量定义将被复制到两者中，所有这些常量现在都在link.o和链接列表中定义。 O`。链接程序时，如果出现名称，则会出现多重定义错误。

您需要从定义中拆分声明，并创建一个flag.c文件，您可以在其中定义const int OK = 1;等，而在flag.h您将继续使用const int OK;这样，常量将被编译成单个目标文件 - flag.o - 并且在链接时不会出现多重定义错误。

Answer 2

由于您不需要将这些常量作为对象，因此您应该使用其他功能来定义它们，枚举。

enum { OK = 1, ERROR = -1, FLAG = 0, ONE = 1, };

这些类型为int，永远不会产生多个符号错误。它们的优点是它们可以保留在.h文件中。因此，所有使用它们的函数都可以看到值，并且可以更好地进行优化。

从上面的示例中可以看出，值不必按顺序显示，并且可能会多次出现相同的值。

Answer 3

flag.h：

extern const int OK, ERROR, FLAG;

flag.c：

const int OK = 1;
const int ERROR = -1;
const int FLAG = 0;

Answer 4

@Idan Arye和@Jens Gustedt给出了两个解决方案。两者都有优点和缺点。枚举的一个主要优点是我们不需要为元素赋值，编译器会自动赋值。重复输入的可能性较小，我们可以安全地添加或删除新元素。

enum的缺点是它默认为int。如果我们在嵌入式编程等内存受限系统中需要uint8_t，我们可能会遇到问题。但是一些编译器支持-fshort-enums编译器选项，它允许编译器将枚举类型的大小设置为可以容纳所有枚举器值的最小数据类型。但我们必须专门设置这些选项。

在C

中也无法向前声明枚举类型的变量

在头文件和源文件中使用const，我们再次需要将所有consts复制到这两个文件中。

值也可能重复（如果值必须是唯一的，则为危险）。

const的另一个主要缺点是它们不能用于初始化静态或全局变量。它们不被视为编译时常量，而是被视为只读变量。

头文件中const变量的多重定义

的 main.c中

的 flag.h

的 link.h

的 link.c

的 linkedlist.h

的 linkedlist.c

4 个答案: