Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2004-09-28 18:29:59

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.

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



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 ?

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