5 ms·

if no one wants to fix this 20yo codebase, why is there someone who wants to push it to the new C++ standard?

reactordev 1y ago
You have it backwards. Everyone wants a new standard but no one wants to fix the code to make it work with a new way. They would rather introduce a whole new thing. We want new stuff, but in order to do that we must break old stuff. Like breaking old habits, except this one will never die.
- bluGill 1y ago
  we spent a billion dollars to rewrite our code breaking everything. 15 years latter and we have a better product than the old stuff- but 15 years ago was pre c++11, and rust didn't exist. i cannot honestly ask for another billion dollars to repeat that again and we are stuck. We must keep the old code running and if your new thing isn't compatible with whatever we did back then you are off the table. c++26 still builds and runs that c++98 and so we can use it. Rust is nice but it can't interoperate as well in many ways and so it gets little use. you can call that bad desingn - I might even agree - but we are stuck.
  - reactordev 1y ago
    This. This is why C++ is stuck. The effort required to rewrite old shit code (that works, does its job, makes money) is just too valuable to the company so it sits. All vendors must conform or else be shown the door. No innovation can take place so long as Clu has its claws in our company. I empathize. This is where rust could really help but there’s a lot of hate around “new” so it sits. The C++2042 standard will still have to be able to solve for C++98. The language will die. A pointer is a pointer and it shouldn’t need weak_ptr, shared_ptr, unique_ptr etc. If you expose it, it’s shared. If you don’t, then it could be unique but let the compiler decide. The issue with all these additions is they are opt in for a community that would rather opt out since it means learning/rewriting/refactoring. I’ve come across this so many times in my career. Thank goodness for AI and LLMs that can quickly decompose these hairball code bases (just don’t ask it to add to it). I love C/C++ but it’s so old at this point that no sane person should ever start with that.
    - StilesCrisis 1y ago
      If you think the problem with C++ is that shared_ptr exists, you should probably just use C.
      - reactordev 1y ago
        If that is what you take from it, you missed the point entirely. I could care less about shared_ptr. The issue is why should I care? Why is it on the dev to determine how a pointer should work? Why the dev has to go back and refactor old code to be new again? Why can’t the committee build non-breaking changes to the spec? I would rather have compile flags that make a pointer an “old pointer style” vs having to mentally juggle which ptr container to use, when, and why. This is just one example. Gang of 3, becomes gang of 5, becomes mob of state… It’s just a giant mess.
        bluGill 1y ago
        that youieven think a compile flag could switch everything shows how little you understand the problem. it is fine not to understand - it isn't possible to understand everything - but stop talking as if there is an easy problem that would work.
Maken 1y ago
The goal is to be able to import that 20yo battle-tested library into your C++20 codebase and it just works.
- feelamee 1y ago
  there are really a lot of simpler solutions than switching the standard of the whole codebase. E.g. write wrapper which interface doesn't require a new standard.
  - reactordev 1y ago
    Mmm pimpl’s and acne…
- anon-3988 1y ago
  Hyrum law would dictate that your C++20 now becomes C++11 or whatever is the oldest in the whole chain of dependency.
  - Maken 1y ago
    That's kind of the point of C++'s retro-compatibility: C++20 contains new additions to the C++11 standard. Unless you rely in mistakes in the standard like auto_ptr or faulty atomics, which should be fixed regardless of the C++ standard, your C++11 dependencies are perfectly valid C++20 and do not block the new shiny toys.

You have it backwards. Everyone wants a new standard but no one wants to fix the code to make it work with a new way. They would rather introduce a whole new thing. We want new stuff, but in order to do that we must break old stuff. Like breaking old habits, except this one will never die.

bluGill 1y ago
we spent a billion dollars to rewrite our code breaking everything. 15 years latter and we have a better product than the old stuff- but 15 years ago was pre c++11, and rust didn't exist. i cannot honestly ask for another billion dollars to repeat that again and we are stuck. We must keep the old code running and if your new thing isn't compatible with whatever we did back then you are off the table. c++26 still builds and runs that c++98 and so we can use it. Rust is nice but it can't interoperate as well in many ways and so it gets little use. you can call that bad desingn - I might even agree - but we are stuck.
- reactordev 1y ago
  This. This is why C++ is stuck. The effort required to rewrite old shit code (that works, does its job, makes money) is just too valuable to the company so it sits. All vendors must conform or else be shown the door. No innovation can take place so long as Clu has its claws in our company. I empathize. This is where rust could really help but there’s a lot of hate around “new” so it sits. The C++2042 standard will still have to be able to solve for C++98. The language will die. A pointer is a pointer and it shouldn’t need weak_ptr, shared_ptr, unique_ptr etc. If you expose it, it’s shared. If you don’t, then it could be unique but let the compiler decide. The issue with all these additions is they are opt in for a community that would rather opt out since it means learning/rewriting/refactoring. I’ve come across this so many times in my career. Thank goodness for AI and LLMs that can quickly decompose these hairball code bases (just don’t ask it to add to it). I love C/C++ but it’s so old at this point that no sane person should ever start with that.
  - StilesCrisis 1y ago
    If you think the problem with C++ is that shared_ptr exists, you should probably just use C.
    - reactordev 1y ago
      If that is what you take from it, you missed the point entirely. I could care less about shared_ptr. The issue is why should I care? Why is it on the dev to determine how a pointer should work? Why the dev has to go back and refactor old code to be new again? Why can’t the committee build non-breaking changes to the spec? I would rather have compile flags that make a pointer an “old pointer style” vs having to mentally juggle which ptr container to use, when, and why. This is just one example. Gang of 3, becomes gang of 5, becomes mob of state… It’s just a giant mess.
      - bluGill 1y ago
        that youieven think a compile flag could switch everything shows how little you understand the problem. it is fine not to understand - it isn't possible to understand everything - but stop talking as if there is an easy problem that would work.

Maken 1y ago

The goal is to be able to import that 20yo battle-tested library into your C++20 codebase and it just works.

feelamee 1y ago
there are really a lot of simpler solutions than switching the standard of the whole codebase. E.g. write wrapper which interface doesn't require a new standard.
- reactordev 1y ago
  Mmm pimpl’s and acne…
anon-3988 1y ago
Hyrum law would dictate that your C++20 now becomes C++11 or whatever is the oldest in the whole chain of dependency.
- Maken 1y ago
  That's kind of the point of C++'s retro-compatibility: C++20 contains new additions to the C++11 standard. Unless you rely in mistakes in the standard like auto_ptr or faulty atomics, which should be fixed regardless of the C++ standard, your C++11 dependencies are perfectly valid C++20 and do not block the new shiny toys.