[ODE] Why no __declspec(dllexport)

[gl]

> You're talking about the user's choice; I'm talking about Microsoft's
> choice.  The other option for Microsoft was to use the facilities
> already built into C and C++, the same facilities they use for static
> libs: functions are exported by default, but not if preceded by the
> keyword "static."

I don't follow you - 'static' can't be applied to class members willy-nilly
for example.  You may also have plenty of global functions/variables (global
to the DLL code that is) that you don't want exposed to the calling app.
The whole idea is that you can very specifically define the public DLL
interface, rather than just exporting everything non-static.

> Can't you so the same thing with a statically compiled library?  If so,
> I don't think it's missed much.  I've never heard anyone argue for dlls
> over static libs simply because of ease of specifying what's exported or
> not.

We were talking about DLLs, which is where you can use the
__declspec(dllimport/dllexport) semantics in VC.   They are used in the
public DLL headers: 'export' dumps the class/function/var/etc into the DLL's
accompanying import library, whilst 'import' tells the compiler to
auto-import the function/var from the DLL.  You then just link your app with
the import library and everything else just works (well, you can even
auto-link the lib from the headers with a non-cross platform #pragma : ).
If you look at the sample that was posted, import/export is toggled based on
a macro definition, so the right one is chosen, depending on whether you're
compiling the DLL (export) or compiling the calling app (import).

The reason I sighed because of the automatic 'MS is evil' assumption.  This
stuff is there because it genuinely makes life much easier on us.  If there
is a cross-platform method of doing this, with as much convenience, then you
have a point - but I haven't seen it.
--
gl