Pure C# : How can a for-loop index exceed itself?

I’ve never seen this before: How can the for-loop index variable “t” exceed itself inside its own for-loop in the code below?

I know this from catching an error (the code below armed with a try-catch block) which tells me that “t” has a value of 5 (causing crash) despite the end of the range is, say 3 (star_indices.Length = 3).

So, how is it possible that “t” is greater than the upper bounds of the array?

	for (var j = 0; j < tvi_connected.Length; j++)
		var star_indices = tvertices.ConnectedTopologyVertices(tvi_connected[j]);
		mv_points[j + 1] = new GH_Point[star_indices.Length];
		// --------------------------------------------------
		for (var t = 0; t < star_indices.Length; t++)   // <--- FROM HERE
		    var star_t = star_indices[t];
		    if (visited_indices.Contains(star_t))
		    mv_points[j + 1][t] = new GH_Point(tvertices[star_t]);
		// --------------------------------------------------
catch ... kaboom! ( t > .length! )

< scratching head >

What is going on here? What do you see here which I don’t see? I mean, only the code from “for(var t=0, ...)” is relevant…

// Rolf

Hard to say from a non-self-contained piece of code that looks redacted.

My guess is that you’re doing something to any of the involved pieces that you are not showing. Changing t, changing lengths of involved arrays…

I would venture a guess that

isn’t the case.

1 Like

True code, but the cause wasn’t t although the value of “t” was scrambled in the crash report. So you were right Nathan! :+1:

It turns out that the cause of the error was instead a too small mv_points array. Adding + 1 to the length on Create, fixed the problem.

Sorry for bothering you guys. I blame the crash report which put me on the wrong track (about “t”) … :blush: which is actually true, but embarrassing nevertheless.

Have a good one!
// Rolf

I guess it’s time for a coffee break when you stop trusting for-loops. :thinking:

// Rolf


For the visited part of the story define a bool[ ] visited = new bool [size]; (creates a collection of false) and then:

if(visited[index]) continue; // way faster than contains
visited[index] = true ;

True. Contains is really slow.I found that out on a very big mesh…

// Rolf

J+1 seems the problem to me

Yup, I pointed that out already, although I didn’t explicitly say that it was j+1 which was exceeding the array length.

For some reason the catch block reported that “t” had a greater value than the array length, which put me on the wrong track.

// Rolf

See attached.

Lists_ContainsVSBool.gh (5.0 KB)

Moral: use Contains only if you are out of Vodka (and cigars)

1 Like

And if you’re prototyping and don’t know the array length in advance… :wink:

If the array won’t occupy too much memory one can of course make a full (V or TV) length array check, but if need for resetting the values while working only in narrower ranges at the time, then resetting a full length array also takes time, so sometimes a Contains check is the easy way out.

But yes, I use array checks like this all the time for a reason.

// Rolf