{"id":958,"date":"2015-02-01T23:39:46","date_gmt":"2015-02-02T07:39:46","guid":{"rendered":"http:\/\/www.elbeno.com\/blog\/?p=958"},"modified":"2015-06-30T21:17:35","modified_gmt":"2015-07-01T04:17:35","slug":"how-to-print-anything-in-c-part-2","status":"publish","type":"post","link":"https:\/\/www.elbeno.com\/blog\/?p=958","title":{"rendered":"How to print anything in C++ (part 2)"},"content":{"rendered":"

Part 1<\/a> Part 2<\/a> Part 3<\/a> Part 4<\/a> Part 5<\/a> Postscript<\/a><\/p>\n

We have a basic plan, and the ability to detect concrete types. But how can we detect whether an object supports output with operator<<<\/code>? For this, there is a recently-discovered amazing trick. Here’s the code:<\/p>\n

\r\ntemplate \r\nusing void_t = void;\r\n\r\ntemplate \r\nusing operator_output_t = decltype(std::cout << std::declval());\r\n\r\ntemplate \r\nstruct has_operator_output : public std::false_type {};\r\n\r\ntemplate \r\nstruct has_operator_output>> \r\n  : public std::true_type {};\r\n<\/pre>\n
The key here is void_t<\/code>. It’s a template alias that takes any template arguments, and always produces void<\/code>. So what’s the use of that? Well, it doesn’t take just any old arguments<\/em>. It can only work with well-formed types<\/em>. So what happens if we give it a type that isn’t well-formed? Nothing too bad – because of course, Substitution Failure Is Not An Error.<\/p>\n
Look at operator_output_t<\/code>. It uses decltype<\/code> to produce the type of outputting a T<\/code>. If T<\/code> doesn’t support operator<<<\/code>, this type will be invalid.<\/p>\n
Now look at has_operator_output<\/code>. We specialize it using the result of void_t<\/code> on operator_output_t<T><\/code>. If this is ill-formed (T<\/code> can’t support operator<<<\/code>) then substitution fails and the unspecialized template, std::false_type<\/code>, is used. But if T supports operator<<<\/code>, the result of void_t<\/code> is well-formed. It’s still void<\/code>, but it’s more specialized<\/em> than the default template and so we get std::true_type<\/code>!<\/p>\n
That is the magic that void_t<\/code> allows; a whole new frontier of template metaprogramming. (And if we relax the “because-we-can-be-general” variadic template, and convert the template aliases, it’s plain old C++98 specialization! Although it’s the combo with decltype<\/code> and declval<\/code> that really gives it phenomenal cosmic power.)<\/p>\n
I’m going to set up a template to work on the tag types, so that the default implementation of stringifier<\/code> in part 1<\/a> now becomes stringifier_select<\/code> with a tag type that we can specialize on:<\/p>\n
\r\ntemplate \r\nstruct stringifier_select;\r\n\r\ntemplate \r\nusing stringifier = stringifier_select>;\r\n\r\ntemplate \r\nstruct stringifier_select\r\n{\r\n  explicit stringifier_select(const T&) {}\r\n\r\n  std::ostream& output(std::ostream& s) const\r\n  {\r\n    return s << \"\";\r\n  }\r\n};\r\n<\/pre>\n
And I can set up type discrimination for outputtable types, and implement their output<\/code> function trivially:<\/p>\n
\r\ntemplate \r\nusing stringifier_tag = std::conditional_t<\r\n  has_operator_output::value,\r\n  is_outputtable_tag,\r\n  void>;\r\n\r\ntemplate \r\nstruct stringifier_select\r\n{\r\n  explicit stringifier_select(const T& t) : m_t(t) {}\r\n\r\n  std::ostream& output(std::ostream& s) const\r\n  {\r\n    return s << m_t;\r\n  }\r\n\r\n  const T& m_t;\r\n};\r\n<\/pre>\n
So, now that we know the void_t<\/code> pattern, it's trivial to use it for detecting any container type; in fact, any type that has begin()<\/code> and end()<\/code>.<\/p>\n
\r\ntemplate \r\nusing begin_t = decltype(std::declval().begin());\r\n\r\ntemplate \r\nstruct has_begin : public std::false_type {};\r\n\r\ntemplate \r\nstruct has_begin>> \r\n  : public std::true_type {};\r\n\r\ntemplate \r\nusing end_t = decltype(std::declval().end());\r\n\r\ntemplate \r\nstruct has_end : public std::false_type {};\r\n\r\ntemplate \r\nstruct has_end>> \r\n  : public std::true_type {};\r\n<\/pre>\n
And then we have a very straightforward way to detect a container or other iterable type:<\/p>\n
\r\ntemplate\r\nusing is_iterable = typename std::conditional<\r\n  has_begin::value && has_end::value,\r\n  std::true_type, std::false_type>::type;\r\n<\/pre>\n
To actually output a container, we will need to output surrounding braces and a comma in between each element. We might want to vary opening\/closing\/separating characters by container type, so I want to allow them to be specialized:<\/p>\n
\r\ntemplate \r\nstruct iterable_opener\r\n{\r\n  constexpr const char* operator()(const T&) const\r\n  { return \"{\"; }\r\n};\r\n\r\ntemplate \r\nstruct iterable_closer\r\n{\r\n  constexpr const char* operator()(const T&) const\r\n  { return \"}\"; }\r\n};\r\n\r\ntemplate \r\nstruct iterable_separator\r\n{\r\n  constexpr const char* operator()(const T&) const\r\n  { return \",\"; }\r\n};\r\n<\/pre>\n
I originally implemented each of these as a straightforward const char*<\/code>, but using functions and passing the container itself allows them to access (for example) size information which might be useful.<\/p>\n
Now that we have the customization points in place, we can write the specialization of stringifier<\/code> for containers. There's a minor wrinkle to deal with fenceposting the separators.<\/p>\n
\r\ntemplate \r\nstruct stringifier_select\r\n{\r\n  explicit stringifier_select(const T& t) : m_t(t) {}\r\n\r\n  std::ostream& output(std::ostream& s) const\r\n  {\r\n    s << iterable_opener()(m_t);\r\n    auto b = m_t.begin();\r\n    auto e = m_t.end();\r\n    if (b != e)\r\n      s << prettyprint(*b);\r\n    std::for_each(++b, e,\r\n                  [&s, this] (auto& e)\r\n                  { s << iterable_separator()(m_t)\r\n                      << prettyprint(e); });\r\n    return s << iterable_closer()(m_t);\r\n  }\r\n  const T& m_t;\r\n};\r\n<\/pre>\n
(Notice that it calls prettyprint<\/code> to output each element recursively.) And that's it, we can handle all iterable things. Next, handling pair<\/code> and tuple<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Part 1 Part 2 Part 3 Part 4 Part 5 Postscript We have a basic plan, and the ability to detect concrete types. But how can we detect whether an object supports output with operator<<? For this, there is a recently-discovered amazing trick. Here’s the code: template using void_t =…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,8],"tags":[],"class_list":["post-958","post","type-post","status-publish","format-standard","hentry","category-cpp","category-programming"],"_links":{"self":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/958","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=958"}],"version-history":[{"count":9,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/958\/revisions"}],"predecessor-version":[{"id":1000,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/958\/revisions\/1000"}],"wp:attachment":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=958"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=958"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=958"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}