You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
unique_resource proposal fills a sore gap in the C++ automatic resource management. I am using an incarnation of it in my projects and recently I noticed the following usability issue when going through the factory functions. Say, one defines a managed resource at some scope as:
using T = unique_resource< int, std::function< void(int) > >;
followed by an instantiation, e.g.:
T t = make_unique_resource_checked (0, 0, (void(*)(int))0);
In the current specification the conversion is prohibited as the deduced type does not match T. This makes for some awkward gymnastics where one is forced to explicitly give the template arguments to the factory function but it could be avoided by a template move assign operator and move constructor (I'll add one shortly in the implementation I use). I am not sure if that fits the original purpose of the design or is generally desirable but I was wondering if this ever came up in the discussions you had during your meetings.
The text was updated successfully, but these errors were encountered:
ghost
changed the title
Conversion from different instantiation.
Conversion from different instantiation of unique_resource.
Oct 29, 2018
unique_resource
proposal fills a sore gap in the C++ automatic resource management. I am using an incarnation of it in my projects and recently I noticed the following usability issue when going through the factory functions. Say, one defines a managed resource at some scope as:using T = unique_resource< int, std::function< void(int) > >;
followed by an instantiation, e.g.:
T t = make_unique_resource_checked (0, 0, (void(*)(int))0);
In the current specification the conversion is prohibited as the deduced type does not match
T
. This makes for some awkward gymnastics where one is forced to explicitly give the template arguments to the factory function but it could be avoided by a template move assign operator and move constructor (I'll add one shortly in the implementation I use). I am not sure if that fits the original purpose of the design or is generally desirable but I was wondering if this ever came up in the discussions you had during your meetings.The text was updated successfully, but these errors were encountered: