From: "Tobias Schwinger"
Terje Slettebø wrote:
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
first of all thanks for your time and for your corrections.
However, I still think there is nothing wrong with the basic idea, just with my sloppy example implementation of it.
By all means, like I said in the posting before it, I find it an interesting idea, and was just as "disappointed" as you to find out that it might not be possible to do it that way, and if there's better way to do the pre-filtering than the "metaprogramming boilerplate", then I'm all for it.
Refinement of the example code: -------------------------------
<snip> Great work! :) This actually works, also on Intel C++/Comeau C++. It's good that you didn't give up on the first try (not that I expected you to. :) ).
Problem discussion: -------------------
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
I renamed the type category 'integral' to 'integral_or_enum' because of 7.2-8 (enum), 4.5-2 (integral promotion).
Good point. What we are looking for is things that could be used in a certain context, e.g. "a + b". This means that not only e.g. arithmetic types match, but also something convertible to them, as well as reference to them.
- One is array and the other is integral or enum, or
I renamed the type category 'pointer' to 'integral_or_array' because of 13.3.3.1.1 (overloading - standard conversion sequences) Tab. 9.
As long as it passes the tests... :) I'll study this more carefully. :) I look (hopefully) forward to a complete code example for has_plus_op<> using this technique, if you could have made something like that.
If there is a need to distiguish between (object) pointer and array this needs extra care (see below), sure. However, has_plus_op applies these tests disjunctively.
- Either is class, and the other is anything but void
A match defines an exclusion - no match means "pass the filter" - and this would correctly happen in this case.
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).
Can't see an "is_enum" - only "is_enum_or_integral" and this is much easier.
True... Good thinking. :) (So it was useful to refactor those tests (like enum-or-integral) into sub-components, after all - it made what being tested for easier to see. :) It might otherwise have got lost in a sea of syntactic noise).
Can't see any distinction between class and union in has_plus_op.hpp, either.
True, again...
The strenght of the overload approach lies in the natural way of grouping types - can't see what separation of integral types should help.
I'm not sure I get your point.
I think you got it - that the previous example didn't compile on some compilers, and that I wondered if it was possible to cover the same cases better - and I think you have convincingly addressed it. :)
Am I making any naive assumptions here ? Am I misreading anything ?
Please, correct me if I'm wrong !
No, I think you're right on. :) Thanks for your very thorough investigation into this. I'll consider your following points carefully. In the mean time, as you suggested in an email, if you could have made this into a polished boostified version, that would have been great. As a proof-of-concept (no pun intended. :) ), as mentioned, maybe you could have written a has_plus_op<> replacement using this technique, which passes the tests, since has_plus_op<> contains a reasonable amount of "boilerplate", so it could be useful to test with. This is remniscent of when I worked on an improved version of lexical_cast a while ago (to support different character types, etc.), and had long if-else switch-on-type chains, and Kevlin Henney instead found a way to do it with much simpler code (which is the current version of lexical_cast). Regards, Terje