5 ms·

The thing I want most is for them to deprecate misfeatures. C++ code can be impenetrable as the language is so large and complex.

TillE 10y ago
I never, ever hear this as a priority from fellow C++ programmers. It's always just on HN. If you're actually working with C++, old "misfeatures" simply aren't something which gets in your way very often. You can just code in the modern way and be happy.
- Doctor_Fegg 10y ago
  But if you're not already working with C++, just trying to learn it, it does make C++ harder to pick up.
- daurnimator 10y ago
  Not everything is a new cleanly constructed codebase. I regularly have to jump into and fix/debug existing C++ projects. Often issues are due to accidental interaction between poorly understood features, or a misunderstanding of what a given syntax/idiom does. Every feature/syntax added to C++ is one more place mistakes can happen, and one more thing to watch out for when debugging. I wish there was someone in a position of C++ power pushing to remove a feature for each one added.
  - DougBTX 10y ago
    > Not everything is a new cleanly constructed codebase. This is true, in lots of ways. Lots of code is rushed, corners cut, so was bad the moment it was written. Other code is written in a particular style, and would need to be cleaned up to match a more modern style. One benefit of backwards compatibility within one language is that these pieces of code can be improved incrementally, without having to switch languages. So, a road to improvement, rather than a source of mistakes. The key is to make the new code better than the old code!
  - gpderetta 10y ago
    And for those existing multi-milion line projects, which are often decades old, you certanly do noy want to break backward compatibility. Ever. It is fine to deprecate small warts if there is an obvious semiautomated path forward or if are hardly used (auto_ptr, trigraphs), but things like ADL are very unlikely to be ever fixed completely.
    - tomjakubowski 10y ago
      > And for those existing multi-milion line projects, which are often decades old, you certanly do noy want to break backward compatibility. Ever. I don't see what's inherently wrong with deprecating and then removing features or standard library templates in newer standards. As long as compilers and library implementations continue to support the old features when you ask for an old standard (by passing `-std=c++11` or whatever), what's the problem if C++26 removes $BAD_FEATURE? The standards committee doesn't seem to think there's an absolute problem with removing features or standard library templates, because they've already removed trigraphs, auto_ptr, and more in C++17.
      - gpderetta 10y ago
        Those multimilion lines of code are not just legacy codebases, they are often continuously updated and slowly dragged in the 21st century by using more modern idioms and embracing newers standards. If c++11 and 14 had significant compatibility breaks, they wouldn't have had the uptake they did and would have split the community. It is not just a theoretical issue btw, unfortunately compatibility breaks do happen outside the standard, especially during the early to mid 2000s as compilers started enforcing the standard more closely; enforcing two phase lookup has been particularly painful and I don't think anybody is willing to repeat that experience very soon; there are still codebases stuck on Visual Studio 6 which was infamous for its nonconformance [1] and was widely popular in the late 90s till the early 2000s. [1] to be fair it parially predates the standard.
        FreezerburnV 10y ago
        Theoretically you could remove features by deprecating them (with warning) for a specific c++xx version, and removing them in the next. So if c++14 warned on some $BAD_FEATURE, and then $BAD_FEATURE was removed in c++17, there is still a migration path from c++11 to c++14, and eventually c++17 once all deprecation warnings are removed. (or even before, if someone wants to take the time to remove any remaining warnings in one shot) If the compilers were then able to support the exact set of warnings/removals per version by a flag, old codebased would continue to compile and theoretically would continue to move into more modern features as the next version would never actually break the code. Probably would be nasty to maintain for the compiler developers though. Imagine having to do a bugfix for c++11 mode when you just released c++26 mode.
- koja86 10y ago
  Well, yes. Unless you happen to work with mammoth size legacy C++ code-base which due to C++ being 30+ years old and prevalent mindset about technical debt I assume is the norm.
- lmm 10y ago
  That's because the people who can't stand to deal with those things have found a way to stop writing C++. The rump of programmers still working in C++ are those who didn't care as much.
  - koja86 10y ago
    Is it to be interpreted that you switched to some other language and ended up being more happy using it? Willing to share any tips?
    - lmm 10y ago
      I did a limited amount of C++ some years ago - it was never my primary language, but there was a time when my primary stack was Python with C++ extensions. I'm a full-time Scala developer these days and love the language - it's concise and expressive, with a powerful type system (I guess C++ template metaprogramming is probably as powerful, but Scala makes that power practical to use) and reasonable runtime performance.
