M
Mr. Arnold
Peter Duniho said:
Don't you know? It's MS and what works up in the IDE and what works when you
deploy it are two different things. I have been there an done that.
Don't you know? It's MS and what works up in the IDE and what works when you
deploy it are two different things. I have been there an done that.
P
Peter Duniho
Don't you know? It's MS and what works up in the IDE and what works when
you deploy it are two different things. I have been there an done that.
No, I don't know. If it is possible that the code that was posted would
somehow stop working when it's deployed, it's not because of the way the
loop is written.
M
Mr. Arnold
Peter Duniho said:
This is beyond the whole little loop function. I am surprised that you don't
understand the statement above that I made.
How long have you been programming with MS solutions not to know that what
happens in development or the test environments may not hold true when a
solution hit's out there in the production environment?
You ever had to go out to a production server and debug code that worked
perfectly in development and test environments but not in production?
P
Peter Duniho
You wrote:
"No, you don't decrement (i) like that, you're going to eventually blow up
at that RemoveAt(i)"
That statement is simply false. But, if you're going to assert that it is
true because .NET is buggy, then the conclusion ("you're going to
eventually blow up") has nothing at all to do with the exposition ("you
don't decrement (i) like that").
Either way, there is nothing wrong at all with the code that was posted,
not in the way you claim.
Actually, I've been programming with MS solutions long enough to know that
they work a lot better than some people would like us to believe. And
that other solutions aren't nearly as superior as those same people would
like us to believe.
But even so, let's assume that .NET is riddled with bugs and there's a
possibility in the loop that was posted that "you're going to eventually
blow up at that RemoveAt(i)". If that's true (and I don't believe it is),
then it has absolutely zero to do with how the variable "i" is
decremented. The loop could be completely rewritten (in the way that I
suggested, for example), without the extra decrement, and the statement
"you're going to eventually blow up at that RemoveAt(i)" would be just as
true as it was with the original code.
I've had plenty of situations in which bugs were not found in production,
due to user scenarios that had not been anticipated and/or tested, as well
as a very small number of situations in which bugs in third-party code was
causing a problem with my own code.
But, so what? None of that changes the fact that any presumed problem you
might care to point out has ZERO to do with whether the code decrements
the variable "i" or not.
Pete
M
Mr. Arnold
Peter Duniho said:
This is all coming from you. I didn't say anything about .NET being buggy.
It's out of your mouth that it's being said.
All I said was not to decrement (i) like that, that the loop is controlling,
which could possibly lead to a termination at RemoveAt(i).
Normally, one does't decrement (i) like that in a loop. Normally, one lets
the loop increment or decrement the count itself. Now, one could do an j=i-1
or j=i+1 and work with j, but one doesn't mess with (i). That's kind of
common sense.
One could just look a tlist.count and with j determine that it's time to
leave the loop.
Again, I never said there was nothing wrong with the code. This is coming
out of your mouth, not mine.
Well, you can't come up with number of months or years, then that tells me
not long at all.
I have been programming MS solutions, since 1994. I been programming
business solutions since 1980. I have been in the IT field since 1971 and
still going strong.
Will you get off of the loop, you have beaten the loop into the ground.
LOL as you have suggested. Who are you?
I didn't see your suggestion nor do I care to see it either.
I am not even talking about some user scenarios that had not been
anticipated. It's more along the lines of Com and Com+ solutions being used
in a enterprise solution.
which things didn't work as aspected, with the same code working without
Com+, as an example.
You are one of these people that has a corn cob stuck up your behind, you
know it all, you got to prove it and you got a mental problem.
I have seen your kind before off the job and on the job as well.
Here comes Pete he's a PITA. Let's cut him off and leave before he gets
started.
J
Jon Skeet [C# MVP]
Excuse me? How about:
<quote>
Don't you know? It's MS and what works up in the IDE and what works
when you deploy it are two different things. I have been there an done
that.
</quote>
and
<quote>
How long have you been programming with MS solutions not to know that
what happens in development or the test environments may not hold true
when a solution hit's out there in the production environment?
</quote>
To me that sounds like a suggestion that you believe it's buggy.
Perhaps you could correct my interpretation of your posts.
Funny how different people come to different conclusions. I've been
reaching the conclusion that Peter is one of the most experienced
posters (not necessarily in C#, but that's a different matter - and one
which is rapidly changing) in the group. When we disagree, it always
leads to a productive discussion which informs both of us.
I for one would welcome more posters of his calibre.
M
Mr. Arnold
Jon Skeet said:Excuse me? How about:
<quote>
Don't you know? It's MS and what works up in the IDE and what works
when you deploy it are two different things. I have been there an done
that.
</quote>
and
<quote>
How long have you been programming with MS solutions not to know that
what happens in development or the test environments may not hold true
when a solution hit's out there in the production environment?
</quote>
To me that sounds like a suggestion that you believe it's buggy.
Perhaps you could correct my interpretation of your posts.
MS solutions as far back Visual Basic 3.0 that I have worked with have had
issues, some little quirkiness in them.
It's been my experience that some things just don't work as expected with MS
solutions, sometimes, and one has to be aware of it. Not just with MS
solutions, but with all the solutions on various platforms I have worked on
over the years have had quirkiness about them.
After all, it's all written by fallible Human Beings. When we are prefect,
then I'll expect everything we do or create to be perfect. Well, that's not
the case with anything we create or do.
And there were IDE(s) for MS solutions well before .NET hit the scene.
Now, you can interpret that anyway you want. But that does not indicate that
I was speaking of .Net's IDE per say, but rather, what my experiences have
been in programming MS solutions over the years.
I am happy that you feel that way about him. I'll put it to you point blank.
He doesn't mean anything to me. I think he is a PITA with a smart mouth,
from my encounter with him.
The whole thing is/was much to do about *nothing*, and I'll know to avoid
him in the future.
M
Marc Gravell
Well, you have to admire frankness; it saves a lot of time.
I have just re-read all of Peter's posts in this chain, and all of
them seem perfectly contextual, factual (not personal / judgemental),
polite, businesslike and proper.
Without tone-of-voice, can I humbly suggest that you might have taken
some comment(s) in a way that the rest of us just aren't seeing?
Anyway, it doesn't matter much in the grand scheme; let's just get
along, eh?
Marc
I have just re-read all of Peter's posts in this chain, and all of
them seem perfectly contextual, factual (not personal / judgemental),
polite, businesslike and proper.
Without tone-of-voice, can I humbly suggest that you might have taken
some comment(s) in a way that the rest of us just aren't seeing?
Anyway, it doesn't matter much in the grand scheme; let's just get
along, eh?
Marc
M
Mr. Arnold
Marc Gravell said:
I'll just say this. I didn't read all of his posts. The last post he posted
to me, I considered parts of it to be out line, showing disrepect.
We'll leave it at that and move on. I suspect I'll just have to ignore him.
Z
Zytan
You said:
Exactly. It's funny how the current argument has absolutely nothing
to do with the initial claim. The initial claim is simply wrong.
Mr. Arnold, you claim that my original code was wrong is simply
false. If you're trying to make a statement other than this, then you
need to be very clear about what you are talking about, and you should
clear up what you meant to say instead of the above. I have come to
the same conclusions as to what you're trying to get at as Peter has,
and your reaction is that he's putting words in your mouth. But, no
one is reading your mind, so all we can go by is your words, and
that's how we are dervied what your argument is. Right now, you're
doing a poor job of explaining what exactly is wrong with my (ugly)
code, so we're struggling to understand where you're coming from,
especially when the code is 100% legitimate and will never blow up.
The only thing I can get from you is that it's Bad News to mess with
the loop iterator within the loop. But, the way loops are implemented
are well defined, so this is ok.
I am completely lost with your position.
Zytan
Z
Zytan
I'll put it to you point blank.
That type of reaction only arrives from being defensive. It's
illogical, and emotional, and thus meaningless. Once you step back
from this argument, and remove the emotional, you will certainly agree
that your above conclusion is false. Wht? Because I am uncertain how
he could have possibly been more factual and logical in his words. I
can't say the same for you, because nothing you've said was clear
(actually, it was clear, but then you say you meant something else, so
it become very unclear, and totally lost me).
Actually, it was about you saying that changing the loop iterator
within a loop is bound to blow up. Peter tried to tell you this is
completely false. He's right.
Arnold, I seriously appreciate your effort to show me that my code was
wrong, but I still have no idea why you think it is wrong. Just tell
me what is wrong with it. Because NET may change the way loops are
implemented? Perhaps an optimization could affect the way an
interator is changed in mid-loop? I agree it seems ugly. Back in the
day they used to be optimized to the CX register, and changing it in
mid-stream would have no effect. It still seems ugly to do it today
(I've never argued my code was nice), but I believe that the loop
implementation allows this now, and that's not going to change, for
backwards compatibility reasons if nothing else.
Zytan
That type of reaction only arrives from being defensive. It's
illogical, and emotional, and thus meaningless. Once you step back
from this argument, and remove the emotional, you will certainly agree
that your above conclusion is false. Wht? Because I am uncertain how
he could have possibly been more factual and logical in his words. I
can't say the same for you, because nothing you've said was clear
(actually, it was clear, but then you say you meant something else, so
it become very unclear, and totally lost me).
Actually, it was about you saying that changing the loop iterator
within a loop is bound to blow up. Peter tried to tell you this is
completely false. He's right.
Arnold, I seriously appreciate your effort to show me that my code was
wrong, but I still have no idea why you think it is wrong. Just tell
me what is wrong with it. Because NET may change the way loops are
implemented? Perhaps an optimization could affect the way an
interator is changed in mid-loop? I agree it seems ugly. Back in the
day they used to be optimized to the CX register, and changing it in
mid-stream would have no effect. It still seems ugly to do it today
(I've never argued my code was nice), but I believe that the loop
implementation allows this now, and that's not going to change, for
backwards compatibility reasons if nothing else.
Zytan
P
Peter Duniho
All of your posts have defended the claim that the loop will "blow up"
based on the assertion that "MS solutions" don't do what they're supposed
to. I'm not sure how I'm supposed to interpret that other than you
claiming .NET is buggy.
The only way decrementing the variable i "could possibly lead to a
termination at RemoveAt(i)" is if .NET is buggy. The language is
well-defined and the behavior of the loop is well-defined based on the
language, and according to the language definition, the loop has no
trouble at all with decrementing the variable i in the loop. So, again,
the only way anything wrong could happen is if .NET doesn't implement the
language correctly.
In other words, it's buggy.
I beg to differ. I agree that it's generally poor convention to modify a
loop counter from within the loop, but both C and C#, and any number of
other languages, do permit it and the behavior is well-defined.
You said it would "blow up". How is that not saying that there's
something wrong with the code?
lol...I didn't realize this was a pissing contest. Sorry. I admit, I
haven't been "in the IT field since 1971", but I have a lot more
experience than you are giving me credit for (and more experience with
Microsoft and Windows than you yourself have). In any case, this
discussion isn't about who has the most experience. If I had only been
writing Windows software for 12 months, my statements would be just as
correct as they are given the experience I do have.
Why would I comment on anything *but* the loop? This entire thread is
about the loop.
I suppose that's your prerogative. I was simply using my other post
elsewhere in this thread as an informative example. If you don't care to
consider all of the available information, you are free to choose not to..
In what way is that relevant to whether one should modify a loop counter
from within the loop?
It's true, I have an almost pathological need to get the details right.
Turns out that's actually a useful personality trait in the programming
business. Still, my pathological need to get the details right doesn't
change the incorrectness of claiming that there's something fundamentally
wrong with modifying the loop index from within the loop.
As near as I can tell, the main reason my pathological need to get the
details right annoys you so much is that you yourself have the details
wrong, and pointing that out bothers you for some reason.
For what it's worth, I've made my own share of mistakes posting in this
newsgroup (and others, for that matter). People have pointed those
mistakes out, and rather than getting all defensive about it, I simply
admit my mistake and move on. You might consider that approach as being
more useful and productive in your own posts.
Nobody is perfect, and nobody should expect anyone else to be perfect.
The real question is whether a person has enough character to admit their
mistake and learn from it, rather than dig in their heels and create a
mountain out of a molehill.
Pete
M
Mr. Arnold
<Plank> - That's a soft logical <plonk>.
I didn't bother to read it.
It's time for you to <disappear>.
I didn't bother to read it.
It's time for you to <disappear>.
M
Mr. Arnold
I see it differently, and somehow you got it into your head that what I told
you what you were doing was wrong. I don't recall me writing the word
*wrong* in any sentence.
If you go back to my posts to you or to this other person Pete, you pick the
one sentence where I wrote the word *wrong*.
All I said is that you shouldn't use (i) the way you were doing it, because
that could lead to the loop blowing.
In the long run, you do what you want. It's your code. You have to support
it, not me.
I really don't care. It's much to do about nothing with you and the *loop*.
P
Peter Duniho
But that's not a true statement. Using "i" the way he's using it could
*not* "lead to the loop blowing".
(Ignoring for the moment the odd implication of your post that saying that
the loop could "blow" is not the same as saying that it's "wrong")
J
Jon Skeet [C# MVP]
You don't need to write the word "wrong" in order to give the
impression that what someone is doing is wrong. For instance:
<quote>
All I said was not to decrement (i) like that, that the loop is
controlling, which could possibly lead to a termination at RemoveAt(i).
</quote>
Telling someone not to do something gives the impression that you think
that what they're doing is wrong, doesn't it?
Likewise:
<quote>
No, you don't decrement (i) like that, you're going to eventually blow
up at that RemoveAt(i).
</quote>
Saying that someone's code will "eventually blow up" is telling them
that their code is wrong, in my opinion.
Just as another example of this, but this time from me, just now:
Saying that the loop will blow up is an incorrect statement.
There - I've just said that you were wrong, without using the word
"wrong" in the sentence at all, haven't I?
That's easy:
<quote>
Again, I never said there was nothing wrong with the code.
</quote>
Message-ID: <#[email protected]>
The double negative doesn't help matters, but it certainly includes the
word "wrong".
Except that it couldn't, which is Pete's point. The code *won't* blow
up, unless there really *is* a bug in .NET in this respect, which
(despite your later claims to the contrary) you heavily implied that
there is.
That doesn't mean the code is the best way of writing it - no-one ever
claimed it is. We've just all maintained that it won't "blow up" at
mylist.Remove(i) contrary to your claim.
Now, were you actually maintaining that you believe there *is* a bug in
..NET (in which case you should apologise to Peter for saying "This is
all coming from you. I didn't say anything about .NET being buggy.
It's out of your mouth that it's being said") or were you maintaining
that the code did actually have something wrong with it, a logical
error which can cause it to fail *without* there being a bug in .NET
(in which case you should show that error)?
The trouble is that by repeatedly claiming that the loop won't work
without giving any evidence, and by making ad hominem attacks, you've
made it about more than the loop. You've made it about an inability to
back down.
I wouldn't have got involved in this thread at all if you hadn't
started attacking Peter without any cause, for example.
M
Mr. Arnold
Please, you're painful.
M
Mr. Arnold
Please, you're painful.
D
Dhiraj Bhandari
Please, you are just illustrating how really stupid you are.
M
Mr. Arnold
Yeah, yeah now <disappear> you have said what you needed to say, move on.