Prev: Problem with compilation
Next: checking whether two vector references / pointers are the same
From: Doug Harrison [MVP] on 24 Apr 2008 21:58
On Thu, 24 Apr 2008 17:59:22 -0700 (PDT), qdin <eryqdin(a)gmail.com> wrote:

>Thanks for your explanation. It's all very clear now.
>
>I do have one more question, now about static function dll exporting.
>Basically - if I use __declspec(dllexport), does it export by name or
>by ordinal?

Always by name.

>I have a class with only static functions in it (the Factory class I
>mentioned above).
>I export each of these functions with __declspec(dllexport).

It's easier to dllexport the whole class, even a factory class like yours.
I would either dllexport the whole thing or use a namespace instead of a
class.

I trust you're using the macro technique to accomplish this, e.g.

#ifdef COMPILING_X_DLL
#define X_EXPORT __declspec(dllexport)
#else
#define X_EXPORT __declspec(dllimport)
#endif

You would replace "X" with the name of your DLL or something sufficiently
unique. The dllimport side is important to help the compiler generate more
efficient function calls.

>So I compiled this into a dll, and a link .lib,
>then compiled the link .lib into my client app.
>
>After this, I added (and exported) another static function in front of
>all other functions in the class, and compiled again.
>
>I did NOT relink the .lib into my client application.
>
>When I swap the new dll in, everything still works, and the proper
>functions are being called.
>I checked both dlls in depends.exe, and have seen that the ordinals on
>some functions do change between the two dlls,
>yet these functions work regardless of the dll that I use.
>
>I guess this would imply that it exports by name in this case (?)...

Yep.

>but then that raises the question of why you would want to export by
>ordinal in the first place?

Ordinals takes up less space, are faster to bind when the DLL is loaded,
and provide a tiny bit of obscurity. None of these reasons are very
compelling.

--
Doug Harrison
Visual C++ MVP
From: Ben Voigt [C++ MVP] on 28 Apr 2008 10:03
> I have a class with only static functions in it (the Factory class I
> mentioned above).
> I export each of these functions with __declspec(dllexport).

IMHO: Yuck!

Why deal with name mangling that takes place for member functions when you
don't have to? You can either dllexport an extern "C" forwarder function,
or use the linker .def file to assign a permanent name to these static
functions, then your names won't be compiler-version dependent.


From: ericyudin on 28 Apr 2008 11:52
On Apr 24, 9:58 pm, "Doug Harrison [MVP]" <d...(a)mvps.org> wrote:
> On Thu, 24 Apr 2008 17:59:22 -0700 (PDT),qdin<eryq...(a)gmail.com> wrote:
> >Thanks for your explanation. It's all very clear now.
>
> >I do have one more question, now about static function dll exporting.
> >Basically - if I use __declspec(dllexport), does it export by name or
> >by ordinal?
>
> Always by name.
>
> >I have a class with only static functions in it (the Factory class I
> >mentioned above).
> >I export each of these functions with __declspec(dllexport).
>
> It's easier to dllexport the whole class, even a factory class like yours.
> I would either dllexport the whole thing or use a namespace instead of a
> class.
>
> I trust you're using the macro technique to accomplish this, e.g.
>
> #ifdef COMPILING_X_DLL
> #define X_EXPORT __declspec(dllexport)
> #else
> #define X_EXPORT __declspec(dllimport)
> #endif
>
> You would replace "X" with the name of your DLL or something sufficiently
> unique. The dllimport side is important to help the compiler generate more
> efficient function calls.
>
> >So I compiled this into a dll, and a link .lib,
> >then compiled the link .lib into my client app.
>
> >After this, I added (and exported) another static function in front of
> >all other functions in the class, and compiled again.
>
> >I did NOT relink the .lib into my client application.
>
> >When I swap the new dll in, everything still works, and the proper
> >functions are being called.
> >I checked both dlls in depends.exe, and have seen that the ordinals on
> >some functions do change between the two dlls,
> >yet these functions work regardless of the dll that I use.
>
> >I guess this would imply that it exports by name in this case (?)...
>
> Yep.
>
> >but then that raises the question of why you would want to export by
> >ordinal in the first place?
>
> Ordinals takes up less space, are faster to bind when the DLL is loaded,
> and provide a tiny bit of obscurity. None of these reasons are very
> compelling.
>
> --
> Doug Harrison
> Visual C++ MVP

Thanks for your help, Doug.
-Eric
From: qdin on 28 Apr 2008 13:07
On Apr 28, 10:03 am, "Ben Voigt [C++ MVP]" <r...(a)nospam.nospam> wrote:
> > I have a class with only static functions in it (the Factory class I
> > mentioned above).
> > I export each of these functions with __declspec(dllexport).
>
> IMHO: Yuck!
>
> Why deal with name mangling that takes place for member functions when you
> don't have to? You can either dllexport an extern "C" forwarder function,
> or use the linker .def file to assign a permanent name to these static
> functions, then your names won't be compiler-version dependent.

Good point. Compiler independence will eventually be of interest, and
I guess name mangling can change from version to version.
So I switched the class to a namespace and individually did an
extern "C" DLLEXPORT func();
on each function I"m exporting.

Thanks.
From: qdin on 28 Apr 2008 13:09
On Apr 24, 9:58 pm, "Doug Harrison [MVP]" <d...(a)mvps.org> wrote:
> On Thu, 24 Apr 2008 17:59:22 -0700 (PDT), qdin <eryq...(a)gmail.com> wrote:
> >Thanks for your explanation. It's all very clear now.
>
> >I do have one more question, now about static function dll exporting.
> >Basically - if I use __declspec(dllexport), does it export by name or
> >by ordinal?
>
> Always by name.
>
> >I have a class with only static functions in it (the Factory class I
> >mentioned above).
> >I export each of these functions with __declspec(dllexport).
>
> It's easier to dllexport the whole class, even a factory class like yours.
> I would either dllexport the whole thing or use a namespace instead of a
> class.
>
> I trust you're using the macro technique to accomplish this, e.g.
>
> #ifdef COMPILING_X_DLL
> #define X_EXPORT __declspec(dllexport)
> #else
> #define X_EXPORT __declspec(dllimport)
> #endif
>
> You would replace "X" with the name of your DLL or something sufficiently
> unique. The dllimport side is important to help the compiler generate more
> efficient function calls.
>
> >So I compiled this into a dll, and a link .lib,
> >then compiled the link .lib into my client app.
>
> >After this, I added (and exported) another static function in front of
> >all other functions in the class, and compiled again.
>
> >I did NOT relink the .lib into my client application.
>
> >When I swap the new dll in, everything still works, and the proper
> >functions are being called.
> >I checked both dlls in depends.exe, and have seen that the ordinals on
> >some functions do change between the two dlls,
> >yet these functions work regardless of the dll that I use.
>
> >I guess this would imply that it exports by name in this case (?)...
>
> Yep.
>
> >but then that raises the question of why you would want to export by
> >ordinal in the first place?
>
> Ordinals takes up less space, are faster to bind when the DLL is loaded,
> and provide a tiny bit of obscurity. None of these reasons are very
> compelling.
>
> --
> Doug Harrison
> Visual C++ MVP

Thanks for your help, Doug.
First  |  Prev  | 
Pages: 1 2
Prev: Problem with compilation
Next: checking whether two vector references / pointers are the same