From: David Abrahams (dave_at_[hidden])
Date: 2003-08-21 08:17:43
"Peter Dimov" <pdimov_at_[hidden]> writes:
> David Abrahams wrote:
>> Jaakko Jarvi <jajarvi_at_[hidden]> writes:
>>> 4. Non-SFINAE compilers
>>> Dave has an implementation of enable_if which defaults to being
>>> always enabled for compilers that do not support SFINAE. We do not
>>> think this is the right approach, and believe that attemts to use
>>> enable_if on a compiler that does not support SFINAE, should cause
>>> an immediate error.
>> Can you justify that choice a bit? In the applications where I've
>> used it, no-op behavior provides good gradual degradation in
>> functionality (I don't have a strong opinion though).
> template<class X, class Y>
> typename enable_if<is_expression<X>::value || is_expression<Y>::value,
> operator+(X const & x, Y const & y);
Yes, I have precisely such a situation (see
boost/python/object_operators.hpp). I put those in an isolated
namespace with the "expression" template, which gets us 90% of the
way there. The last 10% is given by enable_if, when available.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk