
Boost : 
From: Terje Slettebø (tslettebo_at_[hidden])
Date: 20040919 16:17:45
>From: "Terje Slettebø"
> >From: "Tobias Schwinger"
>
> > I attached some experimental source code for the prefiltering of an
> > operator+ check to clearify the basic idea (compiles with GCC and MSVC
> > and CVS version of boost).
>
> It works indeed with GCC and MSVC, but Intel C++ 7.1 had some serious
> problems with it. The following is one of several of the same kind of
error
> messages I got:
I've now looked at the implementation, and I'm afraid Intel C++ (EDG) might
be right. :/
Here's a cutdown version showing the problem:
struct integral
{
integral(int);
};
struct real
{
real(double);
};
int filter(integral);
int filter(real);
int main()
{
int state = sizeof(filter(1)); // filter(int)
}
On Comeau C++ online it gives the same error, not surprisingly:
"ComeauTest.c", line 21: error: more than one instance of overloaded
function
"filter" matches the argument list, the choices that match are:
function "filter(integral)"
function "filter(real)"
The argument types that you used are: (int)
int state = sizeof(filter(1)); // filter(int)
^
We have two viable conversion sequences:
int > integral
int > double > real
They both have the same form  userdefined conversion sequence
(13.3.3.1/3). However, I can't find any case in 13.3.3.2/3 that says that
one is better than the other of the above. If anyone finds otherwise, please
post chapter and verse.
Another problem with this approach can be demonstrated by listing the cases
that are checked by the operator+ detection:
 Both types being arithmetic or enum, or
 One is array and the other is integral or enum, or
 Either is class, and the other is anything but void
Even if we found a way to give a numerical code or something to each
fundamental type (typical typeofimplementation), there's still enum, so we
need some kind of is_enumdetection (which would likely require the Boost
one). The same goes for detecting class or union. We also need a way to
express the above conditions. I haven't found a shorter way of specifying
this, than the current has_plus_op<> definition
(operator_traits/has_plus_op.hpp).
Regards,
Terje
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk