[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