4 ms·

I think our projects are completely different and don't have the same goals. 1. You don't implement the most important algorithms. For example `stable_sort` fo

I think our projects are completely different and don't have the same goals. 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.

rurban 3y ago
Well, you do support only vector containers, by having the limitation of first++ as only iter increment. Your name "array" clashes with the C++ array, which is a compile-time sized vector. And your array is unsafe sized, as last is the only size provision, even unsafer than C++ with its unsafe iterators. With C++ you can it least still bounds check against the vector size. 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.
- clibraries 3y ago
  > Well, you do support only vector containers 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.
camel-cdr 3y ago
Arguable void* is the more idiomatic C implementation, but as you said in the README, compilers still have trouble optimizing this (mostly due to bad decisions regarding function cloning).

rurban 3y ago

Well, you do support only vector containers, by having the limitation of first++ as only iter increment. Your name "array" clashes with the C++ array, which is a compile-time sized vector. And your array is unsafe sized, as last is the only size provision, even unsafer than C++ with its unsafe iterators. With C++ you can it least still bounds check against the vector size. 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.

clibraries 3y ago
> Well, you do support only vector containers 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.

camel-cdr 3y ago

Arguable void* is the more idiomatic C implementation, but as you said in the README, compilers still have trouble optimizing this (mostly due to bad decisions regarding function cloning).