[ODE] Why no __declspec(dllexport)
Royce Mitchell III
royce3 at ev1.net
Tue Apr 27 13:31:30 MST 2004
gl wrote:
>>While microsoft's interface gives you a little more control, I think
>>your use of connotative language gives you away. "Just exporting
>>everything non-static" is the same as "very specifically defining" an
>>interface, as long as you're "very specific" about what you declare
>>
>>
>static.
>
>Did you read what I wrote? Let's say you have a class member function - you
>can't just make it static if it relies on the 'this' pointer. So how would
>your scheme work?
>
>
>
You could use the PIMPL methodology, or have non-member static
"friends". The PIMPL methodology solves other problems as well, so is a
good solution in this case.
I think it would be remiss, however, to neglect the fact that very few
*nix programmers have embraced C++. Therefore, I don't believe this
issue has truly been addressed by the community at large. There is a
stigma about g++'s code size and/or performance in the *nix community,
and most just code in C.
So, in summary:
a) you can hide class functions from being exported by putting them in a
private implementation class, *or* via non-member static friends ( who
cares if this is ugly, you are trying to hide the function, remember )
b) dllimport/dllexport makes this whole mechanism cleaner, and the
non-MSVC crowd has not embraced ( IMHO ) C++ enough to really explore
whether or not it would be advantageous. ( Corrections welcome, I don't
consider myself an expert on this 2nd point - it's just my observation )
--
-------------------------
http://wecanstopspam.org/
More information about the ODE
mailing list