c++ - 在 Python 中公开 C++ 全局变量

Question

我正在尝试使用 Cython 在我的 Python 代码中访问 C++ 全局变量。

假设我的 C++ 代码中有以下数组:

// Project.cpp
int myArr[2] = { 0, 1 };

所以，在 Cython 中定义一个指向 myArr 的指针:

cdef extern int * myArr_ptr

是否 myArr_ptr 真的指向 C++ 数组吗？还是只是一个随机值？

Answer 1

好的，问题是:
Project.cpp拥有全局int *myArr; ，未在 Project.h 中列出，并且您想从 Cython 访问它而不导入 Project.cpp .

在评论中，你说:

I can't include Project.cpp because this file will try to include other files that were already included and will try to redefine many variables.

按照您描述的方式，这里可能存在一个基本错误。你可能知道这些基本的东西，所以请不要因为我提出它们而受到侮辱，但我只想彻底:

首先，如果你的头文件没有防止多重包含，修复它，然后你就不用担心“我不能包含 Project.cpp 因为这个文件会尝试包含其他已经包含的文件并将尝试重新定义许多变量。” (如果你没有头文件，而你只是在 .cpp 文件中使用明确的 extern 语句在所有地方做所有事情，请不要这样做——这在 C 和 C++ 中是个坏主意，早在你得到了 Cythonizing。)

其次，如果您的模块旨在与 Project.cpp 的 .so/.dll/.dylib 接口(interface)。是其中的一部分，您不应该针对该库的源进行构建，而是针对已安装的界面进行构建。另一方面，如果您的模块打算直接包含 C++ 代码，那么您必须包含 Project.cpp .如果您使用 extern声明来引用你不打算链接的东西，你只会得到一个链接器错误——或者，如果你不走运，一切都会构建，但在运行时会失败。

第三，如果它实际上不是全局的，则无法从 Project.cpp 外部访问。 ——出于作用域、生命周期或链接的原因，在单独的实现文件中没有其他类型的变量可用。

同样，我假设您知道所有这些基本知识，而我只是误读了您的评论。有一个真正的问题案例，您需要使用设计不佳的 API 来包装某些东西，这需要您进入内部，这有时会很棘手，您可能确实遇到过这样的事情，而我只是没有弄清楚到底是怎么回事。

有三个基本的解决方案。

首先，显然，如果您可以构建适当的原生 API，那么在 Cython 中包装该 API 是微不足道的。同时，由于其他原因，这很有用。有时，这会耗费太多时间和精力——例如，如果 native 库不是为外部驱动而设计的，并且需要 10 年的遗留维护，这是您必须打包的唯一原因它是当前的 Cython 项目，您可能不想清理它。或者，如果它是一个快速变化的库，您需要保持最新并且没有源代码控制，那么 fork 它并尝试保持同步可能是一场噩梦。等等。但是，如果您的情况没有这样的原因，那么这是正确的答案。如果可以的话 cdef extern from "project.h" ，一切都很简单。

您可以通过在 native 级别创建“shim API”来实现更简单的版本，创建单独的 .h文件具有适当的外部、函数和类型声明，用于您需要从内部使用的各种函数和类型。然后，您可以 cdef extern from "project_extras.h" .

最后，你总是可以写明确的 cdef extern任何东西的陈述，而不告诉 Cython 它来自哪里。 Cython 会在生成的代码中将其转换为适当的 native extern，如果一切正确，它将起作用。这里有一些缺点— the docs解释 cdef extern from 的所有优点你会放弃的。简短的版本是，您的 Cython 声明必须与 native 声明完全匹配；否则，您不会在 Cython 阶段自动修复或引发一个不错的错误，而是会从 C 编译器收到一条难以理解的错误消息，指的是不可读的 Cython 生成的 C 代码，而不是您的实际代码——或者更糟糕的是，代码编译但做错了。

对于简单的 int *或 int []值(value)，所有这些都无关紧要，因为不需要任何解释；一个普通的 cdef extern应该没问题。