.NET Enumerators vs. STL- STL.NET is still not released

As a frequent STL user, I can say that iterators are indispensable, but often an Achille's heel for those new to STL.  It is easy to use iterators incorrectly, such as by not obeying the conventions, or modifying the collection in an inobvious way such as to invalidate the iterator.

One common STL problem is deletion, in this case, if the last element is deleted, the iterator it be moved beyond the end of the collection.  This is a typical beginers mistake; the STL environment provides for an implementation of this algorithm that correctly deals with the iterator (using a while loop).  Beyond that, STL is just a little more complicated for the uninitiated, but Iterators are not the most complicated part, and they are generally easy to use and straightforward.

for (it = collection.begin(); it != collection.end(); it++)
{

  if ( (*it).BoolMethod() )
    it = collection.erase( it );

}

Sadly, .NET's Enumerators are a far cry from STL's and they leave us with much less control or power.  Inorder to reverse traverse a collection, you either must reverse the collection (an O(1) operation) or simply write a different loop with an index that moves through the elements in reverse (as opposed to a reverse iterator)

for ( int i= collection.Count-1; i >= 0; i--)  
{
    // Do work
}

"i" in this case is a fairly poor iterator.  This is a concrete value that defines the boundaries of a class, and is not an extensible object.
The advantage is that this is much more understandable to the VB user; Iterators and Generics are much more complicated.  It is something that happens in the .NET space; the interface speaks to the average developer, not the C++ developer.  Or the Java developer.

On the other hand, less power means fewer bugs!  During a discussion with a co-worker, it was pointed out that adding more complicated features would increase the number of bugs.  In the practical sense, this is true; if you have no features, there can be no bugs.  But finding the mid-point between useful features and unneeded complexity is important, and you need to consider the people who will use them is another.

STL.NET (STL/CLI) Preview release (Sept. 2006) for use with the pre-release of VS 2005+1 ( called "Orcas", which is the next release of Visual Studio). 

STL.NET Release announcement
https://blogs.msdn.com/nikolad/archive/2006/09/30/STCLRinOrcasSeptemberCTP.aspx

STL.NET Primer

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/stl-netprimer.asp

Comments

• Anonymous
  December 03, 2006
  Another point is that in .NET, you basically can't modify the collection AT ALL while you're enumerating it. If you do, an exception is thrown the next time you try to access the enumerator. So your example of removing an element from a collection is much, much more difficult in C#.However, the rules for invalidating iterators in the STL are quite complicated and are different for each collection -- I'd say > 3/4 of C++ developers don't understand them at all. The .NET rule is dead simple -- if you modify the collection, your enumerator is dead.
• Anonymous
  December 05, 2006
  Dean,Right, if you make it simple enough and remove any chance of being cut by the sharp edges, you will essentially have a less useful tool that is safe for even small children to play with.  And STL is too complicated, I agree.  Most people stick to the basics, swim in the shallow end of the pool.Still, it would be nice to have STL.NET for those of us who, at least internally, want to use STL, if not expose STL types to the outside world.  To me, that's sort of a dissapointment when looking at the .NET platform as a whole.