Well, I do like mine better, which is closer to the STL, and for all containers. https://github.com/rurban/ctl/
1. You don't implement the most important algorithms. For example `stable_sort` for arrays. So right there, it's not even a substitute.
One of my motivations from the start was simply to have `stable_sort` in C (to implement database queries).
2. Yours is a clever implementation of C++ features using macros. But it's not idiomatic C. If someone (or their team) wants to use your system, they must learn your macro language.
My file can be included by someone who only knows C array, and will not intrude on any aspect of their C programming style.
3. Mine is intentionally not a data structure library, and avoids making allocations.
There are countless data structure libraries for C. Very few catch on. That's because C programmers tend to manage the life cycle of data themselves. Furthermore, data structures are inter-woven with their data, as opposed to being separate containers.
Besides that point, I see no advantage to yours over other data structure libraries. For example, the best C hash map implementations are written for uint64 keys. Fixing to a concrete type allows for tremendous optimization.
I applaud the efforts in your project and wish it success. Our projects happen to draw on similar source material, but that's about it.
Your variant being static is indeed nice, the STL, CTL cannot do that, just MTL exists for that. Which supports all containers. E.g. Non-vector types allow for much faster inserts.
You can only replace insitu, which is the opposite of functional. No backtracking. Manual copying needed. The spirit of the STL algorithms is to allocate, not overwrite.
Re hash-map: this is not even finished. For now it's just a pointer-stable unordered_map with optimizations for all types, primitives or strings. optimized Swisstable (string) and Stanford hashes (u64) are in work (no time for that), and are indeed multiple times faster.
Yes.
> Your name "array" clashes with the C++ array
In C they are called arrays.
> And your array is unsafe sized, as last is the only size provision, even unsafer than C++ with its unsafe iterators.
Can you explain more? C++ <algorithm> is intended to be used for C pointers as well. The iterator concept is an abstraction of pointer.
> You can only replace insitu
I'm not sure what you mean. The replace/remove/unique work just like the C++ versions. The STL recognizes there are cases when you want to work in-place, and others when you want to use a separate buffer. That's why it provides multiple versions.
> the spirit of the STL algorithms is to allocate, not overwrite.
I don't believe this is true. It's designed to separate memory allocation concerns from the algorithm. That's why a lot of them require you to provide a buffer satisfying some requirements.
On a more constructive side, I think adding some value by giving the poster some feedback or engaging in a conversation about the topic would be nice, otherwise it just sounds as an attempt to show off.
I'm not a fan of these "header only" projects nor am I a fan of overly clever code because even though it's fun and rewarding to write it's not a great fit for larger or collaborative projects where consistently adhering to a coding style (hopefully one of the secure ones) and favoring readability over "coolness" are the way to go.
People love to blame C for all of its footguns but not a lot of people like to write "boring" code which kinda sucks...
Please don't take this personally, even though I have to admit that I felt somewhat irritated upon reading your comment it is my no means my intention to attack you with this rant.
Why not? rurban's work is solid and should be shown off.
On a side note, I looked at both codebases and even though I've already said that I wouldn't use either of them I have to say that I find rurbans to be somewhat messier and uglier so I have to disagree with you.
If I have to choose between "polite" and "innovation", I choose "innovation" any time of day. This is the same kind of difference as to "diss" someone for no real reason as opposed to letting someone just be and "blossom" so they could share their enlightenment with everyone, and thus benefit us all.
It's really valuable (and sometimes even enjoyable) for others to read (or even participate in) a conversation between two (or more) knowledgeable individuals who share their perspective and explain why they made the choices the made in their implementations (hint: here's where he could share some of their work!).
In fact, this is the polar opposite of that and it's just sad.
it's only common for normies (ok, I guess that is a lot) to expend too much energy looking for emotional content. Just pay attention to the facts, here's a library/framework, here's another library/framework. See? now you know about two. Want emotion? ok, one guy seems proud of his, another guy maybe too proud of his? So what, you be the judge, look at the code.
that is very emotional of your part using borderline insults
You don't need to spend any energy looking for emotional content when it's very face front ego inflated "mine is better" without any constructive feedback.