I think the greatest problem is documentation. I work on compilers daily. Sometimes I am forced to read directly in to Ghc’s code to just use as a developer.
Maybe we should use Ai to generate up-to-date docs that are well organized like a book, so that all devs are more easy to conquer the different tools and flows.
For example, in C++, for basic toolchains LSP, formatters, standards of formatting, guidelines for performance, do and don’ts, … are more accessible.
I know it’s partially because of the size of the community. If we find a way to make the beginners, or experienced dev from other languages easier to start writing production code. We can thrive more.
Author here. The concepts in this article were the key to rearchitecting a module in our production codebase, which ultimately yielded a 10x performance improvement. Hope you find these notes useful!
Doing bitwise operations directly on raw pointers is a fast track to Undefined Behavior in standard C/C++. Emacs gets away with it largely due to its age, its heavy reliance on specific GCC behaviors/extensions, and how its build system configures compiler optimizations.
In modern C++, the technically "correct" and safe way to spell this trick is exactly as you suggested: using uintptr_t (or intptr_t).
Thank you for the kind reminder! I have removed the duplicate.
You made a great point. Since the original authors are the same, the fundamentals of the Emacs C core are indeed highly compiler-optimized. I hope I can come up with a way to fully understand and write about that history and relationship. (But to be honest, diving into that level of compiler history is a really hard topic to tackle!)
Thanks for the great inspiration and for taking the time to read!
Just weird enough, my brain feels the same way.