从 C++ 调用 C 函数时,如何告诉 gcc 放宽对类型转换的限制?
我正在尝试使用 Cmockery 来模拟从 C++ 代码调用的 C 函数。因为 SUT 是用 C++ 编写的,所以我的测试也需要用 C++ 编写。
当我像这样使用 Cmockery Expect_string() 宏时:
expect_string(mock_function, url, "Foo");
我得到:
my_tests.cpp: In function ‘void test_some_stuff(void**)’:
my_tests.cpp:72: error: invalid conversion from ‘void*’ to ‘const char*’
my_tests.cpp:72: error: initializing argument 5 of ‘void _expect_string(const char*, const char*, const char*, int, const char*, int)’
我在 cmockery.h 定义了expect_string:
#define expect_string(function, parameter, string) \
expect_string_count(function, parameter, string, 1)
#define expect_string_count(function, parameter, string, count) \
_expect_string(#function, #parameter, __FILE__, __LINE__, (void*)string, \
count)
这是_expect_string的原型(来自cmockery.h):
void _expect_string(
const char* const function, const char* const parameter,
const char* const file, const int line, const char* string,
const int count);
我相信问题是我将C代码编译为C++,因此 C++ 编译器反对将 Expect_string_count 宏中的 (void*)string
作为 const char* string
参数传递给 _expect_string() 函数。
我已经在 my_tests.cpp 中的 cmockery.h 周围使用了 extern "C"
,如下所示:
extern "C" {
#include <cmockery.h>
}
...为了解决名称修改问题。 (请参阅“如何编译和将 C++ 代码与已编译的 C 代码链接起来?")
是否有命令行选项或其他方法告诉 g++ 如何放宽对从我的测试的 C++ 代码到 cmockery.c 中的 C 函数的类型转换的限制?
这是我当前用来构建 my_tests.cpp 的命令:
g++ -m32 -I ../cmockery-0.1.2 -c my_tests.cpp -o $(obj_dir)/my_tests.o
I'm trying to use Cmockery to mock C functions called from C++ code. Because the SUT is in C++, my tests need to be in C++.
When I use the Cmockery expect_string() macro like this:
expect_string(mock_function, url, "Foo");
I get:
my_tests.cpp: In function ‘void test_some_stuff(void**)’:
my_tests.cpp:72: error: invalid conversion from ‘void*’ to ‘const char*’
my_tests.cpp:72: error: initializing argument 5 of ‘void _expect_string(const char*, const char*, const char*, int, const char*, int)’
I see in cmockery.h that expect_string is defined:
#define expect_string(function, parameter, string) \
expect_string_count(function, parameter, string, 1)
#define expect_string_count(function, parameter, string, count) \
_expect_string(#function, #parameter, __FILE__, __LINE__, (void*)string, \
count)
And here's the prototype for _expect_string (from cmockery.h):
void _expect_string(
const char* const function, const char* const parameter,
const char* const file, const int line, const char* string,
const int count);
I believe the problem is that I'm compiling C code as C++, so the C++ compiler is objecting to (void*)string
in the expect_string_count macro being passed as the const char* string
parameter to the _expect_string() function.
I've already used extern "C"
around the cmockery.h include in my_tests.cpp like this:
extern "C" {
#include <cmockery.h>
}
...in order to get around name-mangling problems. (See "How do I compile and link C++ code with compiled C code?")
Is there a command-line option or some other means of telling g++ how to relax its restrictions on typecasting from my test's C++ code to the C function in cmockery.c?
This is the command I'm currently using to build my_tests.cpp:
g++ -m32 -I ../cmockery-0.1.2 -c my_tests.cpp -o $(obj_dir)/my_tests.o
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我明白这不是你的代码,但看起来更简单的方法可能是通过将此强制转换删除到
(void*)
来修复cmockery.h
(可能会放置一些部分仅对使用#ifdef __cplusplus
的 C++ 有效)。甚至可以将其放入您的代码中,只需重新定义
expect_string_count
宏I undersatand it's not your code, but it looks like the easier way is probably to fix
cmockery.h
by removing this cast to(void*)
(may be putting some section active only for C++ using#ifdef __cplusplus
).that could even be put in your code, just redefining the
expect_string_count
macro我认为在编译器级别没有这个选项。您也许可以通过为 CMockery 提供包装标头来解决此问题(我假设您希望避免修改 CMockery 源,因为我在您的另一个问题中读到了评论),该包装标头执行类似以下操作以使其在C 和 C++:
另一个好处是,现在您可以在 C++ 下放置您遇到的任何其他 CMockery 破解/修复程序(希望不要太多)。
如果您准备修改 CMockery 的内容,那可能是它真正所属的地方 - 也许维护人员会接受您的补丁? (我不知道)。
I don't think there's an option for this at the compiler level. You might be able to work around this (I assume you want to avoid modifying the CMockery sources because of comments I've read in another of your questions) by having wrapper header for CMockery that does something like the following to make it play nicely in both C and C++:
An additional benefit is that now you've got a place that you can put any other hacks/fixes for CMockery under C++ you come across (hopefully not too many of them).
If you're up for modifying the CMockery stuff that's probably where it really belongs - maybe the maintainers would accept your patch? (I dunno).