Tobias Schwinger wrote:

Jeff Flinn wrote:

...

Tobias Schwinger wrote:

...

The review of Alexander Nasonov's Promotion Traits start today. Since it's a small contribution it will be fast-track reviewed and the end of the review period is scheduled for April 6.

Download URL ============

http://cpp-experiment.sourceforge.net/promote-20050917.tar.gz

Do you have a link for those of us in the Windows realm?

The converted archive (ZIP format) has been placed into the vault:

http://tinyurl.com/mcs7f

Regards, Tobias

Thanks, got it. Jeff

David Abrahams wrote:

"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:

...

Tobias Schwinger wrote:

...

The review of Alexander Nasonov's Promotion Traits start today. Since it's a small contribution it will be fast-track reviewed and the end of the review period is scheduled for April 6.

Download URL ============

http://cpp-experiment.sourceforge.net/promote-20050917.tar.gz

Do you have a link for those of us in the Windows realm?

http://www.7-zip.org/ ;-)

I don't know how you keep on top of all of these things! :-) Thanks, Jeff

Andy Little wrote:

Hi,

I'm interested to know in what situations the promotion_traits libarary is meant to be used? I looked at the standard and I see that it seems to follow that, but in practise the only similar situation of needing to know promotion rules in my own code was in choosing the type that the input types are to be converted to in some operation.

Are you talking about _usual arithmetic conversions_? I like fine granular model. Since usual arithmetic conversions depend on integral promotion, it's logical to implement integral_promotion fisrt. BTW, LibrariesUnderConstruction has a reference to types_promotion_traits developed by Aleksey Gurtovoy. http://tinyurl.com/4kvla Is arithmetic_conversions_traits<> defined there what you need?

I am surprised to see that input parameters unrelated to promotion are allowed to pass unchanged to the output.The example given is e.g

Expression ---> Result floating_point_promotion<int const>::type ---> int const

I would expect, rather, to have a compilation failure in case of an invalid parameter?

I prefer promote-if-possible because it follows a semantic in the standard. For example, integral promotions can be applied when passing an argument to printf-like function. If integral promotions can't be applied to the argument, nothing happens. If you want to check whether promotion has an effect you can write is_same< T, promote<T>::type >::value. -- Alexander Nasonov

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

Pavel Vozenilek wrote:

1. The documentation should really start with Rationale section and should contain complete examples. Examples written in this thread would be good start.

Since it is a small addition to type_traits I decided to follow type_traits style. Rather then writing complete documentation I wrote small pieces that can be easily integrated into type_traits documentation.

2. Includes should use

#include <boost/config.hpp> Noted.

3. I got problems with Windows Intel 9.0:

Looks like it compiles in MS compatibility mode. I noticed some problems with MS compiler. Have you tried MSVC or Intel with MS compatibility switched off? There is a status for some compilers at the begginning of promote_enum_test.cpp: // Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for // 80x86 // /Ze (enable extentions) promotes UIntEnum incorrectly to int. // /Za (disable extentions) is totally broken. I was suprised to see that many compilers have problems with enums.

4. Intel 7.0 seems to be right out, I was not able to compile any example.

I tested only Intel 8.1 for Linux on FreeBSD. It works fine.

5. Playing with BCB: I got some promising success but full port would require longer work. I can help here if it gets accepted into Boost.

I appreciate this.

As an appetizer: all [::boost::] need to be converted into [boost::] (BCB doesn't like the leading ::) and there are some strange issues with namespaces; Thanks.

6. In

#if (defined(BOOST_MSVC) && (BOOST_MSVC == 1200)) \ || (defined(BOOST_INTEL_CXX_VERSION) && defined(_MSC_VER) && (BOOST_INTEL_CXX_VERSION <= 600)) \ || (defined(__BORLANDC__) && (__BORLANDC__ == 0x600) && (_MSC_VER == 1200))

just all versions of BCB should be covered. 5.5, 5.6 and 5.8 do have the __intX thing.

BCB version 0x600 doesn't exist yet.

Similarly all Windows Intel compilers I know about have __intX as a separate type - the check <= 600 should be omitted too.

I copied this #if from <boost/type_traits/is_integral.hpp> Have you noticed TODO nearby? It says: // TODO: common macro for this #if. Or better yet, PP SEQ of non-standard types. Thanks for comments, -- Alexander Nasonov

Andy Little <andy <at> servocomm.freeserve.co.uk> writes:

I wonder if the three functions are necessary together?

Either there should only be promote or there should only be integral_promotion, float_promotion.

I was never sure about floating_point_promotion<> and promote<>. Section 13.3.3.1.1 of the standard conviced me to add them. It defines Promotion category of standard conversion sequences.

The main rationale for integral_promotion is for enums. float promotion and promotion usage are already handled by Boost.Typeof.

I would say, floating_point_promotion<> is easily implementable even without Boost.Typeof.

ints and floats are very different entities and I wonder if its approporiate to apply the same behaviours.

I agree.

I dont really like the fact types unrelated to int or floats can silently pass through as a general rule, but I think I see the reasoning given the use cases. It could be documented though.

It's documented by not emphasized: type: T if integral promotion can't be applied to an rvalue of type T; otherwise, a type of integral promotion of an rvalue of type T. Resulting type is same cv-qualified as T.

I think it needs some more rationale and examples. I understand its meant to fit with type_traits, but the documentation for other type_traits does include examples and there is room for a bit of rationale too.

Only few type_traits classes are explained in tutorial. I can't add mine without asking the authors.

I vote yes to accept it.

Thanks. -- Alexander Nasonov