3 ms·

Is one release really causing so many problems? I thought C++ treated backwards compatibility as a holy thing.

by pornel 4y ago

forgotpwd16 4y ago
It doesn't cause problems as in old things don't work as in it takes time to get advantage of newly introduced ones and replace anything considered deprecated (edit: and rename variables clashing with new keywords).
TonyTrapp 4y ago
From what I can gather, a majority of the problems reported there are new compiler warnings being triggered. Especially if you enable all compiler warnings to catch potential defects, any upgrade to a new compiler version will typically introduce a ton of new warnings that you have to work around. Edit: There are also quite a few deprecation warnings, which are also not errors per se, but nevertheless you'd want to avoid using deprecated stuff of course.
IshKebab 4y ago
It generally does although they have made technically breaking changes in the past (e.g. `auto`). This is the first release I've used where they broke something in actual code I use because of the comparison operator changes. However it was easy to fix and actually it was because whoever wrote it did it wrong. Google also found a breakage that was hiding a bug. So maybe their new stance is "only break incorrect code"? I dunno. I feel like a small amount of breakage is reasonable anyway. Breaking change absolutionists are generally just being dogmatic, and haven't really thought through what zero breaking changes really implies. E.g. in languages with introspection it technically means you can't change anything.
- pjmlp 4y ago
  They also broke the code of the few users that made use of exception specifications.
pjmlp 4y ago
All languages break backwards compatibility, just not to the extent of Python 3. Heck even Go folks are discovering their stable guarantee isn't as stable as they thought.
- kardianos 4y ago
  Re Go, sure, but most (all?) of those have to do with security updates that may impact features. The discussion is how to make them less painful or opt-in/out in the standard library. None of this has to do with the language itself.
  - pjmlp 4y ago
    A break is a break, regardless of the cause.
    - kardianos 4y ago
      No. There is a practical difference between a language break and a package break (even in the standard library). There is a practical different difference between a break due to an explicit security issue and a break due to a design change.
redox99 4y ago
When you have large codebases, everything causes problems. When I worked with Unreal Engine, minor MSVC releases (same C++ standard, same everything, just going from lets say 17.0 to 17.1) would sometimes make the code not compile anymore. Either because of new MSVC bugs, or because of incorrect code that was previously allowed.

Is one release really causing so many problems? I thought C++ treated backwards compatibility as a holy thing.

by pornel 4y ago

Is one release really causing so many problems? I thought C++ treated backwards compatibility as a holy thing.

It doesn't cause problems as in old things don't work as in it takes time to get advantage of newly introduced ones and replace anything considered deprecated (edit: and rename variables clashing with new keywords).

TonyTrapp 4y ago

From what I can gather, a majority of the problems reported there are new compiler warnings being triggered. Especially if you enable all compiler warnings to catch potential defects, any upgrade to a new compiler version will typically introduce a ton of new warnings that you have to work around. Edit: There are also quite a few deprecation warnings, which are also not errors per se, but nevertheless you'd want to avoid using deprecated stuff of course.

IshKebab 4y ago

It generally does although they have made technically breaking changes in the past (e.g. `auto`). This is the first release I've used where they broke something in actual code I use because of the comparison operator changes. However it was easy to fix and actually it was because whoever wrote it did it wrong. Google also found a breakage that was hiding a bug. So maybe their new stance is "only break incorrect code"? I dunno. I feel like a small amount of breakage is reasonable anyway. Breaking change absolutionists are generally just being dogmatic, and haven't really thought through what zero breaking changes really implies. E.g. in languages with introspection it technically means you can't change anything.

pjmlp 4y ago
They also broke the code of the few users that made use of exception specifications.

pjmlp 4y ago

All languages break backwards compatibility, just not to the extent of Python 3. Heck even Go folks are discovering their stable guarantee isn't as stable as they thought.

kardianos 4y ago
Re Go, sure, but most (all?) of those have to do with security updates that may impact features. The discussion is how to make them less painful or opt-in/out in the standard library. None of this has to do with the language itself.
- pjmlp 4y ago
  A break is a break, regardless of the cause.
  - kardianos 4y ago
    No. There is a practical difference between a language break and a package break (even in the standard library). There is a practical different difference between a break due to an explicit security issue and a break due to a design change.

redox99 4y ago

When you have large codebases, everything causes problems. When I worked with Unreal Engine, minor MSVC releases (same C++ standard, same everything, just going from lets say 17.0 to 17.1) would sometimes make the code not compile anymore. Either because of new MSVC bugs, or because of incorrect code that was previously allowed.