From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-12-18 22:07:50
>> I've encountered a problem when transitioning from Boost.Test 1.32 to
>> 1.33. New to 1.33 is a set_precision(..) method on the print_log_value
>> functor (in test_tools.hpp). The problem, as I see it, is the use of
>> numeric_limits<T>, which exposes the assumption T is a numeric entity at
>> all. I'm actually surprised it compiles as often as it does, so maybe
>> my blame is misdirected. Nonetheless, I was able to create the attached
>> test case to prove my point. I've also included the generated build log
>> with the really nasty compile time error.
> [TRUNCATE Mr. Marshall's code example]
>
> Your blame may be misdirected. Looking at the Boost.Test code:
>
> template<typename T>
> struct print_log_value {
> void operator()( std::ostream& ostr, T const& t )
> {
> typedef typename mpl::or_<is_array<T>,is_function<T>
> >::type couldnt_use_nl;
I've added is_abstract<T> to the or_ above to address OP concern.
[...]
> do nothing. Actually, since the is_specialized field should be a
> compile-time constant, the code should be shifted to compile-time even
> further:
>
> template<typename T>
> struct print_log_value {
> void operator()( std::ostream& ostr, T const& t )
> {
> typedef typename mpl::or_<is_array<T>,is_function<T>,
> mpl::bool_<!std::numeric_limits<T>::is_specialized>
> >::type couldnt_use_nl;
Existent Boost.Test code intentionally avoided code like this. The thing is
that for array and function types (and abstract as aparent now) depending on
STL/compiler implementation std::numeric_limits<T> instantiation is invalid
and you couldn't even query is_specialized. I guess I could've used another
compile time if (instead of runtime one) within set_precision. But that
shouldn't have any difference at runtime and I do not want to complicate an
implementation without compelling reason.
Gennadiy