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