Re: [boost] Simplifying promote_traits

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-10-07 10:10:05

Neal D. Becker <nbecker_at_[hidden]> wrote:
> I frequently need to write arithmetic algorithms which may need to infer the
> type of intermediate variables.  These algorithms will be used with mixed
> types, such as:
>
> double, std::complex<double>
> int, std::complex<int>
>
> I have looked at boost/numeric/ublas/traits.hpp, at promote_traits class.  It
> seems that this suffers from a quadratic explosion, needing to define a
> specialization for every combination of <T1, T2>.
>
> I think it would be simpler to use boost::is_convertible.  The type of the
> product of two types T1, T2 is T1 if T2 is convertible to T1, T2 if T1 is
> convertible to T2, and undefined otherwise.
>
> This might be overly general, but I think the simplicity of the design is more
> significant.
>
> Any thoughts?

Hi Neal,

Have you seen: http://lists.boost.org/MailArchives/boost/msg52718.php  ?

Anyway, the file has been moved to: http://spirit.sf.net/dl_more/best_conversion.cpp

I think, judging from the related posts, and from various emails regarding the need
for such a facility, that there's interest in this. I'll try to make a formal boost proposal
when I get some time. 

Here's the introduction:
/*=============================================================================

    Return Type Deduction
    [JDG Sept. 15, 2003]

    Before C++ adopts the typeof, there is currently no way to deduce the
    result type of an expression such as x + y. This deficiency is a major
    problem with template metaprogramming; for example, when writing
    forwarding functions that attempt to capture the essence of an
    expression inside a function. Consider the std::plus<T>:

        template <typename T>
        struct plus : public binary_function<T, T, T>
        {
            T operator()(T const& x, T const& y) const
            {
                return x + y;
            }
        };

    What's wrong with this? Well, this functor does not accurately capture
    the behavior of the plus operator. 1) It does not handle the case where
    x and y are of different types (e.g. x is short and y is int). 2) It
    assumes that the arguments and return type are the same (i.e. when
    adding a short and an int, the return type ought to be an int). Due to
    these shortcomings, std::plus<T>(x, y) is a poor substitute for x + y.

    The case where x is short and y is int does not really expose the
    problem. We can simply use std::plus<int> and be happy that the
    operands x and y will simply be converted to an int. The problem
    becomes evident when an operand is a user defined type such as bigint.
    Here, the conversion to bigint is simply not acceptable. Even if the
    unnecessary conversion is tolerable, in generic code, it is not always
    possible to choose the right T type that can accomodate both x and y
    operands.

    To truly model the plus operator, what we need is a polymorphic functor
    that can take arbitrary x and y operands. Here's a rough schematic:

        struct plus
        {
            template <typename X, typename Y>
            unspecified-type
            operator()(X const& x, Y const& y) const
            {
                return x + y;
            }
        };

    Now, we can handle the case where X and Y are arbitrary types. We've
    solved the first problem. To solve the second problem, we need some
    form of return type deduction mechanism. If we had the typeof, it would
    be something like:

        template <typename X, typename Y>
        typeof(X() + Y())
        operator()(X const& x, Y const& y) const
        {
            return x + y;
        }

    Without the typeof facility, it is only possible to wrap an expression
    such as x + y in a function or functor if we are given a hint that
    tells us what the actual result type of such an expression is. Such a
    hint can be in the form of a metaprogram, that, given the types of the
    arguments, will return the result type. Example:

        template <typename X, typename Y>
        struct result_of_plus
        {
            typedef unspecified-type type;
        };

    Given a result_of_plus metaprogram, we can complete our polymorphic
    plus functor:

        struct plus
        {
            template <typename X, typename Y>
            typename result_of_plus<X, Y>::type
            operator()(X const& x, Y const& y) const
            {
                return x + y;
            }
        };

    The process is not automatic. We have to specialize the metaprogram for
    specific argument types. Examples:

        template <>
        struct result_of_plus<short, int>
        {
            typedef int type;
        };

        template <typename T>
        struct result_of_plus<std::complex<T>, std::complex<T> >
        {
            typedef std::complex<T> type;
        };

    To make it easier for the user, specializations are provided for common
    types such as primitive c++ types (e.g. int, char, double, etc.), and
    standard types (e.g. std::complex, iostream, std containers and
    iterators).

    To further improve the ease of use, for user defined classes, we can
    supply a few more basic specializations through metaprogramming using
    heuristics based on canonical operator rules (Such heuristics can be
    found in the LL and Phoenix, for example). For example, it is rather
    common that the result of x += y is X& or the result of x || y is a
    bool. The client is out of luck if her classes do not follow the
    canonical rules. She'll then have to supply her own specialization.

    The type deduction mechanism demostrated below approaches the problem
    not through specialization and heuristics, but through a limited form
    of typeof mechanism. The code does not use heuristics, hence, no
    guessing games. The code takes advantage of the fact that, in general,
    the result type of an expression is related to one its arguments' type.
    For example, x + y, where x has type int and y has type double, has the
    result type double (the second operand type). Another example, x[y]
    where x is a vector<T> and y is a std::size_t, has the result type
    vector<T>::reference (the vector<T>'s reference type type).

    The limited form of type deduction presented can detect common
    relations if the result of a binary or unary operation, given arguments
    x and y with types X and Y (respectively), is X, Y, X&, Y&, X*, Y*, X
    const*, Y const*, bool, int, unsigned, double, container and iterator
    elements (e.g the T, where X is: T[N], T*, vector<T>, map<T>,
    vector<T>::iterator). More arguments/return type relationships can be
    established if needed.

    A set of overloaded test(T) functions capture these argument related
    types. Each test(T) function returns a distinct type that can be used
    to determine the exact type of an expression.

    Consider:

        template <typename X, typename Y>
        x_value_type
        test(X const&);

        template <typename X, typename Y>
        y_value_type
        test(Y const&);

    Given an expression x + y, where x is int and y is double, the call to:

        test<int, double>(x + y)

    will return a y_value_type.

    Now, if we rig x_value_type and y_value_type such that both have unique
    sizes, we can use sizeof(test<X, Y>(x + y)) to determine if the result
    type is either X or Y.

    For example, if:

        sizeof(test<X, Y>(x + y)) == sizeof(y_value_type)

    then, we know for sure that the result of x + y has type Y.

    The same basic scheme can be used to detect more argument-dependent
    return types where the sizeof the test(T) return type is used to index
    through a boost::mpl vector which holds each of the corresponding
    result types.

==============================================================================*/

Regards,-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net