5 ms·
The author contacted me via email yesterday (because they saw I'm writing a lot of C++ code on GH) and asked me for a review. This was my somewhat-grumpy somewh
by max_k 3y ago
The author contacted me via email yesterday (because they saw I'm writing a lot of C++ code on GH) and asked me for a review. This was my somewhat-grumpy somewhat-trollish reply:
Your library demonstrates that C++ is the superior language because it can to template specialization, resulting in better machine code. For example, your std::span implementation needs to store the element size, resulting in a larger structure (24 instead of 16 bytes), more memory memory accesses, costly integer multiplications everywhere.
C++ can omit all this, and can do simple bit shifts instead of multiplications.
There are many more places where you demonstrate C++'s superiority (e.g. it can safely do deep copies with no special code, while your library can't do copies at all, and even if it could, doing so safely/deeply would be extremely cumbersome with C, both for your library code AND for the code calling your library; all a piece of cake in C++).
Oh, and "Implements a dynamic array similar to std::array" .... that's factually wrong. std::array is not a dynamic array. std::vector is. Interestingly, your std::array implementation uses your std::vector, while adding some more runtime overhead. Hey, it's C, it's slower than C++ is what I learn again here!
It's a rather pointless library, unless your point is to demonstrate that C is a bad programming language.
- Matheus28 3y agoThe tuple implementation is also nasty in how much memory in allocates. It's the only one I looked at, to be honest.
- nextaccountic 3y agoDo you have anything good to say about it?
- max_k 3y agoMaybe I could say something good about some aspects of their coding style, but that would only distract from my main point that I find it pointless to imitate a C++ API in C, when that API is modeled carefully to take advantage of C++ features, and you lose all of that in C. (Not only that - their C API is designed in a way that adds overhead even where none would be necessary in C, by allocating all structs on the heap.) There are lots of plain C container libraries which are probably suited better for C, if you really must use C, or prefer C for whatever reason that escapes my imagination.
- pjmlp 3y agoThe 1990's were looking so great for C++ adoption on desktop, we had Mac OS (pity about Object Pascal, but at least there was PowerPlant), OS/2 (with CSet++, and OWL), MS-DOS (with Turbo Vision), Windows (with OWL, VCL, MFC, ATL), BeOS (with its Kits), Epoch/Symbian, Windows CE (with MFC),... And then rise of FOSS happened, with the original GNU contribution guidelines asserting only C and Lisp as the all mighty languages for the GNU ecosystem to build upon.
- uecker 3y agoThe UNIX model won over object approaches. And I think there is a reason: The simplicity of flat memory model, C, a unified file interface etc. removes a lot of complexity and allows composition of diverse components to a working system. Or in other words: If C++ were actually better for engineering large systems, GNU wouldn't have had a chance.
- pjmlp 3y agoDid it? From where I am standing, it failed in everything except headless computing, with similar input/output devices as a PDP-11. If it isn't a server, or a some piece of software running on a smart appliance, it hardly matters how much POSIX it is exposed. By the way, C++ is also UNIX, born and raised by AT&T in their UNIX labs, it is the main reason why all C compiler vendors adopted it in first place, including Stalmman's GCC, as you should clearly be aware.
- uecker 3y agoYou are right that you can build a lot of overly complicated crap on top of simpler systems. Android or the modern web are good examples. But in the long run it is usually not the overly complicated crap that prevails.
- pjmlp 3y agoHistory shows otherwise, as proven by any usable modern C compiler is now written in C++ like GNU's compiler, so C++ is definitely better for engineering large sytems, GNU did not had a chance either than accept it and move along into modern times. > If C++ were actually better for engineering large systems, GNU wouldn't have had a chance. Unfortunely I won't be around to see this happen, but I bet when the UNIX/Linux/BSD founders generation is gone, other OS pushed by big corps will take its place, maybe even taken by younger devs that took the free beer source code and created their new cool startup with an OS partially taken from it, NeXTSTEP/Solaris style. Something that is already taking shape on IoT space with all those RTOS using MIT/Apache licenses, and very little POSIX/UNIX on them.
- hardware2win 3y ago>C++ can omit all this, and can do simple bit shifts instead of multiplications. Irrelevant. We need good lib in C
- esrauch 3y agoThe claim is more that the C++ std is designed to take advantage of C++ language features. Mimicking the same API in C isn't a good lib, the C API shape would need to be different.
- eps 3y agoWho are "we" and what's wrong with all existing options?
- hardware2win 3y agoExisting options like? Using 3rd party libs for basic data structures?
- deleted 3y ago[deleted]
- uecker 3y agoI agree with the criticism that one should not mimick C++ in C. A good C library would use intrusive data structures, user-controlled memory allocations, not try to replace built-in types (arrays) with inferior alternatives, and not to try to be a kitchen-sink library. And then it would be obvious such C++ sucks in comparison... ;-)
- gpderetta 3y ago> intrusive data structures, user-controlled memory allocations That's par for the course in c++. > not try to replace built-in types (arrays) How do you pass around C arrays to avoid the braindead pointer decay? You wrap them in a struct. That's literally all that std::array does.
- uecker 3y agoYou do not need to wrap arrays into structs to prevent decay. You just take the address as you would do for any other type: https://godbolt.org/z/Y73j8a7Yf https://godbolt.org/z/Y73j8a7Yf