> On Mon, Feb 03, 2020 at 11:53:57PM +0000, Scott Bloom wrote: > > From: Development [mailto:[email protected]] On > > Behalf Of André Pönitz > > [...] > > An actual "need" for a unique pointer is typically a sign that > > things are created, passed around until they end up somwhere, for > > a long time so that people get unsure about ownership or have > > developed an irrational fear of naked pointers. Fixed by not > > having the 'factory' create the object and pass the object > > around, but by passing the factory around (by 'reference') and > > letting the receiver create the object. Additional advantage: > > creation can take input both from the factory setup (say, lambda > > capture) and the receiver side, saving potentially a lot of > > state. And it's of course fine to use unique pointers if that's > > not the reason. E.g. to delete dynamic stuff in case of early > > returns. I.e. a kind of, surprise, "scoped" pointer. > > > > That people coming from Java exhibit a high affinity to shared > > pointers is not exactly news in this millenium. A bit more > > amusing is that some proponents of "modern" C++ demand using > > unique pointers, when actually more direct, less boiler-plate > > requiring tools (lambdas...) were standardized at the same time. > > To be fair, while I 100% agree with the reasons given, you are not > listing one of the (only???) reasons, that a smart pointer shared > or unique, are truly > necessary. > > When you are working with the possibility that the lifetime of > the pointer, might not be exception safe.
Sorry for not being explicit, I meant this case to be covered by "And it's of course fine to use unique pointer [...] in case of early returns." So, sure, that's a valid use case. But effectively this also uses only the "scoped" feature of unique_ptr to ensure proper destruction, not the feature to pass ownership around. Andre' _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
