References and Pointers, Part Two

re: References and Pointers, Part Two

Alex Davies — Tue, 31 May 2011 05:02:54 GMT

There's a minor bug present in that a pointer to a zero array is permitted by the public constructor.. although this is more so yet another argument in allowing pointers to go 1 past the end ;).

re: References and Pointers, Part Two

Mike Strobel — Thu, 24 Mar 2011 01:02:11 GMT

@Ben: Not safely or with particularly good performance, but you could do something like this: http://pastie.org/1706405

Please do not use that technique for anything other than academic purposes. It really is not a good idea.

re: References and Pointers, Part Two

Ben Voigt [Visual C++ MVP] — Tue, 22 Mar 2011 21:34:33 GMT

In C and C++, taking the difference between two pointers into the same object is well-defined, whether or not that object is an array. Is it safe to assume that there is no library implementation which would provide equivalent functionality in C#?

re: References and Pointers, Part Two

Mike Strobel — Mon, 14 Mar 2011 18:06:18 GMT

Your decision to safely cast 'x' as a Nullble<ArrayPtr<T>> in Equals() threw me for a moment, as 'x' (typed as 'object') could not possibly be a Nullable<> (nullables lose their identity as nullables when boxed). But this technique lets you achieve with a single 'as' cast what would otherwise require both an 'is' check and an unsafe cast. Very clever.

re: References and Pointers, Part Two

Fede Azzato — Mon, 14 Mar 2011 11:27:03 GMT

I believe your this[] operator should check for bound issues. Maybe something like this would be enough.

public T this[int index]

{

get { return index == 0 ? source[this.index] : (this + index)[0]; }

set { if (index == 0) source[this.index] = value; else (this + index)[0] = value; }

}

re: References and Pointers, Part Two

Navaneeth — Sun, 13 Mar 2011 01:13:31 GMT

Nice code. A question on your programming style. Do you use assertions frequently when writing internal classes? I have heard lot of guys talking about avoid to use assertions because they clutter in the actual code. While I think assertions should be used proactively, I would like to get your view also on this.

Thanks

re: References and Pointers, Part Two

Ben — Fri, 11 Mar 2011 22:02:51 GMT

@Shuggy

I agree that a guard is probably a better idea, but the beauty of allowing pointers to outside the bounds is it retains the "object safety" of the class as written. (ie, you get the assert when you try to compare an invalid value of one array to a valid value of another). I'd possibly go for a hybrid, now that you mention it: have all invalid values compare equal, and disallow any operation other than comparison on them. This would allow you to use invalid values as guards, keeping the safety check of "comparing from the same array", while minimising the possiblity that you'll miss seeing an invalid value misused.

re: References and Pointers, Part Two

Shuggy — Fri, 11 Mar 2011 09:28:17 GMT

@Monsignor

did you miss the footnote?

"(*) Were this to be a public type then I'd make the assertions into exceptions because there is no telling what crazy thing the public is going to do; since this is an internal type I can guarantee that I'm using it correctly, so I'll use an assertion instead."

re: References and Pointers, Part Two

Graham Clark — Fri, 11 Mar 2011 08:32:27 GMT

In your example use code, shouldn't

var p5 = arr + 5;

var p5 = p0 + 5

Otherwise it doesn't compile.

re: References and Pointers, Part Two

Shuggy — Fri, 11 Mar 2011 07:44:16 GMT

@Ben

Personally I believe modifying the guard (in this case to be <= end - 2) is appropriate.

If the guard would become very complex the working out what you were going to increment/ decrement and doing a break if it would go put of bounds is also fine.

I admit it might make the code slightly less easy to read but it also ensures that nobody ever has access to an invalid pointer they might use

If you cared you could easily write a SafeIncrement method which returned null (or some other sentinel) once you fell off the edge and use the sentinel in your guard instead.