On 6/5/2015 6:21 AM, Andrey Semashev wrote:
On Friday 05 June 2015 05:45:18 Edward Diener wrote:
The clang explanation, when asked to point to the C++ standard, is:
"[dcl.link]/6: "At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function."
[basic.link]/10: "the types specified by all declarations referring to a given variable or function shall be identical"
So the program is ill-formed because the same function is declared with two different types."
Ok, I'll modify Boost.WinAPI according to Peter's suggestion in a few days. I intend to keep dllimport attributes on the functions though.
That's fine. Just for you interest I asked on the mingw mailing list why their implementation did not have dllimport while mingw64 does have dllimport, and their response was: "AFAIK, the dllimport attribute is not needed with C functions, but it might be needed with variables and C++ classes. See the GCC manual for the details." From the GCC docs: "For Microsoft Windows targets the use of the dllimport attribute on functions is not necessary, but provides a small performance benefit by eliminating a thunk in the DLL." I quoted this in my reply to their reply but that was not going to change their mind evidently as they did not respond further. BTW maybe you can coordinate things so that fixing ticket https://svn.boost.org/trac/boost/ticket/11338 is not going to be duplicated effort.
If that still breaks clang then I believe clang ticket should be reopened (or a MinGW ticket should be filed).
No problem. I can do that if necessary.
Thanks Edward for communicating this through.
Clang, for all its pickiness, problems, and slow compiler speed, is still a great compiler to use to check code so I do have an interest in seeing that it works whenever possible with the Boost code I write or test.