4 ms·

> When thinking about backward compatibility... keep in mind that the old code was arguably already broken. There's not a good reason to keep letting it compile

> When thinking about backward compatibility... keep in mind that the old code was arguably already broken. There's not a good reason to keep letting it compile. Oh how I wish the C++ committee and compiler authors would adopt this way of thinking... Sadly we're dealing with an ecosystem where you have to curate your compiler options and also use clang-tidy to avoid even the simplest mistakes :/ Like its insane to me how Wconversion is not the default behavior.

zahlman 1y ago
>Oh how I wish the C++ committee and compiler authors would adopt this way of thinking Many different committees, organizations etc. could benefit, IMO.
motorest 1y ago
> Oh how I wish the C++ committee and compiler authors would adopt this way of thinking... I disagree. If you expect anyone to adopt your new standard revision, the very least you need to do is ensure their code won't break just by flipping s flag. You're talking about production software, many of which has decades worth of commit history, which you simply cannot spend time going through each and every single line of code of your >1M LoC codebase. That's the difference between managing production-grade infrastructure and hobbyist projects.
- johannes1234321 1y ago
  The option there is better tooling, for which the foundation exists which can do such maintenance somewhat automatically, in the simplest case by just adding the Keywords to request old behavior. But the annoyance comes when dealing with multiple compilers and versions. Then you have to add more compatibility macros all over. Say, when being a library vendor trying to support broad range of customers.
  - motorest 1y ago
    > The option there is better tooling (...) The tooling already exists. The bulk of the criticism in this thread is clearly made from a position of ignorance. For example, all major compilers already provide flags to enable checks for uninitialized variables being used. Onboarding a static code analysis tool nowadays requires setting a flag in CMake. These discussions would be constructive if those engaging in them had any experience at all with the language and tooling. But no, it seems the goal is to parrot cliches out of ignorance. Complaining that they don't know what a reserved word means and using that as an argument to rewrite software in other languages is somehow something worth stating.
- dwattttt 1y ago
  > If you expect anyone to adopt your new standard revision, the very least you need to do is ensure their code won't break just by flipping s flag. Why would you expect that a new revision can't cause existing code to compile? It means that "new" revisions can't fix old problems, and one thing you always get more of over time is perspective. If you don't want your code "broken", don't migrate to a new standard. That's the point of supporting old standards. Don't hobble new standards because you both want new things, but don't want old things to change.
  - motorest 1y ago
    > Why would you expect that a new revision can't cause existing code to compile? For staters, because that would violate the goals and prioritites of the C++ as established by the C++ standardization committee. I could go on and on, but it's you who should provide any semblance of rationale: why do you believe existing software should break? What value do you see in it? Does it have any value at all?
    - dwattttt 1y ago
      > why do you believe existing software should break? What value do you see in it? Does it have any value at all? How exactly can a _new_ standard cause existing software compiling on an old standard to break? EDIT: As to the value, I've mentioned elsewhere in this thread; we know a lot more about the practice of programming than when C++ was created and standardised. Why would we say those design decisions can never be questioned or changed? It locks into place choices we never knew were bad, until they caused decades of problems. > that would violate the goals and prioritites of the C++ as established by the C++ standardization committee. Correct. It's these goals and priorities that are being criticised.
- nickysielicki 1y ago
  > You're talking about production software, many of which has decades worth of commit history, which you simply cannot spend time going through each and every single line of code of your >1M LoC codebase. They can keep using the old standard.
  - motorest 1y ago
    > They can keep using the old standard. But they cannot upgrade. Ever. At least without requiring major maintenance work. Which means never. Do you understand what that means?
    - nickysielicki 1y ago
      Every compiler continues to support old standards. What risk am I missing? This feels like a perfectly acceptable outcome for icky legacy code that is not essential enough to maintain.
      - SideQuark 1y ago
        No they don't, not even close. Name a single long running compiler suite that can compile every version it once did.
        nickysielicki 1y ago
        https://gcc.gnu.org/onlinedocs/gcc/Standards.html https://gcc.gnu.org/onlinedocs/gcc/Standards.html Is this inaccurate?
        SideQuark 1y ago
        https://gcc.gnu.org/projects/cxx-status.html https://gcc.gnu.org/projects/cxx-status.html GCC rarely, like never, supports the complete standards. Every release improves conformance, fixes errors, sometimes drops support for targets, perhaps changes how poorly defined areas work. As a result, likely no version compiles code the same as a previous version across all possible code. You’ll also note GCC doesn’t likely compile the variants of C++ it did before the 1998 version. And this type of page is just the tip of the iceberg https://gcc.gnu.org/gcc-13/porting_to.html https://gcc.gnu.org/gcc-13/porting_to.html. You’ll note changes made that can render previously compilable code no longer compilable. So no, you cannot naively think a new compiler version will simply run all your old code. On big projects upgrading is a huge endeavor to minimize problems. We could do every supported language the same way.
