C++ < C#

Yeah, got to agree with the others that saying "Where would you ever use LINQ in a GAME?" is ridiculous. I use it everywhere, all the time, and yes, it is way faster than your custom C++ code will ever be. Sorry. In fact, do you know how much time is spent running the linq query in my example? Zero! That's one of the nice things about LINQ performance: deferred execution.

On the flipside, I have never once in a game had to write a ton of constructors containing non-wrapped resource handles such that I ever thought "Oh god I wish I had auto_ptr". I don't think I've ever wished for auto_ptr in my life; I mostly wish it would go away when I see it.

 

But like I said, if you're trying to use C++/CLI then your auto_ptr example is no longer valid, as auto_ptr objects aren't going to work with anything from .NET particularly well. And some random dude's attempt at a wrapper on CodeProject is not a good substitute for the real thing.

But it was built for C# and C# expanded to use it; C# has the language constructs needed to use LINQ properly: inferred type declaration (var), dynamic types, query keywords (from, select, etc).

Lol... Microsoft focus on Javascript... lol again.

 

Could you maybe name one example, anywhere, where you had to trade "performance for simplicity" when using LINQ? I think this is the "programmers must suffer" instinct that some developers have. They see a simple piece of code and think "Hmm... looks TOO easy. Must be bad for performance. I'll do it the really hard way." That's the same silly instinct that causes people to waste years of their teams' lives trying to rewrite the entire STL because they're convinced that they need to do everything the hardest way possible to satisfy the demands of the performance gods. Sometimes it is helpful to admit that you might not be the best programmer in the entire known universe, and that perhaps a billion dollar research and development department containing a bunch of experienced developers working for ten years MIGHT just actually know what they're doing as far as performance costs.

 

+ that, finally someone who gets it, easy high level code doesn't mean performance has to suck

 

std::auto_ptr<T> in particular will not work at all.

