Basically, as my recent post in the .Net forum has mentioned, I've discovered you can't apply operator++ to unnamed temporaries. I don't know if that's the proper word for it or not, but essentially it means ++container.Begin() is invalid. This mostly makes sense, but it doesn't seem like something that would be impossible to overcome. Just create an unnamed temporary that is immediately discarded, no big deal.
That wouldn't be quite so big a deal except for this: the C# compiler isn't smart enough to know that its against the rules. Instead, it spits out invalid code that, at run time, throws a nasty exception. The situation is slightly better if Begin is a read-only property instead of a function --- then, the compiler crashes when it sees the code. So at least you know in advance something is wrong, rather than silently emitting invalid code, even if a compiler error would be more appropriate.
So what, exactly, does this mean for the SGL? Well, it could well mean that I'm done. Things like for(Iterator i = ++vec.Begin(); i != vec.End(); ++i) are not exactly uncommon in my code. I certainly can't imagine a more straight forward way of skipping the first element in a container. Technically, I could use vec.Begin().Advance(1), but that's ugly. Seriously, I can't stand it; my test code is littered with it, and every time I write a loop I die a little inside.
And more importantly, the compiler won't stop me, or anybody else, from using the first form. It'll just happily spit out invalid code that'll cause the program to choke when executed. That's unacceptable.
Perhaps I should buckle down and learn C++/CLI. Perhaps, since that is perfectly valid C++ code, it will also be perfectly valid C++/CLI code. And the whole project will be saved. I doubt it, though. I'm a little too tired to be optimistic at this stage.
CM
Take note that with the advent of C++0x and first-class Concepts it is highly likely the entire framework is going to be reworked on. The C++ standards committee are fully aware of the short-commings of the standard library containers & generic algorithms model, Boost.Iterator library addresses some of the issues but it's not enough.
Anyways I think you could use a more suitable & more theoretically correct model for C# (especially with C# 3.0 and above) however there is just on major problem, you cannot constrain type variables (generic type parameters) for all types t such that t supports a particular or a set of operator overloads. You would have to use named methods which kinda of sucks.
Also C#'s generic type constraints need some working to have better support of datatype-generic programming, read Variance and Generalized Constraints for C# Generics it seems that microsoft maybe working on it in the future.