It's not just a question of style. This is likely break with a recent clang. Maybe gcc, too. The compiler has to check that the same named functions with C linkage are equivalent (i.e. receive the same arguments of the same type), and this is not the case with enums. This is one reason why Boost.WinAPI is so complicated.
Thanks, I did not realise that. I tested it only with different versions of GCC (as you know, I have a nicer solution for MSVC) and that does work there (though it warns): extern "C" void f(int) {}; namespace x { extern "C" void f(unsigned int) {} } Gcc is quite tolerant here, but you're right, Clang (rightfully) complains. But I guess if I do that void f(unsigned int) __asm__("f"); I'll be tarred and feathered.
My guess is that unless you are able to avoid enums altogether, you have no choice but to include windows.h. Maybe you could reduce the negative impact of that by providing a way to build that part of your library separately.
It looks that way. Well it is not an esssential feature and it would only be necessary on windows. Still, it's really annoying, that you would need to built a binary because the of the bloody winapi. I hate that thing. And btw.: I did realize how much evil details the winapi holds. So good work, it's really helpful.