Re: [boost] [type_traits] Variadic function pointer with __fastcall calling convention

Subject: Re: [boost] [type_traits] Variadic function pointer with __fastcall calling convention
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-10-07 18:24:22

On 10/7/2013 2:05 PM, Stephan T. Lavavej wrote:
>> If this is left out of a function specification, is not the
>> default calling convention user-specified, with __cdecl being the
>> default ?
>
> Yes for ordinary functions (non-varargs, non-member). Member functions (non-varargs) always default to __thiscall.
>
>> So if the end-user changes the default to something other than
>> __cdecl is that considered the end-user's fault with VC++ ?
>
> Our goal for VC's STL is to be immune to all of the calling-convention switches (/Gd, /Gr, /Gz, /Gv). I believe that 2013's <type_traits> has achieved this (except for /Gv, which we've fixed post-2013-RTM), although I am aware of bugs elsewhere (mostly in <functional>).
>
> Because varargs functions (member and non-member) are always __cdecl, regardless of the calling-convention switches, it doesn't matter if you mark them as such, or leave them unmarked.
>
>> I believe that clang wants to be compatible enough to VC++ on Windows to
>> be able to compile Windows header files, but still wants to follow the
>> C++ standard as closely as possible.
>
> Well, calling conventions are non-Standard.

Agreed ! What I think clang should do, when emulating VC++ under 
Windows, is to do what VC++ does. In the area of calling conventions 
with varargs clang should accept anything the user specifies and 
silently treat the calling convention as __cdecl. As I understand your 
explanation that is what VC++ does.

OTOH, when dealing with VC++ and other compilers emulating VC++ by 
defining _MSC_VER, I am going to suggest that Boost type_traits only 
present vararg overloads with no calling convention, as there is no need 
to specify vararg overloads with any calling convention because they all 
become __cdecl anyway.

Thanks very much for your comments and help with how VC++ treats this topic.

>
> STL
>
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Edward Diener
> Sent: Sunday, October 06, 2013 4:02 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [type_traits] Variadic function pointer with __fastcall calling convention
>
> On 10/5/2013 4:02 PM, Stephan T. Lavavej wrote:
>> [Edward Diener]
>>> The problem from clang's perspective is that they must emulate this
>>> "feature" <g> to compile Boost type_traits. Their developers feel that
>>> Boost type_traits should not depend on this feature, ie. should not
>>> specify any VC++ calling conventions for varargs function or function
>>> template declarations.
>>
>> I agree with clang's devs (because that's what VC's <type_traits> does).
>
> Thanks for the encouragement. I will quote you when I propose to John
> Maddock, the main Boost type_traits implementor, that Boost should so
> the same.
>
>>
>>> What I mean is that in VC++ the declarations are redundant, being the
>>> same template redeclared.
>>
>> Right. So if you want to absorb all old-style varargs, you need only one overload/specialization.
>
> It looks as if the overload specialization for C++ should specify
> __cdecl. If this is left out of a function specification, is not the
> default calling convention user-specified, with __cdecl being the
> default ? So if the end-user changes the default to something other than
> __cdecl is that considered the end-user's fault with VC++ ?
>
>>
>>> In this case clang either has to change to be like VC++
>>
>> Oh, I thought clang was attempting to be VC-compatible here (like our copy of EDG for Intellisense does).
>
> I believe that clang wants to be compatible enough to VC++ on Windows to
> be able to compile Windows header files, but still wants to follow the
> C++ standard as closely as possible. Of course it is a bit of a
> tightrope act because 3rd party libraries for Windows which test for
> VC++ using _MSC_VER and other VC++ macros which clang on Windows
> supports, may want to be able to use clang to compile the code also.
>
>>
>> If clang is supposed to be VC-compatible, then they should treat varargs with calling conventions like VC does, and Boost should do what VC <type_traits> does (i.e. one overload/specialization with no calling convention - or __cdecl would work, I think).
>
> It seems as if __cdecl is better than no calling convention, because the
> end-user has the ability to change the default calling convention on VC++.
>
>>
>> If clang wants to be different from VC, then Boost should do something different for clang and VC.
>
> I do not work developing clang but I am just trying to compile Boost
> code with the clang toolset.