pt., 28 cze 2019 o 10:59 JeanHeyd Meneide via Boost
Dear Andrzej Krzemienski,
Wrapping all of the used APIs -- and maintaining those wrappers for any long-term, sustained period of time -- is not a feasible task or architectural burden for many developers and their codebases.
Yes, maybe this is where I fail to understand the constraints.
Transforming error returns + initialization sequences is a subject best left to an entirely separate library, possibly using the Reflection TS and (maybe) some form of Herb Sutter's proposed metaclasses idea. Doing that in a generic way in today's C++ without these facilities is incredibly difficult and likely to produce unwieldy boilerplate or a large number of specially hand-crafted functions.
I do not think anyone would like to handle this with a library. Every API is different, and you need manual inspection to understand what it does.
Finally, out_ptr works with far more than just pointers. The specification and implementation has out-of-the-box support for plenty of RAII types, including retain_ptr/intrusive_ptr, unique_resource, my own handle type (as shown in the example code), and more. In the San Diego C++ meeting LEWG was very pointed in asking whether this works for just pointers or a large class of types: the design very deliberately works with most pointer types. (Comparisons to nullptr are part of that deal, but nothing requires nullptr initialization: the specification specifically uses "it's value initalization" when it needs to create an empty Pointer object.)
If I am passing my smart pointer by reference to out_otr(), I do not see why you would need to assign a value-initialized value to it. Maybe what would be helpful is a concept that specifies the requirements on parameter `Smart` so that we would figure out easily what can and what cannot be passed to `out_ptr()`? Regards, &rzej;
Sincerely, JeanHeyd
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost