On Monday, 2 May 2016 23:17:37 MSK Klemens Morgenstern wrote:
Now of course, that would never be accepted into the boost/winapi module, but I could just add this in my library. Would this be a dealbreaker for a library attempting to become a boost-library? If so, I'd need to put it into a source file and include windows.h there, but I'd really like the library to be header-only and under no circumstances include windows.h there.
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. 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.