▲ | shultays 7 months ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Do people really say this? Voice this in committee? I have been in a few companies, and one fairly large one, and all are happy to and looking forward to upgrade newer standards and already spend a lot of time updating their build systems. Changing 1% of code on top of that is probably not really that much compared | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | loup-vaillant 7 months ago | parent | next [-] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> Changing 1% of code on top of that is probably not really that much compared Quite a few companies have millions and millions of lines of code. Changing 1% of it would mean changing more than 10K lines of code, perhaps even more than 100K. In much bigger code bases, where changing anything has a risk of breaking something — not just because you might make a mistake, but because your program is full of Undefined Behaviour, and changing anything might manifest latent bugs. Given that, I'm not surprised people say that Sutter quote with a straight face. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | bregma 7 months ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Many of my customers are in an industry with a huge C++ code base and it's all under active development. Safety certification requirements are onerous and lead-times for development are long: many are now experimenting with C++17 and C++20 is on the long-term horizon but not yet a requirement. Because of the safety certification requirements and the fact that the expected lifecycle of the software is the order of decades after their products have been released, changing any lines of their code for any reason is always risky. Lives can be at stake. But this is a multi-billion-dollar industry. If you're working on scripting a little browser "app" for a phone things may be different. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | rwmj 7 months ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
People just don't make mass changes to existing working code. Mostly they cannot. Even if the tooling was available, which it's not, it's also about reeducating their developers, who don't want to or can't change. Plus it'd have to be recertified. It's all cost with no benefit. Except, allegedly, at Google. But is there any evidence they actually do this, eg. in public code bases? Or is it just hype? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | Someone 7 months ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Could be selection bias. Companies (or departments within companies) who are still actively developing their C++ code probably tend to hire more developers and consultants than companies who are doing minimal maintenance on their code base, and that might correlate well with the “two factions of C++” discussed here. “Our code is an asset” ⇒ code kept up-to-date “Our code is a burden, but we need it” ⇒ change averse | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | otabdeveloper4 7 months ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> Changing 1% of code on top of that is probably not really that much compared Changing 1% across all modules is a nightmare. Changing one module which is 1% of the code is nothing. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | MathMonkeyMan 7 months ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A company that I worked at had a few very large C++ related migrations, and they were all very very expensive. The first was removing `long` from the code, since a lot of code assumed its size (is it like `int` or like `long long int`?) and as machines were upgraded it caused problems. The second was moving to C++11/14/17. Most of the difficulty was toolchains on unixen that did not support the new versions of the language, or for which support was incomplete, or for which upgrading to a version with support broke existing builds. The third was moving to Linux from big iron unixen. As far as I understand, this initiative is still underway. It was already underway in 2011 when I joined the company. This is a rich company with a large, healthy engineering department. I imagine that most other companies would not or could not bother. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | Hilift 7 months ago | parent | prev [-] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Are you referring to his book written 20 years ago or 25 years ago? "customers with large [C++] code bases" there aren't that many of these. Vendors, government. With code bases that have stewards, not programmers. |