C++ Language Standard

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.
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.
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.
Unscoped enums are especially prone to throwing up IMO overly pedantic warnings with MSVC.
@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.
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.
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. :)
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.
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.
Last edited on
the <format> library.
it's just https://github.com/fmtlib/fmt integrated into stdlib, you can use fmt as-is until the integration finished.
Cubbi, I can wait for <format> to become part of the standard. :)

Though I should muck around with fmt.
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.)
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.
The latest boost library is easy to install in VS 2017.
Just had to enter 2 commands and wait 2 hours.
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.

Topic archived. No new replies allowed.