Re: [boost] [Style] Import a C function with wrong signature on purpose

Subject: Re: [boost] [Style] Import a C function with wrong signature on purpose
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-05-02 16:59:28

> 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.