This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
2046.shared_future(future<R>&&) should be allowed to throw
Section: 32.10.8 [futures.shared.future] Status: NAD Submitter: Peter Sommerlad Opened: 2011-04-04 Last modified: 2021-06-06
Priority: Not Prioritized
View all other issues in [futures.shared.future].
View all issues with NAD status.
Discussion:
Requiring the constructor shared_future(future<R>&& rhs) not to throw is a pessimisation of the case where a future is returned from a call to async(function,launch::deferred) and possible other cases.
shared_future from that future will require more infrastructure, like space for the value of type R, an exception_ptr, and a synchronized reference counter for the shared_future's instances. Enforcing the constructor shared_future(future<R>&& rhs) not to throw, implies that any implementation of future will need to pre-allocate space for shared_future's infrastructure, that also requires an operating system resource for synchronization, regardless if is ever needed. All this came up when discussing D/N3267 and Concurrency Working Group decided that the constructor shared_future(future<R>&& rhs) should be allowed to throw.
[ 2011 Bloomington ]
Closed as NAD. Rationale to follow by email...
Proposed resolution:
Apply the proposed resolution of n3269
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4