Type-safe generic data structures in C
31–40 of 57 posts
Re: Type-safe generic data structures in C
#32A much more simple alternative way of doing this is to use stretchy buffers. Here's an example of a dynamic array in C in about 20 lines: http://nothings.org/stb/stretchy_buffer.txt And here's a friendly explanation of how this technique works: https://ourmachinery.com/post/minimalist-container-library-i...
> if (p) {
Do you want me to have an embolism?
Re: Type-safe generic data structures in C
#33Author here. I wish I had made it clearer that the intent of the post was "this is an interesting and surprising thing you can achieve in C" and not "this is a good idea for a real software project" or "this is a reason to use C instead of C++/Rust/Go".
thanks, because from my experience edgy first year comp.sci. students will see that article and be like "see ! we don't need anything more than C!"
Re: Type-safe generic data structures in C
#34Why would anyone use this when there is C++, Rust, etc? Genuinely curious.
I favor the CTL over the STL anytime, because it compiles much faster, is much smaller, no indirect vtable calls, no bloated god objects, has no magic hooks attached, like dereferencing refs and ops, is clear on stack vs heap allocation. The downside of course is that generics and iterators on those are a bit more troublesome, only compiler dependent goodies (mostly only clang, not gcc), like overloads or constexpr.…
source ? at least for performance, it seems that there's not a lot of difference from your own link:
https://raw.githubusercontent.com/rurban/ctl/master/docs/ima...
and with the stl you don't have to call
vec_int_free(&a);
manually so I have a hard time seeing how this solution is more secureRe: Type-safe generic data structures in C
#35One of these things is not like the others. I never understood why Go, being a garbage collected language, is grouped with systems programming languages like C or Rust. If anything its direct competitors performance/productivity-wise are probably C# or Java.
Re: Type-safe generic data structures in C
#36>The rise of a new generation of low-level programming languages like Rust, Go and Zig has caused C and its primitive type system to fall into some disrepute. One of these things is not like the others. I never understood why Go, being a garbage collected language, is grouped with systems programming languages like C or Rust. If anything its direct competitors performance/productivity-wise are probably C# or Java.
Re: Type-safe generic data structures in C
#37>The rise of a new generation of low-level programming languages like Rust, Go and Zig has caused C and its primitive type system to fall into some disrepute. One of these things is not like the others. I never understood why Go, being a garbage collected language, is grouped with systems programming languages like C or Rust. If anything its direct competitors performance/productivity-wise are probably C# or Java.
Re: Type-safe generic data structures in C
#38>The rise of a new generation of low-level programming languages like Rust, Go and Zig has caused C and its primitive type system to fall into some disrepute. One of these things is not like the others. I never understood why Go, being a garbage collected language, is grouped with systems programming languages like C or Rust. If anything its direct competitors performance/productivity-wise are probably C# or Java.
I guess because it calls itself a systems language and GC works fine for most systems programming.
Re: Type-safe generic data structures in C
#39Earlier quoted context omitted.
I favor the CTL over the STL anytime, because it compiles much faster, is much smaller, no indirect vtable calls, no bloated god objects, has no magic hooks attached, like dereferencing refs and ops, is clear on stack vs heap allocation. The downside of course is that generics and iterators on those are a bit more troublesome, only compiler dependent goodies (mostly only clang, not gcc), like overloads or constexpr.…
> C++ templates are ugly, and the STL is very buggy and limited. Also no security and no performance. source ? at least for performance, it seems that there's not a lot of difference from your own link: https://raw.githubusercontent.com/rurban/ctl/master/docs/ima... and with the stl you don't have to call vec_int_free(&a); manually so I have a hard time seeing how this solution is more secure
Major quirks: no proper allocation/resize upfront, when you know how big the resulting vector will be. Also not much help with bulk inserts. (Like a proper set join). The 3 STL's I tested massively overallocate.
Unordered containers allow ranges, iterators from some to some, whilst they are unordered by default. This begs for bugs.
Ranges are pairs? How broken is that? Iters need to be fat and ranges. Starting with a broken design upfront does not help.
Set and hashmaps have to use the slowest datastructures, because they considered better ones as too experimental. Hence no open hashmaps, just chained and rb trees. Their arguments of pointer and iterator stability is just an excuse after this decision. Everybody can work around that, and use open hashmaps and btree's just fine.
How about 3way comparison safety in set? It is not. They just found out recently.
No hashtable security, none. Slow, too big and insecure, how nice is that. 0 out if 3.
No sorted vectors, no small (stack) vectors.
No strings. Better than POSIX C, fine. But still no unicode support and identifier (names) support. How would you search for an international string? With accents and different normalization? You wont find it. Strings are not binary buffers.
Formally verified? Not, just 2 parts out of 20. This would have found the 3way compare problems, or their forward_list problems.
forward_list, one of the most basic datastructures, heavily used since the 50ies in Lisp. So why does lisp still has much better support for it than the STL? Cycle detection, length, shuffle, ...?
The manual free is of course annoying, agreed. Ditto the missing operator overloading, which is even worse. Or default args.
Re: Type-safe generic data structures in C
#40Earlier quoted context omitted.
C is still, I have to imagine, the closest thing we have to a language available for all platforms that exist today, while C++ is heavily burdened with featuritis and Rust is limited in platform support.
> Rust is limited in platform support. Rust supports everything you are likely to see in the wild outside of highly, highly specialized applications (e.g. ancient mainframes, satellites from the 80s or 90s, etc.). For God's sake, it's becoming increasingly difficult to justify writing code that takes into account CPU endianness, because all CPUs that are likely to run your code are little endian!
Alright, I'll bite. How is ARM (commonly Bi-Endian) considered a (1) "highly specialized" or (2) little-endian architecture?