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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2004-09-20 11:13:52

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
> 

Terje,

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. I should definitely buy a
more conformant compiler to recognize such things before...

With some refinement (see below) this could be a very attractive (also
see below) alternative to the "metaprogramming boilerplate" used to 
force things into shape.

Refinement of the example code:
-------------------------------

The type categorization could be done like this:

   struct integral_or_enum  { };
   struct real_number       { };
   struct pointer_or_array  { };
   struct class_or_union    { };

   class_or_union    type_category(...);

   integral_or_enum  type_category(char);
   integral_or_enum  type_category(short);
   integral_or_enum  type_category(int);
   integral_or_enum  type_category(long);

   real_number       type_category(float);
   real_number       type_category(double);

   template <typename T>
   pointer_or_array  type_category(T const *);

Used like this:

   BOOST_STATIC_CONSTANT(int, state = ( sizeof(filter(type_category(arg1)
                                              ,type_category(arg2) )) ));

This way the ambiguity problems vanish (tested the overloaded cascade 
with Comeau-online, just in case ;+).

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

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

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.

Can't see any distinction between class and union in has_plus_op.hpp,
either.

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.

Am I making any naive assumptions here ? Am I misreading anything ?

Please, correct me if I'm wrong !

Real world scenario / further suggestions:
------------------------------------------

1

A "real world implementation" will need yet another filtering stage:

The argument creation (currently only add_reference is applied) can be 
changed to achieve this (so in place of just add_reference *any* 
metafunction could be applied in its place).

A tagging type can be created for exceptional cases which can then be 
caught with a type_category overload.

In fact, I believe there is no way around it, if the behaviour of these 
traits should be defined for function and member pointers. With this 
approach it is checked only _once_, however.

2

It is possible to group the category tagging types by
inheritance in addition to using namespaces to elegantly arrange the
rule set (as mentioned in the previous post):

// Note: this is just an example to clearify the text
//       it's *not* a very good grouping here
struct anything                                { };
struct class_or_union     : anything           { };
struct numeric_or_pointer : anything           { };
struct numeric            : numeric_or_pointer { };
struct pointer_or_array   : numeric_or_pointer { };
struct integral_or_enum   : numeric            { };
struct real_number        : numeric            { };

3

All operators of one group having the same prefiltering rules can share 
one filter. The filter implementation can be shared, too - _excpet_ the 
sizeof expression and a using statement to select the rule set.

Why is this approach more attractive than the current implementation ?
----------------------------------------------------------------------

1. It exploits the very nature of the type system instead of brute
forcing around it in order to emulate it afterwards

These metafunctions exclude cases that are naturally easier to detect
together (like class/union, enum/integral).
Afterwards they are or-ed so the exclusion (which did cost us probably
more metafunction invocations than the actual detection) has been done
for nothing.

Nothing wrong with this - but not very efficient if all we want from
them is a model of categories natural to the C++ type system.

Overthis, some metafunction might contain lengthy workarounds for
specific compiler and every one of them tests for cv qualified void.

2. It depends on just a few headers ("driver code" and rule set)

Specification of portability becomes much easier.

The circumstances under which a specific metafunction works become
harder to track the more transitive dependencies arise.

3. It is resource friendly

It takes up less compiler memory, needs less filesystem access and is
likely to be less complex.
These aspect will especially carry weight for the compilation time of
projects split into a lot of small compilation units.

4. It is easier portable

Once the "driver code" runs correctly on a platform, _all_ filtering runs.
Because it does depend on just a few metafunctions it's less tedious
to check their documentation/source if they exist/work/return the right 
result on the target compiler.

Best regards,

Tobias