please wait
C++ Language Standard
Apr 30, 2020 at 3:05pm
I know when compiling new C++ code using /std:C++17 is usually preferred over /std:C++14 or earlier. There are exceptions of course.
Is there any reason(s) why compiling with /std:C++latest would have problems /std:C++17 doesn't have, even if not using latest/C++20 features?
MSVC++ 2019 is my goto compiler, with Code::Blocks 20.03 as my 2nd tier.
Is there any reason(s) why compiling with /std:C++latest would have problems /std:C++17 doesn't have, even if not using latest/C++20 features?
MSVC++ 2019 is my goto compiler, with Code::Blocks 20.03 as my 2nd tier.
Apr 30, 2020 at 3:23pm
from what they said when they introduced version switches, https://devblogs.microsoft.com/cppblog/standards-version-switches-in-the-compiler/ , it was supposed to be safe ("The /std:c++latest switch will not turn on new features guarded by the /experimental switch"), so unless something changed, the only potential problems are the bugs in new features.
Apr 30, 2020 at 3:30pm
if you make a habit of using "make warnings into errors" flags, then 17 and earlier code may have obsolete warnings that trigger on it when you get the 20 version.
Apr 30, 2020 at 3:37pm
Unscoped enums are especially prone to throwing up IMO overly pedantic warnings with MSVC.
Apr 30, 2020 at 3:57pm
@jonnin, so far I haven't had any language standard changed/deprecated/removed problems with my newer code. *knocks on Formica* When C++2a becomes official that might change.
Changing some older code to C++11/C++14/C++17 standard with things like auto_ptr and random_shuffle did make the compiler a bit gassy, but that made finding and fixing the problems easier. Fix one problem, recompile and go to the next error.
Changing some older code to C++11/C++14/C++17 standard with things like auto_ptr and random_shuffle did make the compiler a bit gassy, but that made finding and fixing the problems easier. Fix one problem, recompile and go to the next error.
Apr 30, 2020 at 5:25pm
I used "latest" for a short bit... unless you are specifically enabling known C++20 features, don't.
Be specific about which language standard you are compiling against.
For all new code, I use C++17. All major compilers support it well enough, and I can be pedantic about it.
Be specific about which language standard you are compiling against.
For all new code, I use C++17. All major compilers support it well enough, and I can be pedantic about it.
Apr 30, 2020 at 7:51pm
Since C++2a is still unofficial, C++17 is the current standard, and I don't really use any C++2a features ATM /std:C++17 looks like the way to go.
Since I am still tinkering around with and self-learning C++11/C++14/C++17 enabling C++2a is an exercise in folly.
If anyone else has an opinion one way or the other feel free to vent. :)
Since I am still tinkering around with and self-learning C++11/C++14/C++17 enabling C++2a is an exercise in folly.
If anyone else has an opinion one way or the other feel free to vent. :)
May 1, 2020 at 12:11am
I don't remember off the top of my head, but there have been several times where I tried running some code it wouldn't allow until I set it to latest. They didn't seem to be C++20 features, but I don't remember what they were now to be sure.
May 13, 2020 at 4:54pm
I was at cppreference and while bumping around looking at some other stuff I saw a C++2a feature that really intrigued me because I hadn't noticed it before: the <format> library.
https://en.cppreference.com/w/cpp/header/format
I tried a couple of the examples with MSVC set to /std:c++latest and no joy. :(
It is hard for me to wait for the standard to be finalized and all the major compilers to finish implementing the features.
https://en.cppreference.com/w/cpp/header/format
I tried a couple of the examples with MSVC set to /std:c++latest and no joy. :(
It is hard for me to wait for the standard to be finalized and all the major compilers to finish implementing the features.
Last edited on May 13, 2020 at 4:59pm
May 13, 2020 at 5:24pm| the <format> library. |
May 13, 2020 at 5:35pm
Cubbi, I can wait for <format> to become part of the standard. :)
Though I should muck around with fmt.
Though I should muck around with fmt.
May 13, 2020 at 9:51pm
Meh, C++ committee just can’t stay on one path. I’m kind of sick of the stupid mucking with the language.
What format gives you is nice internationalization powers... assuming C++ gets its schnizit together enough to actually handle Unicode properly in the Standard Library...
(Most frameworks will do this stuff for you, like, automatically.)
What format gives you is nice internationalization powers... assuming C++ gets its schnizit together enough to actually handle Unicode properly in the Standard Library...
(Most frameworks will do this stuff for you, like, automatically.)
May 14, 2020 at 2:21am| C++ committee just can’t stay on one path. |
A giraffe is a horse designed by a committee.
Maybe I'd just a lazy sod, wanting to not take the time or effort to get a 3rd party library to work. Boost is a lot of "add this directory, do that configuration" grunt work even though the bulk of the library is header only.
May 14, 2020 at 6:10am
The latest boost library is easy to install in VS 2017.
Just had to enter 2 commands and wait 2 hours.
Just had to enter 2 commands and wait 2 hours.
May 14, 2020 at 7:57am
I use /std:C++latest since it was introduced, and so far encountered 2 bugs, both of which were caused by compiler.
1. internal compiler error when using in class inline static smart pointer initialization
2. compiler failed to evaluate constexpr statement, which is otherwise perfectly valid and constexpr
I was not able to repro these 2 with /std:C++17
This doesn't bother me at all, it was easy to workaround, what positive (at least in my case)
is that I encountered no code related bugs (by using standard headers) or new language features and API's.
1. internal compiler error when using in class inline static smart pointer initialization
2. compiler failed to evaluate constexpr statement, which is otherwise perfectly valid and constexpr
I was not able to repro these 2 with /std:C++17
This doesn't bother me at all, it was easy to workaround, what positive (at least in my case)
is that I encountered no code related bugs (by using standard headers) or new language features and API's.
Topic archived. No new replies allowed.