[ODE] Why no __declspec(dllexport)

[gl]

> 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?

And what about globals that you _don't_ want exported?

> Right, and I'm pointing out that (a) DLLs are similar in use to static
> libraries

... but behind the scenes the functions are dynamically imported at runtime,
whilst static lib references are resolved at link time - hence the different
mechanisms.  As this is part of the OS, there we are.

, (b) static libraries only have the C "static" keyword to
> define the interface of a compilation unit, and (c) for static
> libraries, no one really complains about lack of any interface
> specification mechanism.

So is 'static' used on other compilers to specify DLL exports?  If no (and I
see a lot of .def files being used instead), what's your point?

And the reason for fine grained control is essentially the same reason you
have public/protected/private class member sections.  If you want to specify
a clean interface, and/or want to hide various internals (if only for
clarity), it makes sense.  Whether you personally use that approach or not
is irrelevant.

> Right.  DLLs have them.  Static libs don't.  People switch between
> static libs and DLLs pretty easily.  I've never heard anyone complain
> that static libs need a more fine grained way of specifying their
> interface.  Therefore, I suspect they're not really needed for DLLs
either.

Is this a dig at MS' compiler, or a general complaint about C/C++ on _any_
platform?

> It's a good thing I didn't assume it, then, but rather said "either
> microsoft is being evil, or the feature had more problems than solutions
> in retrospect."  Are you sure you didn't just knee-jerk to the first
> half of that thought?

Nope, because in the 2nd half you assumed it causes problems.  Actually it
solves them for VC users, and as the solution is usually macro based, you
simply set it up so it vanishes on other builds.  What problems?

> I've never heard anyone on Linux, Solaris or IRIX complain about the
> lack of it.  I can't remember how it worked on the Amiga, but if I lost
> it in moving to Unix, I didn't miss it.  Same with MacOS.

I know nothing about those platforms, but I know DLLs, and that this makes
life a lot easier.  That's why it exists, and that's why people use it this
side of the pond.

As to the original request about using them in ODE, it would make sense for
Windows users, as it automatically keeps the imports/exports up-to-date,
unlike .def files.  The downside would be a simple macro prefix on any
public new functions (and a retrofit to the existing ones of course) -
doesn't seem a big deal to me.
--
gl