|
Hello folks!
I did a little spy-out (with Reflector(c)) the DataView-Class. And found the following:
public IEnumerator GetEnumerator()
{
DataRowView[] array = new DataRowView[this.Count];
this.CopyTo(array, 0);
return array.GetEnumerator();
}
Do I understand right: Each foreach-Initialisation it will copy all its Content to a new array, and return that arrays Enumerator??
And if I break the foreach-loop at second element all these DataRowViews came into live in vain?
|
|
|
|
|
Yeah, must be some old code.
Try not to use foreach if you expect to break the iteration.
|
|
|
|
|
PIEBALDconsult wrote: Try not to use foreach if you expect to break the iteration.
Thats the first time I hear this advice. It results in some little pretty ugly workarounds, doesn't it?
No - I expect the coders to make their enumerators efficient and keep on enjoing the better design of foreach (if available).
|
|
|
|
|
Actually, it's the result of one of the tenets of iteration development. If you have to use a break statement (or god forbid a goto) to get out of a loop, you are using the wrong type of loop. Have a look at Code Complete by Steve McConnell to find more gems like this.
|
|
|
|
|
Hm, I'm real puzzled. Whenever I was searching anything in any Enumerable I used foreach. And broke the loop when I did find, what I wanted.
Sample - how you would improve this little thing?
public TreeNode GetNodeByText(TreeNode Parent, string Txt) {
foreach (TreeNode Nd in Parent.Nodes) {
if (Nd.Text == Txt) return Nd;
}
return null;
}
And how do you think is ICollection<T>.Contains() implemented in hundreds of classes?
Steve McConnells Code Complete Loop - Chapter seems not to be available (for free, I mean).
modified on Friday, January 25, 2008 5:28:44 PM
|
|
|
|
|
Well, try not to, but some times you may need to.
Having said that, you may be able to iterate with the index of the nodes.
Or, if you do more searching than adding/removing, you could use a Dictionary<string,TreeNode> to speed up the search.
|
|
|
|
|
So - if somebody else writes bad code you think it's your duty to also write bad code? Just because somebody gives you a foreach doesn't mean that you have to use it in every case. Take a look at the alternatives such as the do/while loop.
Mr.PoorEnglish wrote: Steve McConnells Code Complete Loop - Chapter seems not to be available (for free, I mean).
So do what others do and buy a copy of the book. You won't regret it.
|
|
|
|
|
lol, you are supposed to ignore using break/return completely so you have something to optimize later:
Check out "The Speedup loop"
http://thedailywtf.com/Articles/The-Speedup-Loop.aspx
I could never bring myself to intentionally build a "speedup loop".
|
|
|
|
|
(Please note the joke icon.)
Mr.PoorEnglish wrote: pretty ugly workarounds
Programs are like women:
They can look good but not work.
Or they can work but not look good.
|
|
|
|
|
PIEBALDconsult wrote: Or they can work but not look good.
That's me
|
|
|
|
|
Entirely depends on the cost of DataRowView - it may be a simple reference holder / adapter class whose creation is cheap, and CopyTo likely does only a flat copy (I don't know, though).
An alternative might have to inject very complex code code to provide the same isolation level (e.g. allowing insertions and deletions applied to the underlying dataset during your enumeration).
So this might be a WTF, or might not.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
peterchen wrote: Entirely depends on the cost of DataRowView - it may be a simple reference holder / adapter class whose creation is cheap, and CopyTo likely does only a flat copy (I don't know, though).
Hi peterchen!
I did investigate that and found out, inside of DataView there is an "Index", managing a RBTree, and CopyTo takes the RBTree-Enumerator, who emits Integer - Indicees. These Indicees do reference the target-Datarow in a rowCache-array of the DataTable.
To finally access the DataRowView there is a rowViewCache - Dictionary<DataRow, DataRowView> inside DataView.
I built my own enumerator as wrapper of the RBTreee-Enumerator.
This makes a enumeration-speed-up of DataRow of (only) 1 : 1.5 for 831 DataRows.
To access only the first DataRow (then break foreach) the speed-up-factor is 1 : 4.
So now I'm actually unshure, wether my selfmade-enumerator is worth-while.
|
|
|
|
|
Interesting results - and good you investigated that! So indeed there are reasonable performance tradeoffs.
In any case, I wouldn't expect the enumerator to be optimized for a "break after first". That's a very uncommon scenario - and if you run into it frequently, and it hits your performance, you could always optimize by "get first, test, then enumerate" on the caller side.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
A former place of employment wrote a LOT of engineering software (Fortran naturally).
This was at a time when we were just able to get our hands on a 640kb PC, the software, even with the best compilers and linkers available still sat at over 800kb.
One of the programmers was prone to naming variables using expletives, which made debugging fairly tedious, there's only so many sh#ts and fu$ks you can put up with before it becomes tiring. However what brought the most amusement was a variable for "Volt Drop Analysis" - it was abbreviated to "VDAnal". Nobody could keep a straight face while debugging that section of code, because it was just so unintentional.
|
|
|
|
|
Reminds me of a time, many years ago, when I worked for someone who thought it was fun to prefix every variable with his initials. He just didn't get why it was wrong.
|
|
|
|
|
I used to use the hungarian rg (for range) notation for an array - as in rgKeys - one of our Seniors at an old job consistently told people it was cos of my initials, and copiously took the proverbial...he felt silly when I explained 
C# has already designed away most of the tedium of C++.
|
|
|
|
|
digital man wrote: He just didn't get why it was wrong.
It is rather to tough to make them understand that their stand is wrong and to correct them. It is a proven saying that it is hard to straighten a dog's tail as also that in the particular case it would like singing near the ear of a total deaf man.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
digital man wrote: He just didn't get why it was wrong.
Out of curiosity why is that wrong?
a) All the user defined variables are together in the auto complete box (intellitype)?
b) As long as the rest of the name reflects it's use, what does it matter?
c) In a team based environment it keeps a (admitidly fairly rudamentary) track of who coded what
|
|
|
|
|
Lee Humphries wrote: One of the programmers was prone to naming variables using expletives, which made debugging fairly tedious, there's only so many sh#ts and fu$ks you can put up with before it becomes tiring. However what brought the most amusement was a variable for "Volt Drop Analysis" - it was abbreviated to "VDAnal". Nobody could keep a straight face while debugging that section of code, because it was just so unintentional.
I can't believe that anyone would do that. We are supposed to be professionals. If I was his supervisor, he would be fired the first time I saw that. Very unprofessional, immature, and like you said, very difficult to debug.
I'm going to become rich when I create a device that allows me to punch people in the face over the internet.
"If an Indian asked a programming question in the forest, would it still be urgent?" - John Simmons / outlaw programmer
|
|
|
|
|
Justin Perez wrote: Very unprofessional, immature, and like you said, very difficult to debug.
I agree, however......
A bit of fun boosts moral and increases productivity.... Lee still remembers that code whereas I bet he doesn't remember much other code from the same period.
|
|
|
|
|
A colleague of mine keeps talking about an intern they had, and who simply had not understood the concept of variable names.
When he was told that "A", "B" and "C" where not to be used, he felt forced to resort to somewhat totally arbitrary:
He started to use animal names: "lion", "rhino" and "giraffe" and so on.
His variable named "giraffe" was left in the code as to commemorate this guy.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
jhwurmbach wrote: His variable named "giraffe" was left in the code as to commemorate this guy.
And if there was a variable named 'dinosaur', that module can be declared obsolete too. Sometime back we had an interesting discussion on Dinosaur and VB in Soapbox. Perhaps if you are interested, check out this permalink:
http://www.codeproject.com/script/Forums/View.aspx?fid=2605&msg=2377913[^]
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Well, thats a step up from most Fortran code you see, which usually uses single letter variables - two letters if you're lucky.  /
|
|
|
|
|
We've got a ReleaseAnalWnd function kicking about in our codebase.
I've no idea if it was originally intentional or not as it's been sitting about since the dawn of the windows version of the software.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
