5 ms·

Maybe I am behind in the times but it was a little surprising to me to see MSVC have full C++20 support while GCC and Clang are still trying to get there.

delta_p_delta_x 4y ago
Has been the case for the past half decade, too. MSVC's stdlib has been open-sourced, and MSVC is used by plenty of companies writing games, native Windows software, etc.
- mmozeiko 4y ago
  Not fully open-sourced. There are bunch of pieces that are available only in compiled form - .obj/lib files. Like math.h functions.
elabajaba 4y ago
Afaik Clang development has massively slowed down since Google gave up on trying to improve C++ as a language (it required breaking ABI, which the C++ standards committee rejected). They moved on and created Carbon instead for future C++ development where they need to work with existing C++ code, and recommend Rust for greenfield development.
- nindalf 4y ago
  Was clang development so dependent on one organisation? I can easily believe that many Google engineers are choosing to spend their time on Carbon now, but it seems strange that there was so much dependence here. Could there be some other reason for clang lagging behind?
  - pjmlp 4y ago
    Yes, it was also dependent on Apple's contributions, which nowadays focus on Swift and Objective-C. If you look at the C++ versions being used across Apple's platforms, they are more than happy staying with C++17 (Metal Shading Language is even lower, based on C++14). Almost everyone else seems to care only about LLVM, otherwise how to explain that LLVM gets almost as many contributions per year as the Linux kernel, while clang is lagging so much behind?
- Dylan16807 4y ago
  From what I am aware of, google wanted to break API significantly, not just ABI, by changing a bunch of standard library guarantees.
  - AngriestLettuce 4y ago
    Good. It is high time for some breakage. When your toe is gangrenous, you should cut it off, even if you're sad to see it go. This applies doubly so if you're as strange and mysterious a beast as C++ is — sprouting body parts in random places seemingly overnight, only incidentally producing anything valuable. Maybe you don't actually need a thumb in your forehead in the first place, especially since it bleeds into your eye whenever you try to use it.
    - witx 4y ago
      > sprouting body parts in random places seemingly overnight, only incidentally producing anything valuable. Maybe you don't actually need a thumb in your forehead in the first place, especially since it bleeds into your eye whenever you try to use it I've been using c++ for a while, and this comment is perhaps the best and funniest description of what I think about the language but was never able to put into words. Kudos for the laughs!
- joatmon-snoo 4y ago
  Far more likely to me is that bringing libc++ up to C++20 standards isn't important for google3. Carbon is a O(10y) project, not a O(3y) project. * absl strings provides the same compile-time guarantees that <format> does * absl date/time libs have integrations with the proto time types * google3 has many threading & synchronization primitives that it prefers over the STL types (all of which already has integrations with fleet-wide performance monitoring and other toolchain customizations, e.g. deadlock detection), so there isn't much reason to move the threading libraries forward
  - Dylan16807 4y ago
    > Carbon is a O(10y) project, not a O(3y) project. So are C++ language updates.
    - joatmon-snoo 4y ago
      Standard updates, not STL implementation.
  - jimbob45 4y ago
    Shouldn't that be big Omega?
Shinmon 4y ago
Microsoft does a pretty good job there. clang has been lacking behind ever since google reallocated resources somewhere else. What bothers me most about C++ is that it's mostly old people now. All the young people who are actively involved in language design, tool development, ... are putting their effort into other languages.
- pjmlp 4y ago
  There are young people still specially those wanting to work in cool domains like game development, however many older ones have some vested interests in keeping C++ the way it is, hence why even advocating for security is such an uphill battle. Or see how WinDev is so resistent to change, instead of providing .NET like tooling for C++, like Borland/Embarcadero have done for the last 25 years, they stick to their ways of manually editing IDL files and COM.
  - Shinmon 4y ago
    While I agree the young people who work on the languages and frameworks are increasingly working with other languages. The rust crowd is much younger than the people who are publicly working on popular C++ frameworks. In 10 years, there won't be many people left working on C++ as a language and on the tooling.
    - pjmlp 4y ago
      Might be, but until Microsoft et all rewrite their tooling in Rust, there will be enough people to keep C++ going. And if it changes, so be it, I am not coding today as I was in 1986, when I typed my first LOAD "".
      - still_grokking 4y ago
        > but until Microsoft et all rewrite their tooling in Rust, there will be enough people to keep C++ going. At least Microsoft started to do exactly this. They started to touch the Win API even to create Rust bindings. Because MS saw that this is the only way to future prove this stuff. Other big players, like IBM, don't look like they're moving, though. But OK, IBM moves so slowly as a pitch drop falls. So maybe we just don't see them moving.
