> If, to use it, you need C++, it's a C++ system, period. If parts are in C, that is an implementation detail
C and C++ are different languages, you can't necessarily treat a codebase of mixed C and C++ as if it were written entirely in C++.
This isn't purely academic, either. For a long time the MSVC compiler had pretty good C++ language support but surprisingly poor C support, which inconvenienced some folks.
> modernizing those to C++ would make them more robust and probably faster
I agree that adopting C++'s insistence on explicit type conversions is a good move for C codebases. I'd be surprised if performance were improved by reworking a C codebase to get it to compile as C++, though.
You can, in fact, compile the C code with a C++ compiler, given trivial adjustments. Adopting "explicit type conversions" would have similarly trivial results. The benefits would come from leaning into higher-level organization.
C++ code going faster than the C is routine. It doesn't come without activity, but the activity yields a more maintainable system, so is commonly done.
MSVC's C compiler only recognized C90. It was generally easier to make your C99 code compile as C++ than to backport it to C90.
C and C++ are different languages, you can't necessarily treat a codebase of mixed C and C++ as if it were written entirely in C++.
This isn't purely academic, either. For a long time the MSVC compiler had pretty good C++ language support but surprisingly poor C support, which inconvenienced some folks.
> modernizing those to C++ would make them more robust and probably faster
I agree that adopting C++'s insistence on explicit type conversions is a good move for C codebases. I'd be surprised if performance were improved by reworking a C codebase to get it to compile as C++, though.