Using an array of function pointers to replace large switch statements... holy shit.. I feel like Thanos getting the time stone.
Just when you think you can’t get your code to run any faster, nor did I think I could get the code any smaller... BOOM.. C never ceases to impress.

Next I’ll be turning this into “object” oriented ... but since it’s C ... it will just be Struct oriented .. SOP ..

I worked on a codebase once that had a “spine” which was a massive array of function pointers where all the globalization functions were “inherented” from the local ones.

@irene hence the quotes, two yes you can do most OOP concepts in C it actually a good way todo oop as you master the concept and understand what truly is going on behind the abstraction of modern OOP languages.. hell the first version of C++ was written using C but a added preprocessor layer of macros and defines.... is OOP pretty in C .. no.. AND it’s why I called it Struct Oriented Programming .... really a object is just a Struct

@irene here’s a great book regarding how todo OOP concepts in C https://cs.rit.edu/~ats/books/...

@irene LOL ... I don’t see why not, I’d like to see how it could be used on embedded systems to break up things into “subsystems” id like to see how it affects performance and code space. Considering most of it is pointer based or preprocessor code.. I think the additional code space would be minimal ...also working on a small RTOS from scratch..

@irene YES... that I can totally agree with 100%

@irene totally true and agree, but I’d like to physically see the “effects” to me it’s not a waste of time.. it’s just an experiment... now if the results turn the way I expect.. doing it again or in the future will be a waste lol.

If you're going that far into OOP, why not just go C++? You're basically doing vtable dispatch, and C++ compilers can hardcode the dispatch directly when they can prove that there's never any uncertainty about which method is actually being called (quality of life improvement mostly) (I think).

@RememberMe c++ isn’t a standard in our industry... c++ isn’t supported by our compilers and or not approved by oems .. plus C is always faster than C++.. and cuz I don’t like c++

@irene no no no ... replicating OOP concepts in C .... is not the same as replicating the C++ syntax

@QuanticoCEO I don't think "C is always faster than C++" is true at all, but the rest, sure. Fair enough.

@RememberMe actually it is true

@RememberMe one of the reasons Linux was written in c as well as git written in c

@RememberMe Well you can have C++ as fast as C, but the problem is that in order to do that, you'd need to see through tons of compiler magic right to the resulting assembly. Most C++ programmers are unable to do so in non-trivial programs, and those who are are too expensive to have them wait during the perverse compiling times.

@Fast-Nop sure, except that C++ is widely used for high performance programming where it's needed and where real money depends on it.

Besides, I was objecting to the "always" bit.

C++ can be made to go as fast as C when needed, but its value comes from being able to trade off a bit of that low level nature and performance for abstractions and quality of life stuff.

For eg. C dynamic arrays are fast, C++ STL vectors are a bit slower but easier and safer to use in general. If my code spends 10% of its time doing array/vector stuff and 90% on some numerical computation, I can do the 90% bit equally fast in C and C++ but lose some C++ performance in the 10% part because vectors. I would do that tradeoff because the impact on overall performance is minute. I gain safety and ease of use of vectors. (Exaggerated example)

It helps that stuff that isn't executed often is a pretty large part of codebases, the "hot" code is small. So, practically, less optimization effort needed too.

@RememberMe Even the abstractions of C++ aren't actually such. Try to overload the + operator to add two string literals. Won't work, and to be able to even use the abstractions, you need to know how they are implemented, which is the hallmark of bad abstractions.

Not to mention the horrible write-only syntax. It's a vac cleaner of ideas that are mutually exclusive and thrown into one language with no vision for the overall result. Design by comittee at its worst.

Btw., also Java is used widely for high performance computing. And on the other end, Fortran, which still beats both C and C++ because Fortran doesn't allow aliasing in the first place.

@Fast-Nop edge cases don't make the whole thing useless. Contrast this with all the cases in which it works fine, eg. in very stressful stuff like expression templates. I would also argue that all abstractions leak in some way (eg. C/C++ array performance depends on lookup order and array size because of caching and paging, when theoretically arrays should be perfectly random access) and achieving perfection is just not reasonable for a practical language. Plus the reason it doesn't work (adding const pointers, overload resolution rules when no objects are present) is quite consistent.

I agree the syntax is kind of objectionable at times and the features are a bit mish-mash. Modern C++ looks quite clean however, and the reeeallly bad syntax is just in libraries like Boost, where people use hacks to get around language limitations.

Yes, the same principle applies to Java, but it has its own pros and cons. Similarly, Python is also used for high perf stuff, also with pros and cons.

@irene Accessing the same memory through different pointers. Undefined behaviour in C if the data types are incompatible, except with char, but allowed for compatible types.

Suppose you have a matrix of float, do a vector multiplication and store the result in another vector. Then with every store in the result vector, C has to assume that the source vector or the matrix have changed, so the compiler must reload. Fortran doesn't have that problem.

C99 introduced "restrict" to address this. You can tell the compiler that the memory pointed to by a pointer is only accessed through that specific pointer.

Then the compiler won't reload in the example above because the store to the result vector cannot change source vector or matrix although everything is float.

@RemindMe 1 hour.