C 库命名约定

Question

简介

大家好，我最近学习了 C 语言编程！ （这对我来说是巨大的一步，因为 C++ 是第一种语言，我接触并害怕了近 10 年。）来自主要面向对象的背景（Java + C#），这是一个非常好的范式转变。

我喜欢 C。这是一门非常美丽的语言。最让我惊讶的是C支持的高级模块化和代码可重用性——当然它没有OO语言那么高，但仍然远远超出了我对命令式语言的期望。

问题

如何防止客户端代码和 C 库代码之间的命名冲突？在 Java 中存在包，在 C# 中存在命名空间。想象一下我编写了一个 C 库，它提供了“add”操作。客户端很可能已经使用了这样的操作 - 我该怎么办？

我特别寻找客户友好的解决方案。例如，我根本不想为所有 api 操作添加前缀，例如“myuniquelibname_add”。 C 世界中常见的解决方案是什么？您是否将所有 api 操作放在一个结构体中，以便客户端可以选择自己的前缀？

我非常期待通过您的回答获得见解！

编辑（修改后的问题）

亲爱的回答者，感谢您的回答！我现在明白了，前缀是安全避免命名冲突的唯一方法。所以，我想修改我的问题：我有什么可能性，让客户选择自己的前缀？

答案放松 发布，是一种方式。它不使用通常意义上的前缀，但必须在每个 api 调用前加上“api->”前缀。还有哪些进一步的解决方案（例如使用#define）？

编辑2（状态更新）

这一切都归结为两种方法之一：

• 使用结构
• 使用#define（注意：有很多方法，如何使用#define来实现，我想要的）

我不会接受任何答案，因为我认为没有正确答案。一个人选择的解决方案取决于具体情况和自己的喜好。我自己会尝试您提到的所有方法，以找出在哪种情况下最适合我的方法。请随意在相应答案的评论中发表支持或反对某些方法的论点。

最后，我要特别感谢：

• Unwind - 他的复杂答案，包括“struct-method”的完整实现
• Christoph - 他的好答案并指出我C 中的命名空间
• 所有其他人 - 为了您的宝贵意见

如果有人认为结束这个问题是合适的（因为没有进一步的见解可期待），他/她应该随意这样做 -我无法决定这一点，因为我不是 C 大师。

Answer 1

我不是 C 专家，但从我使用过的库来看，使用前缀来分隔函数是很常见的。

例如，SDL将使用SDL，OpenGL将使用gl等......

Answer 2

Ken 提到的结构方式看起来像这样：

struct MyCoolApi
{
  int (*add)(int x, int y);
};

MyCoolApi * my_cool_api_initialize(void);

然后客户端会这样做：

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

#include "mycoolapi.h"

int main(void)
{
  struct MyCoolApi *api;

  if((api = my_cool_api_initialize()) != NULL)
  {
    int sum = api->add(3, 39);

    printf("The cool API considers 3 + 39 to be %d\n", sum);
  }
  return EXIT_SUCCESS;
}

这仍然有“命名空间问题”； struct 名称（称为“struct 标记”）需要是唯一的，并且您不能声明本身有用的嵌套结构。不过，它对于收集函数效果很好，并且是一种在 C 中经常看到的技术。

更新：这是实现方面的外观，这是在评论中请求的：

#include "mycoolapi.h"

/* Note: This does **not** pollute the global namespace,
 * since the function is static.
*/
static int add(int x, int y)
{
  return x + y;
}

struct MyCoolApi * my_cool_api_initialize(void)
{
  /* Since we don't need to do anything at initialize,
   * just keep a const struct ready and return it.
  */
  static const struct MyCoolApi the_api = {
    add
  };

  return &the_api;
}

Answer 3

很遗憾你被 C++ 吓跑了，因为它有命名空间来精确处理这个问题。在 C 中，您几乎只能使用前缀 - 您当然不能“将 api 操作放入结构中”。

编辑：针对您关于允许用户指定自己的前缀的第二个问题，我会像避免瘟疫一样避免它。 99.9% 的用户会对您提供的任何前缀感到满意（假设它不是太傻），并且会对他们必须跳过才能满足剩余 0.1% 的需求（宏、结构等）感到非常不高兴。

Answer 4

作为库用户，您可以通过预处理器轻松定义自己的缩短名称空间；结果看起来有点奇怪，但它有效：

#define ns(NAME) my_cool_namespace_ ## NAME

使得可以编写

ns(foo)(42)

而不是

my_cool_namespace_foo(42)

作为库作者，您可以提供缩短的名称 如此处所述。

如果您遵循 unwinds 的建议并创建 API 结构，则应该将该函数指针编译时常量以使 inlinig 成为可能，即在您的 .h 文件中，使用以下代码：

// canonical name
extern int my_cool_api_add(int x, int y);

// API structure
struct my_cool_api
{
    int (*add)(int x, int y);
};

typedef const struct my_cool_api *MyCoolApi;

// define in header to make inlining possible
static MyCoolApi my_cool_api_initialize(void)
{
    static const struct my_cool_api the_api = { my_cool_api_add };
    return &the_api;
}

Answer 5

不幸的是，没有确定的方法可以避免 C 中的名称冲突。由于它缺乏名称空间，因此您只能为全局函数和变量的名称添加前缀。大多数库都会选择一些简短且“唯一”的前缀（唯一由于明显的原因而在引号中），并希望不会发生冲突。

需要注意的一件事是，库的大部分代码都可以静态声明 - 这意味着它不会与其他文件中类似命名的函数发生冲突。但导出的函数确实必须小心地添加前缀。

Answer 6

由于您公开的函数具有相同的名称，因此客户端无法包含您的库头文件以及其他具有名称冲突的头文件。在这种情况下，您可以在头文件中的函数原型之前添加以下内容，这也不会影响客户端的使用。

#define add myuniquelibname_add

请注意，这是一个快速修复解决方案，应该是最后一个选择。

Answer 7

要获得 struct 方法的真正巨大示例，请查看 Linux 内核；这种风格的 C 代码有 30 多万行。

Answer 8

前缀只是 C 级别的选择。

在某些平台（支持链接器的单独命名空间，如 Windows、OS X 和一些商业 unice，但不包括 Linux 和 FreeBSD）上，您可以通过将代码填充到库中来解决冲突，并且仅从您真正需要的库中导出符号。 （例如，在导出的符号中存在冲突的情况下，在导入库中使用别名）