dereferencing null

Adam D. Ruppe destructionator at gmail.com
Sun Mar 4 20:39:57 PST 2012


On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
> News to me.  I've had bad runs with that back in the day, but 
> maybe things have improved a bit.

Strangely, I've never had a problem with gdb and D,
as far back as 2007.
(at least for the basic stack trace kind of stuff).

But, yeah, they've been improving a lot of things
recently too.

> Non-nullable types would be really cool right about now.

Huh, I thought there was one in phobos by now.

You could spin your own with something like this:

struct NotNull(T) {
   T t;
   alias t this;
   @disable this();
   @disable this(typeof(null));
   this(T value) {
      assert(value !is null);
      t = value;
   }

   @disable typeof(this) opAssign(typeof(null));
   typeof(this) opAssign(T rhs) {
       assert(rhs !is null);
       t = rhs;
       return this;
   }
}


This will catch usages of the null literal at
compile time, and other null references at runtime
as soon as you try to use it.

With the disabled default constructor, you are forced
to provide an initializer when you use it, so no
accidental null will slip in.

The alias this means NotNull!T is substitutable for T,
so you can drop it into existing apis.

> It's that I simply cannot expect users to run my code in a 
> debugger.

:) I'm lucky if I can get more from my users than
"the site doesn't work"!

> The problem is that they don't help me when I missed a spot and 
> didn't use assertions, contracts, or invariants.

Aye, I've had it happen. The not null types might help,
though tbh I've never used anything like this in practice
so maybe not. I don't really know.


More information about the Digitalmars-d mailing list