- mystified5016 1y ago
  Python seems to still be pretty popular despite breaking most extant code with language updates
monkeyelite 1y ago
And the cost of this is that every time I open a project in another language it’s broken and I have to make changes to fix all their little breaking changes.

zahlman 1y ago

>Oh how I wish the C++ committee and compiler authors would adopt this way of thinking Many different committees, organizations etc. could benefit, IMO.

motorest 1y ago

> Oh how I wish the C++ committee and compiler authors would adopt this way of thinking... I disagree. If you expect anyone to adopt your new standard revision, the very least you need to do is ensure their code won't break just by flipping s flag. You're talking about production software, many of which has decades worth of commit history, which you simply cannot spend time going through each and every single line of code of your >1M LoC codebase. That's the difference between managing production-grade infrastructure and hobbyist projects.

johannes1234321 1y ago
The option there is better tooling, for which the foundation exists which can do such maintenance somewhat automatically, in the simplest case by just adding the Keywords to request old behavior. But the annoyance comes when dealing with multiple compilers and versions. Then you have to add more compatibility macros all over. Say, when being a library vendor trying to support broad range of customers.
- motorest 1y ago
  > The option there is better tooling (...) The tooling already exists. The bulk of the criticism in this thread is clearly made from a position of ignorance. For example, all major compilers already provide flags to enable checks for uninitialized variables being used. Onboarding a static code analysis tool nowadays requires setting a flag in CMake. These discussions would be constructive if those engaging in them had any experience at all with the language and tooling. But no, it seems the goal is to parrot cliches out of ignorance. Complaining that they don't know what a reserved word means and using that as an argument to rewrite software in other languages is somehow something worth stating.
dwattttt 1y ago
> If you expect anyone to adopt your new standard revision, the very least you need to do is ensure their code won't break just by flipping s flag. Why would you expect that a new revision can't cause existing code to compile? It means that "new" revisions can't fix old problems, and one thing you always get more of over time is perspective. If you don't want your code "broken", don't migrate to a new standard. That's the point of supporting old standards. Don't hobble new standards because you both want new things, but don't want old things to change.
- motorest 1y ago
  > Why would you expect that a new revision can't cause existing code to compile? For staters, because that would violate the goals and prioritites of the C++ as established by the C++ standardization committee. I could go on and on, but it's you who should provide any semblance of rationale: why do you believe existing software should break? What value do you see in it? Does it have any value at all?
  - dwattttt 1y ago
    > why do you believe existing software should break? What value do you see in it? Does it have any value at all? How exactly can a _new_ standard cause existing software compiling on an old standard to break? EDIT: As to the value, I've mentioned elsewhere in this thread; we know a lot more about the practice of programming than when C++ was created and standardised. Why would we say those design decisions can never be questioned or changed? It locks into place choices we never knew were bad, until they caused decades of problems. > that would violate the goals and prioritites of the C++ as established by the C++ standardization committee. Correct. It's these goals and priorities that are being criticised.
nickysielicki 1y ago
> You're talking about production software, many of which has decades worth of commit history, which you simply cannot spend time going through each and every single line of code of your >1M LoC codebase. They can keep using the old standard.
- motorest 1y ago
  > They can keep using the old standard. But they cannot upgrade. Ever. At least without requiring major maintenance work. Which means never. Do you understand what that means?
  - nickysielicki 1y ago
    Every compiler continues to support old standards. What risk am I missing? This feels like a perfectly acceptable outcome for icky legacy code that is not essential enough to maintain.
    - SideQuark 1y ago
      No they don't, not even close. Name a single long running compiler suite that can compile every version it once did.
      - nickysielicki 1y ago
        https://gcc.gnu.org/onlinedocs/gcc/Standards.html https://gcc.gnu.org/onlinedocs/gcc/Standards.html Is this inaccurate?
        SideQuark 1y ago
        https://gcc.gnu.org/projects/cxx-status.html https://gcc.gnu.org/projects/cxx-status.html GCC rarely, like never, supports the complete standards. Every release improves conformance, fixes errors, sometimes drops support for targets, perhaps changes how poorly defined areas work. As a result, likely no version compiles code the same as a previous version across all possible code. You’ll also note GCC doesn’t likely compile the variants of C++ it did before the 1998 version. And this type of page is just the tip of the iceberg https://gcc.gnu.org/gcc-13/porting_to.html https://gcc.gnu.org/gcc-13/porting_to.html. You’ll note changes made that can render previously compilable code no longer compilable. So no, you cannot naively think a new compiler version will simply run all your old code. On big projects upgrading is a huge endeavor to minimize problems. We could do every supported language the same way.
mystified5016 1y ago
Python seems to still be pretty popular despite breaking most extant code with language updates

monkeyelite 1y ago

And the cost of this is that every time I open a project in another language it’s broken and I have to make changes to fix all their little breaking changes.