{"id":1575,"date":"2018-08-31T23:13:49","date_gmt":"2018-09-01T06:13:49","guid":{"rendered":"http:\/\/www.elbeno.com\/blog\/?p=1575"},"modified":"2018-08-31T23:16:46","modified_gmt":"2018-09-01T06:16:46","slug":"pointer-to-member-functions-can-be-tricky","status":"publish","type":"post","link":"https:\/\/www.elbeno.com\/blog\/?p=1575","title":{"rendered":"Pointer-to-member-functions can be tricky"},"content":{"rendered":"

Note: the following applies to Microsoft’s compiler only — not to GCC or Clang.<\/p>\n

Pointers-to-member-functions (PMFs) are a bit off the beaten track in C++. They aren’t very syntactically pleasing, and they aren’t as easy to deal with as regular pointers-to-free-functions (PFFs). But they still see use, particularly in pre-C++11 codebases or where people choose to avoid the overhead of std::function<\/code> or lambdas as template arguments.<\/p>\n

Although idiosyncratic, the way Microsoft’s compiler implements PMFs is fairly well-known in its effects. Classes that use single inheritance can achieve PMFs the same size as PFFs, i.e. the size of a pointer. Classes that use multiple inheritance must use an implementation-defined structure, which is larger than a pointer.<\/p>\n

This snippet of code<\/a> illustrates the difference.<\/p>\n

This has all been well-documented on Raymond Chen’s blog<\/a>, The Old New Thing<\/em>, for years now. But given the scarcity of PMF usage, subtle dangers still lurk.<\/p>\n

One issue can arise when separating the definition of a PMF from its class. Let’s say we have a class defined in a header a.h<\/code>:<\/p>\n

\r\nclass A\r\n{\r\n  \/\/ probably a reasonable size class; we're going to use \r\n  \/\/ PMFs for this class\r\n\r\n  \/\/ multiple inheritance is rare, and this class doesn't \r\n  \/\/ use it, so PMFs for this class will be just the size\r\n  \/\/ of a pointer\r\n};\r\n<\/pre>\n
Because A<\/code> is a fairly large class, we might have a forward declaration for A<\/code>, either in a conventionally-named header such as a_fwd.h<\/code>, or just as a standalone forward declaration where pointers and references to A<\/code> are used.<\/p>\n
Then, in another file somewhere, we have a class that uses PMFs for A<\/code>:<\/p>\n
\r\nusing A_PMF = auto (A::*)() -> void;\r\n\r\nclass B\r\n{\r\n  A_PMF a_pmf;\r\n\r\n  \/\/ other stuff...  \r\n};\r\n<\/pre>\n
A hard-to-diagnose bug lurks here. Do you see it?<\/p>\n
We would assume that A_PMF<\/code> is the size of a pointer. Generally, multiple inheritance is rarer than single inheritance, so this is nice, and what we normally expect from MSVC.<\/p>\n
However, the size of A_PMF<\/code> — and therefore the size of B<\/code> — differs<\/strong> depending on whether A<\/code>‘s class definition is known, or A<\/code> is simply forward-declared!<\/p>\n
If A<\/code> is known, the compiler knows A<\/code> is using single inheritance, and therefore A_PMF<\/code> can be the size of a pointer. This is our normal expectation.<\/p>\n
If A<\/code> is forward-declared, we can still declare A_PMF<\/code>. But now the compiler doesn’t know for sure that A_PMF<\/code> can be the size of a pointer. A<\/code> could use multiple inheritance, so the compiler must err on the side of caution and use the implementation-defined structure for A_PMF<\/code>.<\/p>\n
This can lead to B<\/code> being two different sizes in two different translation units! We could have one where a.h<\/code> is included (and A<\/code> is known) and one where only a_fwd.h<\/code> is included. Both versions will compile without warnings<\/a>, but of course, depending on what comes after a_pmf<\/code> in B<\/code>, the bug may not show up immediately.<\/p>\n
When it does show up, it may be difficult to diagnose because the debugger probably has perfect knowledge of A_PMF<\/code> and will claim that it’s the size of a pointer, even when the translation unit you’re looking at compiled it differently. You can run into situations where you print a value, but when you break at the print statement, what prints is not what the debugger shows. This can be rather confusing, to say the least!<\/p>\n
Perhaps the moral is: if you’re going to use PMFs, declare them right next to the class they belong with, and beware forward declarations.<\/p>\n","protected":false},"excerpt":{"rendered":"
Note: the following applies to Microsoft’s compiler only — not to GCC or Clang. Pointers-to-member-functions (PMFs) are a bit off the beaten track in C++. They aren’t very syntactically pleasing, and they aren’t as easy to deal with as regular pointers-to-free-functions (PFFs). But they still see use, particularly in pre-C++11…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22],"tags":[],"class_list":["post-1575","post","type-post","status-publish","format-standard","hentry","category-cpp"],"_links":{"self":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1575","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=1575"}],"version-history":[{"count":15,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1575\/revisions"}],"predecessor-version":[{"id":1590,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1575\/revisions\/1590"}],"wp:attachment":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1575"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1575"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1575"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}