> I don't know about C11, but i vote for the use of a custom minimum
necessary library (static/dll) with an API compatible (glib or c11) ?
I dont want to jump from one OSAL library to another. The only reasonable
step to supersede glib is moving to C11. And it's a shame that even in 2017
there are
Isn't OS/2 already dead anyway?
On Wed, Oct 11, 2017 at 10:19 AM, Tom M. wrote:
> TinyCThread looks good. Even though they only support Win32 and Pthreads
> they implement the C11 API. So we could move to C11:
>
> #ifdef __STDC_NO_ATOMICS__
> #error "Compiler has no C11 atomics"
> #endif
>
> #
Hi,
>Tom: Would this really make the Windows users life easier as originally
>intended by the glib removal?
Removing glib in Windows is benefict only because the glib dlls is very large
compared to the size of the FluidSynth library.
The effective code in glib necessary to Fluidsynth (mutex
> Any solution staying with Visual Studio would be highly appreciated.
Agreed. I actually forgot the fact that C11 programs should be compilable
in VS using llvm-clang. Not sure if this is an option, never tested myself.
Tom
2017-10-11 12:45 GMT+02:00 Reinhold Hoffmann :
> Hi,
>
> Many of the
Hi,
Many of the Windows users use Visual Studio (good or bad).
Any solution staying with Visual Studio would be highly appreciated.
Reinhold
_
Von: fluid-dev [mailto:fluid-dev-bounces+reinhold=notation@nongnu.org] Im
Auftrag von Tom M.
Gesendet: Mittwoch, 11. Oktober 2017 10:1
handler = server->newclient(server->data, addr);
newclient is a caller provided callback function to return any instance of
fluid_cmd_handler_t. This instance is only *assigned* to any created
fluid_client, it's not *owned* by it. Thus the caller would be responsible
for delete_fluid_cmd_handler()
TinyCThread looks good. Even though they only support Win32 and Pthreads
they implement the C11 API. So we could move to C11:
#ifdef __STDC_NO_ATOMICS__
#error "Compiler has no C11 atomics"
#endif
#ifdef __STDC_NO_THREADS__
#include
#else
#include
#endif
This however might be the end of
