21–30 of 48 posts
Why not just use C++ strings and string_views? So weird to see this masochistic obsession some people have with doing everything in plain C. It's 2026, there are better, more memory safe, more efficient solutions out there.
Hi! The Redis tree contains more advanced versions of this library. Most of the development continued there, eventually.
Why not just use C++ strings and string_views? So weird to see this masochistic obsession some people have with doing everything in plain C. It's 2026, there are better, more memory safe, more efficient solutions out there.
I switched to C because I could not stand the pain of using C++ anymore. I find C refreshingly simple. (Also, as a comment to other responses: C++ is not a superset of C, it is a fork from 95 with divergent language evolution since then).
Hi! The Redis tree contains more advanced versions of this library. Most of the development continued there, eventually.
Simple Dynamic Strings library for C, compatible with null-terminated strings - https://news.ycombinator.com/item?id=21692400 - Dec 2019 (83 comments)
Simple Dynamic Strings library for C - https://news.ycombinator.com/item?id=7190664 - Feb 2014 (127 comments)
Earlier quoted context omitted.
I switched to C because I could not stand the pain of using C++ anymore. I find C refreshingly simple. (Also, as a comment to other responses: C++ is not a superset of C, it is a fork from 95 with divergent language evolution since then).
It is not a fork from 95. Cfront, the original C++ compiler was a new front-end for the C compiler from 1983 that output C which was then compiled regularly. https://en.wikipedia.org/wiki/Cfront
Hi! The Redis tree contains more advanced versions of this library. Most of the development continued there, eventually.
Oh, and redis. That too. :)
Hi! The Redis tree contains more advanced versions of this library. Most of the development continued there, eventually.
It might be worth extracting it back out, it seems pretty useful.
Why not just use C++ strings and string_views? So weird to see this masochistic obsession some people have with doing everything in plain C. It's 2026, there are better, more memory safe, more efficient solutions out there.
If your code is plain C, then anyone can extend it with, or embed it inside, code of literally any other language; and in so doing, they will have full access/exposure to everything in your codebase — all the same stuff that they would if they were writing their host/extension code in C. This is not true of C++ (or most other languages): • C++ has a runtime (however minimal); and so, by including any C++ code in a co…
No it doesn't.
Also, even if there was no associated runtime to deal with, C++ isn't wholly C-FFI-clean
Yes it is, you just extern "C" whatever you want.
All the stuff that people like about C++ — all the reasons you'd want to use C++ — result in codebases that aren't cleanly C-FFI exposable
Not true at all, the biggest two things, destructors and move semantics you still have everywhere except for the boundaries with C.
And even if you bite that bullet, and write your library in C++ but carefully wrap its API to give it C-FFI-clean linkage (usually via a hybrid C / C++ project), this still introduces a layer of FFI runtime overhead
There is no overhead here, it is not different from C.
I don't know where all this comes from, but I doubt it comes from heavy experience with modern C++.
I'm surprised this is aliased to char*, not const char*. The benefit of the aliasing is convenience, but the main risk is absent-mindedly passing it to a libc function that modifies the string without updating the SDS metadata. Const would result in a compiler warning while letting the intended use cases (e.g., the printf example) work fine.