Re: [boost] Re: Proposal: type-promoting arithmetics for derivative types

From: Joel de Guzman (joel_at_[hidden])
Date: 2004-02-25 21:36:58

Max Motovilov wrote:
> "Brian McNamara" <lorgon_at_[hidden]> wrote in message
> news:20040225235607.GA1327_at_gaia3.cc.gatech.edu...
> 
> 
>>See, e.g.
>>   http://www.boost.org/libs/lambda/doc/ar01s06.html
>>operator-tag representations as well as the logic that "when combining
>>float and double, promote both to double" already exist somewhere in
>>Boost (ask Joel or Jaakko, I dunno the details), so reuse those.
> 
> 
> Looks exactly like what I was proposing, even the syntax is similar. I knew
> it had to be there somewhere :)

If you want a newer technology, there's one in the boost-sandbox.
See: boost/utility/type_deduction.hpp
and a test program: libs/utility/type_deduction_tests.cpp.

Let me quote the commentary in type_deduction.hpp (long):

     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