On Thu, Sep 25, 2025 at 7:39 AM Andrzej Krzemienski via Boost <boost@lists.boost.org> wrote:
For example:
void foo(cstring_view value) { c_foo(value.c_str()); }
foo("very long string");
Would calculate the strlen for no reason.
That doesn't mean the cstring_view shouldn't calculate the size, I am just saying that my cstring_ref written specifically for this one use-case doesn't keep a size on purpose.
This is a very important observation. One "optimal" implementation of a null-terminated string_view may not be achievable.
Wouldn't adding an array constructor resolve the problem? template <size_t N> cstring_view(const char (&str)[N]); Keeping size as a member seems redundant, since we only use this type in an interface for two purposes: first, to make it explicit that the arguments require a null-terminated string, which also improves documentation, and second, to check the invariant that the passed string is indeed null-terminated. In practice, we just pass instances of this type as const char* to a C-API style interface that does not take a length. So what would be the use case for an O(1) size() access? Also, most use cases for null-terminated strings involve small strings, otherwise, the C-API would likely have taken a length parameter as well.