Sign in to follow this  

Creating a Wrapper few questions.

This topic is 4729 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've never coded a wrapper before, so I have a few questions. First, I'd like to mention that I'm looking over the source code for a Hekkus wrapper. It basically wraps everything into C functions, compiles into a .dll, then wraps those functions in a .NET class by calling them from the .dll. My questions pertain to the C++ code. I've been reading the msdn library and I just want to make sure I have the terminology correct. First question:
#ifdef __cplusplus
extern "C"
{
#endif // __cplusplus
This basically declares all functions within the { } as C functions, which means they can be used by the C language. My question is, why is this necessary for creating a .dll, or is it not? Is there a reason why the functions must be exported as C functions? Second question: #define HEKKUS_API __declspec(dllexport) HEKKUS_API Sound* __stdcall Sound_Create(HINSTANCE hInst); This basically says the function is to be exported for use, right? Although, I am curious, if we are creating a .dll wouldn't we want all the functions to be exported? So what would the purpose of dllimport be? This is in the header file:
#ifdef HEKKUSSS_EXPORTS
#define HEKKUS_API __declspec(dllexport)
#else
#define HEKKUS_API __declspec(dllimport)
#endif
Last question: __stdcall HEKKUS_API Sound* __stdcall Sound_Create(HINSTANCE hInst); __stdcall basically says that it's a win32 function. So all this is saying is that it's a win32 function (I'm a broken record, heh). Since it's a .dll, I imagine this needs to be used so the calling program knows it's a win32 function. Right? If there's a tutorial on creating .dlls, I'd be more than happy to read 'em. However, most tutorials don't go into the nitty gritty detail of what most things do, and the msdn library isn't always good with their explanations (which I did read, and yet I still have questions). In any case, if there's a tutorial and/or reference that explains the above, I'd appreciate the link. Thanks in advance for your help.

Share this post


Link to post
Share on other sites
I'm going to answer your second question first, cause it's easy ...

These lines of code are in a header file, and that header file is used by both the implementing cpp file, AND by the client cpp files which use your library / dll.

When compiling the library itself, you set the HEKKUSSS_EXPORTS to true, so that the header file basically says to dllexport eveything that is part of the HEKKUS_API

but when the users of your library compiles their code they will NOT have defined HEKKUSSS_EXPORTS, so that header file will be full of dllimports when they compile it (you know the preprocessor does this work before the compiler sees the file - so what is really going on here is a trick where one header file is doing the work of 2 seperate files (an import and an export file) depending on the one symbol 'HEKKUSSS_EXPORTS' being defined or not)

Share this post


Link to post
Share on other sites
The reason why dll functions are always exported as C calls if possible has to do with the fact that the Pascal and C langauges were very explicit about the eact conventions used by the function, how they are named, called, who's responsibility it is to pop the arguments, where the return type is passed, etc ... so LOTS of other langauges know how to use function which adhere to either of these two "calling conventions".

C++ did not specify such things really, and what's more, in order to support overloading, member functions, namespaces, etc ... it has to perform name mangling. The langauge does not specify how this mangling must be done, so no 2 compilers do it the same, so noone can use each others compiled c++ files.

Share this post


Link to post
Share on other sites
third question:

__stdcall is defined as PASCAL calling convention. Which is what all non variable argument functions in the Win32 api use (and the windows api before that).

and you will find windows.h typedefs everything, in case they change their mind when running on different platforms ...

so you ALWAYS use things like stdcall, instead of pascal because on some platform besides x86, the windows api might use some other calling convention ... they are only tied to using the same defines when they want to be binary compatible, but if they support a PowerPC chip they could change the rules to be whatever they want (like for the XBox 2).

Share this post


Link to post
Share on other sites

This topic is 4729 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this