{"id":103556,"date":"2020-03-12T07:00:00","date_gmt":"2020-03-12T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=103556"},"modified":"2020-03-11T17:36:33","modified_gmt":"2020-03-12T00:36:33","slug":"20200312-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20200312-00\/?p=103556","title":{"rendered":"Of what use is a type-dependent expression that is always false?"},"content":{"rendered":"

Last time<\/a>, we saw how to create a type-dependent expression that is always false, and used it in a potentially-discarded statement so that the assertion failed only if the statement ended up being used.<\/p>\n

Another case where you want to defer a static assertion failure to instantiation is if you want to reject a particular specialization.<\/p>\n

Say you have a method that you want to overload, but a particular version of the overload is disallowed. You could use std::<\/code>enable_<\/code>if<\/code> to remove that overload from consideration, leading to a compiler error of the form “No suitable overload found.”<\/p>\n

For example, suppose we have a buffer_<\/code>view<\/code> that represents the raw bytes stored in a vector.<\/p>\n

struct buffer_view\r\n{\r\n  template<typename C>\r\n  buffer_view(std::vector<C> const& v) :\r\n    data(v.data()), size(v.size() * sizeof(C)) { }\r\n\r\n  \/\/ Imagine other constructors for std::array, etc.\r\n\r\n  void const* data;\r\n  std::size_t size;\r\n};\r\n<\/pre>\n
The idea here is that this is a buffer for passing raw bytes to another function. Therefore, in practice, you probably would add a<\/p>\n
typename = std::enable_if_t<std::is_trivial<C>::value>\r\n<\/pre>\n
to the template parameters, so that people won’t try to pass things like std::string<\/code> as a buffer. In practice, you probably also would want a second template parameter std::vector<T, Alloc><\/code> in order to support non-default allocators. But I’ve left off these adjustments to simplify the exposition.<\/p>\n
This class works great until somebody tries this:<\/p>\n
std::vector<bool> flags;\r\nauto view = buffer_view(flags);\r\n<\/pre>\n
The C++ language defines a specialization std::vector<bool><\/code> which represents a packed bit array, rather than defining a separate type like std::bitvector<\/code>. This has made a lot of people very angry and  has been widely regarded<\/a> as a  bad move<\/a>.<\/p>\n
One of the quirks of std::vector<bool><\/code> is that it lacks a data()<\/code> method.<\/p>\n
If you pass in a std::vector<bool><\/code>, you get the weird error from the Microsoft compiler:<\/p>\n
error C2039: 'data': is not a member of 'std::vector<bool, std::allocator<_Ty>>'\r\n        with\r\n        [\r\n            _Ty=bool\r\n        ]\r\nnote: see declaration of 'std::vector<bool, std::allocator<_Ty>>'\r\n        with\r\n        [\r\n            _Ty=bool\r\n        ]\r\nnote: see reference to function template instantiation\r\n'buffer_view::buffer_view<bool>(const std::vector<bool, std::allocator<_Ty>> &)' being compiled\r\n        with\r\n        [\r\n            _Ty=bool\r\n        ]\r\n<\/pre>\n
gcc and clang produce a completely bizarre error:<\/p>\n
error: 'this' argument to member function 'data' has type 'const std::vector<bool>', but function is not marked const\r\n    data(v.data()), size(v.size() * sizeof(C)) { }\r\n         ^\r\n<\/pre>\n
I mean, technically, all the error messages are “correct” in the sense that all the standard requires is the generation of a diagnostic, but does not require that the diagnostic be useful.<\/p>\n
We might try to improve the error message by specializing the constructor for std::vector<bool><\/code> and deleting it.<\/p>\n
template<>\r\nbuffer_view::buffer_view(std::vector<bool> const& v) = delete;\r\n<\/pre>\n
Now the error messages are a little better:<\/p>\n
error C2280: 'buffer_view::buffer_view<bool>(const std::vector<bool, std::allocator<_Ty>> &)':\r\nattempting to reference a deleted function\r\n        with\r\n        [\r\n            _Ty=bool\r\n        ]\r\nnote: see declaration of 'buffer_view::buffer_view'\r\nnote: 'buffer_view::buffer_view<bool>(const std::vector<bool, std::allocator<_Ty>> &)': function was explicitly deleted\r\n        with\r\n        [\r\n            _Ty=bool\r\n        ]\r\n\r\ncall to deleted constructor of 'buffer_view'\r\n\r\nuse of deleted function 'buffer_view::buffer_view(const std::vector<C>&) [with C = bool]'\r\n<\/pre>\n
But it would be great if we could generate a custom error message. You might think you could do it by putting a static_assert<\/code> in the body:<\/p>\n
  template<typename C>\r\n  buffer_view(std::vector<C> const& v) :\r\n    data(v.data()), size(v.size() * sizeof(C))\r\n  {\r\n    static_assert(!is_same_v<C, bool>,\r\n      \"Can't use std::vector<bool>. Try std::array instead.\");<\/span>\r\n  }\r\n<\/pre>\n
Unfortunately, this static_<\/code>assert<\/code> happens after the attempt to use v.data()<\/code>, so the first error the developer sees is the incomprehensible one. We want our message to be the first error message, so we can quickly steer the developer in the right direction.<\/p>\n
So we try again with a specialization that doesn’t try to use the v.data()<\/code> method, thereby avoiding the incomprehensible error message. We can then put our custom error message in the specialization.<\/p>\n
template<>\r\nbuffer_view::buffer_view(std::vector<bool> const& v)\r\n{\r\n  static_assert(false, \"blah blah blah\");\r\n}\r\n<\/pre>\n
However, this generates an error even if nobody tries to use the std::vector<bool><\/code> overload because the controlling expression of the static_<\/code>assert<\/code> is not dependent upon the template type.<\/p>\n
So let’s make it dependent upon the template type.<\/p>\n
  template<typename C,\r\n           std::enable_if_t<!std::is_same_v<C, bool>, int> = 0<\/span>>\r\n  buffer_view(std::vector<C> const& v) :\r\n    data(v.data()), size(v.size() * sizeof(C)) { }\r\n\r\n  template<typename C,\r\n           std::enable_if_t<std::is_same_v<C, bool>, int> = 0<\/span>>\r\n  buffer_view(std::vector<C> const& v)\r\n  {\r\n    static_assert(!sizeof(C)<\/span>, \"blah blah blah\");\r\n  }\r\n<\/pre>\n
We create two templated constructors and let enable_if<\/code> decide which one is active. For anything that isn’t bool<\/code>, we activate the first one, and we activate the second one only for bool<\/code>.<\/p>\n
The trick is that we now have a template type name “C<\/code>” that we can use to generate a type-dependent always-false expression to put into the static_<\/code>assert<\/code>. In this case, we can save a character and elide the *<\/code> because we know that the type is exactly bool<\/code>. We don’t need to worry about the case where C<\/code> is an incomplete type or void<\/code>.<\/p>\n
After I wrote this up, I discovered that  Kenny Kerr<\/a> came up with a simpler solution, which we’ll look at next time.<\/p>\n","protected":false},"excerpt":{"rendered":"
Deferring an assertion to instantiation.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-103556","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Deferring an assertion to instantiation.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/103556","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=103556"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/103556\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=103556"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=103556"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=103556"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}