Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at