> Basically most of the complexity I mention comes from memory management. It's just a lot of details to know about and keep in your head. It's the price to pay for the flexibility and power.
That's basically the point: your complain is not really about C++. You're complaining about a computational problem that some programming languages abstract away with a heavy performance tradeoff. Programming languages that allow developers to manage memory will also force developers to think through memory management and object life cycles. This is not a problem caused by or specific to C++. That's the natural consequence of programming computers.
> Actually, I work on a performance sensitive application and it's written in Java and it's a good choice for it, since the performance comes from algorithmic complexity, mostly from asymptotic complexity. A C++ rewrite wouldn't significantly impact the performance of the application.
I'm sorry for being blunt, but if you think performance-sensitive applications stay at the algorithmic complexity level, you are definitely not dealing with a performance-sensitive application. You're just not writing naive code.
To go straight to the point, performance-sensitive applications are applications where low-level details, such as if memory is allocated at all, if an object is copied or not, and if some data is kept in cache, represent critical performance regressions. We're talking about details beyond cache locality, and keeping that cache hot is a critical feature. Algorithms alone don't cut it.
I recommend checking out the talk from Timur Doumler on low-latency C++ to see what I'm referring.
I know very well what it means to care about a memory allocation cost or an atomic operation in a fast path. In some applications though, that is not the dominating performance factor, instead the algorithm dominates. For example, with C++ an manual memory management our application could take something like 58 minutes to run while in Java it would take 60 minutes. The impact of the low level management is entirely insignificant for performance in the big picture in these cases.
The performance comes from the big O complexity. Memory management is a constant factor in the algorithm.
That's basically the point: your complain is not really about C++. You're complaining about a computational problem that some programming languages abstract away with a heavy performance tradeoff. Programming languages that allow developers to manage memory will also force developers to think through memory management and object life cycles. This is not a problem caused by or specific to C++. That's the natural consequence of programming computers.
> Actually, I work on a performance sensitive application and it's written in Java and it's a good choice for it, since the performance comes from algorithmic complexity, mostly from asymptotic complexity. A C++ rewrite wouldn't significantly impact the performance of the application.
I'm sorry for being blunt, but if you think performance-sensitive applications stay at the algorithmic complexity level, you are definitely not dealing with a performance-sensitive application. You're just not writing naive code.
To go straight to the point, performance-sensitive applications are applications where low-level details, such as if memory is allocated at all, if an object is copied or not, and if some data is kept in cache, represent critical performance regressions. We're talking about details beyond cache locality, and keeping that cache hot is a critical feature. Algorithms alone don't cut it.
I recommend checking out the talk from Timur Doumler on low-latency C++ to see what I'm referring.
https://m.youtube.com/watch?v=EzmNeAhWqVs