On Saturday, 2. Februar 2019 02:53:14 CET justnope wrote: > > size_t is an unsigned type, whereas ssize_t is signed. So these two types > > are used in the code for purpose and simply replacing one with the other > > would break things, especially replacing ssize_t by size_t is not a good > > idea. > > > > It would make more sense to find an equivalent type available with msvc > > and to add an appropriate typedef for msvc instead. > > Or if c++11 is acceptable I could just use auto.
Adding a C++11 dependency just for this minor issue is really not neccessary. I just googled "ssize_t windows" and the solution seems to be: #if defined(_MSC_VER) #include <BaseTsd.h> typedef SSIZE_T ssize_t; #endif As suggested here: https://stackoverflow.com/questions/22265610/why-ssize-t-in-visual-studio-2010-is-defined-as-unsigned And here is a list of Microsofts's predeclared data types, which also lists SSIZE_T along with its precise definition and associated header file on Windows: https://docs.microsoft.com/en-us/windows/desktop/winprog/windows-data-types However maybe you have to fine tune that solution above by also checking the MSC version, because as far as I can see it, in previous MSVC versions there used to be POSIX header files where ssize_t had been declared on Windows, which was later removed, and I don't know if SSIZE_T was always there. > > Does msvc not ship with autoconf at all? If not, maybe a small script > > triggered by the msvc project or by cmake might be an alternative that > > would grep the latest version number from configure.ac? > > I added this to the cmake file. It now gets the version info from > configure.ac. Great! One place less to care about version info! > > I see that you actually disabled demangling completely for msvc. I am not > > sure, but isn't there an alternative function for mscv that's called > > undecorate symbols "unDec" or something? At least that's what I found > > somebody suggested on the net. > > I've disabled it temporarily. I did some searching and I think I can use > dbghelp.dll it's supposed to be included in every version of windows. > > Another option was to use boost, I thought it included a demangler. The > advantage is that it is cross platform, but maybe it's a bit too heavy > handed. I don't know what your thoughts are on using boost. As you already assumed, I would like to avoid new dependencies as much as possible. > If it's ok, I've made a project on github to track the changes I made: > https://github.com/justnope/libgig > It's easier for me to work on and maybe more convenient than to send the > patches each time. If rather receive the patches each time, let me know. Well, once your changes are ready to be committed on our side, I would appreciate if you'd just send one patch with your changes or a link to that patch. CU Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
