-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xlock.cpp: Should _Lock_at_thread_exit_mutex() be noexcept? #273
Comments
No, they should be deleted :) |
For vNext, or can that be done in v19? |
If they aren't exported should be doable in v19. |
What would deletion involve? (i.e. what additional code would be necessary to replace this mechanism?) |
Would probably hook it into the existing locale lock system. Even just moving this stuff into the one .cpp where it's currently used would be an improvement. |
#4106 actually made them |
_Lock_at_thread_exit_mutex()
and_Unlock_at_thread_exit_mutex()
are separately compiled, but aren't used outside the STL's DLL (or static LIB):STL/stl/src/xlock.cpp
Lines 123 to 129 in f9b1dcc
STL/stl/src/xnotify.cpp
Lines 31 to 34 in f9b1dcc
Since they aren't exported, I believe that it would be safe (i.e. binary-compatible) to mark them as
noexcept
, and give them C++ linkage.It's also possible that there's no point in doing so; because they're
extern "C"
and we compile with/EHsc
, they should already be treated asnoexcept
.The text was updated successfully, but these errors were encountered: