Export C++ symbols

[giraldeau]

Export C++ symbols for Windows using macro. This is done adding MUPARSERLIB_EXPORTS to every classes that belongs to the API.

[giraldeau]

Beware: the __cdecl should not be defined on classes.

[beltoforion]

Sorry i totally missed this part of the discussion. C++ exports cannot safely work with an API having STL dependencies. For this reason i do not want them.

[jschueller]

This could be disabled by default (only export the C API), with a warning mentionning the compiler and stl runtime compatibility if enabled what do you think?
I think there are plenty libraries out there that use the stl without getting their tracker flooded with bug reports about abi compatibility, as his responsibility fals back to distro maintainers etc. Muparser can also be entirely included in a project's source code so it doesn't apply there either.
Another point is that its not fair to Windows developers wanting to use the c++ api as allowed on Linux.

[beltoforion]

On Windows there are no package maintainers. It is much more common to drop a dll into the program folder and expect it to work. There are plenty of visual studio versions in productive use. People will expect a DLL to work because it is just a DLL like so many others they used in the past. After all why should one have to recompile a shared library just because the compiler was upgraded? What good is a shared lib that cannot be shared by applications build with different versions of the compiler? Such a library would be combining the disadvantages of a static library with the disadvantages of a dynamic library.

The recommended way to use muparser on windows is as a static library or by including the source code. The overwhelming majority of windows programmers is using the exact same API as their colleges working with Linux. This is open source I'm not preventing anyone from building, using or providing a DLL with STL interface. I just happen to think that this is not a good idea and i don't want to have anything to do with it.

The interface of the muparser.dll has always been a C-interface. The goal was interoperability not having a shared library for the sake of having a shared library. It was aimed at people writing C#, C or Fortran code.

[Ulysses1337]

With the advent of vcpkg, I ask you to reconsider.

https://github.com/Microsoft/vcpkg/tree/master/ports/muparser

[beltoforion]

I don't really see how vcpkg is changing anything but if i get a tested modification that implements this without breaking stuff and without changing the meaning of existing macros i will merge it.

[jschueller]

My PR was working, if you want it tested you can enable continuous integration using Travis/Appveyor services for this repository (see #36), the configuration files are already here. I can resubmit #43 without renaming the macros if that's a concern.

[beltoforion]

Ok, please resubmit without renaming the macros.

[jschueller]

Ok @beltoforion see #49

[beltoforion]

Ok, merged. Thanks