{"id":517,"date":"2010-08-04T18:12:32","date_gmt":"2010-08-04T18:12:32","guid":{"rendered":"http:\/\/kera.name\/articles\/?p=517"},"modified":"2011-06-22T09:27:30","modified_gmt":"2011-06-22T09:27:30","slug":"overcoming-name-shadowing-in-c","status":"publish","type":"post","link":"https:\/\/kera.name\/articles\/2010\/08\/overcoming-name-shadowing-in-c\/","title":{"rendered":"Overcoming Name Shadowing In C++"},"content":{"rendered":"<p>(In the below article, <a href=\"http:\/\/www.eelis.net\/geordi\/\">geordi<\/a> is used to test snippets. &#034;BARK&#034; is a geordi macro that outputs the function name of the enclosing scope.)<\/p>\n<p>Here I briefly explore a common inheritance gotcha and its usual solution.<\/p>\n<h3>Normal overloading<\/h3>\n<p><textarea name=\"code\" class=\"cpp:nocontrols:nogutter\" cols=\"60\" rows=\"10\">struct A { void lol(int); void lol(string); };<\/textarea>\n<\/p>\n<p><code>A::lol(int)<\/code> and <code>A::lol(string)<\/code> are actually different functions.<\/p>\n<h3>Overloading with inheritance<\/h3>\n<p><textarea name=\"code\" class=\"cpp:nocontrols:nogutter\" cols=\"60\" rows=\"10\">struct A { void lol(int) { BARK; } };\nstruct B : A { void lol(string) { BARK; } };\nint main() { B b; b.lol(\"d\"); }\n\/\/B::lol(string)<\/textarea>\n<\/p>\n<p><textarea name=\"code\" class=\"cpp:nocontrols:nogutter\" cols=\"60\" rows=\"10\">struct A { void lol(int) { BARK; } };\nstruct B : A { void lol(string) { BARK; } };\nint main() { B b; b.lol(3); }\n\/\/error: no matching function for call to 'B::lol(int)'<\/textarea>\n<\/p>\n<p>Here one might expect the second example to work, with the output &#034;A::lol(3)&#034; since the function clearly exists and should be inherited.<\/p>\n<p>But in our example, <code>B::lol(string)<\/code> hides or &#034;shadows&#034; <code>A::lol(int)<\/code> so the lookup doesn&#039;t work. Since there is the function with the name &#034;<code>lol<\/code>&#034; in B, when you try to call <code>b.lol(3)<\/code> the compiler never bothers to look for other functions with the name &#034;<code>lol<\/code>&#034; that might be in <code>A<\/code>.<\/p>\n<p>We could be a bit more explicit with our function call:<\/p>\n<p><textarea name=\"code\" class=\"cpp:nocontrols:nogutter\" cols=\"60\" rows=\"10\">struct A { void lol(int) { BARK; } };\nstruct B : A { void lol(string) { BARK; } };\nint main() { B b; b.A::lol(3); }\n\/\/A::lol(int)<\/textarea>\n<\/p>\n<p>But that&#039;s a bit minging. It would be nicer to fix the lookup from within the class definition itself. To do so, we must bring <code>A::lol(int)<\/code> into scope of <code>B<\/code> with the <code>using<\/code> keyword so that the two functions <code>lol(string)<\/code> and <code>lol(int)<\/code> can live side by side in harmony.<\/p>\n<h3>With &#039;using&#039;<\/h3>\n<p><textarea name=\"code\" class=\"cpp:nocontrols:nogutter\" cols=\"60\" rows=\"10\">struct A { void lol(int) { BARK; } };\nstruct B : A { using A::lol; void lol(string) { BARK; } };\nint main() { B b; b.lol(\"d\"); b.lol(3) }\n\/\/B::lol(string) A::lol(int)<\/textarea>\n<\/p>\n<p>It doesn&#039;t matter where you put the &#039;using&#039; statement; it won&#039;t ever cancel out <code>B::lol(string)<\/code>, even if it comes after the function definition:<\/p>\n<p><textarea name=\"code\" class=\"cpp:nocontrols:nogutter\" cols=\"60\" rows=\"10\">struct A { void lol(int) { BARK; } };\nstruct B : A { void lol(string) { BARK; } using A::lol; };\nint main() { B b; b.lol(\"d\"); b.lol(3); }\n\/\/B::lol(string) A::lol(int)<\/textarea>\n<\/p>\n<p>Implicit conversions don&#039;t break this either:<\/p>\n<p><textarea name=\"code\" class=\"cpp:nocontrols:nogutter\" cols=\"60\" rows=\"10\">struct A { void lol(A<em>) { BARK; } };\nstruct B : A { using A::lol; void lol(B<\/em>) { BARK; } };\nint main() { B b; b.lol((B<em>)&b); b.lol((A<\/em>)&b); }\n\/\/B::lol(B<em>) A::lol(A<\/em>)<\/textarea>\n<\/p>\n<p><textarea name=\"code\" class=\"cpp:nocontrols:nogutter\" cols=\"60\" rows=\"10\">struct B;\nstruct A { void lol(B<em>) { BARK; } };\nstruct B : A { using A::lol; void lol(A<\/em>) { BARK; } };\nint main() { B b; b.lol((B<em>)&b); b.lol((A<\/em>)&b); }\n\/\/B::lol(A<em>) A::lol(B<\/em>)<\/textarea>\n<\/p>\n<p>So there you go.<\/p>\n<hr>\n<p><b>Update 05\/05\/2011:<\/b> Here&#039;s <a href=\"http:\/\/stackoverflow.com\/questions\/5896908\/understanding-simple-c-inheritance\/5896943#5896943\">a really good explanation<\/a> of the cause behind this shadowing.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I briefly explore a common inheritance gotcha and its usual solution.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[21,20],"_links":{"self":[{"href":"https:\/\/kera.name\/articles\/wp-json\/wp\/v2\/posts\/517"}],"collection":[{"href":"https:\/\/kera.name\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kera.name\/articles\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kera.name\/articles\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kera.name\/articles\/wp-json\/wp\/v2\/comments?post=517"}],"version-history":[{"count":5,"href":"https:\/\/kera.name\/articles\/wp-json\/wp\/v2\/posts\/517\/revisions"}],"predecessor-version":[{"id":720,"href":"https:\/\/kera.name\/articles\/wp-json\/wp\/v2\/posts\/517\/revisions\/720"}],"wp:attachment":[{"href":"https:\/\/kera.name\/articles\/wp-json\/wp\/v2\/media?parent=517"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kera.name\/articles\/wp-json\/wp\/v2\/categories?post=517"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kera.name\/articles\/wp-json\/wp\/v2\/tags?post=517"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}