4 ms·

> In C++ I could always use my own styles / paradigms / patterns etc. etc. That's also one of its major disadvantages, unless you literally rewrite the entire

by est31 4y ago

> In C++ I could always use my own styles / paradigms / patterns etc. etc. That's also one of its major disadvantages, unless you literally rewrite the entire thing when major maintainer changes happen, because otherwise you get a mix of different C++ styles in your codebase which leads to nobody being able to maintain it.

StillBored 4y ago
I don't know, I never got heavily on the C++ inheritance bandwagon when it was popular in the late 1990's early 2000's. Rather preferring aggregation. If you application is actually using the OO parts of the language that way, even without modern C++ its fairly easy to maintain as the different styles/etc area also encapsulated in their classes. Then hopefully the top level is using some kind of message passing interface/whatever to avoid trying to glue everything together into a god class. AKA, there are a few fairly easy to understand rules that allow people to do their own thing without creating a maintainability nightmare even with very large C++ codebases. If an experienced engineer/architect/etc with a track record of successful C++ projects is in charge during the initial application design/etc you should have a fairly maintainable application. I'm not sure this is really a C++ thing though, rather being a general engineering thing. If the main architecture is well thought out and understandable, a lot of sins can be burred in places where they can't create application wide chaos. There are a lot of things that can make C++ applications suck, but you don't tend to hear about the success stories on your favorite board, those systems silently do their job. So many of the things people rail about with C and C++ simply aren't problems when appropriate engineer culture is maintained. AKA, having solid unit tests for most of the base classes being agragated, means that running them under various address sanitizer/etc tools will find the errors that aren't picked up by static analysis tools/etc. Yes, sometimes things sneak by, but i'm not sure there are any languages java/rust/etc that solve that problem completely.
jcelerier 4y ago
> because otherwise you get a mix of different C++ styles in your codebase which leads to nobody being able to maintain it. I'd be really interested in meeting someone who has enough mental flexibility to learn C++ but not enough to accommodate different code styles in a single codebase.
- ncmncm 4y ago
  Yes. It is always easy to see what generation a piece of code is from. Trying to maintain a "consistent style" just amounts to failing to improve. If you are not embarrassed by your old code, you have not learned anything since.
FpUser 4y ago
I rely on 4 libraries in total when doing web apps in C++ (postgres, http, json, logging). Not a single one ever gave me any surprise of the kind. I use other libs of course but those are domain specific and are solving non web problems

by est31 4y ago

StillBored 4y ago

I don't know, I never got heavily on the C++ inheritance bandwagon when it was popular in the late 1990's early 2000's. Rather preferring aggregation. If you application is actually using the OO parts of the language that way, even without modern C++ its fairly easy to maintain as the different styles/etc area also encapsulated in their classes. Then hopefully the top level is using some kind of message passing interface/whatever to avoid trying to glue everything together into a god class. AKA, there are a few fairly easy to understand rules that allow people to do their own thing without creating a maintainability nightmare even with very large C++ codebases. If an experienced engineer/architect/etc with a track record of successful C++ projects is in charge during the initial application design/etc you should have a fairly maintainable application. I'm not sure this is really a C++ thing though, rather being a general engineering thing. If the main architecture is well thought out and understandable, a lot of sins can be burred in places where they can't create application wide chaos. There are a lot of things that can make C++ applications suck, but you don't tend to hear about the success stories on your favorite board, those systems silently do their job. So many of the things people rail about with C and C++ simply aren't problems when appropriate engineer culture is maintained. AKA, having solid unit tests for most of the base classes being agragated, means that running them under various address sanitizer/etc tools will find the errors that aren't picked up by static analysis tools/etc. Yes, sometimes things sneak by, but i'm not sure there are any languages java/rust/etc that solve that problem completely.

jcelerier 4y ago

> because otherwise you get a mix of different C++ styles in your codebase which leads to nobody being able to maintain it. I'd be really interested in meeting someone who has enough mental flexibility to learn C++ but not enough to accommodate different code styles in a single codebase.

ncmncm 4y ago
Yes. It is always easy to see what generation a piece of code is from. Trying to maintain a "consistent style" just amounts to failing to improve. If you are not embarrassed by your old code, you have not learned anything since.

FpUser 4y ago

I rely on 4 libraries in total when doing web apps in C++ (postgres, http, json, logging). Not a single one ever gave me any surprise of the kind. I use other libs of course but those are domain specific and are solving non web problems