pjmlp 4y ago
It is not surprising given the licenses, that the two major clang contributors decided to focus elsewhere (Swift, Objective-C and Carbon), while everyone else[0] is happilly just consuming clang, and only contributing to LLVM. At least GCC has Red-Hat supporting ISO C++ improvements. [0] - ARM, Intel, Embarcadero, IBM, NVidia, IBM, Nintendo, Sony,...
- still_grokking 4y ago
  But Red Hat is IBM, nowadays. Also AFAIK IBM is one of the most dedicated supporters of C++ in general.
  - pjmlp 4y ago
    Yes and no, while IBM owns Red-Hat, it doesn't dictate how Red-Hat does their own business decisions. Not in what concerns ISO C++ support, and if it was up to IBM, trigraphs would still be supported. See what ISO version their xl compilers support, across all mainframe, Aix and Linux deployments. https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support
    - still_grokking 4y ago
      > Yes and no, while IBM owns Red-Hat, it doesn't dictate how Red-Hat does their own business decisions. Even that's true, it's now IBM's money that gets invested. > Not in what concerns ISO C++ support, and if it was up to IBM, trigraphs would still be supported. I know about the trigraphs. That they were fighting for that shows imho exactly that IBM is heavily invested in C++. They have a shitload of old but hightly important code that can't be migrated realistically. So IBM will keep throwing money on C++ to extend its live infinitely, I guess.
- jocaal 4y ago
  You forgot to mention IBM

delta_p_delta_x 4y ago

Has been the case for the past half decade, too. MSVC's stdlib has been open-sourced, and MSVC is used by plenty of companies writing games, native Windows software, etc.

mmozeiko 4y ago
Not fully open-sourced. There are bunch of pieces that are available only in compiled form - .obj/lib files. Like math.h functions.

elabajaba 4y ago

Afaik Clang development has massively slowed down since Google gave up on trying to improve C++ as a language (it required breaking ABI, which the C++ standards committee rejected). They moved on and created Carbon instead for future C++ development where they need to work with existing C++ code, and recommend Rust for greenfield development.

nindalf 4y ago
Was clang development so dependent on one organisation? I can easily believe that many Google engineers are choosing to spend their time on Carbon now, but it seems strange that there was so much dependence here. Could there be some other reason for clang lagging behind?
- pjmlp 4y ago
  Yes, it was also dependent on Apple's contributions, which nowadays focus on Swift and Objective-C. If you look at the C++ versions being used across Apple's platforms, they are more than happy staying with C++17 (Metal Shading Language is even lower, based on C++14). Almost everyone else seems to care only about LLVM, otherwise how to explain that LLVM gets almost as many contributions per year as the Linux kernel, while clang is lagging so much behind?
Dylan16807 4y ago
From what I am aware of, google wanted to break API significantly, not just ABI, by changing a bunch of standard library guarantees.
- AngriestLettuce 4y ago
  Good. It is high time for some breakage. When your toe is gangrenous, you should cut it off, even if you're sad to see it go. This applies doubly so if you're as strange and mysterious a beast as C++ is — sprouting body parts in random places seemingly overnight, only incidentally producing anything valuable. Maybe you don't actually need a thumb in your forehead in the first place, especially since it bleeds into your eye whenever you try to use it.
  - witx 4y ago
    > sprouting body parts in random places seemingly overnight, only incidentally producing anything valuable. Maybe you don't actually need a thumb in your forehead in the first place, especially since it bleeds into your eye whenever you try to use it I've been using c++ for a while, and this comment is perhaps the best and funniest description of what I think about the language but was never able to put into words. Kudos for the laughs!
