Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SDS: Simple Dynamic Strings library for C

github.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: SDS: Simple Dynamic Strings library for C

#31

Post by anitil »

derefr wrote: post #10
zoddie wrote: post #2

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…

> C++ has a runtime (however minimal)

I'm not familiar with this, are you able to explain it? Do you mean something analogous to _start?

Re: SDS: Simple Dynamic Strings library for C

#32

Post by anitil »

jimbob45 wrote: post #8
zoddie wrote: post #2

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.

Seems like everyone wants to believe they’re as skilled and hardcore as the kernel devs. In reality, I agree - C++ is basically a superset of C and the whole point of “you don’t pay for what you don’t use” is to be able to avoid ridiculous situations like these.

> "you don’t pay for what you don’t use"

In my experience (mostly embedded development) including C++ in a C project adds a lot of build complexity and build time, whereas C99 or C89 is trivial to install in pretty much all situations

Re: SDS: Simple Dynamic Strings library for C

#33

Post by cyber1 »

CyberDildonics wrote: post #29
derefr wrote: post #10

Earlier quoted context omitted.

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…

C++ has a runtime (however minimal); 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 eve…

No, it does. "The only two features in the language that do not follow the zero-overhead principle are runtime type identification and exceptions, and are why most compilers include a switch to turn them off." - https://en.cppreference.com/w/cpp/language/Zero-overhead_pri...

Re: SDS: Simple Dynamic Strings library for C

#34

Post by CyberDildonics »

cyber1 wrote: post #33
CyberDildonics wrote: post #29

Earlier quoted context omitted.

C++ has a runtime (however minimal); 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 eve…

No, it does. "The only two features in the language that do not follow the zero-overhead principle are runtime type identification and exceptions, and are why most compilers include a switch to turn them off." - https://en.cppreference.com/w/cpp/language/Zero-overhead_pri...

So saying 'it has a runtime' doesn't really make sense, it has a runtime if you want for two features that aren't necessary.

Re: SDS: Simple Dynamic Strings library for C

#36

Post by aidenn0 »

MontyCarloHall wrote: post #9
zoddie wrote: post #2

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.

To actually answer your question (beyond the snark/appeal to authority replies you’ve already gotten), there are a couple good reasons: — You're working in embedded development (but somehow need a full-fledged dynamic string library). — While it's true that C++ is (almost) a strict superset of C, and “you don’t pay for what you don’t use” is a good rule of thumb, it can be very hard to restrict a team of developers t…

As soon as you move to "C with classes and the STL" you've now also bought into exceptions, as the STL is not even remotely ergonomic with exceptions disabled.

Re: SDS: Simple Dynamic Strings library for C

#37

Post by aidenn0 »

derefr wrote: post #10
zoddie wrote: post #2

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…

C also has a (granted very small on Unix) runtime[1]. On windows the C runtime is a bit larger, since windows processes get a single string for their arguments, which must be parsed into argc/argv.

As far as "you have to also dynamically link the C++ runtime", try calling malloc from two different libc implementations in the same process and see "interesting" things happen. Even more interesting is calling free() on a pointer that was malloc'd from a different C library.

1: E.g. for musl https://git.musl-libc.org/cgit/musl/tree/crt

Re: SDS: Simple Dynamic Strings library for C

#40

Post by welfareleech »

antirez wrote: post #28
jacquesm wrote: post #22

Earlier quoted context omitted.

It might be worth extracting it back out, it seems pretty useful.

Indeed, but in some way the Redis version is a bit too Redis-ish, that is, memory saving concerns are taken to the extreme instead of having a more balanced approach about simplicity. In my YouTube channel C course, I'm showing something similar to SDS in the latest lessons, and I may use SDS again in later course in order to show how to integrate back the useful features that diverged. Maybe an SDS3 maybe a middle g…

This sounds intriguing. Do you have a link to your C course?
Post reply on HN