Boost logo

Boost :

Subject: Re: [boost] [winapi] Problem with the latest clang on Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-05 11:13:24


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk