8 ms·

By ”stagnation” do you mean “not getting new features”?

deleted 2y ago
[deleted]
vlovich123 2y ago
N3340 is from 2011. Prior to c++11 they had failed to deliver major changes to the language. And arguably the disfunction is still there where big ideas get destroyed in committee (reflection) or take forever and come out half-baked (modules).
- rerdavies 2y ago
  Speaking of half-baked, did continuations get fixed?
CuriousCosmic 2y ago
C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. The issue is that those are the same features everyone has been asking for for over a decade so the people that really care found workarounds and eventually move over to the new std way of doing things when they can while everyone else continues waiting for that one feature they really care about.
- adrianN 2y ago
  The people complaining and the people asking for features need not be overlapping sets.
- physicsguy 2y ago
  > the people that really care found workarounds Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for.
  - chipdart 2y ago
    > Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for. Some use cases like GUI programming sound like they are better addressed by specialized tech stacks. Nevertheless, either you're talking about greenfield projects or you are hard pressed to find a justification to rewrite a project in another framework. Claiming you stopped writing C++ doesn't fit the bulk of the experience of anyone maintaining C++ projects.
    - PathOfEclipse 2y ago
      My experience maintaining old codebases is that you are just as hard-pressed to find a justification to write code to use new language features, or even to take the time to upgrade the language and compiler version. Most often you just continue writing code in the same style as the rest of the code base using an old version of the language and runtime.
      - chipdart 2y ago
        > My experience maintaining old codebases is that you are just as hard-pressed to find a justification to write code to use new language features, or even to take the time to upgrade the language and compiler version. That's perfectly fine. You should only pay for what you use. Your average project, however, consumes dependencies and needs to keep them updated. Just because the code you write doesn't use them that doesn't mean your dependencies don't. So everyone still benefits with each release of C++ even if the are not using fancy features.
    - lallysingh 2y ago
      Services get split up and some parts rewritten. The parts are often written in new languages.
    - physicsguy 2y ago
      Yes that's right, what I meant was that for many of the use cases on greenfield projects that I used to use C++ for, I no longer do.
- Grayskull 2y ago
  > They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/tools people.
  - usrnm 2y ago
    > Can't you just decide to use subset of the language? No, you can't. Not in the long run, at least. You will have to use libraries that have chosen a different subset, new people will join your team, things will get sloppy as the company grows, etc. Committing to a subset of the language is not free, it's hard and it's a lot of work. And for what?
  - foldr 2y ago
    Not really. Even parts of the standard library (e.g. std::variant) more or less require the use of quite advanced language features.
  - kragen 2y ago
    or people who need to maintain someone else's code, debug their own, write a library someone else might use, or understand compiler error messages, all of which involve understanding language features you don't yourself use (at least intentionally)
    - AnimalMuppet 2y ago
      Partly true. If you're writing library code that someone else might use, you don't have much need to understand the features you don't use, unless you have to handle them at the interface. If you're debugging your own code, you really shouldn't have to understand features that you didn't use. (Mostly - see the next paragraph.) You did say "intentionally". You could wind up using a feature unintentionally, but it's not very common, because most of the new features are either in a new library (which you have to explicitly call), or a new syntax. There are definitely exceptions - I could easily see you using a move constructor without meaning to. Maintaining someone else's code... yeah. You have to understand whatever they used, whether or not it made any sense for them to use.
- okanat 2y ago
  I think the bureaucratic cadence of the things also make C++ not a unified entity. C++ is patchwork language. So many of the new features don't work well together or don't fit together or they have conflicting goals. Since the proposals target problems with differing philosophies, they each have different traps in them from bad time complexity to outright unrefined behavior. Keeping up with the updates hard because of this. I think many C++ projects are (or will be) basically infeasible to maintain not because of the old problems but due to the exploding complexity of the interactions of all features, unless developers actively ban using large parts of the language.
  - CuriousCosmic 2y ago
    > C++ is patchwork language. So many of the new features don't work well together or don't fit together or they have conflicting goals. I don't really see this as true. In my experience most C++ features actually "just work" together and there are relatively few footguns involved in mixing features. And it's less that C++ is a patchwork language and more that it is multi-paradigm and multi-discipline. Some features have specific applications and they get used inappropriately but in my experience that is solved with a quick reference/citation of the standard during code review or in a new ticket.
