[ODE] Why no __declspec(dllexport)

Jon Watte hplus-ode at mindcontrol.org
Wed Apr 28 12:12:48 MST 2004


> 3. a function or global variable that isn't visible outside the current 
> compilation unit.

> And that, during this entire discussion, I've been talking about the 
> third use?  Since that's what's relevant for visibility of 
> functions/variables?

You can't make classes static, so their constructors and members 
will always be exported, unless you have other export control methods.

You may also want to have globals or other symbols shared between 
compilation units within a library, but not visible outside the 
library. Like, you don't want to overwrite the client program's 
"malloc()" with your own. However, without explicit export control, 
you can't do that, because the C/C++ language by and large is silent 
on specifics about linkage.

Microsoft decided that they needed the language to do that, so they 
added __declspec(). It's a shame that the language body itself couldn't 
have done something standard instead -- now, we'll have to live with 
the de facto standard.

Cheers,

			/ h+




More information about the ODE mailing list