其中gcc distro支持__declspec(dllexport)_cdecl和_stdcall [英] which gcc distro supports __declspec(dllexport) _cdecl and _stdcall

查看:435
本文介绍了其中gcc distro支持__declspec(dllexport)_cdecl和_stdcall的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想开始使用mingw(MinGW-w64)和eclipse在C ++ Builder工作了很长时间。我很困惑。



我的工作主要围绕供应商提供的以MSVC为中心的API。它由3个头文件和几个libs组成。我可以在C ++ Builder中使用它们的头部不变,但是遇到很多g ++的问题。

  #define GX_WRAPPER_FUNC __declspec(dllexport)
#define GX_STANDARD_FUNC
#define GX_WRAPPER_CALL _cdecl
#define GX_STANDARD_CALL _stdcall


#define GX_OBJECT_PTR void *

#define GX_VAR
#define GX_CONST const

#define GX_VOID void
#define GX_LONG long
#define GX_DOUBLE double
#define GX_HANDLE long

#define GX_LONG_PTR long *
#define GX_DOUBLE_PTR double *
#define GX_HANDLE_PTR long *
#define GX_ASTR_PTR char *
#define GX_WSTR_PTR wchar_t *
#if defined(GEO_UTF8)
#define GX_STR_PTR GX_ASTR_PTR
#elif defined(_UNICODE)
#define GX_STR_PTR GX_WSTR_PTR
#else
#define GX_STR_PTR GX_ASTR_PTR
#endif

#endif


#ifdef __cplusplus
externC{
#endif



/ * ---------------- Copy_3DN [_public] ---------------- * /

GX_WRAPPER_FUNC GX_LONG GX_WRAPPER_CALL
Copy_3DN(GX_VAR GX_OBJECT_PTR,
GX_CONST GX_HANDLE_PTR,
GX_CONST GX_HANDLE_PTR);
GX_STANDARD_FUNC GX_LONG GX_STANDARD_CALL
Std_Copy_3DN(GX_VAR GX_OBJECT_PTR,
GX_CONST GX_HANDLE_PTR,
GX_CONST GX_HANDLE_PTR);
...数百其他类似的内容

这产生了一大堆 错误。



通过重新定义前4个定义,我取得了一些成功:

  #ifdef __GNUC__ 
#define GX_WRAPPER_FUNC __attribute__((dllexport))
#define GX_STANDARD_FUNC
#define GX_WRAPPER_CALL
#define GX_STANDARD_CALL

# else
#define GX_WRAPPER_FUNC __declspec(dllexport)
#define GX_STANDARD_FUNC
#define GX_WRAPPER_CALL _cdecl
#define GX_STANDARD_CALL _stdcall
#endif
 <$ c $> 

c> GX_WRAPPER_FUNC GX_LONG GX_WRAPPER_CALL
RegisterResourceTracking_GEO(GX_VAR GX_OBJECT_PTR,
GX_CONST GX_LONG_PTR,
GX_OBJECT_PTR,
void(_stdcall * param3)(void *));

我真的想使用这些头没有编辑它们, gcc发行版的正确选择可能支持这种语法,但我试过一个已经没有运气的数字。我试过的MinGW-w64和Nuwen和TDM的i686和x86-64变体。我不关心跨平台的问题,因为主机应用程序是Windows只有反正,对于我自己的固执的原因,我不想放弃和切换到MSVC。



那么,有没有一个gcc发行版将支持这种语法?

解决方案

p>作为解决方法,您可以扩展您的宏定义集合以涵盖gcc不能识别的关键字:

  #ifdef __GNUC__ 
#define _cdecl __attribute __((cdecl))
#define __cdecl __attribute __((cdecl))
#define _stdcall __attribute __((stdcall))
#define __stdcall __attribute __ stdcall))

#define GX_WRAPPER_FUNC __attribute__((dllexport))
#else
#define GX_WRAPPER_FUNC __declspec(dllexport)
#endif

作为一个奖励,那些使原来的定义在这里工作:

  #define GX_STANDARD_FUNC 
#define GX_WRAPPER_CALL _cdecl
#define GX_STANDARD_CALL _stdcall


注意这是可能的,因为大多数MSVC扩展是新的简单关键字,从保留给实现的标识符空间。 gcc的多令牌 __属性__(())魔术使得映射在相反的方向完全不可能。因此,任何时候使用gcc非便携式功能编写代码,将它们隐藏在宏之后。)


