GH 单元和 Objective C++
我有一个iPhone项目，使用GHUnit进行单元测试。最近，我需要实现复数并重载一些运算符以简化 FFT 的计算。这里的目标是创建一种干净的方法来执行 FFT，而不需要像 FFTW 这样的库使用的所有可能功能的开销，从这个意义上说，我可以进一步自定义我想要在 FFT 中执行的计算数量（所以我降低了传统 DFT 中使用的因式分解的复杂性）。
简而言之，这就是为什么我决定用 C++ 实现我自己的 FFT 库，而不是使用 FFTW。然而，这给 GHUnit 带来了一些问题。我的所有生产目标都可以与 FFT 库集成正常工作，但 GHUnit 拒绝工作。具体来说，我遇到了诸如 GHComposeString 之类的链接器错误。这仅发生在我的单元测试目标中。我想知道这个问题可能是什么？起初，我怀疑这可能是因为 C 与 C++ 在函数名称的修改方式上存在差异，但它似乎并没有影响项目的其余部分，只是影响 GHUnit 部分。
对于将 C++ 与 GHUnit 混合的任何帮助，我们表示赞赏。
I have an iPhone project that uses GHUnit to conduct unit testing. Recently, I've needed to implement complex numbers and overload some operators to ease the calculation of FFTs. The goal here was to create a clean way to perform an FFT without the overhead of all the possible functionality that libraries like FFTW uses, and in this sense, I could further customize the number of calculations I'd like to do in my FFT (so I reduce the complexity of factorizing this or that used in the traditional DFT).
In short, this is why I decided to implement my own FFT library in C++, rather than use FFTW. However, this has caused some problems with GHUnit. All of my production targets work correctly with the integration of my FFT library, but GHUnit refuses to work. Specifically, I get linker errors with things like GHComposeString. This only happens in my Unit Tests target. I'm wondering what this problem might be? At first, I suspected that this may be because of the differences in C vs C++ in how function names are mangled, but it doesn't seem to affect the rest of the project, just the GHUnit portions.
Any help with mixing C++ with GHUnit appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这并不是真正的答案，但我认为您的名称修改是正确的。重整是在链接时完成的。 GHUnit继承自OCUnit，在运行时由dyld注入到应用程序的内存空间中。因此，可以想象 GHUnit/OCUnit 可能会出现一些与 Obj-C++ 文件损坏相关的问题。
This isn't really an answer, but I think you're on the right track with the name mangling. Mangling is done at link time. GHUnit, which inherits from OCUnit, is injected into the app's memory space at runtime by dyld. So, there could conceivably be some kind of issues with GHUnit/OCUnit regarding the mangling of your Obj-C++ files.
您是否使用 extern "C"?
这将防止它们被破坏。
理想情况下，它们的标头应该在内部提供此功能，但并不是每个人都认为它们的标头在 C++ 中使用：
Are you wrapping your GHUnit includes with extern "C"?
That will prevent them being mangled.
Ideally, their headers should do offer this internally but not everyone thinks of their headers being used in C++:
过去困扰我的一件事（相关的）是 .m 文件（默认情况下）编译为 Obj-C，而 .mm 文件编译为 Obj-C++。
这适用于混合两者（Obj-C(++) 和 cpp）的情况，如果您正在进行 iPhone 开发（在 iOS 中），那么您可能就是这样。
仔细检查使用 FFT 类的 Obj-C 测试文件是否具有 .mm 扩展名，而不是 .m 扩展名。
One (related) thing that has bitten me in the past is that .m files are (by default) compiled as Obj-C, while .mm files are compiled as Obj-C++.
This applies when you are mixing the two (Obj-C(++) and cpp), which, if you are doing iPhone development (in iOS), you probably are.
Double check that your Obj-C test files that are utilizing your FFT class have the .mm and not the .m extension.
将
-lstdc++添加到测试目标中的“其他链接器标志”。Add
-lstdc++to "Other Linker Flags" in your testing target.