Subject: Re: [boost] [Style] Import a C function with wrong signature on purpose
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-05-08 07:14:19
> 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.
>
I missed the most obvious solution (I am using GetLastError because it's
shorter):
inline HANDLE_ kernel32_handle()
{
//it's a system dll, so I don't really need to clean up
static HANDLE_ h = get_module_handle("Kernel32.dll");
return h;
}
inline DWORD_ get_last_error()
{
typedef DWORD_ WINAPI (*GetLastError_t)();
static GetLastError_t p =
reinterpret_cast<GetLastError_t>
(get_proc_address(kernel32_handle(), "GetLastError"));
return (*p)();
}
I tested that directly with the winapi, the loaded address is correct.
That way I could load any function and override the enum type. I would
have few static handles here, but since they all point to system-apis I
don't think it's a problem to not clean them up (though that could be
done via unique_ptr). That would also be pure C++03, but of course
violate the current winapi style. Would that be acceptable for the
winapi by any chance?