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