[review] promotion traits - reminder

Dear users & members of Boost, half of the scheduled review period is over and there were no reviews, so far. Therefore I want to welcome you, once again, to evaluate the proposed Boost software. The end of the review period is scheduled for April 6, so please try to post your review before then. Download URL ============ http://cpp-experiment.sourceforge.net/promote-20050917.tar.gz About the submission ==================== The Promotion Traits extend Boost.TypeTraits with templates that compute the type after promotion has been applied. Example: // given template<typename T> struct some_algorithm; template<> struct some_algorithm<int> { [...] }; // [...] more specializations // , [...] some_algorithm< typename integral_promotion<T>::type > [...] // makes some_algorithm work for any type T that promotes to an integer // (that is enums and smaller integral types) without the need for // additional specialization It's a small submission so you probably won't notice that you're working before you're done... Review questions ================ Please always explicitly state in your review, whether you think the library should be accepted into Boost. You might want to comment on the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, Tobias (Review Manager)

my vote is that the library should be accepted to boost - Did you try to use the library? With what compiler? Did you have any problems? 1) in file promote_enum_test.cpp the version of compiler can be increased. // Status of some compilers: // 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. this test is broken for Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 as well ;-) 2) I've modified the test function from promote_util.hpp : template<class T, class Promoted> inline void test() { typedef BOOST_DEDUCED_TYPENAME ::boost::promote<::boost::remove_reference<T>::type
in order to suppress modifier applied to reference warning: "promote_util.hpp(26) : warning C4181: qualifier applied to reference type; ignored promote_basic_test.cpp(82) : see reference to function template instantiation 'void test<arr_ref,arr_ref>(void)'" this test should be named test_cv, isn't it? - What is your evaluation of the design? excellent. - What is your evaluation of the documentation? enough, but common usage examples would help. a) understand these components b) for users new in this domain it helps learn about the domain and about some common techniques and abilities. so, one can read docs and say: "Wow! I can use it my code! And that is _how_ I can do it!" It should contain references to standard paragraphs about "integral promotion" (4.5) and "floating point promotion" (4.6) to describe these terms. It is necessary, because the behavior of components can not be understood without understanding of terms. May be it makes sense to include full text of corresponding paragraphs of standard in documentation. (for FP it is just one line) - What is your evaluation of the implementation? mistyping error integral_promotion.hpp : 42 // Same set of interral types as in boost/type_traits/is_integral.hpp. should be: // Same set of integral types as in boost/type_traits/is_integral.hpp. the line: // 4.5/3 (integral bit-field) is not supported. _must_ be reflected in docs. Along with rational. (even if it is a lack of resources) All the non-standard types stuff in integral_promotion.hpp seems to be untested. And the purpose of this code is unclear. same for test_platform_dependent test in file promote_util.hpp - it is not used at all. why it is here? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? reading docs is easy and enough to be ready to use the library. (but I've had to see in 4.5-4.6 paragraphs of standard to be sure) In order to make full review, I've dig into code. It was not hard. the code is straightforward, so the full time spent was about 1 hour. - What is your evaluation of the potential usefulness of the library? As Alexander has already noted, and it should be stated in docs, the library under discussion can be used in the following areas: 1. to reduce number of instantiations in template code, especially when enums considered. 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. - Are you knowledgeable about the problem domain? I've experience with template metaprogramming. The first use case mentioned above is close to me, and other two are not. Best, Oleg Abrosimov

Oleg Abrosimov <beholder <at> gorodok.net> writes:
my vote is that the library should be accepted to boost
Thanks/Spasibo :)
Ok
Will be applied.
this test should be named test_cv, isn't it?
You're right.
I understand your concern. As I pointed out in other reply, I can't do this without permission of type_traits authors.
I'll add the references.
May be it makes sense to include full text of corresponding paragraphs of standard in documentation. (for FP it is just one line)
IMHO, that's too much.
mistyping error Noted.
It's implied because a bitfield can't be template argument. I'll reflect it in the docs.
All the non-standard types stuff in integral_promotion.hpp seems to be untested. And the purpose of this code is unclear.
I tried to cover promotions beyond the standard. It seems that different compilers do this differently. It might even depend on flags (eg. -ansi or -strict). I'm going to play eith this more.
-- Alexander Nasonov
participants (3)
-
Alexander Nasonov
-
Oleg Abrosimov
-
Tobias Schwinger