5 ms·

Of course since the old syntax is merely deprecated and not removed, going forward you now have to know the old, bad form and the new, good form in order to rea

Of course since the old syntax is merely deprecated and not removed, going forward you now have to know the old, bad form and the new, good form in order to read code. Backwards compatibility is a strength but also a one-way complexity ratchet. At least they managed to kill `auto_ptr`.

Conscat 7mo ago
PyCuda 2024, used fairly often in certain industries, still contains `auto_ptr` ;-;
hrmtst93837 7mo ago
[flagged]
- tialaramex 7mo ago
  Several times now C++ enthusiasts and indeed the committee have been told the way forward is the "Subset of a superset" that is, Step 1. Add a few new things to C++ and then Step 2. Remove old things to make the smaller, better language they want. Once they've obtained permission to do Step 1 they can add whatever they want, and in a few years for them it's time to repeat "Subset of a superset" again and get permission for Step 1 again. There is no Step 2, it's embarrassing that this keeps working.
vlovich123 7mo ago
I think Rust has shown a way to remove deprecated interfaces while retaining back compat - automated tooling to migrate to the next version and give a few versions for a deprecated interfaces to stick around at the source level.
- jjmarr 7mo ago
  C++ almost never removes features because of the ABI compatibility guarantees. Programs compiled with older versions of the standard can be linked against newer versions. This is allegedly because in the 80s companies would write software, fire the programmers, and throw the source code away once it compiled.
  - Sharlin 7mo ago
    Fixing syntax by definition does not affect the ABI. And Rust has shown that both ABI and API compatibility can be achieved in the presence of several "versions" (editions) of the language in the same build.
    - irishcoffee 7mo ago
      Rust has shown that it’s yet another language that kind of sort of addresses 3% of the issues c/c++ has, tops.
      - tialaramex 7mo ago
        I really don't like C++ but it's hard to come up with thirty-odd times as many other terrible problems as the ones Rust addresses.
      - saghm 7mo ago
        Probably because like 95% of C++'s issues are self-inflicted and don't need to be addressed if you use a different language in the first place, and 1% of them are fundamentally unsolvable by any language.
      - vlovich123 7mo ago
        lol. A functions module system that’s easy to use and adopted? A package manager? A well implemented hash table? Fast compile times? Effectively no segfaults? Effectively no memory leaks? Comparatively no race condition bugs? A benchmark and unit test framework baked into the language? Auto optimization of the layout of structs? No UB? I don’t know what you’re counting as “3% of the issues” but if those are the 3%, they sound like massive productivity and safety wins that’s not existed in a language with a similar performance profile to C/C++.
        jjmarr 7mo ago
        Is Rust faster to compile than C++?
- IcyWindows 7mo ago
  Rust is a single vendor. It's not really the same situation.
  - zaphar 7mo ago
    There is a single standard committee though. There is really nothing stopping them from shipping tooling that can do the conversions for people. The number of vendors isn't really the problem here. The problem is that the committee shifts that responsibility onto the vendors of the compiler rather than owning it themselves.
  - vlovich123 7mo ago
    Having multiple compiler vendors is a problem IMO not a feature. It fragments the ecosystem - the code compiles fine with this compiler but not this other one. The maintenance of portable Rust code is significantly easier. I think the way forward is multiple backends (LLVM + GCC) to improve platform support, but a single unified frontend that works correctly on all platforms is a good thing.
- ameliaquining 7mo ago
  If you're talking about editions, this isn't how they work at all; every edition continues to be supported forever. (The part about automated migration tooling is true, and nice.) There've been a few cases where code was unsound and should never have compiled, but did due to compiler bugs, and then they fixed the bugs and the code stopped compiling. These were handled through deprecation warnings with timelines at least several months long (Rust releases a new version every six weeks), but usually didn't have automated migration tooling, and didn't fracture the language mostly because they were rare edge cases that most programmers didn't encounter.
  - vlovich123 7mo ago
    Editions are still allowed to remove old syntax or even remove APIs - they only can’t break ABIs. So the code is still there once removed from an edition in previous editions, but such symbols don’t even get linked if they’re unused supporting progressive removal. And similarly, I could see editions getting completely removed in the future at some point. Eg rather than indefinitely maintaining editions, in 20 years have a checkpoint version of a compiler that supports the previous 20 years of editions and going forward editions older than 10 aren’t in the build (for example, assuming a meaningful maintenance burden, which is hard to predict when that happens and what a specific policy looks like).
    - ameliaquining 7mo ago
      Editions never remove APIs.
      - vlovich123 7mo ago
        Have not yet. There’s nothing stopping them though and from talking with the std folks it seems like they will likely at some point experiment crossing that bridge.
