compile-time cost of alias templates

Gabriel Dos Reis gdr@integrable-solutions.net
Sun Dec 18 22:41:00 GMT 2011


On Sun, Dec 18, 2011 at 11:38 AM, Jason Merrill <jason@redhat.com> wrote:
> On 12/18/2011 11:00 AM, Jonathan Wakely wrote:
>>
>> Currently in<functional>  we have this helper class to constrain the
>> std::bind function template via SFINAE:
>>
>>   template<typename _Tp>
>>     class __is_socketlike
>>     {
>>       typedef typename decay<_Tp>::type _Tp2;
>>     public:
>>       static const bool value =
>>         is_integral<_Tp2>::value || is_enum<_Tp2>::value;
>>     };
>>
>> I was going to replace the static member with:
>>       static const bool value = __or_<is_integral<_Tp2>,
>> is_enum<_Tp2>>::value;
>>
>> But now that we have alias templates I'm wondering if it would be
>> better to write it as:
>>
>>   template<typename _Tp>
>>     using __is_socketlike
>>       = __or_<is_integral<typename decay<_Tp>::type>,
>>               is_enum<typename decay<_Tp>::type>>;
>>
>>
>> Does the implementation in G++ mean that using an alias template
>> avoids instantiating the separate __is_socketlike class template, or
>> is there just as much cost in instantiating an alias template as a
>> class template?
>
>
> Instantiating an alias is simpler, aliases are basically transparent.

Yes; at some point we are planning to publish "memory usage" numbers
based on existing practice.

> However, this change would mean that any mangling exposure of
> __is_socketlike would change.  But that may not be an issue since it's an
> internal type.
>
> Jason

Agreed.
Jonathan, note however that neither the original code nor the new version does
short-circuiting of instantiations.



More information about the Libstdc++ mailing list