From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-06-28 09:41:58
pt., 28 cze 2019 o 10:59 JeanHeyd Meneide via Boost <boost_at_[hidden]>
> 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
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()`?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk