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

MSVC

MSVC

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

> Noone except you is talking about file handles or dynamic allocation in constexpr constructors.
Certain people in this thread do.

Let me quote:
> constexpr is good for compile-time calculations, so the application starts faster;
Which implies that it's possible to do something more complex other than trivial math in constexprs.

> You still don't know what you're talking about. I don't care about user-defined literals but constexpr is very important. Do you consider solving the static initialization order fiasco to be unimportant?
Constexprs don't solve static init order problems _AT_ _ALL_. In particular, constexprs can't work with forward declarations.

> A constexpr constructor can set a global object's member variables, those member variables are state, setting them to one value or another is observable to the rest of the program.
No it cannot. You can _create_ a constexpr member variable, but you can't _mutate_ it within a constexpr (stanza 5.19.2, "— an assignment or a compound assignment").

In fact, constexprs are designed in such way that they make a purely functional language. So they can be evaluated in any order and at any time. You can ALWAYS replace them with static initialization, only you might have to do evaluation manually.


(Log in to post comments)

MSVC

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

I'm not talking about mutation or constexpr member variables. I'm talking about constexpr constructors. As I've said, I don't think you know what they are. You are the poster-child for the Dunning Kruger effect. Instead of rattling off a reply to something I didn't write try some basic reading comprehension.

MSVC

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

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.

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/

MSVC

Posted Mar 11, 2013 15:21 UTC (Mon) by nix (subscriber, #2304) [Link]

I'm reasonably certain that nobody who was talking about constexprs with reference to compile-time calculation could possibly have thought that you could allocate memory or file handles at compile time. That's ridiculous.

MSVC

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

So what kind of calculations you can do in constexprs that could noticeably reduce app startup time? I'm totally at loss here.

Almost all more-or-less complex algorithms require something that is not really possible with constexprs.

MSVC

Posted Mar 11, 2013 16:52 UTC (Mon) by etienne (guest, #25256) [Link]

> So what kind of calculations you can do in constexprs that could noticeably reduce app startup time?

If you have a very long list of parameters with plenty of sub-parameters (kind of 4096 channels with 50+ configuration options and their SNMP descriptors), you can have them pre-organised (with their next/previous fields pre-initialised) if you declare them "static" and not malloced.
Or if you have a long dictionary.

Note that you could try to support malloc/free inside constexprs by having another section in your ELF file (like .data but after .bss), so that the malloc/free functions (either in glibc or your own wrapper) do not start empty but call brk()/sbrk() to increase that new section... should work at least on Linux (excluding LD_PRELOAD of another malloc/free library).

MSVC

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

> If you have a very long list of parameters with plenty of sub-parameters (kind of 4096 channels with 50+ configuration options and their SNMP descriptors), you can have them pre-organised (with their next/previous fields pre-initialised) if you declare them "static" and not malloced.
Not really. You'll be able to initialize the 'prev' pointers. But you can do this just fine with the current static init.

> Or if you have a long dictionary.
Compile-time? I doubt it. Though you probably could with lots of template magic.

>Note that you could try to support malloc/free inside constexprs by having another section in your ELF file (like .data but after .bss), so that the malloc/free functions (either in glibc or your own wrapper) do not start empty but call brk()/sbrk() to increase that new section
No you can't. Standard explicitly forbids any pointer math that might result in addresses outside of _initialized_ static storage.


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