[Cython] Wrapping C++ Classes

[Michael Abshoff]

Chris Swierczewski wrote:
> Hello,
> 
> I'm having a compile issue with wrapping a certain C++ class. Allow me
> to describe the situation first before stating the issue.
> 
> The Situation: the opentick API is a collection of cross-platform,
> cross-language libraries (and headers in the C++ flavor) for receiving
> live streams of financial data. (See www.opentick.com) Among the
> API/source languages available, there is a collection of
> cross-platform C++ headers along with a static library. What is meant
> by cross-platform? Well, depending on which platform you're using,
> different parts of the code are called and different macro definitions
> are made. For example, when compiling on a Linux system one must write
> 
> #define __LINUX
> 
> at the top of their code before calling the appropriate headers. Now,
> the main class is defined in the following way:
> 
> class DLL_EXP OTClient:
> {
>     public:
>         ...
> }
> 
> When running in the windows environment (that is, if you #define
> __WIN), DLL_EXP is set to "__declspec(dllexport)" which, to my
> understanding, has to do with using .dll files for callbacks akin to
> how twisted works. However, when compiling in the Linux environment,
> (#define __LINUX) the definition of the macro is "empty". That is, at
> some point before the definition of the class, we simply have
> 
> #define DLL_EXP
> 
> implying that no .dll calls need to be made.
> 
> My Question (Finally): How do I go about wrapping this C++ class with
> this strange little define hanging around the class declaration?
> Methinks I'm having compile issues precisely because of this addition.
> I checked the Cython wiki and the Sage Wiki on wrapping C++ classes
> and couldn't find anything that looked like this. Thank you very much
> in advance for any help! (And thank you for such an awesome
> technology!)
> 

Hi,

Have you tried passing -D__Linux at the build time of the extension?

I saw your discussion with Glenn and the removal of the 
__declspec(dllexport) constructs as suggested by him will bite us in the 
ass down the road since we intent to support MSVC for which the above 
constructs are needed.

Cheers,

Michael