Ticket #11907 (closed Bugs: fixed)

Opened 17 months ago

Last modified 6 months ago

Why does BOOST_TEST() treat std::string as a collection?

Reported by: bspencer@… Owned by: renficiaud
Milestone: Boost 1.63.0 Component: test
Version: Boost 1.59.0 Severity: Problem
Keywords: Cc:


Captured from

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: error: in "test": check std::string("a") == "b" has failed [a != b] 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) 

(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 :)


Change History

comment:1 Changed 8 months ago by renficiaud

  • Owner changed from rogeeff to renficiaud
  • Status changed from new to assigned
  • Milestone changed from To Be Determined to Boost 1.63.0

comment:2 Changed 6 months ago by renficiaud

  • Status changed from assigned to closed
  • Resolution set to fixed

Add a comment

Modify Ticket

Change Properties
<Author field>
as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.