ddavis2speedray / googletest

Automatically exported from code.google.com/p/googletest
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

need a way for the user to override how STL-container-like classes are printed #359

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Currently gtest's universal value printer detects whether a value is a 
container (by checking the existence of member types iterator and 
const_iterator), and prints the value using gtest's built-in format if yes.  
The user has no way to override this decision: even if he defines a << or 
PrintTo() for the class in its namespace, gtest will still use gtest's own 
printer.

The rationale behind this decision is that some environments gtest works in 
define their own << for STL containers and they do a poor (compared to gtest) 
job of formatting the container contents.  We want to use gtest's printer even 
though a << is available for the type.

This is hacky but has been working well...  Until recently we found that some 
classes define 'iterator' or 'const_iterator' as *private* member types.  This 
breaks gtest's container-detection code and results in a compiler error when 
gtest tries to print such an object.

We could ask the class author to make its 'iterator' and 'const_iterator' 
members public, but it may not always be a good option.  It would be nice if a 
*user* (as opposed to an owner) of the class could work around the problem by 
providing a PrintTo() function for the class.

Therefore, I think it's useful to change gtest's printer logic to use a custom 
<< or PrintTo() first if one is available, and only do the container-detection 
when no << or PrintTo() is defined for the type.  It may result in degraded 
formatting in some cases (when an inferior << is defined by the user or 
third-party for a container class), but is more principled, and gives the user 
the flexibility of overriding gtest's decision if he really wants to.

Original issue reported on code.google.com by w...@google.com on 9 Mar 2011 at 7:40