从 C++ 调用 C 函数时,如何告诉 gcc 放宽对类型转换的限制?

发布于 2024-10-10 17:34:46 字数 1962 浏览 1 评论 0原文

我正在尝试使用 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

撩起发的微风 2024-10-17 17:34:46

我明白这不是你的代码,但看起来更简单的方法可能是通过将此强制转换删除到 (void*) 来修复 cmockery.h (可能会放置一些部分仅对使用 #ifdef __cplusplus 的 C++ 有效)。

甚至可以将其放入您的代码中,只需重新定义 expect_string_count

#ifdef __cplusplus
#undef expect_string_count
#define expect_string_count(function, parameter, string, count) \
    _expect_string(#function, #parameter, __FILE__, __LINE__, string, \
              count)
#endif

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

#ifdef __cplusplus
#undef expect_string_count
#define expect_string_count(function, parameter, string, count) \
    _expect_string(#function, #parameter, __FILE__, __LINE__, string, \
              count)
#endif
只等公子 2024-10-17 17:34:46

我认为在编译器级别没有这个选项。您也许可以通过为 CMockery 提供包装标头来解决此问题(我假设您希望避免修改 CMockery 源,因为我在您的另一个问题中读到了评论),该包装标头执行类似以下操作以使其在C 和 C++:

#ifndef MY_CMOCKERY_H
#define MY_CMOCKERY_H

/*
    A wrapper for cmockery.h that makes it C++ friendly while keeping things
    the same for plain-old C
 */

#if __cplusplus
extern "C" {
#endif

#include "cmockery.h"

#if __cplusplus
}
#endif


#if __cplusplus
// fixup CMockery stuff that breaks in C++

#undef expect_string_count
#define expect_string_count(function, parameter, string, count) \
    _expect_string(#function, #parameter, __FILE__, __LINE__, (char*)string, \
                  count)

#endif


#endif  /* MY_CMOCKERY_H */

另一个好处是,现在您可以在 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++:

#ifndef MY_CMOCKERY_H
#define MY_CMOCKERY_H

/*
    A wrapper for cmockery.h that makes it C++ friendly while keeping things
    the same for plain-old C
 */

#if __cplusplus
extern "C" {
#endif

#include "cmockery.h"

#if __cplusplus
}
#endif


#if __cplusplus
// fixup CMockery stuff that breaks in C++

#undef expect_string_count
#define expect_string_count(function, parameter, string, count) \
    _expect_string(#function, #parameter, __FILE__, __LINE__, (char*)string, \
                  count)

#endif


#endif  /* MY_CMOCKERY_H */

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).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文