C++ – Is it possible to make nonnull become part of C++ type system

cnull

NULL is the billion-dollar mistake but there is nothing in the type system of C++ to prevent it. However, C++ already has const-correctness so implementing NULL-correctness seems trivial:

introduce a keyword, __nonnull, as a specifier in the same class as const, which can only be placed after the * in a declaration.
All pointers obtained by & operator is __nonnull.
A __nonnull pointer value or const reference can be automatically converted to a normal pointer, but not vice-versa without a cast. (T *__nonnull can be converted to T *, and T *__nonnull & can be converted to T *const &)

Writable references of pointers cannot be automatically converted between normal and __nonnull (T *__nonnull & CANNOT be converted to T *&), i.e.

int x;
int *__nonnull p = &x;
int *q = p; // OK
int *const &r = p; // OK
int *const *s = &p; // OK
int *&t = p; // ERROR, don't want to assign NULL to t
int **u = &p; // ERROR, don't want to assign NULL to *u

const_cast can be used to cast a normal pointer to a __nonnull pointer, in which if the pointer is really NULL, the behaviour is undefined.
Assigning a null-pointer constant 0, NULL and nullptr to a __nonnull pointer variable is an error.
__nonnull pointers cannot be default initialised, like a reference.
Have a standard library function to convert a normal pointer to a __nonnull pointer, which throws an exception on NULL.
An optional warning will be given by compiler for dereferencing normal pointers without NULL check, which the practice is going to be deprecated.

Is the above proposal viable? Are the above things enough for a NULL-safe type system?

Best Answer

Is the above proposal viable?

No.

First, it doesn't work for user-defined types. Whereas const does. Even volatile does. And with lots of smart pointer types, having it work with user-defined types is kind of important.

Second, using const_cast to convert to __notnull is... silly.

Third, C++ is not C. If something is important enough to get a keyword in C++, then it's important enough to get a keyword that doesn't look terrible.

Fourth, this can be done adequately through a simple type. The C++ core guidelines support library provides not_null, which essentially has the properties you suggest. And, unlike __notnull, it works with user-defined smart pointers too (though not unique_ptr).

Related Solutions

Error Handling – Null Pointers vs. Null Object Pattern

You wouldn't use a Null Object Pattern in places where null (or Null Object) is returned because there was a catastrophic failure. In those places I would continue to return null. In some cases, if there's no recovery, you might as well crash because at least the crash dump will indicate exactly where the problem occurred. In such cases when you add your own error handling, you are still going to kill the process (again, I said for cases where there's no recovery) but your error handling will mask very important information that a crash dump would've provided.

Null Object Pattern is more for places where there's a default behavior that could be taken in a case where object isn't found. For example consider the following:

User* pUser = GetUser( "Bob" );

if( pUser )
{
    pUser->SetAddress( "123 Fake St." );
}

If you use NOP, you would write:

GetUser( "Bob" )->SetAddress( "123 Fake St." );

Note that this code's behavior is "if Bob exists, I want to update his address". Obviously if your application requires Bob to be present, you don't want to silently succeed. But there are cases where this type of behavior would be appropriate. And in those cases, doesn't NOP produce a much cleaner and concise code?

In places where you really can't live without Bob, I would have GetUser() throw an application exception (i.e. not access violation or anything like that) that would be handled at a higher level and would report general operation failure. In this case, there's no need for NOP but there's also no need to explicitly check for NULL. IMO, those checks for NULL, only make the code bigger and take away from readability. Check for NULL is still the right design choice for some interfaces, but not nearly as many as some people tend to think.

C Programming – When to Check Pointers for NULL

Invalid null pointers can either be caused by programmer error or by runtime error. Runtime errors are something a programmer can't fix, like a malloc failing due to low memory or the network dropping a packet or the user entering something stupid. Programmer errors are caused by a programmer using the function incorrectly.

The general rule of thumb I've seen is that runtime errors should always be checked, but programmer errors don't have to be checked every time. Let's say some idiot programmer directly called graph_get_current_column_color(0). It will segfault the first time it's called, but once you fix it, the fix is compiled in permanently. No need to check every single time it's run.

Sometimes, especially in third party libraries, you'll see an assert to check for the programmer errors instead of an if statement. That allows you to compile in the checks during development, and leave them out in production code. I've also occasionally seen gratuitous checks where the source of the potential programmer error is far removed from the symptom.

Obviously, you can always find someone more pedantic, but most C programmers I know favor less cluttered code over code that is marginally safer. And "safer" is a subjective term. A blatant segfault during development is preferable to a subtle corruption error in the field.

Best Answer

Related Solutions

Error Handling – Null Pointers vs. Null Object Pattern

C Programming – When to Check Pointers for NULL

Related Topic