Non-null objects, the Null Object pattern, and T.init

Michel Fortin michel.fortin at michelf.ca
Sat Jan 18 04:33:52 PST 2014


On 2014-01-18 03:38:31 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> On 1/17/2014 7:23 PM, Michel Fortin wrote:
>> I guess so. But you're still unconvinced it's worth it to eliminate null
>> dereferences?
> 
> I think it's a more nuanced problem than that. But I agree that compile 
> time detect of null reference bugs is better than runtime detection of 
> them.

In the C++ project I'm working on (full of asynchronous callbacks) I've 
built myself a not-null smart pointer type. It tries to disallow things 
at compile time, but because it can't follow control flow there's 
obviously some possible leaks that are caught at runtime through an 
assertion upon assignment. I created it because I had some untraceable 
bugs and I though it'd be simpler to convert the code base to use 
not-null pointers than it'd be to narrow the issues manually. The 
transition was surprisingly easy: just try to make everything you can 
not-nullable. Sometime the logic forces you to make a variable 
nullable, sometime you discover a bug in the form of a missing null 
check.

Implementing non-nullable pointers and adapting the code base was worth 
it for me. I found some bugs that I couldn't track otherwise, and some 
others that had yet to occur. But more importantly now when I look at a 
pointer in this project I know immediately from its declaration whether 
that pointer can be null or not, and I find that very helpful when 
tweaking code that was written a while ago.

But in the process I've created a new meta-language (make_new< T > 
instead of new, a new smart pointer types, cast function for those 
pointers, etc.) that someone new on the project will have to learn and 
train himself to use correctly. Integrating the thing in the language 
would make things that much simpler because it'd preserve the normal 
syntax of the language and also because null leaks can all be detected 
at compile-time, with clearer error messages.

This is what motivated my proposal earlier in this thread. I'm 
proposing an improved version of what I'm already using currently:
http://forum.dlang.org/thread/lba1qe$1sih$1@digitalmars.com?page=4#post-lbbgr6:247sf:241:40digitalmars.com

I'd 

like to know what you think of it.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca



More information about the Digitalmars-d mailing list