Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@frederick-vs-ja
Copy link
Contributor

@frederick-vs-ja frederick-vs-ja commented Feb 5, 2023

Fixes #3324. Towards #363.

These functions are made noexcept.

Also make some special member functions defaulted.

  • thread::id's default constructor
  • unique_lock's default constructor
  • scoped_lock<>'s default constructor and destructor, also strengthening exception specification
  • timed_mutex, recursive_timed_mutex, and shared_timed_mutex's default constructors, keeping exception specification strengthened (some comments were missing before, although IMO we don't need to add back now)

Comment changes:

  • timed_mutex::try_lock isn't marked noexcept in working draft ([thread.timedmutex.class]). So this PR adds the missing /* strengthened */ comment.

- `condition_variable`'s default constructor and `native_handle`
- `recursive_mutex`'s default constructor
- all `adopt_lock_t` constructors

Also make some special member functions defaulted.
@frederick-vs-ja frederick-vs-ja requested a review from a team as a code owner February 5, 2023 04:58
@CaseyCarter CaseyCarter added the enhancement Something can be improved label Feb 5, 2023
@StephanTLavavej
Copy link
Member

Looks good to me. As before, I believe this is ABI-safe because no copy ctors are being defaulted.

@StephanTLavavej StephanTLavavej self-assigned this Feb 13, 2023
@StephanTLavavej
Copy link
Member

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

@StephanTLavavej StephanTLavavej merged commit ade0d66 into microsoft:main Feb 14, 2023
@StephanTLavavej
Copy link
Member

Thanks for making our threads stronger! 🧵 🦾 😹

@frederick-vs-ja frederick-vs-ja deleted the thread-noexcept branch February 14, 2023 01:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Something can be improved

Projects

None yet

Development

Successfully merging this pull request may close these issues.

<mutex>: Is _Mutex_base::try_lock actually noexcept?

4 participants