alt Hacker NewsSmart-arse is comparing C versus JavaScript, instead of C vs C++, for example.
And then coming with such lengthy ad hominem.
Let make a fun exercise for the audience, given your performance remark.
Paste a random C code that I should replicate in whatever language I feel like.
There is one rule.
If the sample code is pure ISO C, then I will only use what is in the standard of whatever language I pick up.
If the sample code makes use of single language extension not part of ISO C, then I will have the freedom to also pick whatever language extensions I feel like.
Replies
> If the sample code makes use of single language extension not part of ISO C
What are you even arguing right now? (Btw -ansi compiler flag)
> Smart-arse is comparing C versus JavaScript
I chose JavaScript to make the idea of a spectrum clearer using extremes. I can do C++ if you like. The machine doesn’t care about destructors, move, concepts, initializer lists, virtual methods, launder, or inheritance. You are programming against an abstract model further divorced from how x86 CPUs work.
So do you want to "rewrite" some C code in C++ to think you made a point? I think you should do C# or Java.
What about you do xxHash? Should be quite basic, not a lot of complicated structures. https://github.com/Cyan4973/xxHash/blob/dev/xxhash.h
Or what about you do an audio or video codec? Or an operating system?
Not going to paste any of my own code, because any non-trivial stuff is hundreds to thousands of lines. But one more example (that I recently did myself): Create a block allocator (power of two blocks) with bookkeeping in shadow memory (administered in individually committed zones representing virtual memory regions of 64 MB (2^26)). Any used memory has bookkeeping support for being sub-allocated at any and all levels up from 64 KB (2^16) to 64 MB (2^26), and even higher (by joining committed regions). Individual blocks are collected (using intrinsic linking, because no memory allocation) in a hierarchy of pools of same-sized chunks that have the same parent, and can be recursively sub-allocated on any smaller chosen power-of-2 level, and finally be consumed in linear fashion (arenas). Blocks are pooled with a moderate retain policy (watermark system) to allow subsystems to almost completely avoid any system calls and avoid inter-thread synchronisation. The memory overhead must be below 1% even though it's totally flexible (as said has metadata for all levels from 64 KB up).
The bookkeeping should function on 32-bit systems (small virtual space, occupancy range from megabytes to 3 GB) as well 64-bit systems (2^48-2^57 bytes of virtual address space, occupancy range from megabytes to hundreds of gigabytes) with reasonable overhead compared to actual usage.
This requires intrusively linked lists, occupancy bitmasks, bit-counting and bit-prefix counting, OS syscall access (virtual memory), pointer arithmetic (alignment needed to address shadow bookkeeping memory) and thread synchronisation. The reference code is >> 95% pure ISO C++11 (could be C99 with few changes), with a little platform code glued in. It works on Windows but it could be ported to Linux in a few hours. It supports a mostly-immediate-mode GUI with hundreds of thousands (maybe millions?) of small variable-sized allocations per second. Allocation has almost completely disappeared from the CPU profile, well below 1% of CPU usage.