Jump to content
Sign in to follow this  
  • entries
    16
  • comments
    27
  • views
    15607

C# was designed to not implement the SGL

Sign in to follow this  
Conner McCloud

476 views

That's the conclusion I've reached. After jumping through dozens of hoops to finally get everything to a point where it pretty much works as you'd expect, they light one of the hoops on fire and put it over a shark tank. And the sharks have fricken lazers on their fricken heads.

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
Sign in to follow this  


3 Comments


Recommended Comments

I haven't been following your progress however I think it's not worth trying to emulate std C++ containers & algorithms model, this model isn't entirely correct (theoretically-wise) besides.

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.

Share this comment


Link to comment
Quote:
Original post by snk_kid
I haven't been following your progress however I think it's not worth trying to emulate std C++ containers & algorithms model, this model isn't entirely correct (theoretically-wise) besides.

Yeah I largely agree that emulating them in C# is a bad idea. My primary purpose has always been just to prove it was possible given the limitations placed on generics. I think I succeeded in this goal, so I'm not entirely dissatisfied with where it ended up. It just would have been nice if I could have taken it to completion, even though I never had any intention of actually using the library. I have more than enough half finished projects sitting around on my harddrive.

And besides, the last few weeks I've been itching to make something real, possibly with XNA, and this gives me just the excuse I need to switch gears.
Quote:
Original post by snk_kid
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.

One of the MS blogs has suggested this is on the drawing board for things to fix in the future. Naming them intuitively might be clumsy, but after that they're just function calls like anything else. The fact that they're static may make things a bit more tricky, but it generated the proper code for me, so that must not be an impossible barrier.

CM

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!