{"id":106516,"date":"2022-04-22T07:00:00","date_gmt":"2022-04-22T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=106516"},"modified":"2022-04-22T06:45:05","modified_gmt":"2022-04-22T13:45:05","slug":"20220422-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220422-00\/?p=106516","title":{"rendered":"Trying to create a factory that remembers the parameters to pass to another method"},"content":{"rendered":"

Continuing from using maker functions to work around limitations of class template argument deduction<\/a>, let’s suppose you want to create a generic factory. This sounds like an arbitrary academic exercise, but this stemmed from a real problem. This has practical use, say, if you have a common object and need to generate various factories that produce preconfigured objects.<\/p>\n

\/\/ Imaginary code that doesn't even compile.\r\n\r\ntemplate<typename T, typename...Args>\r\nstruct generic_factory\r\n{\r\n    template<typename... Actuals>\r\n    generic_factory(Actuals&&... args) : \/* something *\/ { }\r\n\r\n    auto make()\r\n    {\r\n        return std::make_unique<T>(args...);\r\n    }\r\n};\r\n\r\ntemplate<typename T, typename... Args>\r\nauto make_generic_factory(Args&&... args)\r\n{\r\n    return generic_factory<T, std::decay_t<Args>...>\r\n        (std::forward<Args>(args)...);\r\n}\r\n<\/pre>\n
The idea is that you create the generic factory by telling it what type you want to create (T<\/code>) and the arguments to pass to the constructor (args...<\/code>). You can then call the make<\/code> method on the generic factory, and out comes a new T<\/code> object, constructed with exactly those parameters.<\/p>\n
The question is how to convert this sketch into a real class.<\/p>\n
A handy place to store a bunch of values is a tuple, and getting the values out of a tuple to pass them as parameters can be done with std::apply<\/code>: While we’re at it, we’ll move the std::decay<\/code> into the generic_factory<\/code>, to make things a little less awkward.<\/p>\n
\/\/ Compiles but doesn't work.\r\n\r\ntemplate<typename T, typename...Args>\r\nstruct generic_factory\r\n{\r\n    using Tuple = std::tuple<std::decay_t<Args>...>;\r\n    Tuple captured;\r\n\r\n    generic_factory(Args&&... args) :\r\n        captured(std::forward<Args>(args)...) {}\r\n\r\n    auto make()\r\n    {\r\n        return std::apply(std::make_unique<T>, captured);\r\n    }\r\n};\r\n\r\ntemplate<typename T, typename...Args>\r\nauto make_generic_factory(Args&&... args)\r\n{\r\n    return generic_factory<T, Args...>(std::forward<Args>(args)...);\r\n}\r\n<\/pre>\n
Now, it looks like we’re reinventing std::bind<\/code>, and yes, that’s very similar what we’re doing. We don’t have the special rules about std::ref<\/code> and std::cref<\/code> that std::bind<\/code> has, nor do our parameters decay, nor do we support placeholders. But one annoying thing about std::bind<\/code> is that the return type has no name<\/i>, so it’s hard to store it in a variable for later use. (I guess what you usually do is immediately put it inside a std::function<\/code>, but that comes with its own issues.)<\/p>\n
And it turns out that std::bind<\/code> has the same problem that our make<\/code> does:<\/p>\n
    \/\/ with std::bind\r\n    auto make = std::bind(std::make_unique<T>, args...);\r\n    make();\r\n\r\n    \/\/ with std::apply\r\n    return std::apply(std::make_unique<T>, captured);\r\n<\/pre>\n
Both of these fail with some horrible error message:<\/p>\n
\/\/ std::bind\r\nFailed to specialize function template 'unknown-type std::_Binder<std::_Unforced, std::unique_ptr<T, std::default_delete<T>> (__cdecl &)(void),T>::operator ()(_Unbound &&...) noexcept() const'\r\n\r\n\/\/ std::apply\r\n'std::invoke': no matching overloaded function found\r\nsee reference to function template instantiation 'decltype(auto) std::_Apply_impl<std::unique_ptr<T, std::default_delete<T>> (__cdecl &)(void),std::tuple<Args...>&,0>(std::unique_ptr<T,std::default_delete<T>> (__cdecl &)(void), std::tuple<int> &, std::integer_sequence<size_t, 0>)' being compiled\r\n<\/pre>\n
I find it interesting that calling std::bind<\/code> does compile. However, it produces an object that cannot be used for anything: Trying to invoke the bound call generates the compiler error.<\/p>\n
These calls fail because the first parameter to std::bind<\/code> and std::apply<\/code> is a callable<\/i>. No overloading or template type inference is happening here: In order for those to occur, the expression needs to be cast to a specific type, or there need to be parameters to force a resolution to occur. But std::bind<\/code> and std::apply<\/code> accept their first parameters as an arbitrary type, so there is no coersion to any particular parameter list.<\/p>\n
I mean, you and I know that the parameter is given by the remaining arguments, but that’s only because we understand the semantics of what std::bind<\/code> and std::apply<\/code> are going to do, namely, combine the first parameter with the other parameters to create a function call. But the compiler doesn’t know that. It just sees a bunch of parameters and doesn’t know that they’re going to be combined at some point in the future.<\/p>\n
This means that when we write std::make_unique<T><\/code>, we are specifying the version of make_unique<\/code> that takes no parameters. The parameters to make_unique<\/code> correspond to the second and subsequent template type paramters, for which we passed none.<\/p>\n
Since the compiler doesn’t have enough information to infer the extra parameters, we have to specify them explicitly:<\/p>\n
    \/\/ with std::bind\r\n    auto make = std::bind(std::make_unique<T, Args...<\/span>>, args...);\r\n    make();\r\n\r\n    \/\/ with std::apply\r\n    return std::apply(std::make_unique<T, Args...<\/span>>, captured);\r\n<\/pre>\n
Unfortunately, this still doesn’t work. The confusing error message this time is<\/p>\n
\/\/ std::bind\r\n'operator __surrogate_func': no matching overloaded function found\r\nFailed to specialize function template 'unknown-type std::_Binder<std::_Unforced, std::unique_ptr<T, std::default_delete<T>> (__cdecl &)(void), T>::operator ()(_Unbound &&...) noexcept() const'\r\n\r\n\/\/ std::apply\r\n'std::invoke': no matching overloaded function found\r\nsee reference to function template instantiation 'decltype(auto) std::_Apply_impl<std::unique_ptr<T, std::default_delete<T>>(__cdecl &)(int &&), std::tuple<int>&, 0>(std::unique_ptr<T, std::default_delete<T>> (__cdecl &)(int &&), std::tuple<int>, std::integer_sequence<size_t, 0>)' being compiled\r\n<\/pre>\n
Buried in all that error message is the interesting part:<\/p>\n
(__cdecl &)(int &&)\r\n<\/pre>\n
The specialization of make_unique<\/code> we are calling wants an int&&<\/code>. Why does it want an int&&<\/code>?<\/p>\n
The corresponding parameter is an int&&<\/code> because the declaration of make_unique<\/code> uses a universal reference:<\/p>\n
template<typename T, typename... Args>\r\nunique_ptr<T> make_unique(Args&&... args);\r\n<\/pre>\n
Since we explicitly passed Args = int<\/code>, this makes the parameter list make_unique(int&& args)<\/code>. And that’s why the function wants an int&&<\/code>.<\/p>\n
Okay, so we need to pass an int&&<\/code>. But what does std::apply<\/code> actually pass?<\/p>\n
The std::apply<\/code> function passes std::get<N>(tuple)<\/code> for each parameter. Since the tuple we passed was an lvalue, std::get<N>(tuple)<\/code> returns an lvalue reference to the tuple element.<\/p>\n
And that’s where the error is coming from. The function wants an rvalue reference to int<\/code>, but we’re passing an lvalue reference.<\/p>\n
Before we try to solve this problem, we need to understand what we are trying to do.<\/p>\n
We want to capture the parameters to pass to make_unique<\/code>, and each time someone calls make<\/code>, we want to call make_unique<\/code> again with the same parameters. Therefore, we don’t want to pass rvalue references to our tuple elements: The first call to make_unique<\/code> would be able to steal the resources from our captured parameters, leaving nothing for the the second and subsequent calls.<\/p>\n
Similarly, we don’t want to pass a straight lvalue reference, because that allows the T<\/code> constructor to mutate the parameter, which would mess up the captured parameters for the second and subsequent calls.<\/p>\n
What we really want to pass is a const<\/code> lvalue reference. And we can make this easier to enforce by making our captured<\/code> member variable also const<\/code>.<\/p>\n
template<typename T, typename...Args>\r\nstruct generic_factory\r\n{\r\n    using Tuple = std::tuple<std::decay_t<Args>...>;\r\n    Tuple const<\/span> captured;\r\n\r\n    generic_factory(Args&&... args) :\r\n        captured(std::forward<Args>(args)...) {}\r\n\r\n    auto make()\r\n    {\r\n        return std::apply(std::make_unique<T,\r\n            std::decay_t<Args> const&...<\/span>>, captured);\r\n    }\r\n};\r\n\r\ntemplate<typename T, typename...Args>\r\nauto make_generic_factory(Args&&... args)\r\n{\r\n    return generic_factory<T, Args...>(std::forward<Args>(args)...);\r\n}\r\n<\/pre>\n
A note of caution here: The parameters passed to make_generic_factory<\/code> are captured as-is. If constructing a T<\/code> from them requires a parameter conversion, the conversion is applied at the time the T<\/code> is constructed, not at the time the parameters are captured.<\/p>\n
Here’s an example:<\/p>\n
struct widget\r\n{\r\n    widget(std::string const& name) : m_name(name) { }\r\n    std::string m_name;\r\n};\r\n\r\nauto factory = make_generic_factory<widget>(\"bob\");\r\n<\/pre>\n
The parameter captured by make_generic_factory<\/code> is the string literal, not a std::string<\/code>. Each time you call make<\/code>, the string literal is converted to a std::string<\/code>, which is then passed to the widget<\/code> constructor, and then when the constructor returns, the temporary std::string<\/code> is destructed. If you want to construct the std::string<\/code> only once, you’ll have to capture it as a std::string<\/code>:<\/p>\n
auto factory = make_generic_factory<widget>(\"bob\"s);\r\n<\/pre>\n
This can get scary for some conversion constructors:<\/p>\n
auto make_widget_factory(int id)\r\n{\r\n    char name[80];\r\n    snprintf(name, 80, \"item #%d\", id);\r\n    return make_generic_factory<widget>(name);\r\n}\r\n<\/pre>\n
In this case, the captured parameter is the raw pointer to the stack buffer, which immediately goes out of scope. When you call make()<\/code>, that raw pointer is then passed to make_unique<\/code>, which will try to convert it to a std::string<\/code>, but it’s too late. The raw pointer is dangling.<\/p>\n
Bonus chatter<\/b>: A lambda would also do the trick. The make<\/code> method becomes the operator()<\/code>:<\/p>\n
template<typename T, typename...Args>\r\nauto make_generic_factory(Args&&... args)\r\n{\r\n    return [captured = std::make_tuple(args...)]() {\r\n        return std::apply(std::make_unique<T,\r\n            std::decay_t<Args> const&...>, captured);\r\n    };\r\n}\r\n<\/pre>\n
C++20 adds the ability to capture a parameter pack into a lambda without having to hide it inside a tuple:<\/p>\n
template<typename T, typename...Args>\r\nauto make_generic_factory(Args&&... args)\r\n{\r\n    return [...args = std::forward<Args>(args)]() {\r\n        return std::make_unique<T>(args...);\r\n    };\r\n}\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Lost in a twisty maze of universal references.<\/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-106516","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Lost in a twisty maze of universal references.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106516","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=106516"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106516\/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=106516"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=106516"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=106516"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}