Karliss 7mo ago
I doubt it will be a problem in practice. Regular variadic arguments in general aren't used very often in C++ with exception of printf like functions. Not rare enough for majority of C++ programmers to not know about them, but definitely much more rare than their use in python. Main reason people know about it at all is printf. The "new" C compatible form has been supported since the first ISO standardized version of c++ if not longer. There haven't been a good reason to use the "old" form for a very long time. Which means that the amount of C++ code using deprecated form is very low. Being deprecated means that most compilers and linters will likely add a warning/code fix suggestion. So any maintained project which was accidentally using C incompatible form will quickly fix it. No good reason not to. As for the projects which for some reason are targeting ancient pre ISO standard c++ version they wouldn't have upgraded to newer standard anyway. So if new standard removed old form completely it wouldn't have helped with those projects. So no you don't need to know the old form to read C++ code. And in the very unlikely case you encounter it, the way for accessing variadic arguments is the same for both forms through special va_list/va_arg calls. So if you only know the "new" form you should have a pretty good idea of whats going on there. You might lookup in references what's the deal with missing coma, but other than that it shouldn't be a major problem for reading code. This is hardly going to be the biggest obstacle when dealing with code bases that old.
layer8 7mo ago
The “new” form has been valid since the original 1998 C++ standard, where it was added for compatibility with C. “You now have to know” has therefore already been the case for the past 27 years. Back then the old pre-standard form was kept for backwards compatibility, and is only now being deprecated.
jandrewrogers 7mo ago
The old-style variadics are rarely seen in C++ these days, never mind this particular edge case. If you working in a vaguely modern version of C++ this largely won’t impact you. You can almost certainly ignore this and you’ll be fine. Unless you have a massive legacy code base that is never updated, C++ has become much simpler over time. At a lot companies we made a point of slowly re-factoring old code to a more recent C++ standard (often a couple versions behind the bleeding edge) and it always made the code base smaller, safer, and more maintainable. It wasn’t much work to do this either. To some extent with C++, complexity is a choice.

Conscat 7mo ago

PyCuda 2024, used fairly often in certain industries, still contains `auto_ptr` ;-;

hrmtst93837 7mo ago

[flagged]

tialaramex 7mo ago
Several times now C++ enthusiasts and indeed the committee have been told the way forward is the "Subset of a superset" that is, Step 1. Add a few new things to C++ and then Step 2. Remove old things to make the smaller, better language they want. Once they've obtained permission to do Step 1 they can add whatever they want, and in a few years for them it's time to repeat "Subset of a superset" again and get permission for Step 1 again. There is no Step 2, it's embarrassing that this keeps working.

vlovich123 7mo ago

I think Rust has shown a way to remove deprecated interfaces while retaining back compat - automated tooling to migrate to the next version and give a few versions for a deprecated interfaces to stick around at the source level.

jjmarr 7mo ago
C++ almost never removes features because of the ABI compatibility guarantees. Programs compiled with older versions of the standard can be linked against newer versions. This is allegedly because in the 80s companies would write software, fire the programmers, and throw the source code away once it compiled.
- Sharlin 7mo ago
  Fixing syntax by definition does not affect the ABI. And Rust has shown that both ABI and API compatibility can be achieved in the presence of several "versions" (editions) of the language in the same build.
  - irishcoffee 7mo ago
    Rust has shown that it’s yet another language that kind of sort of addresses 3% of the issues c/c++ has, tops.
    - tialaramex 7mo ago
      I really don't like C++ but it's hard to come up with thirty-odd times as many other terrible problems as the ones Rust addresses.
    - saghm 7mo ago
      Probably because like 95% of C++'s issues are self-inflicted and don't need to be addressed if you use a different language in the first place, and 1% of them are fundamentally unsolvable by any language.
    - vlovich123 7mo ago
      lol. A functions module system that’s easy to use and adopted? A package manager? A well implemented hash table? Fast compile times? Effectively no segfaults? Effectively no memory leaks? Comparatively no race condition bugs? A benchmark and unit test framework baked into the language? Auto optimization of the layout of structs? No UB? I don’t know what you’re counting as “3% of the issues” but if those are the 3%, they sound like massive productivity and safety wins that’s not existed in a language with a similar performance profile to C/C++.
      - jjmarr 7mo ago
        Is Rust faster to compile than C++?
