On Freitag, 8. Februar 2019 01:03:59 CET justnope wrote: > > Yes, that makes sense. Would you also share your real name so I can > > credit you > > > for your patch? > > I'm fine with being uncredited or using justnope.
Committed, slightly modified. Thanks! I figured we should fix the same issue with DLS::File::ExtensionFiles one day, so I added a FIXME comment there for now. > Another thing I noticed but I'm unable to test is that in > Serialization.cpp the return value of abi::__cxa_demangle isn't freed. Yep, good catch! I just committed a fix for that as well, thanks! > > 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: > I've used the typedef and a check for msvc 2015 or higher. If it's a > lower version an preprocessor error gets displayed. Installing 2013 only > to check if it works seems overkill. That's fine with me. > > As you already assumed, I would like to avoid new dependencies as much as > > possible. > I've implemented demangling and it seems to work. > > I've used dbghelp.dll. It's also possible to use an undocumented crt > function, but I rather add a dependency on dbghelp (which is always > installed on windows) than using that undocumented crt function. If dbghelp.dll is part of the system anyway then I would favour it as well. I just made a quick lookup on the net if that DLL was probably introduced by some Windows version, but could not find anything useful. The Microsoft docs just say "available on all supported systems", so not sure if XP,Vista,7 users would have it as well, but I guess we will find out. > When you use raw_name it gives you a string that you can demangle but it > adds a "." in the beginning of the string which you must skip. > > The question I have is that in the documentation it states that function > I call to demangle is not thread safe. So the question I have is: can > DataType::customTypeName be called from different threads? Well, at the moment the Serialization API is only used by gigedit which calls it always on the main thread. But it is a good point and I will add an API doc comment for that issue to be aware of on Windows to avoid potential future issues. > I'm also able to build all the tools except for: akaiextract, gig2mono, > gig2stereo. The reason is I have to write a replacement for opendir. > Maybe at a later date it can be implemented if there's demand for it. > The other tools compiled without any modification. You might have a look at InstrumentEditorFactory::LoadPlugins(), here is the link to the relevant code portion: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/plugins/InstrumentEditorFactory.cpp?revision=3034&view=markup#l158 That might be a candidate for borrowing the required code for the opendir() implementation, which uses FindFirstFile() and FindNextFile() there. CU Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
