
Terje Slettebø wrote:
From: "Terje Slettebø"
If we get a version of has_plus_op using this technique, we could compare it to the current version, in terms of dependencies, compilation speed (instantiating it with a lot of types), etc.
Hi again, got a modified version of your operator+ detection ready, which passes your test unit. http://tinyurl.com/6gtn2 Nearly all dependecies are gone - I kept 'mpl::and_' (just because I was too lazy to change things which are likely to change again ;+) - actually we can get rid of this, too. ( For that matter it's probably a good idea to use these "bool_trait_(un)def" headers [boost/type_traits/detail], which seem much more portable than just inheriting from a "bool holder type"). I generated a simple stress test, instantiating it for about 500 different types and the results look very promising: modified version | original version GCC 13 seconds | 5 minutes (*) MSVC 13 / 7(#) seconds | 1.5 minutes (*) the machine started swapping after gcc had ate up all physical memory (#) ANSI-mode /Za The categorization pipeline was successfully tested with gcc 3.2, 3.3 and 3.4, msvc 13.10.3077, bcc 5.5.1, 5.6.4. If I did not forget anything, it should be sufficient to implement builtin operator detection on top of it, too. Here's a list of the leaves in the categorization inheritance graph (i.e. the finest level of separation): Non object types: function (function - not function pointer) void_type (represents void) Each LValue and RValue of these object types: aggregate (class or union) enumeration floating integral object_ptr (pointer to object type) special_ptr (pointer to member, function or member function) On MSVC (in ANSI-mode, that is) for example, it does not need a single Type Traits class to accomplish this. Note that the 'is_plus_op' test uses the full categorization - so there is no extra cost in performance. Regards, Tobias P.S.: There is a note within the Type Traits ICE workaround documentation about Metrowerks having problems using sizeof on the result type of an overloaded function (dated 2001) - is this still true for later / the current version ?