msclr::auto_handle<T> however is awesome and will work perfectly. (http://msdn.microsoft.com/en-us/library/ms177066.aspx)

Since everything is on the heap in .NET managed languages (so stack based smart ptr containers can't work), it actually works by modifying the output of intermediate language in all areas where the contained variable is used with a try/fault cleanup. (The IL is messy, but the functionality is critical).

Code (csharp):

1.  
2.   MyClass()
3.   {
4.         myDisposable.reset(gcnew MyDisposable());
5.         throw gcnew Exception("Hello World");
6.         // myDisposable needs to clean up now
7.         // because it is very large or locks a limited resource.
8.         // Luckily with RAII.. it does!
9.   }
10.  
11. ... becomes...
12.  
13.   .try
14.   {
15.   IL_0006:  ldarg.0
16.   IL_0007:  ldloc.0
17.   IL_0008:  stfld      class msclr.'auto_handle<MyDisposable>' modreq([mscorlib]System.Runtime.CompilerServices.IsByValue) MyClass::myDisposable
18.   IL_000d:  ldarg.0
19.   IL_000e:  call       instance void [mscorlib]System.Object::.ctor()
20.   IL_0013:  ldarg.0
21.   IL_0014:  ldfld      class msclr.'auto_handle<MyDisposable>' modreq([mscorlib]System.Runtime.CompilerServices.IsByValue) MyClass::myDisposable
22.   IL_0019:  newobj     instance void MyDisposable::.ctor()
23.   IL_001e:  call       instance void msclr.'auto_handle<MyDisposable>'::reset(class MyDisposable)
24.   IL_0023:  ldstr      "Hello World"
25.   IL_0028:  newobj     instance void [mscorlib]System.Exception::.ctor(string)
26.   IL_002d:  throw
27.   IL_002e:  leave.s    IL_003c
28.   }  // end .try
29.   fault
30.   {
31.   IL_0030:  ldarg.0
32.   IL_0031:  ldfld      class msclr.'auto_handle<MyDisposable>' modreq([mscorlib]System.Runtime.CompilerServices.IsByValue) MyClass::myDisposable
33.   IL_0036:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()
34.   IL_003b:  endfinally
35.   }  // end handler
36.  
37.  

In other words, C++.NET has best of both worlds now. (garbage collection and deterministic destruction).

Metro apps (stuff for the Microsoft app store, can be written written in C++/CX, .NET or Javascript. We have had the Microsoft guys round to our company to talk with us about the Windows market place, and they are highly recommending moving to C++/CX or Javascript for metro apps. Not C#.

Admittedly the Javascript will have microsoft extensions to make it similar to C#. (such as a class keyword etc...).

http://msdn.microsoft.com/en-us/library/windows/apps/br211385.aspx

The underlying implementation of LINQ is part of the .NET VM. That is written in native C++... So yeah, LINQ is about as fast as it will get. In C#, you only use the bindings which don't do much processing.
Kinda the same reason the Unity engine is written in native C++ rather than entirely in C#.

 

I should point out that there is no underlying implementation of LINQ. Maybe you're thinking of LINQ to objects?

It's a small but important clarification.

 

I posed the challenge to post a use case where LINQ was the best solution; no one has risen to that challenge. I have already explained the alternative algorithmic optimization of using separate data structures.

You are wrong, don't straw man. I posed a simple question, if LINQ has any purpose whatsoever in game development explain the use case.

Blind faith in libraries does not go a long way for performance critical code. Tools are designed for specific purposes, their highest priority is not always performance. However, this is completely unrelated to the discussion at hand. Post a use case for LINQ in a game.

 

Their hightest priority is not always performance, but in LINQ's case IT IS and that's most people don't get. LINQ WILL produce MUCH MUCH faster than what any sane programmer usually writes for any NON TRIVIAL data transformation (anything taking an object graph and returning a very diferently typed/shaped object graph) because while it's possible and even easy to write code that's faster than LINQ, the type of code you'd usually write looks nothing like that type of fast code (litered with mid loop nested 4 or 5 level deeps conditional breaks).
Anything sane, maintainable, and non trivial can be kept as such with usually a performance boost (or, in some edge cases, no performance change) in LINQ. That's the main goal of LINQ, better composability / readability without sacrificing performance. And i've written many "thouthands" of lines of LINQ (probably 10-20K lines of LINQ, including some 500+ lines long queries for some very specific performance critical cases)
For reasonably readable code, by design, linq will use less memory (streaming, no buffers) and cpu (pruning) with very very small overhead (unless you're doing trivial stuff like just I++ on a per element basis, as then the overhead becomes comparatively large) per element.

If you have any non trivial graph reshaping / complex querying that you're doing by hand i'd be glad to port them to LINQ and compare the perf, if you only have simple 1 level foreachs working on simple types applying 1 or 2 operations, then that's simple not a use case for LINQ, LINQ isn't a foreach replacement.

 

I see no use case there, so I take it you are conceding that LINQ is completely useless for games?

 

Certainly not no, i don't see myself living without it, if you don't see any use cases for what i mentioned, then there's no use for you (not for games, for you) but that doesn't change the key point i made (which wasn't to convince you to switch to linq) that using LINQ in games (where appropriate) is like using LINQ anywhere else, usually resulting in more performant / less memory hungry code and not the reverse.

I can think of hundreds of use cases (anywhere you'd want to display data in 2 diferent shapes for exemple a leaderboard) but i can't give you any specifics out of the blue like i could when explaining foreach as programming with LINQ required a diferent mindset and it tends to grow on you, you don't covert code X to linq, you just don't write code that looks like X at all when you know LINQ, and the LINQ solution usually performs a lot faster.

LINQ has a purpose anywhere you have nontrivial data structures you need to traverse or reshape, a logical tree like unity's hierarchy made of nested gameobjects sounds like quite the perfect match . . .

 

Excuse me, your entire argument is based around the premise that there are better ways, or more performant ways of doing something.

Yet you've not demonstrated a since case where this is:

A) True.

B) A beneficial improvement.

Not using LINQ because it's perceived to be slow is like not using C# because assembly is 'faster'. It ignores many metrics for an arbitrary and ultimately [by itself] useless one.

 

Why are people getting worked up over the performance of something that's not going to be run on a per-frame basis anyway?

 

When certain code impacts per-frame results is extremely complicated.

Though I would tend to agree that it's not normally an issue either way.

 

Well... no, it shouldn't be. If you're doing a large and non-trivial data structure transformation per-frame then you've probably got design issues, regardless of what language or tools you're using. If you're not doing it per-frame, then it should not effect per-frame performance.

 

It depends
1) you can do some non trivial data structure transformation on a small data set , so might as well make it maintainable and quick
2) you can do some things on a non per frame basis, that aren't at load time either (some simulations can run all the time, the faster the merrier) and those could be on complex graphs

 

If I pick a use case then you can easily call it contrived, and it probably would be since I do use LINQ. I haven't encountered any tasks which require it when developing games. That is why I have put the challenge out there to any of you LINQ evangelists, to pitch a specific use case.

That challenge remains. All I have asked for is a specific use case where LINQ is the best solution in a game context.

 

Which'll have had a heck of a lot more power if you'd noticed the two examples I posted 3 days ago.

 

Ok I have a question about C++ structuring..

I was looking at the way the Visual Studio IDE sets up a Windows form application in C# and I was wondering can a C++ program be structured the same way? For instance can I have one source file that runs main which points to another source file with all my code? Because I don't like how main has to come after all your methods and what not in C++ I like main at the top of the source code(I know the work around for this in C++ to have something like the main function at the top still not the same thing and IMO it just makes the code sloppier)...

 

This still wouldn't work. The function at the top would still have no idea of the implementation of the functions defined after it without forward declares.

main only needs to come after your methods in C++ because the way the parser works. It needs to know the definitions of the functions before it can use them. This requirement can be removed by simply forward declaring the functions before they are called. (or declare them in a header file and include that).

However, if the code is structured in a correct object orientated way, then you wont need to worry about this, (since the functions will be declared within a class within the header).

Microsoft Visual Studio 2005 allows you to create a C++ Winforms application. Perhaps do that and look at how the default layout is done. (You might be able to then update it to Visual Studio 2012). Though I wouldn't recommend it because this layout of code is warped in such a way purely to increase interoperability with the GUI Building tool.

for a simple solution to the specific issue you were experiencing...

Code (csharp):

1.  
2.  
3. void hello();
4. void turtle();
5.  
6. int main(int argc, char* argv[])
7. {
8.   hello();
9.   return 0;
10. }
11.  
12. void hello()
13. {
14.   turtle();
15. }
16.  
17. void turtle()
18. {
19.   std::cout << "Turtle!" << std::endl;
20. }
21.  
22.  

So the declares at the top could go in a header file.

Remember, you should be using classes really or you will generally be writing C. (afterall, C# doesn't even let you have functions outside classes, C++ just happens to gives us extra flexibility for many things)

 

That is another thing I am not really fond of... that is the work around I wanna avoid.. i guess main at the bottom isn't so bad it will just take some time getting used to it...

The main thing I wanted to be able to do was leave main and a few core functions in a different source file and have main run another class/source file with most of my core game logic.. After reading this:

It seems if I put all my core game logic in a class in another .cpp source file and inside the .cpp source with main I could just call the class using a header declaration it should work accordingly.. im going to try it..

BTW I have Visual Studio 2008

 

The following is perhaps the simplest example I can give of how header files can be used.
It is almost similar to how C# does it using interface classes (http://msdn.microsoft.com/en-us/library/87d83y5b(v=vs.80).aspx).
Basically the .h file should contain the structure of the class, and nothing more.

main.cpp

Code (csharp):

1.  
2. #include "Test.h"
3.  
4. int main(int argc, char* argv[])
5. {
6.   Test test("Hello");
7.  
8.   return 0;
9. }
10.  

Test.h

Code (csharp):

1.  
2. #ifndef TEST_H
3. #define TEST_H
4.  
5. #include <string>
6.  
7. class Test
8. {
9. public:
10.   Test(std::string someVar);
11. };
12.  
13. #endif
14.  

Test.cpp

Code (csharp):

1.  
2. #include "Test.h"
3.  
4. #include <iostream>
5.  
6. Test::Test(std::string someVar)
7. {
8.   std::cout << someVar << std::endl;
9. }
10.  

 

Here is a simple console message to express my thanks..



I have much to learn still

Code (csharp):

1. #include<iostream>
2. #include<string>
3.  
4. using namespace std;
5.  
6. void MyFunction(){
7.     string userName = "k.pedersen";
8.     char someVar = 'c';
9.     cout << "C++ is very complex!" << endl;
10.     cout << "This syntax with take more time getting used to." << endl;
11.     cout << "Thank you " + userName << endl;
12.     cin >> someVar;  //This was used to stop the console from closing after it ran, not ideal but a quick hack
13. }
14.  
15.  
16. int main(){
17.     MyFunction();
18.     return 0;
19.    
20.  
21. }

and its supposed to say "This syntax will take more time getting used to." I messed up lol

 

I actually believed you and went back through this thread, why do you lie? Either you do not understand what a use case is or you are just trolling, if it's the the former you could have googled it and if it's the latter I have better thing to do with my time. I don't want to hijack the OPs thread any further. You have had ample opportunity to provide a use case and failed to do so, I'm calling this case closed.

 

I can give a global use case:
Anywheyre you're:
- starting with a set of data
- ending with a another set of data or a scalar value computed from the first set of data
- the work per item is non trivial (not a simple increment for exemple)
- and either or both
a) the input and output have diferent types and shapes
b) the non LINQ instrumentation is more complex that a single loop

Pretty much everything that fits those 4 points at once is a good use case for linq to end up with similar or better performing code that will be more maintainable / composable.

 

How are the examples posted not valid use cases? The "use case" for LINQ is pretty simple; you would use it for the same reason you'd use a table query in general. Unless you're saying there's no use case for databases at all, and that everything in the world should be hardcoded in custom data storage structures, which sounds insane. If you have a lot of data (which a lot of games do) and you need to be able to transform and query that data easily, you should use a database and query syntax. You also seem to be implying that a valid use case for a game needs to be something that happens every frame, which doesn't make sense. Games have a ton of code that doesn't happen every frame. Think of something like World of Warcraft, which has petabytes of data for all of its items and player stats, and thousands of ways it needs to be transformed, queried and updated throughout the game and all of its satellite apps. You're going to do all that by hand without a database or any sort of query syntax?

 

I don't think we should bring databases into this discussion, it's been implicitely about linq to objects and will only get more confusing if we add uneelated topics

 

Lol this topic was derailed a long long time ago in a community far far away..lmao.

 

I thought it was about LINQ in general, but even without an external SQL DB you could still have a "database" that is an object in memory that loads text files or whatever and organizes it in some kind of relational database manner. My main point is that if you have a large amount of data that you need to query in different ways, it makes sense to have a query syntax instead of forcing the programmer to convert every query by hand into the base language all over the place because you're convinced that somehow, the programmer is going to know how to write a bunch of clever nested for-loops in for every single query in a more performant way than the compiler. It's especially doubtful that your devs are going to consistently do it if you want LINQ's extra features like late binding and execution, so that you can return queries that are transformable rather than direct data sets.

It sort of reminds me of one guy I knew on a team I worked with once, who was convinced that we shouldn't use SQL because he heard it was slow, and who wanted to write a whole bunch of custom code to handle all of the project's data. He got fired. A whole bunch of crappy devs are convinced that they can out-code SQL or the STL or the CLR or whatever. Or that their project is the one special exception where reinventing the wheel is necessary because it's "customized". Almost all of them are wrong.

 

I like how k.pendersen is explaining the common practice of having to use header files and #ifdef's all over the place for simple things so soon after insisting that C++ code is always so much shorter and more concise than C#.

 

Because you're not clear on what you wanted?

You asked for use-cases... I gave two [purposely unusual] use-cases where I've used LINQ in production. Of course, why bother either clarifying what you're asking for, or working with what's available when instead you can call me a roll?

Okay, let's google 'use case'.

In software and systems engineering, a use case (pronounced /juːs/, a case in the use of a system) is a list of steps, typically defining interactions between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a human or an external system.

http://en.wikipedia.org/wiki/Use_case

If that's what you want then:

A) Be upfront about it.
B) WTF?

 

