On 1/17/2014 2:05 PM, H. S. Teoh wrote:
Of course, but that requires a few rounds of recompilation, repacking the EEPROM image, installation on device, and repeating a user interaction that possibly only randomly hits the bug. Hardly the work of a few minutes.
I've done EEPROM programming & debugging, I know how to do it. Nulls still aren't a special kind of bug.
BTW, even back in the 1970's, people developing EEPROM systems would plug a special device into the board which would redirect the EEPROM access to some off-board RAM, or would debug using emulators. Maybe this technology has been forgotten :-)
But in many cases, the source of a bad value is easy to find because of its uniqueness (hmm, why does variable x have a value of 24576? oh I know, search for 24576 in the code). Nulls, though, can occur in many places, and in D they are implicit. There's no easy way to search for that.
Come on. Every type in D has a default initializer. There's still nothing special about null.
Even if you got rid of all the nulls and instead use the null object pattern, you're not going to find it any easier to track it down, and you're in even worse shape because now it can fail and you may not even detect the failure, or may discover the error much, much further from the source of the bug.
