[boost] Re: Review request: enable_if

From: David Abrahams (dave_at_[hidden])
Date: 2003-07-03 17:58:20

Markus Werle <numerical.simulation_at_[hidden]> writes:

>> Dear Boosters,
>> 
>> The enable_if library defines the enable_if and disable_if templates,
>> which are tools for controlling which function templates are included
>> in the overload resolution set based on the properties of the argument
>> types.
>> 
>> The following example demonstrates their use:
>> 
>> template <class T>
>> typename enable_if<boost::is_arithmetic<T>::value, void>::type foo(T t) {
>>   std::cout << "An arithmetic type\n";
>> }
>> 
>> template <class T>
>> typename disable_if<boost::is_arithmetic<T>::value, void>::type foo(T t) {
>>   std::cout << "Not an arithmetic type\n";
>> }
>
> Wow! C++ always has a solution for its own problems:
> I always wondered how I could prevent Daixtrose template operators 
> get applied to other user's or builtin types and decided to put 
>
> template <class T1, class T2> 
> SomeComplicatedType operator+(T1 const &, T2 const &)
>
> et. al. into their own namespace DefaultOps.
>
> As of today Daixtrose users are explicitly forced to say
> using namespace Daixt::DefaultOps if they want their code to compile.
> And still may run into disambiguities when they include other beasts
> of that kind. This is annoying.

Yes, I've been meaning to apply the same fix to Boost.Python's "self"
operators ever since I learned about enable_if last fall.
Unfortunately, not all compilers support it so the special namespace
is still needed, but at least we can make things work perfectly on
some compilers.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com