best way to enumerate List<> & remove unwanted elements?

[Zytan]

......somehow you got it into your head that

what I told you what you were doing was wrong.

I have no idea why.

All I said is that you shouldn't use (i) the way you were
doing it, because that could lead to the loop blowing.

Oh, that's why.

Zytan

 

[Mr. Arnold]

I have no idea why.


Oh, that's why.

Please, let's forget about your little loop example. Let's just take dealing
with the idx counter on the loop, period.

Under normal circumstances, one doesn't mess with the count idx. It's a best
programming practice that's used by many.

Most use another variable an indirect method to control the loop, if they
need a way of terminating out of the loop based on the iteration count.

So your way works, big deal. Your way would simply not be the way I would do
it. I would never let your way come through a code review if you were
setting in front of me.

It's a bad habit a lazy habit of programming, that could lead to trouble in
the long run in other areas where you worked a project.

I would never directly start controlling the idx counter of a loop. the way
you're doing it.

By an indirect method of controlling the count to control the loop, yes.

Your way should never hit the light of day IMHO. Is it wrong, no it's not
wrong. Is it a best practice, no it's not a best practice either.

That's just the way I was taught.

This will be my last post on this subject, because I am through with you and
anybody else that needs to make a comment. There will not be a return reply.
It won't be read by me, because I am moving on.

 

[Peter Duniho]

[...]
Under normal circumstances, one doesn't mess with the count idx. It's a
best programming practice that's used by many.

That's true...it's generally bad form to modify a for() loop index outside
the for() statement. No one's disagreed with that.

Most use another variable an indirect method to control the loop, if
they need a way of terminating out of the loop based on the iteration
count.

Well, it is fairly common to use a different looping construct, such as
"while() { }" or "do { } while ()", when one intends for the looping
condition to be adjusting in non-linear ways inside the loop. It's not
that one doesn't modify a loop control variable from within the loop, it's
just that one doesn't normally do it with a for() loop.

So your way works, big deal. Your way would simply not be the way I
would do it. I would never let your way come through a code review if
you were setting in front of me.

That's fine. If you are in the position to impose your own requirements
on someone else's code, you're free to come up with whatever rules you
like. And in fact, I would probably strongly urge someone to change the
loop if I saw the same thing.

Still, no one's disagreed with the concern that the loop is poorly
formed. So your assertion here is not relevant.

It's a bad habit a lazy habit of programming, that could lead to trouble
in the long run in other areas where you worked a project.

Again, no one disagreed with this.

I would never directly start controlling the idx counter of a loop. the
way you're doing it.

Again, no one disagreed with this.

By an indirect method of controlling the count to control the loop, yes.

Your way should never hit the light of day IMHO. Is it wrong, no it's
not wrong. Is it a best practice, no it's not a best practice either.

That's just the way I was taught.

All of the above, no one has disagreed with. All of those assertions are
preaching to the choir and irrelevant to your original claim.

So why did you leave out your original claim, that the loop would blow
up? Is it possible that you've seen the error of your ways and realized
that the loop will not in fact blow up? Why not just admit it?

This will be my last post on this subject, because I am through with you
and anybody else that needs to make a comment. There will not be a
return reply. It won't be read by me, because I am moving on.

Cool. I love getting the last word. Another one of those pesky
personality defects I've got.

Pete

 

[Mr. Arnold]

[...]
Under normal circumstances, one doesn't mess with the count idx. It's a
best programming practice that's used by many.

That's true...it's generally bad form to modify a for() loop index outside
the for() statement. No one's disagreed with that.

Most use another variable an indirect method to control the loop, if
they need a way of terminating out of the loop based on the iteration
count.

Well, it is fairly common to use a different looping construct, such as
"while() { }" or "do { } while ()", when one intends for the looping
condition to be adjusting in non-linear ways inside the loop. It's not
that one doesn't modify a loop control variable from within the loop, it's
just that one doesn't normally do it with a for() loop.

So your way works, big deal. Your way would simply not be the way I
would do it. I would never let your way come through a code review if
you were setting in front of me.

That's fine. If you are in the position to impose your own requirements
on someone else's code, you're free to come up with whatever rules you
like. And in fact, I would probably strongly urge someone to change the
loop if I saw the same thing.