Hehehe exactly. Going back to page two:

Are headers really as persuasive/redundant as they appear?

 

Heh, my issue with C# is not so much with length of code. It is all to do with the fact that the language is lacking functionality that I find critical for any robust and efficient software.

But FYI, this is a comparison of C++ and C# to solve the same thing as above. (using the same formatting style (no one-liners ))

c++ (15 lines)

Code (csharp):

1.  
2. #include <iostream>
3.  
4. class Test
5. {
6.   public: Test(std::string someVar)
7.   {
8.     std::cout << someVar << std::endl;
9.   }
10. };
11.  
12. int main(int argc, char* argv[])
13. {
14.   Test test("Hello World");
15.   return 0;
16. }
17.  

c# (17 lines)

Code (csharp):

1.  
2. using System;
3.  
4. public class Test
5. {
6.   public Test(String someVar)
7.   {
8.     Console.WriteLine(someVar);
9.   }
10. }
11.  
12. public class Program
13. {
14.   public static void Main(String[] args)
15.   {
16.     Test test = new Test("Hello World");
17.   }
18. }
19.  

Looks like C++ wins here too
Not to mention, in C#, Test isnt even properly cleaned up by the end of it.

 

Comparing LoC on trivial samples is pretty irrelevant too, while droping headers in C# is pretty nice, along with the faster compilation speed, the less LoC comes from API mostly, not the language, it's the HL features that come from the language but yea the less LoC is mostly the .net framework's work for all managed languages, gotta love a single api that you don't have to patch together from ton of libraries.

 

