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

MSVC

MSVC

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

I think you need a refresher:
http://en.wikipedia.org/wiki/Side_effect_%28computer_scie...

No, constexprs do not have side effects since they don't modify anything outside of their scope. No, constexpr constructors also do not have side effects.

Anyway, my other points still stand:
1) Constexprs are useless for reducing the startup speed.
2) Constexprs do not solve the static init order problem.


(Log in to post comments)

MSVC

Posted Mar 11, 2013 11:46 UTC (Mon) by jwakely (guest, #60262) [Link]

1) I never claimed this, go argue with someone else.
2) Then why do std::mutex, std::atomic and std::once_flag have constexpr constructors? What's that for?

MSVC

Posted Mar 11, 2013 14:08 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

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.

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.

MSVC

Posted Mar 11, 2013 14:23 UTC (Mon) by nye (guest, #51576) [Link]

>1) I never claimed this, go argue with someone else.

But that was a part of the argument that you loudly jumped into before almost immediately throwing insults about.

I think Cyberax must have a great deal of patience to be bothering with you, given your abusive behaviour in this thread.

MSVC

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

I didn't jump into it, the first mention of constexpr was a descendant of my comment: http://lwn.net/Articles/541018/


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