Markus Werle <[EMAIL PROTECTED]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
