I don’t really get this argument. Large C++ codebases are generally divided to libraries. The internal libraries and vendor libraries should both be of high quality. I’m not familiar with industrial use cases where every C++ user would not be a library writer.
> The internal libraries and vendor libraries should both be of high quality.
From my limited experience - high-quality internal libraries are simply not the reality; less likely to be achieved than winning the lottery. Companies typically:
* are not able to identify candidates able of writing high-quality C++
* do not try to attract SW engineers by committing to high-quality code.
* don't believe they should invest developer time in making a library more robust, and bringing them to the level of polish of a popular publicly-available FOSS libraries.
* do not have a culture of acquiring, honing and sharing coding skills and expertise, with the help of actual experts. Again, time and effort is mostly not invested in this.
Either you’ve worked with rookie developers (which is fine, but not ’expected industry baseline’) or in an engineering core lacking years of C++ development. Doing stuff ’the right way’ does not generally need extra resourcing - you simply do it the right way.
Quality gaps like described above - I think this happens when you try to develop C++ without actual experience in C++. C++ is so weird anyone trying to ”do the right thing in the language they are most familiar with” generally get it wrong for the first few years. And then you end up with a quagmire nobody wants to volunteer to clean up.
This is not a skill issue as such or lack of talent. C++ simply is so weird and there is so much bad ”professional advice” that you are expected to loose a few limbs before being able to navigate the design landscape full of mines.
> And then you end up with a quagmire nobody wants to volunteer to clean up.
Not only that, but the rookie developers coming in get inculcated into that. That's what they're used to, and they have all the motivation to continue writing poor code, because they need to avoid their better code clashing with what's already written - clashing compilation-wise and style-wise.
Of course, it's not 100% all bad, there are gradual improvements in some aspects by some developers.
No, and they shouldn’t probably. Most internal libraries don’t have and don’t need to implement novel complex template based specialization - not in their API at least. And stuff that’s internal to library needs to only implement the things the API contract requires - which usually does not require the rigmarole of fully generic ’modern’ template based implementation.