- codeflo 10y ago
  That's great for you, but unfortunately doesn't match my experience. Large, old codebases tend to become a mix of all "eras" of C++. That's either because old code was never completely reworked, or because newer programmers pick stuff up in the wrong place, for example from an old blog post. The problem then is that some of the advantages of modern C++ are a bit "all or nothing". Just to pick an example, for exception safety in the current sense to really work, basically all of your code has to be written in a certain style, which is something that's really hard to achieve. Maybe that's less of a problem for codebases started after 2011 that have been written in the modern style from the beginning. But given the way the C++ language continues to evolve, my bet is that even those will eventually run into the same problem with whatever new feature is introduced in 2026. There really needs to be a way to deprecate old language features.
  - pjmlp 10y ago
    True, but I also find a mix of all eras on JVM and .NET projects. No language that lives long enough is safe from it.
  - ansible 10y ago
    Maybe that's less of a problem for codebases started after 2011 that have been written in the modern style from the beginning. But given the way the C++ language continues to evolve, my bet is that even those will eventually run into the same problem with whatever new feature is introduced in 2026. There really needs to be a way to deprecate old language features. That's one of the things I think the golang project did right. The gofix tool can be used to update old codebases.
- akavel 10y ago
  The problem is you must keep all those "misfeatures" in the back of your head when trying to code "in the modern way". If you'd really try hard to ignore them, they'll just show up now and then and wreak havoc, sprinkled with some bitter undefined behavior topping. As a related question: I seem to vaguely recall some mention by someone on HN, that somebody is trying to get some kind of "safe/strict blocks" markers into C++ (or some compiler? I have the feeling it was to be MSVCpp?), where "misfeatures"* would be disabled. Is anybody aware of something like this? Or was that just a beautiful dream I had? * -- for some unknown definition of "misfeatures"
  - DennisP 10y ago
    Sounds like someone could make a decent language by just removing all the old misfeatures from C++ and calling it something new. You could argue that anyone who wants that is already on Rust or whatever, but I bet there are plenty of people who like modern C++ and don't necessarily like Rust.
  - akavel 10y ago
    As to the "related question", see answer I got in a related subthread here: https://news.ycombinator.com/item?id=13277071 https://news.ycombinator.com/item?id=13277071 That's probably what created my vague memories.
- tomjakubowski 10y ago
  > I never, ever hear this as a priority from fellow C++ programmers. It's always just on HN. These aren't mutually exclusive groups. I'm a professional C++ programmer posting on HN to say that C++ is terrible, even when you can somehow confine yourself to "modern C++" -- presumably because you're free from legacy code originally written in the 00s, or earlier! C++11 (and to some extent C++14) made C++ less awful, but it's still a turd. And even many of the best features of C++11, like move semantics, are blown away by their equivalents in Rust. By the way, even whenever concepts and concepts finally land (I've given up now), C++ templates are still going to miles behind Rust's trait-based generics in ease of use and readability.
- deleted 10y ago
  [deleted]

TillE 10y ago

I never, ever hear this as a priority from fellow C++ programmers. It's always just on HN. If you're actually working with C++, old "misfeatures" simply aren't something which gets in your way very often. You can just code in the modern way and be happy.

Doctor_Fegg 10y ago
But if you're not already working with C++, just trying to learn it, it does make C++ harder to pick up.
daurnimator 10y ago
Not everything is a new cleanly constructed codebase. I regularly have to jump into and fix/debug existing C++ projects. Often issues are due to accidental interaction between poorly understood features, or a misunderstanding of what a given syntax/idiom does. Every feature/syntax added to C++ is one more place mistakes can happen, and one more thing to watch out for when debugging. I wish there was someone in a position of C++ power pushing to remove a feature for each one added.
- DougBTX 10y ago
  > Not everything is a new cleanly constructed codebase. This is true, in lots of ways. Lots of code is rushed, corners cut, so was bad the moment it was written. Other code is written in a particular style, and would need to be cleaned up to match a more modern style. One benefit of backwards compatibility within one language is that these pieces of code can be improved incrementally, without having to switch languages. So, a road to improvement, rather than a source of mistakes. The key is to make the new code better than the old code!
- gpderetta 10y ago
  And for those existing multi-milion line projects, which are often decades old, you certanly do noy want to break backward compatibility. Ever. It is fine to deprecate small warts if there is an obvious semiautomated path forward or if are hardly used (auto_ptr, trigraphs), but things like ADL are very unlikely to be ever fixed completely.
  - tomjakubowski 10y ago
    > And for those existing multi-milion line projects, which are often decades old, you certanly do noy want to break backward compatibility. Ever. I don't see what's inherently wrong with deprecating and then removing features or standard library templates in newer standards. As long as compilers and library implementations continue to support the old features when you ask for an old standard (by passing `-std=c++11` or whatever), what's the problem if C++26 removes $BAD_FEATURE? The standards committee doesn't seem to think there's an absolute problem with removing features or standard library templates, because they've already removed trigraphs, auto_ptr, and more in C++17.
    - gpderetta 10y ago
      Those multimilion lines of code are not just legacy codebases, they are often continuously updated and slowly dragged in the 21st century by using more modern idioms and embracing newers standards. If c++11 and 14 had significant compatibility breaks, they wouldn't have had the uptake they did and would have split the community. It is not just a theoretical issue btw, unfortunately compatibility breaks do happen outside the standard, especially during the early to mid 2000s as compilers started enforcing the standard more closely; enforcing two phase lookup has been particularly painful and I don't think anybody is willing to repeat that experience very soon; there are still codebases stuck on Visual Studio 6 which was infamous for its nonconformance [1] and was widely popular in the late 90s till the early 2000s. [1] to be fair it parially predates the standard.
      - FreezerburnV 10y ago
        Theoretically you could remove features by deprecating them (with warning) for a specific c++xx version, and removing them in the next. So if c++14 warned on some $BAD_FEATURE, and then $BAD_FEATURE was removed in c++17, there is still a migration path from c++11 to c++14, and eventually c++17 once all deprecation warnings are removed. (or even before, if someone wants to take the time to remove any remaining warnings in one shot) If the compilers were then able to support the exact set of warnings/removals per version by a flag, old codebased would continue to compile and theoretically would continue to move into more modern features as the next version would never actually break the code. Probably would be nasty to maintain for the compiler developers though. Imagine having to do a bugfix for c++11 mode when you just released c++26 mode.
