{"id":103066,"date":"2019-11-06T07:00:00","date_gmt":"2019-11-06T15:00:00","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/oldnewthing\/?p=103066"},"modified":"2019-11-05T16:30:08","modified_gmt":"2019-11-06T00:30:08","slug":"20191106-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20191106-00\/?p=103066","title":{"rendered":"How can I have a C++ function that returns different types depending on what the caller wants?"},"content":{"rendered":"

Here’s something crazy: You have a function that has two different callers. One of them expects the function to return a widget. The other expects the function to return a doodad.<\/p>\n

class widget;\r\nclass doodad;\r\n\r\nclass experiment\r\n{\r\npublic:\r\n    doodad get_entity();\r\n    widget get_entity();\r\n};\r\n<\/pre>\n
This is not allowed in C++. The return type of a function cannot be overloaded.<\/p>\n
But  Kenny Kerr<\/a> taught me how to fake it. What you do is return an object that doesn’t yet know whether it’s a widget or doodad.<\/p>\n
class experiment\r\n{\r\npublic:\r\n    auto get_entity()\r\n    {\r\n        struct result\r\n        {\r\n            operator widget()\r\n            {\r\n                return experiment->get_entity_as_widget();\r\n            }\r\n\r\n            operator doodad()\r\n            {\r\n                return experiment->get_entity_as_doodad();\r\n            }\r\n\r\n            experiment* experiment;\r\n        };\r\n        return result{ this };\r\n    }\r\n};\r\n<\/pre>\n
The thing that is returned is neither a widget nor a doodad, but observing it will trigger a collapse to one or the other.<\/p>\n
widget w = exp.get_entity();\r\ndoodad p = exp.get_entity();\r\n<\/pre>\n
In the first call, the get_<\/code>entity()<\/code> returns the private result<\/code> type, and then immediately assigns it to a variable of type widget<\/code>. This triggers the operator widget()<\/code> conversion operator, which calls get_<\/code>entity_<\/code>as_<\/code>widget<\/code>.<\/p>\n
Similarly, the second call obtains the private result<\/code> type and converts it to a doodad<\/code>, which winds up calling get_<\/code>entity_<\/code>as_<\/code>doodad<\/code>.<\/p>\n
The wave function collapse could be triggered by anything that accepts a conversion.<\/p>\n
move_widget(exp.get_entity()); \/\/ will call get_entity_as_widget\r\nsignal_doodad(exp.get_entity()); \/\/ will call get_entity_as_doodad\r\n<\/pre>\n
If you take the return value of get_<\/code>entity<\/code> and save it in an auto<\/code>, then the wave function hasn’t collapsed yet. It’s still not sure which thing it is.<\/p>\n
auto entity = exp.get_entity();\r\n<\/pre>\n
The thing doesn’t become a widget or doodad until you convert it.<\/p>\n
move_widget(entity); \/\/ calls get_entity_as_widget\r\n<\/pre>\n
Note that the call to get_<\/code>entity_<\/code>as_<\/code>widget<\/code> is delayed until the conversion occurs.<\/p>\n
auto entity = exp.get_entity();\r\nexp.replace_entity();\r\nmove_widget(entity); \/\/ calls get_entity_as_widget\r\n<\/pre>\n
Between calling get_<\/code>entity<\/code> and converting the result to a widget, we changed the entity in the experiment. Not until the conversion occurs does the call to get_<\/code>entity_<\/code>as_<\/code>widget<\/code> happen, at which point it will get the new entity rather than the original one. And of course, if you destroy the experiment, then the unresolved entity<\/code> has a dangling pointer, and the behavior is undefined.<\/p>\n
This trick works best if the caller will convert the result immediately<\/i> to its final type (widget or doodad).<\/p>\n
Of course, you could try to fix these problems, say by taking a strong reference to the experiment<\/code> to prevent it from being destructed prematurely. Or you could call both get_<\/code>entity_<\/code>as_<\/code>widget<\/code> and get_<\/code>entity_<\/code>as_<\/code>doodad<\/code> as part of the constructor, and then hand out the appropriate type during the conversion. That would fix the “delayed evaluation” problem, but at a cost of doing eager evaluation of both branches, even if only one will end up being used.<\/p>\n
In the case where Kenny used it, it was to  permit the First<\/code> method to return a different iterator<\/a> depending on who’s asking for it. The underlying problem is the object wants to be able to produce a stream of T<\/code> objects or IInspectable<\/code> objects, so it implements both the IIterable<T>::First()<\/code> and IIterable<IInspectable>::First()<\/code> methods. The projection for those interfaces forward to the implementation’s First()<\/code>, which forces First()<\/code> to serve two masters. And the way he solved it was to return an ambiguous object, so that each master sees what it wants.<\/p>\n","protected":false},"excerpt":{"rendered":"
Quantum superposition comes to C++.<\/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-103066","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Quantum superposition comes to C++.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/103066","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=103066"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/103066\/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=103066"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=103066"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=103066"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}