Re: [boost] [review] promotion traits

From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2006-04-02 05:02:36

Andy Little wrote:
> I am talking about usefulness. In what practical situation is promotion_traits
> likely to be used? Put it another way. What is the rationale for
> promotion_traits?

1. to reduce number of instantiations in template code. For example:

    enum bits { bit1 = 1, bit2 = 2 };
    lexical_cast<double>(bit1);
    lexical_cast<double>(bit1|bit2);

produces 2 instantiantions of lexical_cast and 2 instantiantions of
detail::lexical_stream.
In general, this number is proportional to a number of enums used.
If lexical_cast were to apply integral_promotion, this could reduce
number of instantiantions of lexical_stream to one.

2. to find a type that can hold all values of enum type. This technique
can be used in langbinding to make sure that all C++ enum values are
mapped without truncation.

3. to use in other metafunctions like arithmetic_convertion_traits and
to provide a solution for (_1 | _2)(bit1, bit2) lambda expression.

> IMO All this has recently been superceded by Boost.Typeof.

Only native mode of Boost.Typeof can compete with hand-made
integral_promotion or arithmetic_convertion_traits.
Emulation is too complex and require registration of every enum type.

Even in native mode you would need more then typeof(+T()) simply because
this expression is not valid for some types. You should write
is_subject_to_integral_promotion<T> metafunction and use eval_if.

> It might help to show useage examples to decide the behaviour, but is it not
> generally better to constrain a functions input to only those types for which
> its functionality is meaningful?  If you want to widen the behaviour to accept
> other types you can use mpl::eval_if for example.
I knew this :) but I decided that writing
eval_if< is_subject_to_integral_promotion<T>, ... > is not worth it.
Existing behavior is better in all use-cases listed above.
-- 
Alexander Nasonov