C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Stop gap required for NRVO until Anton's paper is assimilated

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Thu, 18 Jul 2024 00:11:08 +0200
Hi Lenard,   the approach is exception-safe, as with current RVO:   myclass f() {     try {         return std::factory<myclass>([](auto &a){a.i = 4; throw std::exception();});     } catch(...) {         return myclass();     } }   P3357 works (except the constexpr) with current C++.   I would except, it does exactly, what you wrote: - Construct in the return slot - if not successful, destroy, and construct a new object there     P3357 can do the cited widget example with exceptions.     For checking a condition without using exceptions, and potentially returning a different object, the function syntax would have to be slightly extended, if there is a use case for it.   In the possible implementation this would happen in the Derived class. There a member variable would have to be exchanged with a different one in-place. That can be done with an explicit constructor call and in-place new. (And possibly the object storage as correctly aligned and sized char array.)     I am not sure, if you asked out of interest (what happens to the return slot and exceptions), or, if you were interested, how "complete" P3357 would be compared to P2025, or, if you were actually emphasizing that specific usage as common and important.   Let's entertain that use case.   As long as there is a real use case and it is easily expressible in one call, a function for your example would at least need:   Widget // type i, // constructor parameters [] (Widget &w) { return w.some_observer(); } // modification and/or acceptance [] { return Widget(0); } // alternate result   A function could be made with those parameters, perhaps also with some structured syntax. But the aim is definitely not, to create a one-line functional syntax for any possible structured C++ code.     Best, Sebastian      

Received on 2024-07-17 22:11:16