On Jun 9, 2011, at 12:05 PM, Steven G. Johnson wrote:
On Jun 9, 2011, at 10:46 AM, Day, Tom wrote:
There's a lot of Windows stuff that can't call cdecl functions,
such as Excel VBA.
Thanks for reminding about the stdcall issue. I've just uploaded
the Windows DLL for NLopt 2.2.3, which fixes the header file and
compilation to use stdcall for the callbacks (as well as other API
functions).
Actually, on second thought, I've reverted this.
The problem with making the callbacks use stdcall is that every user
of NLopt then needs to put __stdcall in their definition of the
objective function. i.e. it breaks source compatibility on Windows
(not to mention binary compatibility).
As usual, Microsoft created a mess -- if they wanted people to use
stdcall on Windows, they should have made it the default. For that
matter, they should have just settled on one ABI.
The more I think about it, the more it seems like I should have just
not used stdcall at all on Windows. It seems like .NET can call
cdecl functions after all. And to use NLopt from Excel, I'm guessing
that you will probably need to write some glue code in C or C++ anyway
just to deal with datatypes and callbacks, and that glue code can
paper over any calling-convention difference.
Steven
_______________________________________________
NLopt-discuss mailing list
[email protected]
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/nlopt-discuss