Re: compile-time cost of alias templates

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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.