{"id":110637,"date":"2024-12-13T07:00:00","date_gmt":"2024-12-13T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110637"},"modified":"2024-12-13T13:04:30","modified_gmt":"2024-12-13T21:04:30","slug":"20241213-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20241213-00\/?p=110637","title":{"rendered":"Converting to a derived class from the future: How to cast from a base class to an incomplete derived class?"},"content":{"rendered":"

A customer had a header-only design in which the clients of the header are expected to derive from the base class with a specific class name. Sort of like CRTP<\/a> without the CR. Or the even the T.<\/p>\n

\/\/ awesome.h\r\n\r\n\/\/ Client is expected to define this class\r\n\/\/ as a derived class of AwesomeAppBase.\r\nstruct AwesomeApp;\r\n\r\nstruct AwesomeAppBase\r\n{\r\n    AwesomeApp* derived()\r\n    { return static_cast<AwesomeApp*>(this); }\r\n\r\n    \/\/ AwesomeApp may override this method to provide\r\n    \/\/ custom preparation work.\r\n    void PrepareForSomething() {}\r\n\r\n    void DoSomething()\r\n    {\r\n        derived()->PrepareForSomething();\r\n        \u27e6 .. do something ... \u27e7\r\n    }\r\n};\r\n<\/pre>\n
This doesn’t work because Awesome\u00adApp<\/code> is an incomplete type, so the static_cast<AwesomeApp*>(this)<\/code> doesn’t know how to convert from an Awesome\u00adApp\u00adBase<\/code> to an Awesome\u00adApp<\/code>.<\/p>\n
Normally, you would fix this problem by deferring the definition of the methods like derived()<\/code> and Do\u00adSomething()<\/code> to a point after Awesome\u00adApp<\/code> has been defined, but this is a header-only library, so there’s no chance to provide code later. The header is your only chance.<\/p>\n
We can use a trick we saw earlier:  Using a type before it is defined<\/a>. In this case, we templatize the methods that depend on the definition of Awesome\u00adApp<\/code> by giving them a template type parameter whose default is the incomplete type.<\/p>\n
struct AwesomeAppBase\r\n{\r\n    template<typename T = AwesomeApp><\/span>\r\n    AwesomeApp* derived()\r\n    { return static_cast<T<\/span>*>(this); }\r\n\r\n    \/\/ AwesomeApp may override this method to provide\r\n    \/\/ custom preparation work.\r\n    void PrepareForSomething() {}\r\n\r\n    template<typename T = AwesomeApp><\/span>\r\n    void DoSomething()\r\n    {\r\n        derived<T><\/span>()->PrepareForSomething();\r\n        \u27e6 .. do something ... \u27e7\r\n    }\r\n};\r\n<\/pre>\n
It is, however, rather awkward to have to templatize every method that depends on the Awesome\u00adApp<\/code>. You can remove that awkwardness by templatizing the entire class, transforming it into true CRTP, and then making Awesome\u00adApp\u00adBase<\/code> be an alias for the version of the template with Awesome\u00adApp<\/code> as the derived class.<\/p>\n
template<typename T><\/span>\r\nstruct AwesomeAppBaseT\r\n{\r\n    T<\/span>* derived()\r\n    { return static_cast<T*>(this); }\r\n\r\n    \/\/ AwesomeApp may override this method to provide\r\n    \/\/ custom preparation work.\r\n    void PrepareForSomething() {}\r\n\r\n    void DoSomething()\r\n    {\r\n        derived()->PrepareForSomething();\r\n        \u27e6 .. do something ... \u27e7\r\n    }\r\n};\r\n\r\nusing AwesomeAppBase = AwesomeAppBaseT<AwesomeApp>;\r\n<\/pre>\n
You have to be careful to say T<\/code> instead of Awesome\u00adApp<\/code> inside the Awesome\u00adApp\u00adBase\u00adT<\/code> so that you use the dependent type and therefore defer the name lookup until the point the template is instantiated.\u00b9<\/p>\n
To remove the temptation to say Awesome\u00adApp<\/code> prematurely, you can move the forward declaration of Awesome\u00adApp<\/code> to appear after the template. And you can even use Awesome\u00adApp<\/code> as the name of the template type parameter, so the code looks “normal”.<\/p>\n
template<typename AwesomeApp<\/span>>\r\nstruct AwesomeAppBaseT\r\n{\r\n    AwesomeApp<\/span>* derived()\r\n    { return static_cast<AwesomeApp*>(this); }\r\n\r\n    \/\/ AwesomeApp may override this method to provide\r\n    \/\/ custom preparation work.\r\n    void PrepareForSomething() {}\r\n\r\n    void DoSomething()\r\n    {\r\n        derived()->PrepareForSomething();\r\n        \u27e6 .. do something ... \u27e7\r\n    }\r\n};\r\n\r\n\/\/ Client is expected to define this class\r\n\/\/ as a derived class of AwesomeAppBase.\r\nstruct AwesomeApp;\r\n\r\nusing AwesomeAppBase = AwesomeAppBaseT<AwesomeApp>;\r\n<\/pre>\n
If you don’t want anybody to specialize Awesome\u00adApp\u00adBaseT<\/code> with anything other than Awesome\u00adApp<\/code>, you can move it into a details<\/code> namespace. But it seems useful to let people use the full CRTP form, if they want to give their derived class some other name, or if they want to create more than one derived class. (Say, because they want to have a Contoso\u00adAwesome\u00adApp<\/code> and a Fabrikam\u00adAwesome\u00adApp<\/code> and choose between them at runtime based on a command line switch.)<\/p>\n
\u00b9 Note that declaring a type alias does not instantiate the type. According to [temp.inst<\/a>], instantiation occurs “when the specialization is referenced in a context that requires a completely-defined object type or when the completeness of the class type affects the semantics of the program,” neither of which applies here.<\/p>\n","protected":false},"excerpt":{"rendered":"
Deferring the definition until the class is complete.<\/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-110637","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Deferring the definition until the class is complete.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110637","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=110637"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110637\/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=110637"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110637"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110637"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}