Should C++ be deprecated? [LWN.net]

Should C++ be deprecated?

Posted Sep 18, 2025 16:18 UTC (Thu) by farnz (subscriber, #17727)
In reply to: Should C++ be deprecated? by pizza
Parent article: Comparing Rust to Carbon

IME, regulated spheres don't care whether you get 100 functional components from one library, or whether you use 100 libraries each with one component - they want you to do the compliance burden for each component you use, not for each supplier.

You don't get to avoid doing the paperwork for each unique type/size of screw by saying "they're all from The Phillips Screw Company"; you have to do paperwork for each unique type/size anyway. Similar, IME, applies in software - just because it's all "Qt" doesn't mean that you can avoid doing the paperwork for each component you use.

to post comments

Should C++ be deprecated?

Posted Sep 22, 2025 23:05 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

> IME, regulated spheres don't care whether you get 100 functional components from one library, or whether you use 100 libraries each with one component - they want you to do the compliance burden for each component you use, not for each supplier.

Not sure what the exact extend of "regulated spheres" is but here at $BIGCORP there is definitely some amount of per-supplier work. How could the compliance process not care about the supplier at all?

> You don't get to avoid doing the paperwork for each unique type/size of screw by saying "they're all from The Phillips Screw Company"; you have to do paperwork for each unique type/size anyway

You can at least copy/paste the supplier information, that's much less work that researching 100 different suppliers.

Should C++ be deprecated?

Posted Sep 23, 2025 8:18 UTC (Tue) by farnz (subscriber, #17727) [Link]

For some regulated processes, the compliance process does not care about the supplier at all. Instead, we have to show that every line of code available to the build system is (a) approved by a named employee of the company using the code, and (b) that there is a process to ensure that no changes are made to that code without a named employee of the company using the code approving it. This implies that when we update a dependency, we're having to take a diff between the two versions, and audit the changes line-by-line as well as in context, just as you do for new code from within the company.

And 100 small libraries does not have to imply 100 suppliers - Qt, for example, is 59 libraries from one supplier. And because it's 59 libraries, instead of having to review all of Qt if we pull it into the regulated system, we only have to review the Qt libraries we use - maybe 2 or 3, instead of 59.