IcyWindows 7mo ago
Rust is a single vendor. It's not really the same situation.
- zaphar 7mo ago
  There is a single standard committee though. There is really nothing stopping them from shipping tooling that can do the conversions for people. The number of vendors isn't really the problem here. The problem is that the committee shifts that responsibility onto the vendors of the compiler rather than owning it themselves.
- vlovich123 7mo ago
  Having multiple compiler vendors is a problem IMO not a feature. It fragments the ecosystem - the code compiles fine with this compiler but not this other one. The maintenance of portable Rust code is significantly easier. I think the way forward is multiple backends (LLVM + GCC) to improve platform support, but a single unified frontend that works correctly on all platforms is a good thing.
ameliaquining 7mo ago
If you're talking about editions, this isn't how they work at all; every edition continues to be supported forever. (The part about automated migration tooling is true, and nice.) There've been a few cases where code was unsound and should never have compiled, but did due to compiler bugs, and then they fixed the bugs and the code stopped compiling. These were handled through deprecation warnings with timelines at least several months long (Rust releases a new version every six weeks), but usually didn't have automated migration tooling, and didn't fracture the language mostly because they were rare edge cases that most programmers didn't encounter.
- vlovich123 7mo ago
  Editions are still allowed to remove old syntax or even remove APIs - they only can’t break ABIs. So the code is still there once removed from an edition in previous editions, but such symbols don’t even get linked if they’re unused supporting progressive removal. And similarly, I could see editions getting completely removed in the future at some point. Eg rather than indefinitely maintaining editions, in 20 years have a checkpoint version of a compiler that supports the previous 20 years of editions and going forward editions older than 10 aren’t in the build (for example, assuming a meaningful maintenance burden, which is hard to predict when that happens and what a specific policy looks like).
  - ameliaquining 7mo ago
    Editions never remove APIs.
    - vlovich123 7mo ago
      Have not yet. There’s nothing stopping them though and from talking with the std folks it seems like they will likely at some point experiment crossing that bridge.

Karliss 7mo ago

I doubt it will be a problem in practice. Regular variadic arguments in general aren't used very often in C++ with exception of printf like functions. Not rare enough for majority of C++ programmers to not know about them, but definitely much more rare than their use in python. Main reason people know about it at all is printf. The "new" C compatible form has been supported since the first ISO standardized version of c++ if not longer. There haven't been a good reason to use the "old" form for a very long time. Which means that the amount of C++ code using deprecated form is very low. Being deprecated means that most compilers and linters will likely add a warning/code fix suggestion. So any maintained project which was accidentally using C incompatible form will quickly fix it. No good reason not to. As for the projects which for some reason are targeting ancient pre ISO standard c++ version they wouldn't have upgraded to newer standard anyway. So if new standard removed old form completely it wouldn't have helped with those projects. So no you don't need to know the old form to read C++ code. And in the very unlikely case you encounter it, the way for accessing variadic arguments is the same for both forms through special va_list/va_arg calls. So if you only know the "new" form you should have a pretty good idea of whats going on there. You might lookup in references what's the deal with missing coma, but other than that it shouldn't be a major problem for reading code. This is hardly going to be the biggest obstacle when dealing with code bases that old.

layer8 7mo ago

The “new” form has been valid since the original 1998 C++ standard, where it was added for compatibility with C. “You now have to know” has therefore already been the case for the past 27 years. Back then the old pre-standard form was kept for backwards compatibility, and is only now being deprecated.

jandrewrogers 7mo ago

The old-style variadics are rarely seen in C++ these days, never mind this particular edge case. If you working in a vaguely modern version of C++ this largely won’t impact you. You can almost certainly ignore this and you’ll be fine. Unless you have a massive legacy code base that is never updated, C++ has become much simpler over time. At a lot companies we made a point of slowly re-factoring old code to a more recent C++ standard (often a couple versions behind the bleeding edge) and it always made the code base smaller, safer, and more maintainable. It wasn’t much work to do this either. To some extent with C++, complexity is a choice.