joatmon-snoo 4y ago
Far more likely to me is that bringing libc++ up to C++20 standards isn't important for google3. Carbon is a O(10y) project, not a O(3y) project. * absl strings provides the same compile-time guarantees that <format> does * absl date/time libs have integrations with the proto time types * google3 has many threading & synchronization primitives that it prefers over the STL types (all of which already has integrations with fleet-wide performance monitoring and other toolchain customizations, e.g. deadlock detection), so there isn't much reason to move the threading libraries forward
- Dylan16807 4y ago
  > Carbon is a O(10y) project, not a O(3y) project. So are C++ language updates.
  - joatmon-snoo 4y ago
    Standard updates, not STL implementation.
- jimbob45 4y ago
  Shouldn't that be big Omega?

Shinmon 4y ago

Microsoft does a pretty good job there. clang has been lacking behind ever since google reallocated resources somewhere else. What bothers me most about C++ is that it's mostly old people now. All the young people who are actively involved in language design, tool development, ... are putting their effort into other languages.

pjmlp 4y ago
There are young people still specially those wanting to work in cool domains like game development, however many older ones have some vested interests in keeping C++ the way it is, hence why even advocating for security is such an uphill battle. Or see how WinDev is so resistent to change, instead of providing .NET like tooling for C++, like Borland/Embarcadero have done for the last 25 years, they stick to their ways of manually editing IDL files and COM.
- Shinmon 4y ago
  While I agree the young people who work on the languages and frameworks are increasingly working with other languages. The rust crowd is much younger than the people who are publicly working on popular C++ frameworks. In 10 years, there won't be many people left working on C++ as a language and on the tooling.
  - pjmlp 4y ago
    Might be, but until Microsoft et all rewrite their tooling in Rust, there will be enough people to keep C++ going. And if it changes, so be it, I am not coding today as I was in 1986, when I typed my first LOAD "".
    - still_grokking 4y ago
      > but until Microsoft et all rewrite their tooling in Rust, there will be enough people to keep C++ going. At least Microsoft started to do exactly this. They started to touch the Win API even to create Rust bindings. Because MS saw that this is the only way to future prove this stuff. Other big players, like IBM, don't look like they're moving, though. But OK, IBM moves so slowly as a pitch drop falls. So maybe we just don't see them moving.

pjmlp 4y ago

It is not surprising given the licenses, that the two major clang contributors decided to focus elsewhere (Swift, Objective-C and Carbon), while everyone else[0] is happilly just consuming clang, and only contributing to LLVM. At least GCC has Red-Hat supporting ISO C++ improvements. [0] - ARM, Intel, Embarcadero, IBM, NVidia, IBM, Nintendo, Sony,...

still_grokking 4y ago
But Red Hat is IBM, nowadays. Also AFAIK IBM is one of the most dedicated supporters of C++ in general.
- pjmlp 4y ago
  Yes and no, while IBM owns Red-Hat, it doesn't dictate how Red-Hat does their own business decisions. Not in what concerns ISO C++ support, and if it was up to IBM, trigraphs would still be supported. See what ISO version their xl compilers support, across all mainframe, Aix and Linux deployments. https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support
  - still_grokking 4y ago
    > Yes and no, while IBM owns Red-Hat, it doesn't dictate how Red-Hat does their own business decisions. Even that's true, it's now IBM's money that gets invested. > Not in what concerns ISO C++ support, and if it was up to IBM, trigraphs would still be supported. I know about the trigraphs. That they were fighting for that shows imho exactly that IBM is heavily invested in C++. They have a shitload of old but hightly important code that can't be migrated realistically. So IBM will keep throwing money on C++ to extend its live infinitely, I guess.
jocaal 4y ago
You forgot to mention IBM