71–80 of 94 posts
Earlier quoted context omitted.
pjmlp is a C++ fan who consistently criticizes C.
Correction, pjmlp is a security fan who consistently criticizes C.
Earlier quoted context omitted.
I think it's not polite, if you just want to show something cool you did you could create your own thread. You don't interrupt a street musicians and start playing in front of the crew just because you think you are a "better" artist or that your version of the song is cooler right? It's common courtesy. 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…
Your attitude may apply to some situations, but in general preliminary judgements kill innovation. Next time after reading your comment, someone somewhere may remain silent without showing off their art, and the world will be missing the next Copernicus, Gauss, Wozniak, Stroustrup. 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 "…
Why header only? Jesus christ, we have a linker.
Earlier quoted context omitted.
I think it's not polite, if you just want to show something cool you did you could create your own thread. You don't interrupt a street musicians and start playing in front of the crew just because you think you are a "better" artist or that your version of the song is cooler right? It's common courtesy. 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…
Your attitude may apply to some situations, but in general preliminary judgements kill innovation. Next time after reading your comment, someone somewhere may remain silent without showing off their art, and the world will be missing the next Copernicus, Gauss, Wozniak, Stroustrup. 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 "…
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.
Earlier quoted context omitted.
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 some…
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, th…
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++ 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.
Nice work! Have you considering combining ARRAY_ALG_TYPE and ARRAY_ALG_PREFIX into a single function-like macro? ARRAY_ALG_TYPE_PREFIX(int, intv_), for example, can set up all the other macros. I would also recommend adding a ARRAY_ALG_ prefix to the NAME1, NAME2, NS, and T macros so that you don't redefine any previous macros with these names.
Earlier quoted context omitted.
The issue here is people too lazy to tell their compiler where to find a header file so instead they cook up a bespoke system that is specific to every library using this approach.
That is not why this project is header-only. It's so you can include it multiple times to produce multiple specialized types; it has to be header-only so it can produce a series of structs and functions for each specialized type into your compilation unit, with the compiler separately checking each produced specialization. You configure it before including using a series of preprocessor defines. It's a common way to…
That depends on the compiler, linker and desired linking being static or dynamic and resource concerns. If dynamic, the entire specialized/monomorphized library could be loaded for a single function compared to static linking with the "-O2 -flto" options that removes unused functions.
Nice work! Have you considering combining ARRAY_ALG_TYPE and ARRAY_ALG_PREFIX into a single function-like macro? ARRAY_ALG_TYPE_PREFIX(int, intv_), for example, can set up all the other macros. I would also recommend adding a ARRAY_ALG_ prefix to the NAME1, NAME2, NS, and T macros so that you don't redefine any previous macros with these names.
can you give an example for the function like macro?
I don’t think this is true. p != end is a very common check in C?
Regarding composition, I suppose it’s kind of true. The string functions in the C standard library for example unfortunately often return null instead of end. I use functions that return end instead, which makes C code much more elegant.