Opened 17 months ago

Closed 12 months ago

Last modified 12 months ago

#12540 closed Feature Requests (fixed)

Provide customisation point for printing types in tests

Reported by: Tony Lewis <TonyELewis@…> Owned by: Raffi Enficiaud
Milestone: Boost 1.64.0 Component: test
Version: Boost 1.61.0 Severity: Optimization
Keywords: test, customization, customisation, output, print, stream, insertion operator, print_log_value, BOOST_TEST_DONT_PRINT_LOG_VALUE Cc:


AFAIU (from doc "Logging user defined types"), the current design gives users two options for handling output for their types in tests:

  • Provide operator<<
  • Prevent printing with BOOST_TEST_DONT_PRINT_LOG_VALUE()

...and all types must be printed.

I suggest that this is to rigid. For some types, users may not want to provide a global operator<<, or they may have already provided an operator<< or they may not own the type.

For these reasons, I think it would be better if Boost Test provided an explicit customization point that defaulted to calling operator<< but that could be overridden by the user to explictly control the Test printing without affecting operator<<.

In fact, I think boost::test_tools::tt_detail::print_log_value is already close to serving this purpose and perhaps it needs little more than being made part of the public interface and documented.

Thanks for all your work.

PS "D4381: Suggested Design for Customization Points" may be relevant here.

Attachments (0)

Change History (9)

comment:1 Changed 14 months ago by Raffi Enficiaud

Owner: changed from Gennadiy Rozental to Raffi Enficiaud
Status: newassigned

comment:2 Changed 14 months ago by Raffi Enficiaud

Milestone: To Be DeterminedBoost 1.64.0

comment:3 Changed 14 months ago by Raffi Enficiaud

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;

    printing_test::user_defined_type 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?

comment:4 Changed 14 months ago by Tony Lewis <TonyELewis@…>

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.

comment:5 Changed 13 months ago by Raffi Enficiaud

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

comment:6 Changed 13 months ago by Tony Lewis <TonyELewis@…>

Fantastic. Thanks very much for your work on this.

comment:7 Changed 12 months ago by Raffi Enficiaud

Merged to master, rev af78890325948bed598361966fa7f5fc9560c41d

comment:8 Changed 12 months ago by Raffi Enficiaud

Resolution: fixed
Status: assignedclosed

comment:9 Changed 12 months ago by Tony Lewis <TonyELewis@…>

Great. Thanks very much.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Raffi Enficiaud.
The resolution will be deleted.

Add Comment

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

Note: See TracTickets for help on using tickets.