constexpr mutex #2309
constexpr mutex #2309
Conversation
|
Apparently the tests fail/hang because of #2311 |
|
Closing, details in the issue #2285 (comment) Edit: reopened, but still looks risky, want to ask if it is ok to have this approach |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Resolves microsoft#2286 Wanted to combine with microsoft#2309, but apparently constexpr mutex will have long way to go if ever succeeds
|
Blocked by DevCom-1570141 |
stl/inc/mutex
Outdated
| _Mutex_base(int _Flags = 0) noexcept { | ||
| #if _HAS_CXX20 | ||
| if (_STD is_constant_evaluated()) { | ||
| ::new (static_cast<void*>(&_Mtx_storage)) _Stl_critical_section_constexpr{}; |
There was a problem hiding this comment.
This new-expression isn't valid in a constant expression since it doesn't select a replaceable global allocation function ([expr.const]/5.19). We could use construct_at, but it will need storage for an actual _Stl_critical_section_constexpr to target - presumably in a union, which will make mutex not standard-layout.
There was a problem hiding this comment.
This new-expression isn't valid in a constant expression since
What if I use custom form of placement new, that would be constexpr?
which (I think) will make
mutexnot standard-layout
Right, we can't do union here.
There was a problem hiding this comment.
Addressed, seem to compile
There was a problem hiding this comment.
This new-expression isn't valid in a constant expression since
What if I use custom form of placement new, that would be constexpr?
Either it wouldn't really allocate storage ("select a replaceable global allocation function") or it wouldn't deallocate the storage within the evaluation of the constant expression (also [expr.const]/5.19).
There was a problem hiding this comment.
Got your point. But what if the non-standard code still compiles?
There was a problem hiding this comment.
Ok, I put construct_at there, but with a static_cast. Is this still a crime?
There was a problem hiding this comment.
That violates [expr.const]/5.15 since it involves "a conversion from type cv void* to a pointer-to-object type".
|
Ok, I give up again. |
Fixes #2285