Jump to content
• Advertisement

# Unity C# .Net Open Source

This topic is 1454 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

## Recommended Posts

Was it going to be Microsoft embrace/extend/extinguish, or a case of promoting it to world class software?

Sadly the jury is still out on this.

Its a bit of a shame that worries of the Old Microsoft follow the New Microsoft so doggedly, but your skepticism is understandable.

Speaking generally, and from the inside, I can assure you that the new leaf really is genuine. If you consider the corpus of all the announcements made last week, and the sheer effort or expenditure that it took to make them happen, I'd hope that'd go a long way towards convincing you of the new strategy.

#### Share this post

##### Share on other sites
Advertisement

One thing that hasn't been considered in all this GC discussion is that the GC only knows about memory.

That's it.

The C++ "RAII" idiom actually can clean up any resource immediately. And this is incredibly important. It is, in fact, so important that .NET has the IDisposable idiom to perform RAII-like tasks in its GC world.

Yep, and that means you get scoped RAII the same as C++, so I don't really see why that's an issue?

And they don't do anything for you with non-memory resources.

Not entirely true. Consider the following class

public class Resource<T> : IDisposable
where T : class, new()
{
private readonly string _id;
private T _resource;

public Resource(string id)
{
_id = id;
_resource = new T();
Console.WriteLine("{0} acquired", _id);
}

public void Dispose()
{
if (_resource != null)
{
_resource = null;
Console.WriteLine("{0} released", _id);
}
}

~Resource()
{
Dispose();
}
}


In this case, the resource can either be manually scoped (i.e. using) or if we're not concerned about when the Resource is released, we can let the GC take care of it

new Resource<object>("global");
using (new Resource<object>("local"))
{

}

// output
global acquired
local acquired
local released
global released


#### Share this post

##### Share on other sites

One thing that hasn't been considered in all this GC discussion is that the GC only knows about memory.

That's it.

The C++ "RAII" idiom actually can clean up any resource immediately. And this is incredibly important. It is, in fact, so important that .NET has the IDisposable idiom to perform RAII-like tasks in its GC world.

Yep, and that means you get scoped RAII the same as C++, so I don't really see why that's an issue?

Because I have to write a huge amount of boilerplate code, and write it perfectly, knowing whether other "garbage collected" pointers I'm using have been cleaned up or not, just do implement something I get for "free" in C++.

I have to actively work against the GC because the GC is not designed for this.

And they don't do anything for you with non-memory resources.

Not entirely true. Consider the following class

public class Resource<T> : IDisposable
where T : class, new()
{
private readonly string _id;
private T _resource;

public Resource(string id)
{
_id = id;
_resource = new T();
Console.WriteLine("{0} acquired", _id);
}

public void Dispose()
{
if (_resource != null)
{
_resource = null;
Console.WriteLine("{0} released", _id);
}
}

~Resource()
{
Dispose();
}
}

In this case, the resource can either be manually scoped (i.e. using) or if we're not concerned about when the Resource is released, we can let the GC take care of it

new Resource<object>("global");
using (new Resource<object>("local"))
{

}

// output
global acquired
local acquired
local released
global released


Again, the GC only handles memory. It has no sense of urgency with how needed another resource is because it can only see memory pressure, not active file system requests (for example). Also, you have actually implemented it incorrectly. You do not handle cleanup of managed resources, and you do not tell the GC to suppress the finalizer when it is disposed (reference).

The sheer number of people asking how to implement IDisposable properly show how much of a hack it is.

I'm not saying you should avoid C# because of this. But it is a major downside to the way it (and other GC languages) are designed that languages like C++ just handle far better.

Oh, and I almost forgot. The IDisposable pattern requires your user to be aware that you use it, and to handle it correctly on their end. Or even better - they have to figure out how to implement the disposable pattern if they store an instance of your class in their own. Both things that, again, C++ gives you automatically with its stack and RAII wrappers for heap objects. Edited by SmkViper

#### Share this post

##### Share on other sites

I agree with a hell of a lot of what you have said in this thread, but I think we are missing the point a little.

Yes you have to think of the GC when you write your code, it's really important, but if you screw up, then your game runs slowly because the GC is running all the time.

If you screw up in c++, the game crashes.

Now I personally prefer the game to crash, it MAKES you fix the problem, but for a newb starting out the game running slowly is probably a better idea.

I spend a hell of a lot of my working week finding memory issues. They usually come down to some idiot grabbing a reference to something and failing to release it at the right time. Simple fix when I do find it.

Hell of a job to find it.

One line of code missing in several million LOC's...... whimper.

I also have to deal with several completely different memory managers, fast ones, safe ones, ones that defrag themselves, ones that were written in 1991, even one called a Two Level Segregated Fit memory allocator,

GC is looking rather nice at the moment.

#### Share this post

##### Share on other sites

• Advertisement
• Advertisement

• ### Popular Contributors

1. 1
Rutin
40
2. 2
3. 3
4. 4
5. 5
• Advertisement

• 9
• 24
• 20
• 14
• 14
• ### Forum Statistics

• Total Topics
633384
• Total Posts
3011592
• ### Who's Online (See full list)

There are no registered users currently online

×

## 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!