Boost logo

Boost :

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
> 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

struct real

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
          "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
( However, I can't find any case in 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



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