Boost logo

Boost :

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-09-14 15:59:33


>From: "Tobias Schwinger" <tschwinger_at_[hidden]>

> My apologies - please, just forget what I've posted.
>
> > no_overload_tag function( \
> > BOOST_PP_ENUM_PARAMS(BOOST_PP_DEC(arity) \
> > , any BOOST_PP_INTERCEPT)...); \
>
> GCC allows this for binary operators (even in ansi mode), making me jump
> to conclusions - couldn't find anything in the standard backing it.
>
> Further I doubt there is a chance of weakening the "no-match-overload"
> in any other way to match worse than a function with one user defined
> conversion per argument.

Actually, there is...:

--- Start ---

#include <iostream>
#include <boost/config.hpp> // For BOOST_STATIC_CONSTANT

struct proxy
{
  proxy(...);
};

struct no_match_type {};

char op_test(...);
char (&op_test(const no_match_type &))[2];

no_match_type operator+(const proxy &,const proxy &);

template<class T,class U>
struct has_plus_op
{
  static T t;
  static U u;

  typedef has_plus_op type;

  BOOST_STATIC_CONSTANT(bool, value=sizeof(op_test(t+u))==1);
};

class A
{
public:
  A(int); // Note user-defined conversion
};

class B {};

A operator+(A,A);

int main()
{
  std::cout << has_plus_op<int,int>::value << "\n"; // Sure
  std::cout << has_plus_op<int,double>::value << "\n"; // No sweat (standard
conversion - promotion)
  std::cout << has_plus_op<int,A>::value << "\n"; // Again, no problem
UDC int -> A takes preference to ...
  std::cout << has_plus_op<A,B>::value << "\n"; // Nope
}

--- End ---

This shows that using "proxy" allows implicit promotions/conversions, as
well as user-defined conversions, to take place as part of the overload
resolution. You can't use "..." as an operator parameter (as you found out),
but you _can_ get around it like this. ;)

The above is the "modified" isAddable that I mentioned in the OP, and which
is found (with appropriate namespace protection) in
operator_traits/detail/binop.hpp.

It's good to be back. ;)

Regards,

Terje


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk