4 ms·
1. Ditching null termination makes it cumbersome for interoperability with C ecosystem. 2. It has terrible overhead.
by zajio1am 4y ago
1. Ditching null termination makes it cumbersome for interoperability with C ecosystem.
2. It has terrible overhead.
- LegionMammal978 4y ago> All strbuf functions maintain a null terminator at the end of the buffer, and the buffer may be accessed as a regular c string using mybuffer->cstr. So effectively a str_t works like an std::string_view from C++, and strbuf_t works like an inline std::string. To produce a null-terminated string from a section of a longer string requires an allocation, unless you can temporarily modify the original string to replace one of its characters with a terminator.
- zajio1am 4y agoWell, the documentation says that null terminator is maintained at the end of the buffer (i.e. mybuffer->cstr[mybuffer->capacity - 1]), not at the end of the string stored in the buffer (i.e. mybuffer->cstr[mybuffer->size]).
- LegionMammal978 4y agoNot sure where you're getting that interpretation from. If you look at the actual code, it sets buf->cstr[buf->size] = 0 every time the string is resized. After all, what else could "the buffer may be accessed as a regular c string" possibly mean?
- zajio1am 4y ago> Not sure where you're getting that interpretation from. That is just plain reading of "null terminator at the end of the buffer", as 'buffer' is just place in memory, regardless of what is stored in it. 'End of the buffer' is commonly used for end of such reserved memory, not end of valid data in that memory. But maintaining the null-terminated string in the buffer is much more useful behavior than just maintaining null terminator at the end of the buffer, so it is likely just sloppiness in the documentation.