Comment by MontyCarloHall
6 months ago
To actually answer your question (beyond the snark/appeal to authority replies you’ve already gotten), there are a couple good reasons:
— You're working in embedded development (but somehow need a full-fledged dynamic string library).
— While it's true that C++ is (almost) a strict superset of C, and “you don’t pay for what you don’t use” is a good rule of thumb, it can be very hard to restrict a team of developers to eschew all that complexity you dearly pay for and treat C++ as “C with classes and the STL.” Without very strict coding standards (and a means of enforcing them), letting a team of developers use C++ is often opening a Pandora's Box of complex, obscure language features. Restricting a project to plain old C heads that off at the pass.
> You're working in embedded development (but somehow need a full-fledged dynamic string library).
The situation isn't all that implausible: e.g., many ESP32-based devices want to work with strings to interface with HTTP servers, and they do have C++ support, but the size limit is small enough that you can easily bump your head into it if you aren't careful.
Or anything processing JSON— it's nice to be able to get string views directly into the original payload without having to copy them into fixed size buffers elsewhere.
> and the STL
Even this has a lot of "payment" for what you don't use. Even some C++ libraries forbid it just because of the size of debug symbols.
As soon as you move to "C with classes and the STL" you've now also bought into exceptions, as the STL is not even remotely ergonomic with exceptions disabled.