In C++, there are ambiguities when a member function has the same name as a type. Consider: <\/p>\n
\n\/\/ Some header file from a UI library you are using\n\nnamespace Windows::UI::Xaml\n{\n enum class Visibility { Collapsed, Visible };\n\n struct Style { \/* ... *\/ };\n\n namespace Controls\n {\n struct UIElement\n {\n public:\n \/* ... *\/\n\n \/\/ returns current visibility\n Windows::UI::Xaml::Visibility Visibility();\n\n \/\/ change visibility\n void Visibility(Windows::UI::Xaml::Visibility value);\n\n \/\/ returns current style\n Windows::UI::Xaml::Style Style();\n\n \/\/ change style\n void Style(Windows::UI::Xaml::Style value);\n };\n }\n}\n<\/pre>\nYour project has a custom element, say like this: <\/p>\n
\nnamespace MyProject\n{\n class CustomElement : public Windows::UI::Xaml::Controls::UIElement\n {\n void OnThemeChanged();\n };\n}\n<\/pre>\nAnd now you are implementing the OnThemeChanged<\/code> method. <\/p>\n\nusing namespace Windows::UI::Xaml;\n\nvoid MyProject::CustomElement::OnThemeChanged()\n{\n \/\/ Find out what style to use.\n Style style = GetStyleFromCurrentTheme();\n\n \/\/ Set it as our style.\n Style(style);\n}\n<\/pre>\nThis code doesn’t compile. The word Style<\/code> can mean multiple things: <\/p>\n\n- It could refer to the class
Windows::<\/code>UI::<\/code>Xaml::<\/code>Style<\/code>. <\/li>\n- It could refer to the method
MyProject::<\/code>CustomElement::<\/code>Style()<\/code>. <\/li>\n<\/ul>\nC++ unqualified name lookup in member functions<\/a> searches the class before searching in namespaces, so it finds the method CustomElement::<\/code>Style()<\/code>. SFINAE<\/a> does not apply, so if the name inside the class doesn’t make sense, the compiler doesn’t keep looking for a better match; it simply reports an error. Depending on how you used the name Style<\/code>, the error message will vary, but whatever it is, it is usually incomprehensible. <\/p>\n\nerror: expected ';' before 'style'\nerror: statement cannot resolve address of overloaded function\n\nerror: cannot determine which instance of overloaded function\n'MyProject::CustomElement::Style' is intended\nerror: expected a \";\"\n\nerror: syntax error: missing ';' before identifier 'style'\nerror: non-standard syntax; use '&' to create a pointer to member\n<\/pre>\nThese error messages make sense once you realize that the compiler resolved Style<\/code> to the member function. It’s a case of an error message written with compiler-colored glasses. To be fair, the compiler doesn’t realize that it’s wearing glasses. It’s simply following the rules for unqualified name resolution and reporting the problems with the name you chose by mistake. <\/p>\nThe only compiler I found that generates a helpful error is clang, which goes the extra mile and realizes that the name the language rules require it to choose may not have been the name you intended. <\/p>\n
\nerror: must use 'struct' tag to refer to type 'Style' in this scope\nnote: struct 'Style' is hidden by a non-type declaration of 'Style' here\n Windows::UI::Xaml::Style Style();\n<\/pre>\nThe clang compiler even provides a suggestion as to how you can force the name to be resolved the way you intended. <\/p>\n
\nvoid MyProject::CustomElement::OnThemeChanged()\n{\n \/\/ Find out what style to use.\n struct<\/font> Style style = GetStyleFromCurrentTheme();\n\n \/\/ Set it as our style.\n Style(style);\n}\n<\/pre>\nAlternatively, you can use the scope resolution operator to force the name to be looked up in the global scope: <\/p>\n
\nvoid MyProject::CustomElement::OnThemeChanged()\n{\n \/\/ Find out what style to use.\n ::<\/font>Style style = GetStyleFromCurrentTheme();\n\n \/\/ Set it as our style.\n Style(style);\n}\n<\/pre>\nThe global lookup will work because you did a using namespace Windows:<\/code>:UI::<\/code>Xaml;<\/code> to import the names from that namespace into the global namespace. After all, that’s what led you to believe that writing simply Style<\/code> was good enough in the first place. <\/p>\nThis problem also exists with the Visibility<\/code> enumeration: <\/p>\n\nvoid MyProject::CustomElement::OnThemeChanged()\n{\n \/\/ See if we should be visible in the current theme.\n Visibility visibility = IsVisibleInCurrentTheme();\n \/\/^^^^^^^^ compiler error here\n\n \/\/ Set it as our new visibility.\n Visibility(visibility);\n}\n<\/pre>\nThe solution is the same. You need to quailfy the name in a way that prevents the compiler from considering the member function. You could say enum Visibility<\/code>, or you could say ::Visibility<\/code>. <\/p>\nNote, however, that there is no problem here: <\/p>\n
\nvoid MyProject::CustomElement::OnThemeChanged()\n{\n \/\/ Always hide on theme change.\n Visibility(Visibility::Collapsed);\n \/\/ ^^^^^^^^^^ no ambiguity here\n}\n<\/pre>\nThere is no ambiguity in this case because of a special rule for unqualified name lookup that excludes functions, variables, and enumeration fields if the name is followed by a ::<\/code><\/a>. <\/p>\nThe case of a member with the same name as a type is called the Color Color problem<\/a>, and the C# language “was specifically designed to permit” it<\/a>. Unfortunately, the C++ language struggles with it. <\/p>\n","protected":false},"excerpt":{"rendered":"You have to nudge the compiler in the right direction.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-102431","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
You have to nudge the compiler in the right direction.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102431","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=102431"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102431\/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=102431"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=102431"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=102431"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}