Boost C++ Libraries: Ticket #12540: Provide customisation point for printing types in tests

owner, status changed

Raffi Enficiaud — Sat, 04 Feb 2017 21:45:59 GMT

owner changed from Gennadiy Rozental to Raffi Enficiaud
status new → assigned

milestone changed

Raffi Enficiaud — Sun, 05 Feb 2017 12:03:02 GMT

milestone To Be Determined → Boost 1.64.0

Raffi Enficiaud — Sun, 05 Feb 2017 12:11:34 GMT

Hi there,

I am not very familiar with the intrinsics of ADL and qualified/unqualified calls. What seems to be working right now in the branch topic/12540-printing-types-customisation-point is something like this:

namespace printing_test {
struct user_defined_type {
    int value;
    user_defined_type(int value_) : value(value_)
    {}
    bool operator==(int right) const {
        return right == value;
    }
};
std::ostream& boost_test_print_type(std::ostream& ostr, user_defined_type const& right) {
    ostr << "** value of my type is " << right.value << " **";
    return ostr;
}
}
BOOST_AUTO_TEST_CASE(test1)
{
    printing_test::user_defined_type t(10);
    BOOST_CHECK_EQUAL(t, 10);
    BOOST_TEST(t == 11);
}

However, if I move the definition of boost_test_print_type to another namespace, it does not find the definition anymore. This seems to be normal, but I do not know if this is what we want from the users' perspective.

What do you think?

Sat, 11 Feb 2017 19:23:32 GMT

Thanks very much for your work on this.

The changes on topic/12540-printing-types-customisation-point look like the sort of thing I was thinking of.

Yes, I think the idea of D4381 is that users customise by putting their function in the namespace of the type so that it gets picked up by ADL. What are your hesitations about this? It may be sub-optimal when users want to specify a boost_test_print_type() for a types in namespaces that they don't own and hence want to avoid polluting (eg std:: - I think I read that polluting std:: technically induces undefined behaviour). Still, I'd say it's still much better than expecting them to put an operator<< in there. Maybe it's possible to document that users can alternatively specialise the default boost_test_print_type template (and rename/move the namespace to something specific)? I don't know how that would play with the ideas of D4381.

I think I'd vote for: for now, document and release the current changes as a supported part of the interface. If the feedback is that users like the idea but want a way to avoid having to pollute namespaces that they don't own, consider extending the customisation interface. What do you think?

I think these changes are a really helpful improvement and are well worth highlighting to users.

Thanks again.

Raffi Enficiaud — Wed, 01 Mar 2017 11:35:31 GMT

Sorry I missed your reply, then it is good :) I will update the documentation. Should be fine for 1.64.

Tue, 07 Mar 2017 12:34:19 GMT

Fantastic. Thanks very much for your work on this.

Raffi Enficiaud — Sun, 19 Mar 2017 22:00:39 GMT

Merged to master, rev af78890325948bed598361966fa7f5fc9560c41d

status changed; resolution set

Raffi Enficiaud — Sun, 19 Mar 2017 22:00:54 GMT

status assigned → closed
resolution → fixed

Tue, 21 Mar 2017 20:51:08 GMT

Great. Thanks very much.