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