←back to thread

Making a StringBuffer in C, and questioning my sanity

(briandouglas.ie)
42 points coneonthefloor | 8 comments | 15 Jul 25 10:48 UTC | HN request time: 1.241s | source | bottom
Show context
o11c ◴[18 Jul 25 21:22 UTC] No.44609974[source]▶
Hm, this implementation seems allergic to passing types by value, which eliminates half of the allocations. It also makes the mistake of being mutable-first, and provides some fundamentally-inefficient operations.

The main mistake that this makes in common with most string implementations make is to only provide a single type, rather than a series of mostly-compatible types that can be used generically in common contexts, but which differ in ways that sometimes matter. Ownership, lifetime, representation, etc.

replies(4): >>44610524 #>>44610702 #>>44611230 #>>44611895 #
1. remexre ◴[18 Jul 25 22:34 UTC] No.44610524[source]▶
How would you recommend doing that sort of "subtyping"? _Generic and macros?
replies(1): >>44611063 #
2. o11c ◴[18 Jul 25 23:39 UTC] No.44611063[source]▶
Yup. It's a lot saner in C++, but people who refuse to use C++ for political reasons can do it the ugly way using C11 or GNU C.
replies(2): >>44611135 #>>44613588 #
3. improgrammer007 ◴[18 Jul 25 23:51 UTC] No.44611135[source]▶
They even downvote people who suggest C++ :-). Doing this in C is such a colossal waste of time and energy, not to mention the bugs it'll introduce. Sigh!
replies(2): >>44611260 #>>44611802 #
4. zahlman ◴[19 Jul 25 00:10 UTC] No.44611260{3}[source]▶
Trolling about the choice of implementation language from a throwaway account is worth downvotes, yes. Doing a given task in a given language, simply for the sake of having it done in that language, is a legitimate endeavour, and having someone document (from personal experience) why it's difficult in that language is real content worth discussion. Choosing a better language is very much not a goal here.

> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

5. vlovich123 ◴[19 Jul 25 01:46 UTC] No.44611802{3}[source]▶
Following that argument, c++ is also a colossal waste of time and energy and bugs when compared with Rust :D.
replies(1): >>44613569 #
6. pjmlp ◴[19 Jul 25 08:13 UTC] No.44613569{4}[source]▶
Eventually, when Rust finally catches up with C++ ecosystem, including being used in industry standards like Khronos APIs, CUDA, console devkits, HPC and HFT standards.

Until then, the choice is pretty much between C and C++, and the latter provides a much saner and safer alternative, than a language that keeps pretending to be portable macro assembler.

7. uecker ◴[19 Jul 25 08:17 UTC] No.44613588[source]▶
"political reasons"?

I switched from C++ to C because C++ is too complex and dealing with this complexity was stealing my time. I would not call this a "political reason".

replies(1): >>44615694 #
8. ◴[19 Jul 25 14:23 UTC] No.44615694{3}[source]▶