Gitiles
Code Review Sign In
gerrit.cesnet.cz / github / onqtam / doctest / 24725ad29895264a91a2d558030b299e86dbc881 / . / doc / html_generated / stringification.html
blob: 70c2846e9953c9fabcf106bc7cf67b7f258e2a16 [file] [log] [blame]
onqtam8126b562016-05-27 17:01:15 +0300[diff] [blame]1<!DOCTYPE html>
2<html>
3<title>stringification</title>
4<xmp theme="united" style="display:none;">
5
6## String conversions
7
8**doctest** needs to be able to convert types you use in assertions and logging expressions into strings (for logging and reporting purposes).
9Most built-in types are supported out of the box but there are three ways that you can tell **doctest** how to convert your own types (or other, third-party types) into strings.
10
11## ```operator<<``` overload for ```std::ostream```
12
13This is the standard way of providing string conversions in C++ - and the chances are you may already provide this for your own purposes. If you're not familiar with this idiom it involves writing a free function of the form:
14
15```
16std::ostream& operator<< (std::ostream& os, const T& value) {
onqtamb8220c52017-05-16 00:21:15 +0300[diff] [blame]17 os << convertMyTypeToString(value);
18 return os;
onqtam8126b562016-05-27 17:01:15 +0300[diff] [blame]19}
20```
21
22(where ```T``` is your type and ```convertMyTypeToString``` is where you'll write whatever code is necessary to make your type printable - it doesn't have to be in another function).
23
24You should put this function in the same namespace as your type.
25
26Alternatively you may prefer to write it as a member function:
27
28```
29std::ostream& T::operator<<(std::ostream& os) const {
onqtamb8220c52017-05-16 00:21:15 +0300[diff] [blame]30 os << convertMyTypeToString(*this);
31 return os;
onqtam8126b562016-05-27 17:01:15 +0300[diff] [blame]32}
33```
34
35## ```doctest::toString``` overload
36
onqtamb18680d2016-11-15 14:08:56 +0200[diff] [blame]37If you don't want to provide an ```operator<<``` overload, or you want to convert your type differently for testing purposes, you can provide an overload for ```toString()``` for your type which returns ```doctest::String```.
onqtam8126b562016-05-27 17:01:15 +0300[diff] [blame]38
39```
onqtamb18680d2016-11-15 14:08:56 +0200[diff] [blame]40namespace user {
41 struct udt {};
42
onqtamb8220c52017-05-16 00:21:15 +0300[diff] [blame]43 doctest::String toString(const udt& value) {
44 return convertMyTypeToString(value);
45 }
onqtam8126b562016-05-27 17:01:15 +0300[diff] [blame]46}
47```
48
onqtamb18680d2016-11-15 14:08:56 +0200[diff] [blame]49Note that the function must be in the same namespace as your type. If the type is not in any namespace - then the overload should be in the global namespace as well. ```convertMyTypeToString``` is where you'll write whatever code is necessary to make your type printable.
onqtam8126b562016-05-27 17:01:15 +0300[diff] [blame]50
51## ```doctest::StringMaker<T>``` specialisation
52
53There are some cases where overloading ```toString``` does not work as expected. Specialising ```StringMaker<T>``` gives you more precise and reliable control - but at the cost of slightly more code and complexity:
54
55```
56namespace doctest {
onqtamb8220c52017-05-16 00:21:15 +0300[diff] [blame]57 template<> struct StringMaker<T> {
58 static String convert(const T& value) {
59 return convertMyTypeToString(value);
onqtam8126b562016-05-27 17:01:15 +0300[diff] [blame]60 }
61 };
62}
63```
64
onqtamb8220c52017-05-16 00:21:15 +0300[diff] [blame]65## Translating exceptions
66
67By default all exceptions deriving from ```std::exception``` will be translated to strings by calling the ```what()``` method. For exception types that do not derive from ```std::exception``` - or if ```what()``` does not return a suitable string - use ```REGISTER_EXCEPTION_TRANSLATOR```. This defines a function that takes your exception type and returns a ```doctest::String```. It can appear anywhere in the code - it doesn't have to be in the same translation unit. For example:
68
69```
70REGISTER_EXCEPTION_TRANSLATOR(MyType& ex) {
71 return doctest::String(ex.message());
72}
73```
74
75Note that the exception may be accepted without a reference but it is considered bad practice in C++.
76
77An alternative way to register an exception translator is to do the following in some function - before executing any tests:
78
79```
80 // adding a lambda - the signature required is `doctest::String(exception_type)`
81 doctest::registerExceptionTranslator<int>([](int in){ return doctest::toString(in); });
82```
83
84The order of registering exception translators can be controlled - simply call the explicit function in the required order or list the exception translators with the macro in a top-to-bottom fashion in a single translation unit - everything that auto-registers in doctest works in a top-to-bottom way for a single translation unit (source file).
85
onqtam8126b562016-05-27 17:01:15 +0300[diff] [blame]86------
87
onqtamb8220c52017-05-16 00:21:15 +0300[diff] [blame]88- Check out the [**example**](../../examples/all_features/stringification.cpp) which shows how to stringify ```std::vector<T>``` and other types/exceptions.
89- Note that the type ```String``` is used when specializing ```StringMaker<T>``` or overloading ```toString()``` - it is the string type **doctest** works with. ```std::string``` is not an option because doctest would have to include the ```<string>``` header.
onqtam1435c012016-09-21 15:29:11 +0300[diff] [blame]90- To support the ```operator<<(std::ostream&...``` stringification the library has to offer a forward declaration of ```std::ostream``` and that is what the library does - but it is forbidden by the standard. It currently works everywhere - on all tested compilers - but if the user wishes to be 100% standards compliant - then the [**```DOCTEST_CONFIG_USE_IOSFWD```**](configuration.html#doctest_config_use_iosfwd) identifier can be used to force the inclusion of ```<iosfwd>```. The reason the header is not included by default is that on MSVC (for example) it drags a whole bunch of stuff with it - and after the preprocessor is finished the translation unit has grown to 42k lines of C++ code - while Clang and the libc++ are so well implemented that including ```<iosfwd>``` there results in 400 lines of code.
onqtam8126b562016-05-27 17:01:15 +0300[diff] [blame]91
92---
93
94[Home](readme.html#reference)
95
96
97</xmp>
98<script src="strapdown.js/strapdown.js"></script>
99</html>