But why

Posted Oct 2, 2024 15:56 UTC (Wed) by rsidd (subscriber, #2582)
In reply to: But why by atnot
Parent article: An update on gccrs development

> Although it's worth noting that the major reason C and C++ ended up that way is because of the wide use of proprietary compilers, which is not really a thing affecting any modern language.

This is worth emphasizing. Today C and C++ standards are de facto GCC and LLVM. Extensions in those get picked up by the "standards" years later. Ok, that's still two independent compilers. But it used to be just one (gcc), at least in linux and FLOSS. Alternatives like Intel's icc had to implement many gcc-isms to survive.

When there is a good OSS compiler there is little incentive to develop another from scratch.

But why

Posted Oct 2, 2024 20:04 UTC (Wed) by dankamongmen (subscriber, #35141) [Link] (10 responses)

ignoring MSVC here seems a weird miss

But why

Posted Oct 2, 2024 20:47 UTC (Wed) by intelfx (subscriber, #130118) [Link] (9 responses)

Nobody looks to MSVC as if it was a de facto standard though?

In my experience with industry, MSVC is "that quirky thing that lags behind the real compilers, oh and I guess we need to stick a bunch of ~~polyfills~~workarounds all over the code code for every real compiler feature it lacks or does a NIHy thing instead".

But why

Posted Oct 3, 2024 10:22 UTC (Thu) by peter-b (guest, #66996) [Link] (8 responses)

In my experience with industry, MSVC is "that quirky thing that lags behind the real compilers, oh and I guess we need to stick a bunch of polyfillsworkarounds all over the code code for every real compiler feature it lacks or does a NIHy thing instead".

Recently the MSVC team have been implementing C++ features well ahead of clang. They have been doing very good work and engaging with C++ standardization in a constructive way.

The quality of the compiler and standard library is right up there with GCC and clang, especially with /permissive-. The diagnostics often catch things that GCC and clang don't.

"MSVC is a crap compiler" was an accurate meme in 2015, but that's no longer the case.

But why

Posted Oct 3, 2024 12:44 UTC (Thu) by aragilar (subscriber, #122569) [Link] (1 responses)

Not suggesting MSVC is in any way poor quality, but I believe that there are still is a fair amount C features post C89 that are not supported, and the lack of __float128 (or its various other incantations) remains a source of pain (even icc supports it, and has for a while). I suspect it depends what part of the standard you are interested in as to who is ahead in features.

But why

Posted Oct 7, 2024 15:56 UTC (Mon) by itrue (guest, #156235) [Link]

MSVC is a bad C compiler, but a pretty solid C++ one.

But why

Posted Oct 4, 2024 16:47 UTC (Fri) by StillSubjectToChange (guest, #128662) [Link] (5 responses)

MSVC is no "Cinderella story", so to speak. Sure, Microsoft has stepped up their investment into the product, but the fact remains that MSVC has a substantial deficit to overcome. Also, there is a world of difference between advertising support for a feature and actually using it in production. For instance, MSVC has "supported" modules for quite some time now, yet it's quite difficult to find *anyone* (outside of MS at least) who genuinely uses them. Furthermore, MSVC is a total non-factor when it comes to supporting other standards like OpenMP, and eventually OpenACC and SYCL too.

I'm not trying to degrade MSVC in order to elevate GCC and/or Clang. The fact is that MSVC simply doesn't compete with them in most circumstances. Or rather, MSVC simply is not a factor for vendors building a custom toolchain (Intel, AMD, Nvidia, etc) or for anyone targeting mobile, linux dominated environments like cloud or HPC, game consoles, embedded, etc.

But why

Posted Oct 4, 2024 17:36 UTC (Fri) by excors (subscriber, #95769) [Link] (1 responses)

> MSVC simply is not a factor for vendors building a custom toolchain (Intel, AMD, Nvidia, etc) or for anyone targeting mobile, linux dominated environments like cloud or HPC, game consoles, embedded, etc

I'm not sure game consoles are a great example, because MSVC is very relevant on Xbox, so it's still an important factor for cross-platform games and libraries. (But it does seem to be retreating even from that niche - the Microsoft Game Development Kit claims to support both MSVC and Clang on Windows and Xbox, though I have no idea how often people choose Clang.)

But why

Posted Oct 4, 2024 17:56 UTC (Fri) by pizza (subscriber, #46) [Link]

> I'm not sure game consoles are a great example, because MSVC is very relevant on Xbox,

It's more accurate to say that the only reason to use MSVC is if you're targeting Microsoft platforms (including the Xbox).

> so it's still an important factor for cross-platform games and libraries.

That should be "it's still a source of major headaches for cross-platform games and libraries"

(Granted, many of those problems were due to Windows platform-isms rather than MSVC itself...)

But why

Posted Oct 13, 2024 13:59 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (2 responses)

> For instance, MSVC has "supported" modules for quite some time now, yet it's quite difficult to find *anyone* (outside of MS at least) who genuinely uses them.

MSVC's module support is ahead of the other implementations IME. Adoption issues have mostly been related to tooling and using modules. Now that CMake[1] has (experimental) support for `import std;` (MSVC and Clang only right now), I think that it is a good time for projects to start investigating modules usage and file issues to compilers for what needs fixing on their side. There's still work to be done on non-compiler, non-build tooling, but I'm working on that too[2].

And I am interesting in modules adoption ecosystem-wide, not just for CMake. I've gone to many build systems trying to get modules support (e.g., xmake[3], tup[4], meson[5], bazel[6]) implemented. There's also the "Are We Modules Yet?"[7] page which aims to track progress.

[1] Full disclosure: I'm a CMake developer and implemented its C++ modules support.
[2] https://cppcon2024.sched.com/event/1gZg8/beyond-compilati...
[3] https://github.com/xmake-io/xmake/issues/386
[4] https://groups.google.com/g/tup-users/c/FhJTA6KAzWU/m/t5P...
[5] https://github.com/mesonbuild/meson/issues/5024#issuecomm...
[6] https://github.com/bazelbuild/bazel/pull/19940#issuecomme...
[7] https://arewemodulesyet.org/

But why

Posted Oct 13, 2024 15:52 UTC (Sun) by intelfx (subscriber, #130118) [Link] (1 responses)

> Full disclosure: I'm a CMake developer and implemented its C++ modules support

Can we bribe you with beer and/or cookies to write a guest article for LWN on the state of C++ modules? :-)

I remember one of your multi-screen comments talking about modules a few months ago and I would *love* to see it in form of an article...

But why

Posted Oct 13, 2024 20:11 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Sure, cookies are more enticing than alcohol for me :) . COI policies may have things to say about actually fulfilling such an offer, but I'll put in a request to do something for LWN (we have our own blog as well, so cross-posting or the like may need considered).