Live data from Hacker News

Simple Dynamic Strings library for C, compatible with null-terminated strings

github.com

81–85 of 85 posts

Re: Simple Dynamic Strings library for C, compatible with null-terminated strings

#81
post #75

Earlier quoted context omitted.

You use sdslen() instead of strlen(). Ditto for everything else. Failure to do so results in subtle bugs.

Then (in my opinion) the library shouldn't advertise itself as compatible with Null terminated C strings, as users will assume that means they can use strlen (or more likely, other functions which use strlen themselves). In a similar system I work on, we have a list of functions (like strlen, Strcat), where we carefully vet every occurrence in the code base. It's annoying but the only way to stop subtle bugs we've fo…

Redis doesn’t really have this problem because its mostly developed by Antirez.

Re: Simple Dynamic Strings library for C, compatible with null-terminated strings

#82
post #76
post #75

Earlier quoted context omitted.

You use sdslen() instead of strlen(). Ditto for everything else. Failure to do so results in subtle bugs.

Then why bother making these strings superficially compatible with C strings? Just printf or am I missing something?

The same reason std::string has the c_str() method. It’s convenient.

Re: Simple Dynamic Strings library for C, compatible with null-terminated strings

#83
post #24

Hi, author here. May make sense to make SDS in perspective given a few comments I'm reading here. 1. Yep, more than "strings" SDS may be consider a library for dynamic buffers, especially from people coming from C++ or higher level languages. However I think that for C, it makes sense to provide a very low level thing like that. 2. In practice, if you see how SDS is used (extensively) inside Redis, it normally models…

> Probably an UTF-32 layer could be implemented on top of that UTF-32 is, in all but extreme niche cases, a supremely wasteful and inefficient way to store and process strings, even in light of the cost of variable-length codepoints. The longest UTF-8 sequence is now four bytes anyway, so UTF-8 is never ever less compact than UTF-32. The only conceivable practical use of UTF-32 is a case where the upper 11 bits are u…

With UTF16, simple string handling code runs faster.

When you're iterating over characters, with UTF8 branch prediction mispredicts all the time. Characters in UTF-8 have random length from 1 to 3 bytes. This might be good for bandwidth, but the tradeoff is slower processing, all modern CPUs have branch prediction hardware, and deep pipelines.

With UTF-16 CPUs predict these branches all the time, surrogate pairs are extremely rare, the rest of languages are 2 bytes/character.

While it's technically possible to optimize UTF-8 with clever programming like manual SIMD, that code gonna be much more complex than just a while or for loop, i.e. more expensive to develop and harder to support.

I think that's the reason why all platforms with rich GUI ecosystem (Windows, OSX, iOS, Android, JavaScript) use UTF-16 almost exclusively.

Re: Simple Dynamic Strings library for C, compatible with null-terminated strings

#84

Earlier quoted context omitted.

This alternative (by me) covers char , int , etc with a compiletime inlined generic api much the same way SDS does strings https://tse.gratis/aArray/ aStr("string"); then aMap aFold aConcat, etc, but aAppend(&array,'\0') needs to be done manually if passing to standard str functions. This is so long* or whatever arrays can have the same interface

Nice. I wrote myself up a quick C++ wrapper just now. Will play with this. Intend to use on embedded/bare-metal systems with no C stdlib, so will have to rip out the printfs and the like.

Wow, sounds neat! Look forward to seeing what you create

Re: Simple Dynamic Strings library for C, compatible with null-terminated strings

#85
post #20

UTF support?

Exactly. You should not name a buffer lib "string", when it does not support the basic unicode operations: case fold, normalize => compare, search. In utf-8 of course. I'm also missing stack allocation support, needed for fast short strings. It should be even included in sdsnew, for len < 128.

For C string library with stack allocation and some Unicode support you can check: https://github.com/faragon/libsrt
Post reply on HN