No doubt, large frameworks like .NET and Qt certainly have their place. However, I am a fan of patching together lots of libraries which specialize in a single task rather than being a jack of all trades.
I also like the fact I can maintain my own versions of smaller libraries. (i.e if the API changes and I don't like the new direction it is going).

 

I don't know. I don't like jack of all trades, master of none. But .NET feels more like jack of aml trades master of all. And the tight integration between all libraries as well as the same mindset make them very discoverable. Besides it's good for speed (same api meens no cpu time wasted converting objects from 1 API to the next)

 

Well, yeah but only if you stay within the bounds of the framework. But this isn't specific to C# or .NET, but is true with any large framework.
One area where Microsoft CLR languages (or Java or AS3/Flash etc...) have an issue is when they need to use a native library outside of the framework. If there is no binding available, not only is there going to be a performance hit converting the data from native to managed objects, but the programming time required is quite high.

Things get even worse if you want to use a Java library in C# etc... Interoperability is not what .NET was made for and unfortunately in modern software, this is now very important.

 

Yes for the performance hit but no for the long programming time

Anything exposed as com is trivial to work with since v4 and there are tools to automate .net to native. For what's not automatable there c++/cli

 

For the average programmer here, c# is the best choice and probably the most profitable in the mid run (1-3-5 years time).

 

If you are required to use .NET, I suggest using C++/CLI for everything and not worry about using tools etc...
If you then decide to move to a platform with no .NET implementation, then you only need to chuck out the .NET bits and not have to lose all you hard work.

That is just what they were saying about Visual Basic 6 years ago. Turned out that C++ was.

 

But i'm not "required to use .net" , i choose to use C# (the language) and .net, i'm just saying i can toss in some C++/cli if needed to interop, but i pretty much never need to.

Pretty much everything i had to use (outside of graphics and physics) in C++ before i used C# is available as is or in a better form in the .net framework, and when it's not there's third party .net API for it too. But i was just disagreeing that it's hard to interop, C++/cli's sole purpose is that pretty much, bridging the .net / managed gap

 

It is a fundamental component to software design, given that this was a software development discussion about languages I assumed it was pretty clear.

This is still not quite a use case but I feel it's about as close as we're going to get, so let's run with it.

I don't think storing game data as pseudo-database is a particularly viable solution for real time performance. If we could narrow this down to a particular subsystem I think it would be easier to talk specifics and explore the problem in more depth.

I'm not convinced that you want to be running queries over databases during game play.

It needn't be happening every frame to be an issue, time is an asset during loading screens as well as at runtime. You still haven't demonstrated a reason why this data couldn't be preprocessed.

There aren't petabytes of data stored client side, that work happens on the server using a real database. I'm pretty sure both sides are written in native code without any use of LINQ. This is from their website:

http://sea.blizzard.com/en-sg/company/careers/faq.html

The use case for data bases has been clearly demonstrated by many games including WoW. This discussion is specifically focused on value of LINQ, not databases.

 

And i still think it's best to leave the DB variants of linq out of this (or create another discussion on them) as they work very diferently from linq to objects, and thus have a very different performance profile (a good one too, but definately not for the same reason nor in the same context so the comparison is apples to orange)

Raw code VS linq to objects makes sense, as you're comparing the same use case, if you want to compare linq to SQL/entities, then the comparison isn't C++, but C++ SQL, so it's really a whole diferent topic there

 

This is your primary mistake IMO. You know how to write 'robust and efficient' software in C++, can't use the same methods in C# and therefor decide C# can't write robust and efficient code. What you need to do is learn how to write robust and efficient code in C#.

Put it this way - If I coded C++ the same way I coded C#, then had a bunch of memory leaks - who's problem is it? Mine or C++'s?

But FYI, this is a comparison of C++ and C# to solve the same thing as above. (using the same formatting style (no one-liners ))

LOL, not only is this a trivial difference, and a useless example... the code isn't the same. Where is your Program class in the C++ version?

 

Yet when that assumption was apparently wrong I'm the troll?

Look, if you want some formal design document/diagram thingy then you're going to have to give an example. If you want scenarios where it's actually used then take a look at what's available. If you can't find fault with them... then what's the problem?

A database is an organized collection of data. The data is typically organized to model relevant aspects of reality (for example, the availability of rooms in hotels), in a way that supports processes requiring this information (for example, finding a hotel with vacancies).

http://en.wikipedia.org/wiki/Database

This is exactly what a unity does. It stored the positions of objects, the data on the objects, the relationships between those objects etc.

It's not a database per say - I'd not use Unity instead of MySQL - but some of the basic concepts overlap. For example I can ask unity to perform a geospatial query using physics sphere cast. I can then, using LINQ, perform various manipulation on the result - I can filter results, join results, project data etc. Then, back to Unity API I can instert records [create GO], update records [move GO] and remove objects [destroy GO].

It's not limited just to some basic spacial data though - any IEnumerable can be queried - so that's any array, list or other collection or, as I demonstrated earlier, a streaming data generator. Ever wanted to find a child of a GO with specific tags? Transform is a IEnumerable! Want to know which URL is online - you can use LINQ! So on and so forth.

Again, LINQ is nothing but a handy tool - but it is handy.

 

Surely from my C# snippets previously in the thread where I have pointed out exception safety issues and given solutions, I have proven that my knowledge of writing robust and efficient code in C# is generally as good as any other C# developer here. Because I happen to know C++ too, I am in a good position to be able to suggest and attempt to explain my preference of C++.
And my reason for this is simply that C# does not offer us what we need without a lot of error prone boilerplate exception (re)handling code.

I know , this was just to show that my demonstration of using header files wasn't required to do such a simple thing.

As for where the Program class was.. I didn't need it to achieve the same task. C++ gives us this flexibility (or conversley ISO C++ doesn't allow the main entry point to reside in a class because multiple classes might contain a main function).

 