Still, no one's disagreed with the concern that the loop is poorly
formed. So your assertion here is not relevant.

It's a bad habit a lazy habit of programming, that could lead to trouble
in the long run in other areas where you worked a project.

Again, no one disagreed with this.

I would never directly start controlling the idx counter of a loop. the
way you're doing it.

Again, no one disagreed with this.

By an indirect method of controlling the count to control the loop, yes.

Your way should never hit the light of day IMHO. Is it wrong, no it's
not wrong. Is it a best practice, no it's not a best practice either.

That's just the way I was taught.

All of the above, no one has disagreed with. All of those assertions are
preaching to the choir and irrelevant to your original claim.

So why did you leave out your original claim, that the loop would blow
up? Is it possible that you've seen the error of your ways and realized
that the loop will not in fact blow up? Why not just admit it?

This will be my last post on this subject, because I am through with you
and anybody else that needs to make a comment. There will not be a
return reply. It won't be read by me, because I am moving on.

Cool. I love getting the last word. Another one of those pesky
personality defects I've got.

Pete

 

[Mr. Arnold]

Cool. I love getting the last word. Another one of those pesky
personality defects I've got.

Is the boy's code going to blow, no. Is his method of messing with the idx
going to possibly cause trouble from him in the long run with a lazy
programming practice, which was my point in the first place? Most likely,
yes, it's going to be that way for him. Is the code a piece of trash. Yes,
it is a piece of trash.

So, the bottom line is it's a "D-" and it's barely above *wrong* from my
view point.

It's just my parting *shot*.

 

[Jon Davis]

Zytan,

As it makes me uncomfortable to evaluate an object's property during each
iteration of a loop, here's how I like to clear lists:

List<type> myList = .... something ;
for (int i=myList.Count - 1; i >= 0; i--)
{
myList.RemoveAt(i);
}

Jon

 

[Jon Davis]

... more to the point ..

for (int i=myList.Count - 1; i >= 0; i--)
{
if (ShouldBeDiscarded(myList))
{
myList.RemoveAt(i);
}
}

Note that this in itself isn't thread-safe. The point of it is that, using
this approach, removing an item at i doesn't suddenly invalidate the
consecutive items to be evaluated, unless your list is not a standard list
and is using some kind of dynamic re-sorting.

Jon

 