- maccard 2y ago
  Also that the features c++ is getting are bolt on additions that we already have solutions for. I think fmt is a great example - fmt is a header only library that can be dropped in. Meanwhile std format was standardised without printing to stout. That took 3 years to standardise. Meanwhile we’re working on things like ranges, and instead of implementing them in the language it’s shoe horned in as a library feature - we now pay massive compile time hits for these features that are being shoved in alongside the kitchen sink. Meanwhile the solution (modules) has been talked about longer than I’ve been writing c++, it’s still unusable, and it hasn’t shown one of the key things people have been begging for for a decade - faster compile times. I think the committee is focused on the wrong things
  - meindnoch 2y ago
    >instead of implementing them in the language it’s shoe horned in as a library feature Quite the opposite. Proliferating the language itself with ad-hoc constructs would be shoe-horning.
    - maccard 2y ago
      I disagree completely. Libraries like ranges are dumped into algorithm, and are de-facto considered parts of the language. Reflection has gone back to have range support added, for example. Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself. I would much rather gcc saw me passing a span around and could treat it as a special built in type.
      - meindnoch 2y ago
        >Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself. False. Nothing prevents compilers from giving their own stdlib types special treatment under the hood.
- account42 2y ago
  Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions. This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to be standardized (or indifinitely - not everything should be added to the stdlib). But even language features can and should exist as compiler extensions before we are stuck with them.
  - chipdart 2y ago
    > There are still too many half-baked ideas that turn out to be mistakes afterwards (...) Care to point an example?
    - gpderetta 2y ago
      Some examples on top of my mind: - export templates is the canonical one. - Universal references are a great feature in principle, but the way they are integrated in the language is far from ideal. - Both features are great in isolation, but the interaction between initializer lists and aggregate initialization is a giant footgun. - Coroutines are overly complex and still incomplete but I still have hope. - Modules feel DOA so far. - Unrestricted compile time evaluation is great, but the constexpr qualifier per se doesn't guarantee any useful property. edit: overall I'm happy with the evolution of the language, but the standardization process has flaws
      - pjmlp 2y ago
        Module are already being used by Office, and those of us that don't need to rely on GCC, don't hate CMake, can already enjoy using them. Which is what I have been using on my C++ hobby projects for the last two years, on work projects we are still on C++17 land anyway.
    - kragen 2y ago
      marshall cline's c++ mini-faq is a list of about 100 pages of them from the 01990s
- lenkite 2y ago
  Wish C++ fixed some of its mistakes in the standard library. std::regex is embarrassing when even Python can beat it and nobody uses std::unordered_map due to its pointer chasing. Basic Maps are something that you shouldn't need to use a third party library for.
  - ghosty141 2y ago
    Could you explain the issue with unordered_map?
    - lenkite 2y ago
      The standard guarantees that you can get a pointer to an object in the map and this pointer will remain valid after rehashing and insertion/deletion of other elements. That basically forces implementers to use “buckets with linked lists”, also known as separate chaining. This is not cache friendly (and also suffers from excessive allocation). Other hash map implementations like abseil's don't provide this guarantee so they can put everything right there inline, which is much more efficient.

deleted 2y ago

[deleted]

N3340 is from 2011. Prior to c++11 they had failed to deliver major changes to the language. And arguably the disfunction is still there where big ideas get destroyed in committee (reflection) or take forever and come out half-baked (modules).

rerdavies 2y ago
Speaking of half-baked, did continuations get fixed?

CuriousCosmic 2y ago

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. The issue is that those are the same features everyone has been asking for for over a decade so the people that really care found workarounds and eventually move over to the new std way of doing things when they can while everyone else continues waiting for that one feature they really care about.

adrianN 2y ago
The people complaining and the people asking for features need not be overlapping sets.
physicsguy 2y ago
> the people that really care found workarounds Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for.
- chipdart 2y ago
  > Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for. Some use cases like GUI programming sound like they are better addressed by specialized tech stacks. Nevertheless, either you're talking about greenfield projects or you are hard pressed to find a justification to rewrite a project in another framework. Claiming you stopped writing C++ doesn't fit the bulk of the experience of anyone maintaining C++ projects.
  - PathOfEclipse 2y ago
    My experience maintaining old codebases is that you are just as hard-pressed to find a justification to write code to use new language features, or even to take the time to upgrade the language and compiler version. Most often you just continue writing code in the same style as the rest of the code base using an old version of the language and runtime.
    - chipdart 2y ago
      > My experience maintaining old codebases is that you are just as hard-pressed to find a justification to write code to use new language features, or even to take the time to upgrade the language and compiler version. That's perfectly fine. You should only pay for what you use. Your average project, however, consumes dependencies and needs to keep them updated. Just because the code you write doesn't use them that doesn't mean your dependencies don't. So everyone still benefits with each release of C++ even if the are not using fancy features.
  - lallysingh 2y ago
    Services get split up and some parts rewritten. The parts are often written in new languages.
  - physicsguy 2y ago
    Yes that's right, what I meant was that for many of the use cases on greenfield projects that I used to use C++ for, I no longer do.
Grayskull 2y ago
> They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/tools people.
- usrnm 2y ago
  > Can't you just decide to use subset of the language? No, you can't. Not in the long run, at least. You will have to use libraries that have chosen a different subset, new people will join your team, things will get sloppy as the company grows, etc. Committing to a subset of the language is not free, it's hard and it's a lot of work. And for what?
- foldr 2y ago
  Not really. Even parts of the standard library (e.g. std::variant) more or less require the use of quite advanced language features.
