What's wrong with the code, then, is that it was written under a little too much pressure for the developer to think clearly. for ( int i=0 ; i
while (this.MyControl.TabPages.Count > 0)
{
this.MyControl.TabPages.Remove ( 0 );
}21–30 of 217 posts
What's wrong with the code, then, is that it was written under a little too much pressure for the developer to think clearly. for ( int i=0 ; i
while (this.MyControl.TabPages.Count > 0)
{
this.MyControl.TabPages.Remove ( 0 );
}Deleting from a container while you are iterating over it should always raise red flags.
for (int i=0,j=this.MyControl.TabPages.Count; i Like the blog author, I thought it was obvious what the problem was: Every time I read that, I'm going to have to figure out what it means. Any time there's a problem or change to code in that area, I have to stop and understand what it's doing. To clean it up, I'd do 1 of 2 things: Either write a .clear() function, or rewrite it to start at the end and clear the items in reverse. With the .clear() function, I can at…
The other nice thing about running it in reverse is that the .count method (assuming it's a method and not a property), needs only to be accessed in the initial condition setup. If you're accessing the size of, say, a linked list, you end up sneaking an O(n^2) runtime because it has to re-count the size of the list every iteration to check for termination. c.f. https://secure.wikimedia.org/wikipedia/en/wiki/Schlemiel…
for(i = list.size; i >= 0; i--)
list.removeAt(i);
Is itself a schlemiel algorithm on any singly-linked list...Deleting from a container while you are iterating over it should always raise red flags.
Isn't clear() itself a "while (not empty) delete element"?
But thats not the point - while (not empty) is not iterating over the loop, so there is no danger of corrupting the iterator.
Deleting from a container while you are iterating over it should always raise red flags.
Isn't clear() itself a "while (not empty) delete element"?
When you first start programming, you generally have no idea what the hell you are doing. You learn all these strange, abstract concepts best, by experimenting.
It's easy to dismiss people "jiggling things around until they work", as lesser, more inefficient or just plain bad programmers. Just remember that you were once like that too.
I think there should be more patience among the experienced, for the programmers who are still learning the basics.
As soon as I saw that snippet I could see what's wrong. In C# / .Net you can't remove an element from an enumerator while you're enumerating through it. You can remove the last element however, as it's the final loop the enumerator isn't used again so it won't throw an error. The original developer probably tried to remove it forward only first, encountered an error and wrote the code to loop through it backwards, us…
The can't-modify-a-collection-while-enumerating-it issue only comes into play if you're actually using an enumerator (either directly, or as part of a foreach loop) - the code in the article uses a plain for loop along with indexing into the collection, and wouldn't run into the problem.
Rather, the primary "issue" is that without that "i--" at the end it only removes half the elements - after removing an element, all the following elements shift back one index, and so the very next element never gets removed.
Deleting from a container while you are iterating over it should always raise red flags.
Especially when you're re-calculating the count on each iteration :) Inefficient and incorrect. Double whammy. While not as efficient as while(--), the fix get's the point across: for (int i=0,j=this.MyControl.TabPages.Count; i