←back to thread

40 points coneonthefloor | 2 comments | | HN request time: 0.627s | source
Show context
o11c ◴[] 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 #
remexre ◴[] No.44610524[source]
How would you recommend doing that sort of "subtyping"? _Generic and macros?
replies(1): >>44611063 #
o11c ◴[] 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 #
improgrammer007 ◴[] 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 #
1. vlovich123 ◴[] No.44611802[source]
Following that argument, c++ is also a colossal waste of time and energy and bugs when compared with Rust :D.
replies(1): >>44613569 #
2. pjmlp ◴[] No.44613569[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.