Re: [boost] Re: Constrained genericity at last? (any interest in an operator traits/concept traits library?)

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-09-19 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 cut-down 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 - user-defined 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 typeof-implementation), there's still enum, so we
need some kind of is_enum-detection (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