koja86 10y ago
Well, yes. Unless you happen to work with mammoth size legacy C++ code-base which due to C++ being 30+ years old and prevalent mindset about technical debt I assume is the norm.
lmm 10y ago
That's because the people who can't stand to deal with those things have found a way to stop writing C++. The rump of programmers still working in C++ are those who didn't care as much.
- koja86 10y ago
  Is it to be interpreted that you switched to some other language and ended up being more happy using it? Willing to share any tips?
  - lmm 10y ago
    I did a limited amount of C++ some years ago - it was never my primary language, but there was a time when my primary stack was Python with C++ extensions. I'm a full-time Scala developer these days and love the language - it's concise and expressive, with a powerful type system (I guess C++ template metaprogramming is probably as powerful, but Scala makes that power practical to use) and reasonable runtime performance.
codeflo 10y ago
That's great for you, but unfortunately doesn't match my experience. Large, old codebases tend to become a mix of all "eras" of C++. That's either because old code was never completely reworked, or because newer programmers pick stuff up in the wrong place, for example from an old blog post. The problem then is that some of the advantages of modern C++ are a bit "all or nothing". Just to pick an example, for exception safety in the current sense to really work, basically all of your code has to be written in a certain style, which is something that's really hard to achieve. Maybe that's less of a problem for codebases started after 2011 that have been written in the modern style from the beginning. But given the way the C++ language continues to evolve, my bet is that even those will eventually run into the same problem with whatever new feature is introduced in 2026. There really needs to be a way to deprecate old language features.
- pjmlp 10y ago
  True, but I also find a mix of all eras on JVM and .NET projects. No language that lives long enough is safe from it.
- ansible 10y ago
  Maybe that's less of a problem for codebases started after 2011 that have been written in the modern style from the beginning. But given the way the C++ language continues to evolve, my bet is that even those will eventually run into the same problem with whatever new feature is introduced in 2026. There really needs to be a way to deprecate old language features. That's one of the things I think the golang project did right. The gofix tool can be used to update old codebases.
akavel 10y ago
The problem is you must keep all those "misfeatures" in the back of your head when trying to code "in the modern way". If you'd really try hard to ignore them, they'll just show up now and then and wreak havoc, sprinkled with some bitter undefined behavior topping. As a related question: I seem to vaguely recall some mention by someone on HN, that somebody is trying to get some kind of "safe/strict blocks" markers into C++ (or some compiler? I have the feeling it was to be MSVCpp?), where "misfeatures"* would be disabled. Is anybody aware of something like this? Or was that just a beautiful dream I had? * -- for some unknown definition of "misfeatures"
- DennisP 10y ago
  Sounds like someone could make a decent language by just removing all the old misfeatures from C++ and calling it something new. You could argue that anyone who wants that is already on Rust or whatever, but I bet there are plenty of people who like modern C++ and don't necessarily like Rust.
- akavel 10y ago
  As to the "related question", see answer I got in a related subthread here: https://news.ycombinator.com/item?id=13277071 https://news.ycombinator.com/item?id=13277071 That's probably what created my vague memories.
tomjakubowski 10y ago
> I never, ever hear this as a priority from fellow C++ programmers. It's always just on HN. These aren't mutually exclusive groups. I'm a professional C++ programmer posting on HN to say that C++ is terrible, even when you can somehow confine yourself to "modern C++" -- presumably because you're free from legacy code originally written in the 00s, or earlier! C++11 (and to some extent C++14) made C++ less awful, but it's still a turd. And even many of the best features of C++11, like move semantics, are blown away by their equivalents in Rust. By the way, even whenever concepts and concepts finally land (I've given up now), C++ templates are still going to miles behind Rust's trait-based generics in ease of use and readability.
deleted 10y ago
[deleted]