I don't program in C or defend that language, but each time I read someone complain about the need to manage null-termination and such in C, I wonder if they'd have similar complaints about assembly programming. Sure, C is "higher level" than assembly but only barely? 🤔

#programming #reasoning

@smurthys People complaining usually have something specific in mind. For example, for the null-terminated string, people want pointer + length instead. The proliferation of C APIs accepting null-terminated strings means that even if one writes a custom pointer + length representation, it can't be safely interoperated with those APIs (and this impacts the usability of C++ string_view as well).

@lesley @smurthys Nope. It can be. You just need to provide a C++ header for the consumer to compile in that wraps the C API (or, without C++, the pointer be to a C struct of a pointer and a length, instead of the string itself).

It does require effort to design a good, difficult-to-misuse API, though. C will push you in simple, brittle directions by default.

@scottmichaud @smurthys If a C API only accepts null-terminated strings (no pointer/length version) and I have a string_view, I need to convert that string_view to a std::string to pass it to it safely. This negates the advantage of string_view, and I'd just stick with string in the first place (otherwise, in the worst case, std::string -> string_view -> string round-trip will happen)
@lesley @scottmichaud @smurthys This is why I kept having to tell people who wanted to change string APIs in the standard library that pass to C under the covers to string_view "no"