[Jon Skeet [C# MVP]]

As it makes me uncomfortable to evaluate an object's property during each
iteration of a loop, here's how I like to clear lists:

Why does it make you uncomfortable? For performance reasons? I'd rather
take the simplicity and familiarity of a "counting up" loop (without
having to remember to use >= instead of > and Count-1 as the starting
point) and only adjust this for the sake of performance if it actually
comes up.

In fact, there's a more important performance reason (which I still
wouldn't care about until you prove you have an issue) - removing from
the end reduces the copying that needs to be done. Imagine the
situation where *every* element is removed - with the "counting down"
code, no copying is required; by counting up you've got to copy the
whole remaining list each time.

 

[Peter Duniho]

Is the boy's code going to blow, no.

Now, see? Was that really so hard? To finally admit you were wrong in
the first place? No, of course not!

It's wonderful that you finally saw the light and I hope that admitting
your mistake helps make you feel better.

Pete

 

[Mr. Arnold]

There was no light to see.

<Plank> that's a soft logical <plonk>.

 

[Zytan]

......somehow you got it into your head that
Please explain the logic of the above.

Me and everyone else:
loop could blow == doing something wrong

You:
loop could blow != doing something wrong

Please, let's forget about your little loop example. Let's just take dealing
with the idx counter on the loop, period.

This entire discussion is about the loop. If you want to talk about
something else, start another thread.

Under normal circumstances, one doesn't mess with the count idx. It's a best
programming practice that's used by many.

Yes, because it used to be the CX register, and if you changed the
variable, CX didn't change. I agree. But, times have changed. I
agree that it's still ugly, but mostly due to the past. Since, it is
guaranteed to work today, so we are allowed to change it. Still ugly,
yes, since it's the loop iterator, and it should be left to do what it
should do. I agree.

Most use another variable an indirect method to control the loop, if they
need a way of terminating out of the loop based on the iteration count.

Yes, I agree.

So your way works

Yes, thank you. So my loop will not blow. That's what I thought. We
are now all in agreement.

, big deal.

Sorry, but you're the one making it a big deal. That's what happens
when you say legitimate code is faulty. You said it would blow. It
wouldn't. It's just ugly code, not wrong. Two different things.

Your way would simply not be the way I would do
it. I would never let your way come through a code review if you were
setting in front of me.

I agree. That's EXACTLY why I asked to find the better way.

It's a bad habit a lazy habit of programming, that could lead to trouble in
the long run in other areas where you worked a project.

I agree.

I would never directly start controlling the idx counter of a loop. the way
you're doing it.

Me neither.

Your way should never hit the light of day IMHO. Is it wrong, no it's not
wrong. Is it a best practice, no it's not a best practice either.

My way is legitimate code that will never blow up. But it's ugly
code, since it hides the what the loop iterator does, since it is
changed inside the loop. So, it's horrible practive. Thus my search
for a better solution. Thanks to this group, I found it.

That's just the way I was taught.

You were taught well.

This will be my last post on this subject, because I am through with you and
anybody else that needs to make a comment. There will not be a return reply.
It won't be read by me, because I am moving on.

Please, stop with the drama.

Zytan

 

[Zytan]

All I said is that you shouldn't use (i) the way you were
doing it, because that could lead to the loop blowing.

Is the boy's code going to blow, no.

Arnold, everyone including me says my original code sucks. This
entire discussion was about your statement saying the code would
blow. Now that you admit that your original statment, the basis of
the entire discussion, was wrong, we are ALL on the same page.

Thank you.

Zytan

 

[Mr. Arnold]

Maybe, what I should have said out of the gate was *that your coding was
horrible enough with messing with the idx that the approach could lead to a
blow up with something else you might be trying to do in the future when
jacking around with an idx like that in a loop*.


Really, that's what stood out to me (the red flag) was that idx manipulation
and not the intent of the little loop, which if you will recall, you asked
didn't I understand what the loop was doing. Well, all I saw was the idx
being manipulated with you in the meantime doing something with the idx in
another statement.

It was not until later with ones that needed to post slobbering at the mouth
about the horrible little loop and how it wasn't going to blow up, that this
thread spun out of control, along with the .Net buggy nonsense as well being
thrown in my face.

I mis-spoke about the intend of my statement and the blow up condition,
which I should have clarified my statement right out of the gate, to avoid
the pitiful and trifling nonsense that was displayed to me here in this
thread.

And if you think I read every post that was being made to you about your
little loop and the general take about the loop, you would be wrong.

I have never seen something like this being ran into the ground and hard at
that.

 

[Mr. Arnold]

Please do me a favor and go lay down, in your crib. I am not here to explain
anything to you. I am not here to hold your hand. I got better things to do.

 

[Zytan]

Maybe, what I should have said out of the gate was *that your coding was

horrible enough with messing with the idx that the approach could lead to a
blow up with something else you might be trying to do in the future when
jacking around with an idx like that in a loop*.

Yes, that would explained what you meant. And I totally agree. As
does everyone else here.

Really, that's what stood out to me (the red flag) was that idx manipulation

Yes, it's certainly ugly.

It was not until later with ones that needed to post slobbering at the mouth
about the horrible little loop and how it wasn't going to blow up, that this
thread spun out of control, along with the .Net buggy nonsense as well being
thrown in my face.

You said the loop would blow up, and it wouldn't. The only way it
possibly could is if .NET was buggy. Since you made a mis-statement,
which you now admit, everything you said implied this.

So, how could you possibly expect anything but the reaction that
occurred?

Now we know you meant otherwise.

I mis-spoke about the intend of my statement and the blow up condition,
which I should have clarified my statement right out of the gate

Yes, you should have. Especially when people asked. Now that you
have, everything is ok

Well, except you are still complaining that people were calling you on
your mis-statement, but just as we now understand your point now that
you clarified it, why can't you understand why people misunderstood
you, especially since you know you made a mis-statement?

Zytan

 

[Mr. Arnold]

It's not read.

Yeah, go ahead and keep the thread alive. You'll be posting to year 2008. It
looks like.

 

[T]

http://www.arnold.com/

Is this your website, Mr. Arnold?