Re: [Boost-users] [Boost.Test] Use of numeric_limitsin print_log_value (VC++7.1)

...

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_::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_ >::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