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

MSVC

MSVC

Posted Mar 7, 2013 21:11 UTC (Thu) by jwakely (guest, #60262)
In reply to: MSVC by Cyberax
Parent article: Michaelsen: One

> > There is no problem with instantiation depth, not even any templates involved.
> Standard guarantees only 512 level recursion. Everything else is implementation-specific.

The example I was talking about has *no recursion*, so there is no problem with a limit of 512 levels. Why are you even mentioning it?


(Log in to post comments)

MSVC

Posted Mar 8, 2013 19:49 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Ok. I'll bite.

You CAN'T use constexprs to solve the initialization ordering problem. By definition constexprs can't have any side effects (in fact, allowing side effects is a compiler bug). This means that constexprs can refer to each other and can have any ordering.

So using constexprs to allocate a mutex is right out. The only remaining usages:
1) Precalculating complex mathematics formulae. It's right out - you can't really do anything real-world interesting in 512 level recursion limit.
2) Template mindfskery - instead of using partial template specialization. That cleans up code somewhat, but it still doesn't change the fsked up nature of template metaprogramming.

Basically, that's it.

MSVC

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

You *still* don't know what you're talking about.

> By definition constexprs can't have any side effects (in fact, allowing side effects is a compiler bug).

Citation needed.

I'll start you off with 7.1.5 [dcl.constexpr] which says "The definition of a constexpr constructor shall satisfy the following constraints: [...] every non-variant non-static data member and base class sub-object shall be initialized"

Please show where in the standard it contradicts that or how to initialize non-static data members without side-effects.

> So using constexprs to allocate a mutex is right out

On a grown-up OS mutexes don't need "allocating" so can be constexpr.

If you disagree please file a defect with the C++ standard, file a GCC bug (category "doing impossible things before breakfast") and tell MS to stop working on the fix to not allocate memory in std::mutex because it's an impossible task, so sayeth Cyberax the unknowing.

I don't think you know what a constexpr constructor is or how it works. Stop trying to educate me on C++, you're embarassing yourself.

MSVC

Posted Mar 10, 2013 20:55 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> Please show where in the standard it contradicts that or how to initialize non-static data members without side-effects.
I thought it was obvious to anyone who follows C++ development.

But OK. Stanza 7.1.5.5:
>For a constexpr function, if no function argument values exist such that the function invocation substi- tution would produce a constant expression (5.19), the program is ill-formed; no diagnostic required. For a constexpr constructor, if no argument values exist such that after function invocation substitution, ev- ery constructor call and full-expression in the mem-initializers would be a constant expression (including conversions), the program is ill-formed; no diagnostic required.

Given that a function can only involve operations on literals (or references to them) or other constexpr values we are immediately (7.1.5.3) limited in possibilities to refer to non-constexpr data like file handles, for example (because open/close do not return constexprs).

Can a body of a constexpr function involve side effects? No. See 5.19.1 - it explicitly notes:
>[Note: Constant expressions can be evaluated during translation. — end note ]

Then in the stanza 5.19.2 the Standard lists tons of things that are Verbotten. Included in them:
>- a new-expression (5.3.4);
>- a delete-expression (5.3.5);
And you also can't use malloc since it's not a constexpr. So yes, dynamic allocation is impossible.

Basically, constepxrs can only use other constexprs (in evaluated paths). And the only available constexpr functions are simple mathematical functions that can't produce side-effects.

>On a grown-up OS mutexes don't need "allocating" so can be constexpr.
Then there's no problem with their initialization order. What's the problem that constexprs should be solving?

> I don't think you know what a constexpr constructor is or how it works. Stop trying to educate me on C++, you're embarassing yourself.
Yes, please do.

MSVC

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

Noone except you is talking about file handles or dynamic allocation in constexpr constructors. Of course dynamic allocation is impossible during static initialization.

A constexpr constructor is the language feature that guarantees objects with non-trivial constructors (such as std::mutex) can be initialized during the static initialization phase. Without a constexpr constructor you have no such guarantee. 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. If that state has not been initialized before it's needed, you have a problem. A constexpr constructor ensures it is set before needed.

MSVC

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

> 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.

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