> 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.
I assume you are not familiar with modern C, but I think it's a good opportunity to explain.
A single header style allows you to customize the library with the preprocessor before `#include`. I use this ability to implement generics. Otherwise, you're stuck with void* or code generation (want my python script instead?).
However, you don't have to forgo the benefits of separate compilation units. You can include the declarations in a header, and the implementation in a separate C file. No other parts of the code base will be impacted.
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.