My thought exactly. Not only that, but MSVC supports C++17 features natively so I have no idea why you'd want to do this on Windows.
Granted, the state of C++ on MacOS is embarrassingly bad.
Granted, the state of C++ on MacOS is embarrassingly bad.
If you're trying to write portable software, that's the easiest way to validate compilation for Linux without: a) using an external CI, or b) running a full VM in parallel.
But probably the real option (c) that you are missing here is the fabulously named "Windows Subsystem for Linux".
Re WSL: If the app you're working on works on WSL, great. It's not an option for many projects though.
Cross-targeting from linux is probably slower ATM (clang-cl is not fast :P)
That said, if you have a single compiler you can use across platforms, and it generates the best code (or within a small enough percent), and enables a suite of cross-platform dynamic error checking capabilities (ASAN, etc), that provides significant productivity/etc advantages for people. Especially when you can easily improve them according to your own engprod priorities.
MSVC is the worst standard non-conforming C++ compiler in the current major compilers. I consider it MS C++-ish dialect compiler.
Only from C++17 on gcc and clang do have an advantage. http://en.cppreference.com/w/cpp/compiler_support
The label worst std support would go to: EDG eccp, Intel C++, IBM XLC++, Sun/Oracle C++, Embarcadero C++ Builder, Cray, HP aCC [Collapse], Digital Mars C++
MSVC has very bad C support, this is their problem, not C++.
Really, it's garbage and it shouldn't be considered as C++ compiler.
See eg here for MSFT explaining about the lack of even C99 conformance, as recently as November 2017: https://visualstudio.uservoice.com/forums/121579-visual-stud...
Meanwhile clang and gcc have had full C99 for a long time and have complete or near-complete support of C11, including optional parts.
C11 is an extension of C99, so you can't have C11 support without C99.
But this nonwithstanding, MSVC doesn't appear have wide support for post-C99 C11 features either. For example, _Generic and t.
Are there any parts of C11 that MSVC supports aside from the Annex K functions, which is optional in C11? Annex K happens to be an extension proposed by Microsoft, so it's small wonder they implement it and it's quite disingenious to talk up microsoft for C11 support in this case. Other vendors didn't think it was very good, so didn't implement that optional feature.
And contrary to your claim, gcc and clang seem to have quite good C11 support.
I write many simple scripts with node just because it works everywhere with minimal quirks. I also have a few incredibly simple web apps which I use to visualize or explore small datasets. It's great to able to open up an html file in the browser and have it work everywhere.
Docker containers aren't an ideal solution, but they make it easier to get things running everywhere. Consider why stuff like Electron is so popular, despite its many quirks.
In what sense? Apple keeps Clang up to date on macOS, and it is essentially no work to get the associated Clang tooling and other C++ tools (valgrind, etc) installed through something like homebrew.
Actually, not especially. The system compiler that ships with Xcode is still quite old and the libraries are quite out of date. For example, though the most recent Xcode finally added -std=c++17 it still lacks core library features like std::variant. I wish they could keep close to mainline but for whatever reason they can't.
quite old, quite old... -std=c++17 was only added in clang 5 released in september, 3 months ago. AFAIK current Xcode is based on Clang 4.
As far as compiler support goes, Clang supports all of C++17 except for P0522R0 which is a defect report (ambiguity in specification) so cannot be implemented as written. Ditto GCC.
However std::variant is a library entity, not a compiler entity, and indeed, the libraries are a bit behind. Neither GCC's nor LLVM's runtime library support the parallelism extensions and have other gaps in areas exotic (memory, unfortunately which I would like to use) and prosaic (filesystem, which though I'd like to use it as well don't really care about). But they have been solid on C++17 core functionality for quite a long time.
C++ isn't as important to Apple as Swift (or even, still, ObjC) and C++17 is pretty new, so one can hardly blame Apple for this, especially since it's so trivial to simply use another compiler.
It's due to issues like this that I do all our clang testing on FreeBSD, where it's a more vanilla build of the llvm codebase, and I treat AppleClang as a wholly separate compiler variant which requires independent testing.