Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at