A concept-centered standard library for C++20, enabling safer and more reliable products and a more modern feel for C++ code.; Also home of Subdoc the code-documentation generator.
Currently some of them take const char& to present a non-null pointer to a NUL-terminated string. But that's weird and kinda wrong. We can use assume if we'd like or nonnull attributes.
Some others take const char*, which is more normal for C code, but maybe we can do better with a char slice/string_view?
The majority of callers just pass a string literal, making it more expensive in those cases would be poor form.
But a string literal is an array, not just a pointer, so the length is known. So we could receive that. Or a type that can be converted from that, as well as from stuff like std::string, which we sometimes create from fmt::format()?
Related to https://github.com/chromium/subspace/issues/326 but in this case we don't need to bottom out in a C lib function that expects a NUL terminator. We can just puts(each_char) in a loop or whatever.
Currently some of them take const char& to present a non-null pointer to a NUL-terminated string. But that's weird and kinda wrong. We can use assume if we'd like or nonnull attributes.
Some others take const char*, which is more normal for C code, but maybe we can do better with a char slice/string_view?
The majority of callers just pass a string literal, making it more expensive in those cases would be poor form.
But a string literal is an array, not just a pointer, so the length is known. So we could receive that. Or a type that can be converted from that, as well as from stuff like std::string, which we sometimes create from
fmt::format()?Related to https://github.com/chromium/subspace/issues/326 but in this case we don't need to bottom out in a C lib function that expects a NUL terminator. We can just
puts(each_char)in a loop or whatever.