User: Password:
|
|
Subscribe / Log in / New account

MSVC

MSVC

Posted Mar 11, 2013 14:08 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: MSVC by jwakely
Parent article: Michaelsen: One

Claim one was made by other author, yes.

std::mutex has a constexpr constructor (added to maintain compatibility with POSIX), but recursive and timed mutexes don't (check it). MSVC choose to ignore it completely because it's not practical to implement mutexes this way on Windows.

This requirement was just a codification of existing practice where POSIX mutexes can be statically initialized. And yet again, I repeat that constexprs can't solve the problems with initialization order. If your code works with constexprs then it works on MSVC.


(Log in to post comments)

MSVC

Posted Mar 12, 2013 11:52 UTC (Tue) by jwakely (guest, #60262) [Link]

I don't need to check it, thanks, I didn't ever claim the other mutex types have constexpr constructors.

Things don't get added to the C++ standard for POSIX compatibility if they don't work on other platforms, MS have representatives on the committee so they don't need to "choose to ignore" requirements in the standard, they can prevent them being standardised in the first place. That's how the process is supposed to work, a "top-notch compiler" team doesn't keep quiet then be forced to ship a non-conforming implementation. Having a constexpr constructor is by design, not a compatibility feature, remember that when MSVC eventually fix their std::mutex.

https://connect.microsoft.com/VisualStudio/feedback/detai...

MSVC

Posted Mar 12, 2013 14:40 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> Things don't get added to the C++ standard for POSIX compatibility if they don't work on other platforms, MS have representatives on the committee so they don't need to "choose to ignore" requirements in the standard, they can prevent them being standardised in the first place.
The standard committee can choose to ignore Microsoft's objections (that happens, really).

>Having a constexpr constructor is by design, not a compatibility feature, remember that when MSVC eventually fix their std::mutex.
No they haven't (yet). Empty std::mutex in MSVC 11 is NOT a constexpr since it uses an extern function in its constructor.

Windows synchronization primitives require initialization, so if you want to do a constexpr then you have to use a spinlock to protect a delayed initialization of the real synchronization primitive. Possible, but ugh.

BTW, your very link tells us that the next MSVC version supports constexprs.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds