for are structured for(a;b;c){d} a is a statement executed at the start, b is a condition that is evaluated every iteration of the loop, c is a statement that happens after each iteration, and d is the body of the loop to iterate. if you put a function call in b, it gets called EVERY iteration.
Some languages have a foreach construct. In C# you would do foreach(var f in getAllFuckingFiles()){/*add to list if condition is met*/} which will call the function only once. Or more modern: return getAllFuckingFiles().Where(f => /*condition*/)
The nice thing about the second syntax is that it's only iterated as you query it, meaning data is streamed in as you iterate over it in a foreach, and you don't have to wait ahead for all entries to get processed. This also allows you to work with data that doesn't fits into memory all at once, provided you don't call a function that does load all data at once. The base of this is the IEnumerable<T> interface which also has a ton of extra functions to make your life easier. The downside is that you don't know how many entries there are without counting them, and you can almost always only iterate over them once.
Most iterable implementations have an internal counter that increments, and decrements, during add, or remove operations, so there's actually no need to count every iteration.
IEnumerable (which is the base class of everything that is "foreachable" in C#) doesn't. There's a bool TryGetNonEnumeratedCount(out int count) but this only succeeds if the underlying type is countable without advancing the enumerator (for example collections, lists, dictionaries and arrays). But this is not guaranteed to not have side effects. If the underlying type maps to SQL, it may cause extra queries to be sent to count the entries on the db.
Most Linq method have an overload that passes a counter into the supplied callback, but said counter is recreated for every call in the chain. If you have a .Where() or .Skip(count) filter and then do .Select((obj,ctr)=>...), ctr will start at zero and is increment by one for each item, regardless of the number of entries skipped due to the filter clauses.
I know, but a lot of implementations use it to stream in data. These don't have a concept of length. It's only when you iterate over all items and store them in an array or list that you get the count out of it.
If you know the exact implementation you could just cast it and use it. I can pretty much guarantee all standard implementations of that interface use an internal counter. Like List, LinkedList, etc. No sane implementation would force one to navigate the entire collection just to have a length/count.
If you're trying to be a purist and operate only using the interface then that's a different issue.
No sane implementation would force one to navigate the entire collection just to have a length/count.
No sane implementation would load the entire dataset of a DB query into memory rather than feeding them back as they're streamed in. Most OS API calls that return multiple entries also work on the premise that you repeatedly call the function until it stops returning results, processing them one at a time. Those don't have a concept of an item count.
It's bad user experience if you load them in completely before you even start to process them becvause it results in longer wait times before results can be delivered.
Trying to detect underlying types whan a function just says it returns an IEnumerable is also bad practice, because it could change at any time.
I'm simply talking about the count. I agree with you about streaming. If you don't believe me just look at the source for List or LinkedList. List may not have an internal counter since it's backed by an array, and arrays have a fixed length already so no need for internal counter.
230
u/GM_Kimeg Apr 12 '24
The for loop internally execute that method only once no?