{"id":102816,"date":"2019-08-29T07:00:00","date_gmt":"2019-08-29T14:00:00","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/oldnewthing\/?p=102816"},"modified":"2019-08-29T06:29:15","modified_gmt":"2019-08-29T13:29:15","slug":"20190829-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20190829-00\/?p=102816","title":{"rendered":"On resolving the type vs member conflict in C++, revisited"},"content":{"rendered":"

Some time ago, I wrote about the type vs. member conflict<\/a>, known informally as The Color Color problem<\/i>. I may have started in the deep end of the pool, so here’s a little bit of getting-up-to-speed so that article might make more sense.<\/p>\n

namespace Windows::UI::Xaml\r\n{\r\n  enum class Visibility { Collapsed, Visible };\r\n\r\n  struct Style { \/* ... *\/ };\r\n\r\n  namespace Controls\r\n  {\r\n    struct UIElement\r\n    {\r\n    public:\r\n      \/* ... *\/\r\n\r\n      \/\/ returns current visibility\r\n      Windows::UI::Xaml::Visibility Visibility();\r\n\r\n      \/\/ change visibility\r\n      void Visibility(Windows::UI::Xaml::Visibility value);\r\n\r\n      \/\/ returns current style\r\n      Windows::UI::Xaml::Style Style();\r\n\r\n      \/\/ change style\r\n      void Style(Windows::UI::Xaml::Style value);\r\n    };\r\n  }\r\n}\r\n<\/pre>\n
The fundamental problem here is that there is a name conflict between the type Style<\/code> and the method Style<\/code>. There is also a name conflict between the type Visibility<\/code> and the method Visibility<\/code>.<\/p>\n
When used from within the UIElement<\/code> class, or any class derived from it, the names Style<\/code> and Visibility<\/code> refer to the methods UIElement::<\/code>Style<\/code> and UIElement::<\/code>Visibility<\/code>, rather than to the types.<\/p>\n
In language-speak, these are unqualified names<\/i>, meaning that the name is just hanging out by itself without any clues as to where to find it. You’re asking the compiler to figure out what you’re referring to. And if you are using the name in the context of a class, the members of the class have priority over names outside the class.<\/p>\n
In other words, the method names Style<\/code> and Visibility<\/code> cause the type names to become hidden. (Another name for this is shadowing<\/i>.)<\/p>\n
Some people tut-tut at this problem and declared, “You silly Windows people, using Pascal case for your names. If you had followed the language standard naming pattern, this problem wouldn’t even exist!”<\/p>\n
The C++ language standard naming convention has the same problem. In the C++ standard library, type names are snake_case<\/code>, and method names are also snake_case<\/code>. The method<\/p>\n
mutex_type* std::shared_lock::mutex<\/u>() const noexcept;\r\n<\/pre>\n
has a name mutex<\/code> that shadows the type name std::mutex<\/code>. If you derive from std::shared_lock<\/code> and try to use a mutex<\/code>, you’re going to get the method, not the type.<\/p>\n
Even outside of Windows, type hiding is not a purely theoretical problem: The sys\/stat.h<\/code> header file defines a structure called struct stat<\/code>, as well as a function stat()<\/code>. As a result, you are forced to say struct<\/u> stat<\/code> in order to get the structure. Writing stat<\/code> by itself gets you the function.<\/p>\n
So keep your eye open for the Color Color<\/code> problem, even if your use case doesn’t involve Color<\/code>.<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Filling in some gaps in the previous discussion.<\/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-102816","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Filling in some gaps in the previous discussion.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102816","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=102816"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102816\/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=102816"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=102816"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=102816"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}