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

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Jan 17 19:42:00 PST 2014


On Fri, Jan 17, 2014 at 07:11:16PM -0800, Walter Bright wrote:
[...]
> We've talked about the floating point issue, where nan values
> "poison" the results rather than raise a seg fault. I remembered
> later that a while back Don tried to change D to throw an exception
> when a floating point nan was encountered, specifically because this
> made it easier for him to track down the source of the nan. He said
> it was pretty hard to backtrack it from the eventual output.
[...]

This is tangential to the discussion, but the nan issue got me thinking
about how one might detect the source of a nan. One crude way might be
to use a pass-thru function that asserts if its argument is a nan:

	real assumeNotNan(real v, string file=__FILE__, size_t line=__LINE__) {
		assert(!isNan(v), "assumeNotNan failed at " ~ file ~ " line " ~
				to!string(line));
		return v;
	}

Then you can stick this inside a floating-point expression in the same
way you'd stick assert(ptr !is null) in some problematic code in order
to find where the null is coming from, to narrow down the source of the
nan:

	real complicatedComputation(real x, real y, real z) {
		// Original code:
		//return sqrt(x) * y - z/(x-y) + suspiciousFunc(x,y,z);

		// Instrumented code (UFCS rawkz!):
		return sqrt(x).assumeNotNan * y
			- (z/(x-y)).assumeNotNan
			+ suspiciousFunc(x,y,z).assumeNotNan;
	}

Makes it *slightly* easier than having to break up a complex expression
and introduce temporaries in order to insert asserts between terms.
But, granted, not by much. Still, it reduces the pain somewhat.


T

-- 
Political correctness: socially-sanctioned hypocrisy.


More information about the Digitalmars-d mailing list