{"id":107532,"date":"2022-12-02T07:00:00","date_gmt":"2022-12-02T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107532"},"modified":"2022-12-02T07:36:15","modified_gmt":"2022-12-02T15:36:15","slug":"20221202-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20221202-00\/?p=107532","title":{"rendered":"C++ template parlor tricks: Using a type before it is defined"},"content":{"rendered":"

C++ templates are instantiated only on demand, which means that they provide you a way of talking about things before knowing what they are.<\/p>\n

template<typename T>\r\nauto get_foo(T&& t)\r\n{\r\n    return t.foo;\r\n}\r\n<\/pre>\n
This template function takes any object and returns its foo<\/code> member. It has no idea what type T<\/code> it’s going to be given, but by golly it’s going to return the foo<\/code> member.<\/p>\n
Sometimes, though, you may know what type you have, but you don’t have the power to say its name.<\/p>\n
\/\/ contoso.h\r\n\r\nnamespace Contoso\r\n{\r\n    struct Point\r\n    {\r\n        int X;\r\n        int Y;\r\n    };\r\n}\r\n\r\n\/\/ litware.h\r\n\r\nnamespace LitWare\r\n{\r\n    struct Point\r\n    {\r\n        int X;\r\n        int Y;\r\n\r\n        constexpr Point() : X(0), Y(0) {}\r\n        constexpr Point(int x, int y) : X(x), Y(y) {}\r\n\r\n        \/\/ To ease interop with Contoso.\r\n        constexpr Point(Contoso::Point const& cpt) : X(cpt.X), Y(cpt.Y) {}\r\n    };\r\n}\r\n<\/pre>\n
The idea here is that LitWare knows that a lot of its customers use the Contoso library, so it adds a conversion from Contoso::Point<\/code> to for LitWare::Point<\/code> to improve interop.<\/p>\n
This works great, as long as the customer is actually using the Contoso library and has perform a #include <contoso.h><\/code>.<\/p>\n
But the litware.h<\/code> header may choose to be “Contoso-agnostic”: It doesn’t want to include contoso.h<\/code> explicitly because the consuming application may not have the Contoso SDK installed, or maybe the consuming application declined to include the contoso.h<\/code> header because it comes with other side effects like additional dependencies.<\/p>\n
We can use a template here, taking advantage of the fact that dependent expressions in templates are not compiled until the template is instantiated.<\/p>\n
        template<typename T>\r\n        Point(T const& cpt) : X(cpt.X), Y(cpt.Y) {}\r\n<\/pre>\n
This constructor accepts any object which has fields called X<\/code> and Y<\/code> which can be used to initialize an int<\/code>. We have a Contoso::Point<\/code> in mind, but really, anything that meets the criteria will work.<\/p>\n
Since this is defined as a template, the dependent expressions cpt.X<\/code> and cpt.Y<\/code> are not resolved until somebody actually tries to use that template.<\/p>\n
void test(Contoso::Point& cpt)\r\n{\r\n    LitWare::Point lpt(cpt);\r\n}\r\n<\/pre>\n
This invokes the constructor with a Contoso::Point<\/code>, so T<\/code> becomes Contoso::Point<\/code>, and the X<\/code> and Y<\/code> members of the LitWare::Point<\/code> are initialized with the corresponding members of the Contoso::Point<\/code>.<\/p>\n
Unfortunately, we also get confusing error messages when the thing that gets passed in doesn’t satisfy these criteria:<\/p>\n
void test(std::mutex& oops)\r\n{\r\n    \/\/ clang error: no member named 'X' in 'std::mutex'\r\n    \/\/ gcc error: 'const class std::mutex' has no member named 'X'\r\n    \/\/ msvc error: 'X' is not a member of 'std::mutex'\r\n    LitWare::Point lpt(oops);\r\n}\r\n<\/pre>\n
We were hoping for an error message like “Cannot convert std::mutex<\/code> to Contoso::Point<\/code>.”<\/p>\n
Another thing that doesn’t work is constructing a LitWare::Point<\/code> from an object that is convertible to<\/i> a Contoso::Point<\/code>:<\/p>\n
struct ProtoPoint\r\n{\r\n    operator Contoso::Point const&() const;\r\n};\r\n\r\nvoid test(ProtoPoint& ppt)\r\n{\r\n    \/\/ clang error: no member named 'X' in 'ProtoPoint'\r\n    \/\/ gcc error: 'const class ProtoPoint' has no member named 'X'\r\n    \/\/ msvc error: 'X' is not a member of 'ProtoPoint'\r\n    LitWare::Point lpt(ppt);\r\n\r\n    \/\/ must convert explicitly\r\n    LitWare::Point lpt(static_cast<Contoso::Point const&>(ppt));\r\n}\r\n<\/pre>\n
We can sort of work around this with SFINAE and a forward declaration.<\/p>\n
namespace Contoso\r\n{\r\n    struct Point;\r\n}<\/span>\r\n\r\nnamespace LitWare\r\n{\r\n    struct Point\r\n    {\r\n        ...\r\n\r\n        template<typename T, typename = std::enable_if_t<\r\n            std::is_convertible_v<std::decay_t<T>, Contoso::Point>><\/span>>\r\n            constexpr Point(T const& cpt) ...\r\n    };\r\n}\r\n<\/pre>\n
but what do we write as the body of the constructor? We want to convert T<\/code> to Contoso::Point<\/code>, but do it only once. This means writing a helper.<\/p>\n
    template<typename T, typename = std::enable_if_t<\r\n        std::is_convertible_v<std::decay_t<T>, Contoso::Point>>>\r\n        constexpr Point(T const& cpt)\r\n        noexcept(noexcept(static_cast<Contoso::Point const&>(cpt))) :\r\n            Point(convert(static_cast<Contoso::Point const&>(cpt))) {}\r\n\r\nprivate:\r\n    static constexpr Point convert(Contoso::Point const& cpt) noexcept\r\n    {\r\n        return { cpt.X, cpt.Y };\r\n    }\r\n<\/pre>\n
Note the use of the  noexcept noexcept<\/code> idiom<\/a> in the constructor to deal with the possibility that the conversion from T<\/code> to Contoso::Point<\/code> may throw.<\/p>\n
But now we’re back where we started: We need a definition for Contoso::Point<\/code> in order to write convert()<\/code>.<\/p>\n
To escape this trap, we use two tricks. The first is to reintroduce the dependent type trick:<\/p>\n
    template<typename T>\r\n    static constexpr Point convert(T const& cpt) noexcept\r\n    {\r\n        return { cpt.X, cpt.Y };\r\n    }\r\n<\/pre>\n
Now, the convert()<\/code> function takes anything at all, but in practice, the only thing it is passed is a Contoso::<\/code>Point<\/code>. It’s a C++ version of the  Most Interesting Man in the World<\/a> meme.<\/p>\n
<\/p>\n
Our revised constructor is awfully wordy and still has problems.<\/p>\n
For one thing, we might be adding a potentially-throwing constructor, whereas the original version consisted exclusively of non-throwing constructors. This may have ripple effects such as making the LitWare::Point<\/code> ineligible for certain optimizations, or making it unusable by certain algorithms or data structures.<\/p>\n
Another problem is that it changes the relative priority of the overload with respect to other overloads, since its specificity is lower than a simple conversion directly from Contoso::Point<\/code>. This could result in conflicts with other constructors of LitWare::Point<\/code>. For example, if you also want to support a Fabrikam::<\/code>Point<\/code> (which uses lowercase letters for the X- and Y-coordinates), you’ll get a template redeclaration error.<\/p>\n
    template<typename T, typename = std::enable_if_t<\r\n        std::is_convertible_v<std::decay_t<T>, Contoso::Point>>>\r\n        constexpr Point(T const& cpt)\r\n        noexcept(noexcept(static_cast<Contoso::Point const&>(cpt))) :\r\n            Point(convert(static_cast<Contoso::Point const&>(cpt))) {}\r\n\r\n    \/\/ error: 'template<class T, class> Test::Test(const T&)' cannot be overloaded with\r\n    \/\/        'template<class T, class> Test::Test(const T&)'\r\n    template<typename T, typename = std::enable_if_t<\r\n        std::is_convertible_v<std::decay_t<T>, Fabrikam::Point>>>\r\n        constexpr Point(T const& cpt)\r\n        noexcept(noexcept(static_cast<Fabrikam::Point const&>(cpt))) :\r\n            Point(convert_fabrikam(static_cast<Fabrikam::Point const&>(cpt))) {}\r\n\r\nprivate:\r\n    static constexpr Point convert(Contoso::Point const& cpt) noexcept\r\n    {\r\n        return { cpt.X, cpt.Y };\r\n    }\r\n\r\n    static constexpr Point convert_fabrikam(Fabrikam::Point const& cpt) noexcept\r\n    {\r\n        return { cpt.x, cpt.y };\r\n    }\r\n<\/pre>\n
Also, we generate a separate templated constructor for each argument type that is convertible to Contoso::Point<\/code>, so you do have some template expansion bloat.<\/p>\n
The error is also a little cumbersome if you pass something that isn’t convertible to Contoso::Point<\/code>:<\/p>\n
std::string oops;\r\nLitWare::Point pt(oops);\r\n\r\n\/\/ clang\r\nno matching constructor for initialization of 'LitWare::Point'\r\n\r\ncandidate template ignored: requirement 'std::is_convertible_<std::string, Contoso::Point>' was not satisfied\r\n\r\n    constexpr Point(T const& cpt) : Point(convert(static_cast<Contoso::Point const&>(cpt))) {}\r\n\r\n\/\/ gcc\r\n\r\nno matching function for call to 'LitWare::Point::Point(std::string&)'\r\n\r\n    LitWare::Point pt(oops);\r\n\r\ncandidate 'template<class T, class> constexpr LitWare::Point::Point(const T&)'\r\n\r\n    constexpr Point(T const& cpt) : Point(convert(static_cast<Contoso::Point const&>(cpt))) {}\r\n\r\ntemplate argument deduction\/substitution failed.\r\n\r\n\/\/ msvc\r\nerror: 'LitWare::Point::Point': none of the 4 overloads could convert all the argument types\r\n\r\ncould be 'LitWare::Point::Point(LitWare::Point &&)'\r\nor       'LitWare::Point::Point(const LitWare::Point &)'\r\nor       'LitWare::Point::Point(int, int) noexcept'\r\nor       'LitWare::Point::Point(void) noexcept'\r\n\r\nwhile trying to match the argument list '(std::string)'\r\n<\/pre>\n
The Microsoft Visual C++ compiler doesn’t even list the SFINAE’d away constructor, the one that the caller was trying to invoke, but couldn’t because it failed the enable_if<\/code>.<\/p>\n
And finally, another point against this pattern is simply that it’s a hot mess.\u00b9<\/p>\n
Fortunately, there’s a simpler solution.<\/p>\n
Just declare the constructor as taking a Contoso::Point<\/code>, but add a dummy template parameter to force delayed instantiation.<\/p>\n
namespace LitWare\r\n{\r\n    struct Point\r\n    {\r\n        int X;\r\n        int Y;\r\n\r\n        constexpr Point() : X(0), Y(0) {}\r\n        constexpr Point(int x, int y) : X(x), Y(y) {}\r\n\r\n        \/\/ To ease interop with Contoso.\r\n        template<bool dummy = true>\r\n        constexpr Point(Contoso::Point const& cpt) noexcept\r\n            : Point(convert<dummy>(cpt)) {}\r\n\r\n    private:\r\n        template<bool dummy, typename T>\r\n        static constexpr Point convert(T&& cpt) noexcept\r\n        { return { cpt.X, cpt.Y }; }\r\n    };\r\n}\r\n<\/pre>\n
With this version, there is only one templated constructor that will be instantiated in practice, namely the one where dummy<\/code> is true<\/code>. The conversion to Contoso::Point<\/code> happens at the call site rather than in the constructor, and the constructor remains non-throwing. The explicitly-typed parameter helps the overload sit at the right priority in the overload resolution process, and you can repeat this pattern for other types without running into template redefinition errors.<\/p>\n
This trick works with functions, too.<\/p>\n
template<typename T>\r\nvoid Widget_ToggleHelper(T& widget)\r\n{\r\n    if (widget.IsOn()) {\r\n        widget.TurnOff();\r\n    } else {\r\n        widget.TurnOn();\r\n    }\r\n}\r\n\r\ntemplate<bool = true>\r\nvoid Widget_Toggle(Widget& widget)\r\n{\r\n    Widget_ToggleHelper(widget);\r\n}\r\n<\/pre>\n
Since lambdas with auto<\/code> parameters are templates, you can move the helper function inline and turn it into a lambda, which makes it impossible for a consumer to call the helper directly.<\/p>\n
template<bool = true>\r\nvoid Widget_Toggle(Widget& widget)\r\n{\r\n    [](auto& widget)\r\n    {\r\n        if (widget.IsOn()) {\r\n            widget.TurnOff();\r\n        } else {\r\n            widget.TurnOn();\r\n        }\r\n    }(widget);\r\n}\r\n<\/pre>\n
Bonus chatter<\/b>: This trick of using a dummy parameter to delay expansion also comes in handy if you need to break a circular reference between two classes:<\/p>\n
struct TweedleDee\r\n{\r\n    TweedleDee(TweedleDum const& dum)\r\n    : value(dum.value) {}\r\n\r\n    int value;\r\n};\r\n\r\nstruct TweedleDum\r\n{\r\n    TweedleDum(TweedleDee const& dee)\r\n    : value(dee.value) {}\r\n\r\n    int value;\r\n};\r\n<\/pre>\n
Each of the classes is constructible from the other, but the constructor bodies each require that the other party be a complete type, putting them in a Catch-22 situation. You can break the cycle by introducing a dummy template parameter and a forward declaration:<\/p>\n
struct TweedleDum;\r\n\r\nstruct TweedleDee\r\n{\r\n    template<bool dummy = true>\r\n    TweedleDee(TweedleDum const& dum)\r\n    : value(get_value_of<dummy>(dum)) {}\r\n\r\n    template<typename T, bool>\r\n    int get_value_of(T&& dum) { return dum.value; }\r\n\r\n    int value;\r\n};\r\n\r\nstruct TweedleDum\r\n{\r\n    TweedleDum(TweedleDee const& dee)\r\n    : value(dee.value) {}\r\n\r\n    int value;\r\n};\r\n<\/pre>\n
or with the lambda trick:<\/p>\n
struct TweedleDee\r\n{\r\n    template<bool dummy = true>\r\n    TweedleDee(TweedleDum const& dum)\r\n    : value([](auto&& dum)\r\n            { return dum.value; }(dum)) {}\r\n\r\n    int value;\r\n};\r\n<\/pre>\n
This trick is less useful because you can also solve the problem without needing any tricks: Forward-declare the constructor.<\/p>\n
struct TweedleDum;\r\n\r\nstruct TweedleDee\r\n{\r\n    TweedleDee(TweedleDum const& dum);\r\n\r\n    int value;\r\n};\r\n\r\nstruct TweedleDum\r\n{\r\n    TweedleDum(TweedleDee const& dee)\r\n    : value(dee.value) {}\r\n\r\n    int value;\r\n};\r\n\r\ninline TweedleDee::TweedleDee(TweedleDum const& dum)\r\n    : value(dum.value) {}<\/span>\r\n<\/pre>\n
\u00b9 Another problem is the untyped braced list.<\/p>\n
LitWare::Point({ 1, 2 });\r\n<\/pre>\n
We’ll look at this problem some more later. But this is not really much of an issue in the LitWare::Point<\/code> case, because you could just use the two-parameter constructor.<\/p>\n
LitWare::Point(1, 2);\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
You can talk about hypothetical things, hoping that a real thing shows up later.<\/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-107532","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
You can talk about hypothetical things, hoping that a real thing shows up later.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107532","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=107532"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107532\/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=107532"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107532"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107532"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}