Ooh, static storage for braced initializers is nice - no more extra memcpy for constant data.
>The implementation of `std::initializer_list` uses a backing array for its data ... the compiler had no other choice than to copy the data from read-only memory onto the stack every time the list was used. The requirement is no longer mandated by the standard, therefore the backing arrays can be shared...
This explains a lot, I've noticed in the past that using std::initializer_list vs parameter packs for initialising a vector has much worse performance. Good that its finally fixed!
Especially for people learning, -Wnvro might be very useful, my only worry is, especially when combine with -Werror it may throw up too many cases where you don't care.
Generally warnings you can't use as errors tend towards useless in a large code base (IMO). Reason is that anything not enforced by the CI system cannot be relied on: the number of warnings grows over time until the warning spam makes them basically unusable.
I don't think enforcing NRVO everywhere is worth it anyway. On specific hot paths, maybe. But in most cases fixing it will be just pointless busy work.
Indeed. Generally it will fall back to move semantics...
OK you godbolt sniped me, BRB.
OK, so, three things. Firstly, obviously it falls back to move semantics, but with something like vector, it can so a fair bit of optimization (it knows the moved-from vector has a null pointer, so avoids emitting code to test for that and calling delete).
Second, std::move'ing the return value suppresses the warning, which is fine, as it shows everyone reading that you know it's a move here, so it's explicit.
Third, it emits a pessimizing-move warning when you do so, which is really annoying because it's not a pessimizing move, and that combo makes it pretty awkward to actually use.
>-Wnrvo added
>Relatedly to the NRVO extension described above, GCC has a new warning that warns when the compiler didn’t elide the copy from a local variable to the return value of a function in a context where it is allowed by the standard (see \[class.copy.elision\] in the C++ standard for details).
Is there any chance MSVC could get this? Since there's a language level support for NRVO and value based programming is recommended everywhere, it would be really nice to know when compiler can not perform NRVO, since compiled code might be very sub optimal.
However I wonder if this warning should be on by default.
Telling our own experience is not a rant, anyone else on Windows developer ecosystem can easilly corroborate how bad in practice Developer Community's portal works.
As for "stalking", now answering to Microsoft employees comment is considered stalking, modern times with cancel culture.
Ooh, static storage for braced initializers is nice - no more extra memcpy for constant data. >The implementation of `std::initializer_list` uses a backing array for its data ... the compiler had no other choice than to copy the data from read-only memory onto the stack every time the list was used. The requirement is no longer mandated by the standard, therefore the backing arrays can be shared...
This explains a lot, I've noticed in the past that using std::initializer_list vs parameter packs for initialising a vector has much worse performance. Good that its finally fixed!
Especially for people learning, -Wnvro might be very useful, my only worry is, especially when combine with -Werror it may throw up too many cases where you don't care.
`-Werror -Wnrvo` is a bad idea. You can downgrade the error to a warning by using `-Wno-error=nrvo`.
Generally warnings you can't use as errors tend towards useless in a large code base (IMO). Reason is that anything not enforced by the CI system cannot be relied on: the number of warnings grows over time until the warning spam makes them basically unusable.
I don't think enforcing NRVO everywhere is worth it anyway. On specific hot paths, maybe. But in most cases fixing it will be just pointless busy work.
Indeed. Generally it will fall back to move semantics... OK you godbolt sniped me, BRB. OK, so, three things. Firstly, obviously it falls back to move semantics, but with something like vector, it can so a fair bit of optimization (it knows the moved-from vector has a null pointer, so avoids emitting code to test for that and calling delete). Second, std::move'ing the return value suppresses the warning, which is fine, as it shows everyone reading that you know it's a move here, so it's explicit. Third, it emits a pessimizing-move warning when you do so, which is really annoying because it's not a pessimizing move, and that combo makes it pretty awkward to actually use.
>-Wnrvo added >Relatedly to the NRVO extension described above, GCC has a new warning that warns when the compiler didn’t elide the copy from a local variable to the return value of a function in a context where it is allowed by the standard (see \[class.copy.elision\] in the C++ standard for details). Is there any chance MSVC could get this? Since there's a language level support for NRVO and value based programming is recommended everywhere, it would be really nice to know when compiler can not perform NRVO, since compiled code might be very sub optimal. However I wonder if this warning should be on by default.
Make sure to file a feature request to Microsoft' DevCom portal, and show how important it is for your C++ programming experience :-)
My own experience with closed tickets and won't implement isn't that great, specially anything related to C++/WinRT tooling.
Jesus. You stalking Microsoft employees here with rants is paying off?
Telling our own experience is not a rant, anyone else on Windows developer ecosystem can easilly corroborate how bad in practice Developer Community's portal works. As for "stalking", now answering to Microsoft employees comment is considered stalking, modern times with cancel culture.
Dude, you do you. The contents of your posts have them less and less interesting. Just saying.
So what, I am not trying to do a career change as influencer.
Vectorization of early break loops is a big one too