id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
11907	Why does BOOST_TEST() treat std::string as a collection?	bspencer@…	Raffi Enficiaud	"Captured from http://lists.boost.org/boost-users/2015/12/85472.php

Why does BOOST_TEST() compare std::string values as collections instead of scalars (by default)? It's odd that the following produce different output, for example: 

{{{
BOOST_TEST(std::string(""a"") == ""b""); 
BOOST_TEST(std::string(""a"") == std::string(""b"")); 
}}}

This will output: 

{{{
test.cc(6): error: in ""test"": check std::string(""a"") == ""b"" has failed [a != b] 
test.cc(7): error: in ""test"": check std::string(""a"") == std::string(""b"") has failed 
}}}

Note the lack of ""[a != b]"" on the second case. Also note that BOOST_CHECK_EQUAL() would emit as in the first form. This seems to be because std::string is_forward_iterable, and thus falls 
into the collection_comparison_op.hpp comparators instead of the scalar comparators. Is this intentional or an oversight? 

As a simple fix, adding a condition to the partial specialization of the collection_comparison_op.hpp comparators that specifically excludes std::string is enough to have std::string treated as scalars. For example, to handle std::string but not std::wstring with C++11 support: 

{{{
template<typename Lhs,typename Rhs> 
struct name<Lhs,Rhs,typename boost::enable_if_c< 
     unit_test::is_forward_iterable<Lhs>::value && 
     unit_test::is_forward_iterable<Rhs>::value && 
     !(std::is_same<typename std::decay<Lhs>::type, std::string>::value 
      || std::is_same<typename std::decay<Rhs>::type, std::string>::value) 
>::type 
}}}

(The above is an example and not a complete change supporting std::wstring and C++98.) 

The response on the mailing list was that this was a bug, so here's a ticket to help track it :)"	Bugs	closed	Boost 1.63.0	test	Boost 1.59.0	Problem	fixed