See #144 and #165 for examples of the build.
It seems that the following results in a test to see if a value is streamable in catch.hpp:
unit.cpp:2588 CHECK(*p1 == value.get<test_type>());
This causes a call to operator == in catch.hpp (17771):
template<typename RhsT>
ResultBuilder& operator == ( RhsT const& rhs ) {
return captureExpression<Internal::IsEqualTo>( rhs );
}
THAT causes a call to the captureExpression function on catch.hpp:1829
template<Internal::Operator Op, typename RhsT>
ResultBuilder& captureExpression( RhsT const& rhs ) {
return m_rb
.setResultType( Internal::compare<Op>( m_lhs, rhs ) )
.setLhs( Catch::toString( m_lhs ) )
.setRhs( Catch::toString( rhs ) )
.setOp( Internal::OperatorTraits<Op>::getName() );
}
The Catch::toString results in a call to catch.hpp: 1731's toString->StringMaker:
template<typename T>
std::string toString( T const& value ) {
return StringMaker<T>::convert( value );
}
StringMaker simply offloads to Detail::StringMakerBase, but first goes through the Detail::IsStreamInsertable::value! This happens on 1575:
template<typename T>
struct IsStreamInsertable {
static std::ostream &s;
static T const&t;
enum { value = sizeof( testStreamable(s << t) ) == sizeof( TrueType ) };
};
On Linux, this appears to realize there is NO overload for operator << that works, however MSVC doesn't seem to know that, and decides that it is an ambiguous call between just about every possible overload.
See #144 and #165 for examples of the build.
It seems that the following results in a test to see if a value is streamable in catch.hpp:
unit.cpp:2588 CHECK(*p1 == value.get<test_type>());
This causes a call to operator == in catch.hpp (17771):
THAT causes a call to the captureExpression function on catch.hpp:1829
The Catch::toString results in a call to catch.hpp: 1731's toString->StringMaker:
StringMaker simply offloads to Detail::StringMakerBase, but first goes through the Detail::IsStreamInsertable::value! This happens on 1575:
On Linux, this appears to realize there is NO overload for operator << that works, however MSVC doesn't seem to know that, and decides that it is an ambiguous call between just about every possible overload.