Issues with porting C++ code to a 64-bit platform

Re:Issues with porting C++ code to a 64-bit platform by CamperBob2 on Monday April 01, 2013 @05:41PM (#5476123)

True, but again, the whole problem is all of these weird, random changes and exceptions that only a small subset of programmers can keep in their heads. If you're going to go down that path, you should pick safe weird, random changes and exceptions.

In this case, they should have turned NULL into a first-class keyword that would parse as an invalid pointer of any given type, and called it "done." In the original C spec NULL wasn't supposed to be a pointer at all -- it was just a more polite way to write "zero." As endless Internet debates have shown, it turns out that it would have been better to reserve it for use in pointer expressions.

[ Parent | on HN ]

Re:Issues with porting C++ code to a 64-bit platform by mpyne on Monday April 01, 2013 @05:57PM (#5476217)

Turning a macro defined in probably hundreds of header files into a keyword would be a very bad idea for backward compatibility. It would have been nice if C had reserved it for use as a pointer and C++ had been coded from the beginning to allow NULL to be defined to any pointer type, but that wasn't how it ended up.

But what library vendors can do now is to simply

    #ifdef __cplusplus
    #if /* version check for C++11 */
    #undef NULL
    #define NULL nullptr
    #endif
    #endif

And that way there's less stuff to memorize, but still requires that the code itself has to opt-in, instead of the language having to figure out what insanity NULL may have been defined to.

[ Parent | on HN ]