{"id":111134,"date":"2025-05-01T07:00:00","date_gmt":"2025-05-01T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=111134"},"modified":"2025-05-01T09:33:54","modified_gmt":"2025-05-01T16:33:54","slug":"20250501-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20250501-00\/?p=111134","title":{"rendered":"Using C++ type aliasing to avoid the ODR problem with conditional compilation, part 1"},"content":{"rendered":"

Some time ago, I discussed the C++ concept of ill-formed no diagnostic required<\/i> (IFNDR)<\/a>. A common accidental source of this is violating the One Definition Rule<\/i> (ODR) by defining a class or function differently based on compile-time switches.<\/p>\n

\/\/ widget.h\r\n\r\nstruct Widget\r\n{\r\n    Widget();\r\n\r\n    void SetName(std::string const& name);\r\n\r\n    \u27e6 more stuff \u27e7\r\n\r\n#ifdef EXTRA_WIDGET_DEBUGGING\r\n    Logger m_logger;\r\n\r\n    void Log(std::string const& message) {\r\n        m_logger.log(message);\r\n    }\r\n#else\r\n    void Log(std::string const& message) {\r\n        \/\/ no extra logging\r\n    }\r\n#endif\r\n\r\n    std::string m_name;\r\n};\r\n<\/pre>\n
If one .cpp file is compiled with extra widget debugging enabled, but another is compiled with extra widget debugging disabled, and they are linked together, then you have a One Definition Rule violation because the Widget<\/code> structure and the Widget::Log<\/code> method have conflicting definitions.<\/p>\n
But all is not lost.<\/p>\n
Type aliases are not subject to the One Definition Rule!<\/p>\n
It’s okay to have a type alias with different definitions in different translation units because a type alias is just a a way to introduce an alternate name for an existing type; it does not introduce a new type.<\/p>\n
\/\/ widget.h\r\n\r\ntemplate<bool debug>\r\nstruct WidgetT\r\n{\r\n    WidgetT();\r\n\r\n    \u27e6 more stuff \u27e7\r\n\r\n    [[msvc::no_unique_address<\/a>]]\r\n    [[no_unique_address]]\r\n    std::conditional_t<debug, Logger, std::monostate<\/a>> m_logger;\r\n\r\n    void Log(std::string const& message) {\r\n        if constexpr (debug) {\r\n            m_logger.log(message);\r\n        }\r\n    }\r\n\r\n    std::string m_name;\r\n};\r\n\r\nextern template struct WidgetT<false>;\r\nextern template struct WidgetT<true>;\r\n\r\n#ifdef EXTRA_WIDGET_DEBUGGING\r\nusing Widget = WidgetT<true>;\r\n#else\r\nusing Widget = WidgetT<false>;\r\n#endif\r\n\r\n\/\/ widget.cpp\r\n#include \"widget.h\"\r\n\r\ntemplate<bool debug><\/span>\r\nvoid Widget<debug><\/span>::Widget()\r\n{\r\n    \u27e6 constructor stuff \u27e7\r\n}\r\n\r\ntemplate<bool debug><\/span>\r\nvoid Widget<debug><\/span>::SetName(std::string const& name)\r\n{\r\n    m_name = name;\r\n    Log(\"Name changed\");\r\n    Log(name);\r\n}\r\n\r\ntemplate struct WidgetT<false>;<\/span>\r\ntemplate struct WidgetT<true>; <\/span>\r\n<\/pre>\n
There are two versions of WidgetT<\/code>. The WidgetT<true><\/code> is the debugging version, and the WidgetT<false><\/code> is the non-debugging version. In the debugging version, there is a Logger<\/code> member object, and in the non-debugging version, we have a std::monostate<\/code>, which is a dummy object that does nothing. We also mark the object as no_unique_address<\/code> to tell the compiler that it’s okay to collapse the empty object to nothing, so that it disappears entirely when not debugging.\u00b9<\/p>\n
All of the methods are implemented as templates, which is a bit annoying, but it’s just a bunch of boilerplate repetition for each method you want to implement.<\/p>\n
Since the implementations are not in the header file, we have to instantiate the templates explicitly to trigger the code generation. There are two versions of the template, and we instantiate them both.<\/p>\n
Meanwhile, when clients use the widget.h<\/tt> header file, they can pick what they want the name Widget<\/code> to refer to. For example, if they have debugging enabled, then it is an alias for WidgetT<true><\/code>, so when they create a Widget<\/code>, they are creating a WidgetT<true><\/code>, and when they call a method on it, they are calling a method of WidgetT<true><\/code>, and when they pass it to another function, they are passing a WidgetT<true><\/code>.<\/p>\n
Meanwhile, another client has debugging disabled, then all of its operations on a Widget<\/code> are really happening with a WidgetT<true><\/code>. Even though each client uses the name Widget<\/code> to refer to a different thing, there is no conflict here because the compiler cares about the actual type, not any nickname you may have given it.<\/p>\n
\/\/ client1.h\r\n\r\n#include <widget.h>\r\n\r\nvoid Client1DoSomething(Widget const& widget);\r\n<\/pre>\n
If Client1 is compiled with debugging enabled, its client1.cpp<\/tt> will implement void Client1DoSomething(Widget<true> const& widget)<\/code>. But if Client2 is compiled with debugging disabled, its client2.cpp<\/tt> will try to call void Client1DoSomething(Widget<false> const& widget)<\/code>. Since there is no definition for that function, you get a linker error.<\/p>\n
If the two clients (which disagree on what Widget<\/code> refers to) try to talk to each other through a Widget<\/code>, you will get a linker error because one side is trying to call a function that takes a WidgetT<true><\/code>, but the other side implemented a function that takes a WidgetT<false><\/code>.<\/p>\n
There is a tricky bit if one or the other client exposes a class that uses a Widget<\/code>.<\/p>\n
\/\/ client1.h\r\n\r\n#include <widget.h>\r\n\r\nstruct Client1\r\n{\r\n    Widget m_widget;\r\n};\r\n<\/pre>\n
Then Client1 (with debugging enabled) thinks that the Client1<\/code> structure uses a Widget<true><\/code>, but Client2 (with debugging disabled) thinks that the the Client1<\/code> structure uses a Widget<false><\/code>. This is an ODR violation, and depending on how unlucky you are, it may go undetected.<\/p>\n
Similarly, there is an ODR violation with the global function if the presence of the Widget<\/code> is in something that doesn’t participate in overload resolution, like a return value.<\/p>\n
\/\/ client1.h\r\n\r\n#include <widget.h>\r\n\r\nWidget Client1MakeWidget();\r\n<\/pre>\n
Okay, so I got stuck.<\/p>\n
But I think can still save this. We’ll do that next time.<\/p>\n
Bonus reading<\/b>:  What is __wchar_t<\/code> (with the leading double underscores) and why am I getting errors about it<\/a>? uses a similar technique to deal with multiple possible definitions of wchar_t<\/code>.<\/p>\n
\u00b9 The no_unique_address<\/code> attribute also tells the compiler that if there is any trail padding in the Logger<\/code> object, it is allowed to put other WidgetT<\/code> members inside the trail padding.<\/p>\n","protected":false},"excerpt":{"rendered":"
Still one definition, but two types.<\/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-111134","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Still one definition, but two types.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111134","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=111134"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111134\/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=111134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=111134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=111134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}