- kragen 2y ago
  or people who need to maintain someone else's code, debug their own, write a library someone else might use, or understand compiler error messages, all of which involve understanding language features you don't yourself use (at least intentionally)
  - AnimalMuppet 2y ago
    Partly true. If you're writing library code that someone else might use, you don't have much need to understand the features you don't use, unless you have to handle them at the interface. If you're debugging your own code, you really shouldn't have to understand features that you didn't use. (Mostly - see the next paragraph.) You did say "intentionally". You could wind up using a feature unintentionally, but it's not very common, because most of the new features are either in a new library (which you have to explicitly call), or a new syntax. There are definitely exceptions - I could easily see you using a move constructor without meaning to. Maintaining someone else's code... yeah. You have to understand whatever they used, whether or not it made any sense for them to use.
okanat 2y ago
I think the bureaucratic cadence of the things also make C++ not a unified entity. C++ is patchwork language. So many of the new features don't work well together or don't fit together or they have conflicting goals. Since the proposals target problems with differing philosophies, they each have different traps in them from bad time complexity to outright unrefined behavior. Keeping up with the updates hard because of this. I think many C++ projects are (or will be) basically infeasible to maintain not because of the old problems but due to the exploding complexity of the interactions of all features, unless developers actively ban using large parts of the language.
- CuriousCosmic 2y ago
  > C++ is patchwork language. So many of the new features don't work well together or don't fit together or they have conflicting goals. I don't really see this as true. In my experience most C++ features actually "just work" together and there are relatively few footguns involved in mixing features. And it's less that C++ is a patchwork language and more that it is multi-paradigm and multi-discipline. Some features have specific applications and they get used inappropriately but in my experience that is solved with a quick reference/citation of the standard during code review or in a new ticket.
maccard 2y ago
Also that the features c++ is getting are bolt on additions that we already have solutions for. I think fmt is a great example - fmt is a header only library that can be dropped in. Meanwhile std format was standardised without printing to stout. That took 3 years to standardise. Meanwhile we’re working on things like ranges, and instead of implementing them in the language it’s shoe horned in as a library feature - we now pay massive compile time hits for these features that are being shoved in alongside the kitchen sink. Meanwhile the solution (modules) has been talked about longer than I’ve been writing c++, it’s still unusable, and it hasn’t shown one of the key things people have been begging for for a decade - faster compile times. I think the committee is focused on the wrong things
- meindnoch 2y ago
  >instead of implementing them in the language it’s shoe horned in as a library feature Quite the opposite. Proliferating the language itself with ad-hoc constructs would be shoe-horning.
  - maccard 2y ago
    I disagree completely. Libraries like ranges are dumped into algorithm, and are de-facto considered parts of the language. Reflection has gone back to have range support added, for example. Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself. I would much rather gcc saw me passing a span around and could treat it as a special built in type.
    - meindnoch 2y ago
      >Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself. False. Nothing prevents compilers from giving their own stdlib types special treatment under the hood.
account42 2y ago
Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions. This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to be standardized (or indifinitely - not everything should be added to the stdlib). But even language features can and should exist as compiler extensions before we are stuck with them.
- chipdart 2y ago
  > There are still too many half-baked ideas that turn out to be mistakes afterwards (...) Care to point an example?
  - gpderetta 2y ago
    Some examples on top of my mind: - export templates is the canonical one. - Universal references are a great feature in principle, but the way they are integrated in the language is far from ideal. - Both features are great in isolation, but the interaction between initializer lists and aggregate initialization is a giant footgun. - Coroutines are overly complex and still incomplete but I still have hope. - Modules feel DOA so far. - Unrestricted compile time evaluation is great, but the constexpr qualifier per se doesn't guarantee any useful property. edit: overall I'm happy with the evolution of the language, but the standardization process has flaws
    - pjmlp 2y ago
      Module are already being used by Office, and those of us that don't need to rely on GCC, don't hate CMake, can already enjoy using them. Which is what I have been using on my C++ hobby projects for the last two years, on work projects we are still on C++17 land anyway.
  - kragen 2y ago
    marshall cline's c++ mini-faq is a list of about 100 pages of them from the 01990s
lenkite 2y ago
Wish C++ fixed some of its mistakes in the standard library. std::regex is embarrassing when even Python can beat it and nobody uses std::unordered_map due to its pointer chasing. Basic Maps are something that you shouldn't need to use a third party library for.
- ghosty141 2y ago
  Could you explain the issue with unordered_map?
  - lenkite 2y ago
    The standard guarantees that you can get a pointer to an object in the map and this pointer will remain valid after rehashing and insertion/deletion of other elements. That basically forces implementers to use “buckets with linked lists”, also known as separate chaining. This is not cache friendly (and also suffers from excessive allocation). Other hash map implementations like abseil's don't provide this guarantee so they can put everything right there inline, which is much more efficient.