I thought this was a well written and fair article. My preference would be that C++ is not "forked", but I understand the reasons for the impasse and consequences.
I found the part about member access operators interesting.
I've written C++ for 25 years, and although I've used "pointer"-to-member(function/fields) ability many times (indeed, this is how you bind signals to your member slots statically in QT!), I had no idea that it could both be null, and that -1 was used for a 'null' 'pointer' in this instance.
Good example about how large the language is, with so many weird dark darks. The number of air quotes needed above is pretty illuminating on its own.
I've heard that null pointers were greatly regretted. My favorite example of their issue is that there exists embedded devices with memory at address 0. Even worse, it's ITCM (instruction memory) so one might think that on startup you may want to copy a block of program code into it for lower latency (such as ISRs). Maybe you want to point the DMA to that while the CPU is busy initializing other things. But you can't. Because the driver code checks for... A null pointer where that's defined as 0.
Also, anything that doesn't do a null check (failed malloc anyone?) ends up writing to that memory. Good luck if you need it for something.
Similarly when I was writing a simulator for the chip I ended up commenting out that block for a lot of it because it was masking so many issues as other issues.
Unsure if newer generations moved it to somewhere else.
I found the part about member access operators interesting.
I've written C++ for 25 years, and although I've used "pointer"-to-member(function/fields) ability many times (indeed, this is how you bind signals to your member slots statically in QT!), I had no idea that it could both be null, and that -1 was used for a 'null' 'pointer' in this instance.
Good example about how large the language is, with so many weird dark darks. The number of air quotes needed above is pretty illuminating on its own.