Not really no, you're definalte not writing C# like i do, writing robust C# doesn't involve try catches everywhere, i've had whole programs without a try catch, it's mostly about not throwing to begin with, exceptions tend to be overused IMHO.

Most objects aren't IDisposable too, not everything is about 40MB arrays and unmanaged objects (and in the case of unmanaged objects, i'll go ahead and say that if everyone was using C#, we wouldn't have this problem to begin with )

 

Not really, because your commentary is unusual to say the least. Overly focused on what is, even as a network programmer, a very specialized and limited use-case, and unable to see how one would black box the code so others wouldn't have to deal with it as they build upon it. I've commented on this before.

It would have made more scene if you wrote idiomatic code - nobody [in their right mind] would write that C# code - why would I create a class so that I can make a function call?

 

Then you are probably not writing robust or exception safe code.
I generally have 1 try catch in every IDisposable class.. and that is because my software designs encourage exception propagation. Other designs would have even more try / catches.

If one of your classes contains an IDisposable, it must also be IDisposable (for the pattern to work). The fact that you don't have many IDisposable classes tells me that you don't quite understand the problem.

You also wouldn't have Unity.. or C#. Good luck with that.

If everyone just used C++ we wouldn't have thi.... Oh wait... we don't have any issues anyway

 

This tells me you don't understand the solution.

 

I am writing robust code, just architecting it so most of the edge cases that cause exception cannot happen "by design" instead of letting them happen and caching them (sometime with tradeoffs in functionality for this)

I know how IDisposable works thanks, i perfectly understand the problem and most classes are not AND DO NOT HAVE NESTED IDisposable classes, not everything is about working with unmanaged or constrained system ressources, there are a few common APIS that are IDisposable (files, connections large memory objects etc), but that's not the bulk of the framework.

We definately would have unity, just done in C#, don't get me wrong i'm not saying "don't use anything that isn't full C#", i'm just saying that counting a minus for C#, for something that is largely used for working with non C# things is harsh, IDisposable is for unmanaged and expensive ressources, it would be nice to drop the "for unmanaged" part.

Let's be clear on my position here, most HL languages are similar, i'm not some C# fanboi, C#/Java/C++/python/ whatever , it's all rather similar when you're not writing system oriented code, there are 3 key reasons i love C#
- the .net Framework (applies to all managed languages)
- LINQ and the C# 3.0 features
- Managed environment
So i really don't have much interest in discussing things outside of those 3 features, i don't think C# is ahead or behind on anything else pretty much