I am trying to get started using mingw (MinGW-w64) and eclipse after working in C++Builder for a long time. I'm very confused.

My work mostly revolves around a vendor supplied API which is MSVC-centric. It consists of 3 header files and a couple of libs. I was able to use their headers unchanged in C++Builder but am running into lots of problems with g++.

#define GX_WRAPPER_FUNC  __declspec(dllexport)
#define GX_STANDARD_FUNC
#define GX_WRAPPER_CALL  _cdecl
#define GX_STANDARD_CALL _stdcall


#define GX_OBJECT_PTR    void*

#define GX_VAR
#define GX_CONST         const

#define GX_VOID          void
#define GX_LONG          long
#define GX_DOUBLE        double
#define GX_HANDLE        long

#define GX_LONG_PTR      long*
#define GX_DOUBLE_PTR    double*
#define GX_HANDLE_PTR    long*
#define GX_ASTR_PTR      char*
#define GX_WSTR_PTR      wchar_t*
#if defined(GEO_UTF8)
   #define GX_STR_PTR       GX_ASTR_PTR
#elif defined( _UNICODE)
   #define GX_STR_PTR       GX_WSTR_PTR
#else
   #define GX_STR_PTR       GX_ASTR_PTR
#endif

#endif


#ifdef __cplusplus
   extern "C" {
#endif



/*---------------- Copy_3DN[_public] ----------------*/

GX_WRAPPER_FUNC GX_LONG GX_WRAPPER_CALL
Copy_3DN(GX_VAR   GX_OBJECT_PTR,
         GX_CONST GX_HANDLE_PTR,
         GX_CONST GX_HANDLE_PTR);
GX_STANDARD_FUNC GX_LONG GX_STANDARD_CALL
Std_Copy_3DN(GX_VAR   GX_OBJECT_PTR,
             GX_CONST GX_HANDLE_PTR,
             GX_CONST GX_HANDLE_PTR);
...hundreds more like this

This yields a whole bunch of "expected initializer before " errors.

I've had some success by redefining the first 4 defines like this:

#ifdef __GNUC__
    #define GX_WRAPPER_FUNC  __attribute__ ((dllexport))
    #define GX_STANDARD_FUNC
    #define GX_WRAPPER_CALL
    #define GX_STANDARD_CALL

#else
    #define GX_WRAPPER_FUNC  __declspec(dllexport)
    #define GX_STANDARD_FUNC
    #define GX_WRAPPER_CALL  _cdecl
    #define GX_STANDARD_CALL _stdcall
#endif

but it barfs later on when it encounters

GX_WRAPPER_FUNC GX_LONG GX_WRAPPER_CALL
RegisterResourceTracking_GEO(GX_VAR   GX_OBJECT_PTR,
                             GX_CONST GX_LONG_PTR,
                             GX_OBJECT_PTR,
                             void (_stdcall *param3)(void*));

I would really like to use these headers WITHOUT editing them, and I've seen some references that suggest the correct choice of gcc distro might support this syntax, but I've tried a number already with no luck. I've tried both the i686 and x86-64 variants of MinGW-w64 and Nuwen and TDM. I'm not concerned with cross platform issues as the host app is Windows only anyways, and for my own stubborn reasons I don't want to give up and switch to MSVC.

So, is there a gcc distro which will support this syntax? If not, what is the path of least resistance?

cheers

解决方案

As a workaround, you can expand your set of macro definitions to cover the keywords gcc doesn't recognize:

#ifdef __GNUC__
    #define _cdecl __attribute__((cdecl))
    #define __cdecl __attribute__((cdecl))
    #define _stdcall __attribute__((stdcall))
    #define __stdcall __attribute__((stdcall))

    #define GX_WRAPPER_FUNC  __attribute__ ((dllexport))
#else
    #define GX_WRAPPER_FUNC  __declspec(dllexport)
#endif

As a bonus, those make the original definitions here work:

#define GX_STANDARD_FUNC
#define GX_WRAPPER_CALL  _cdecl
#define GX_STANDARD_CALL _stdcall

(FWIW, note that this is possible because most MSVC extensions are new simple keywords, from the space of identifiers reserved to the implementation. gcc's multi-token __attribute__(()) magic makes mapping in the reverse direction completely impossible. So any time you write code using gcc non-portable features, hide them behind macros.)

这篇关于其中gcc distro支持__declspec(dllexport)_cdecl和_stdcall的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