You guys are off on a tangent here with memory management, I’m rather shocked that a company like Unity would even bother with C#. Maybe it is the circles I travel in but C# seems to be very dead as a language. I can’t imagine that they will get a rush of developers to work on C#.
Announcement
Collapse
No announcement yet.
Unity Is Growing Their LLVM Compiler Team As They Try To Make C# Faster Than C++
Collapse
X
-
Memory management is hard to get perfect. It shouldn't be hard to do it well and I wouldn't say it's particularly hard.
I have no problem with garbage collection itself. it can actually be pretty cool in that it *can* be easier to debug memory leaks, it *can* be faster, and it *can* be easier to manage (among a few other things).
It's just never that way in reality. Because of the way garbage collection gets advertised, the people who use garbage collected languages basically think memory management is no longer a thing and end up doing ridiculous things with memory. In some cases, the language prefers/encourages it as well, making matters worse. It's gone from, "Here's a way to make memory management easy" to "Here's a way to be as inefficient as possible with memory".
For the main topic, C# can be a fine language. I've used it in personal projects a handful of times frankly. I like it.Last edited by computerquip; 08 April 2019, 12:16 AM.
Comment
-
Originally posted by duby229 View Post
Um, no... There is -no- garbage collector that can manage memory... GC is -not- memory management. There is -no- possible way for any GC mechanism to perform decent let alone well. And it far, far worse in memory constrained scenarios. I'm pretty sure Google has already proved to billions of people worldwide how terrible garbage collection is with android.
- Likes 3
Comment
-
Originally posted by wizard69 View PostMaybe it is the circles I travel in but C# seems to be very dead as a language. I can’t imagine that they will get a rush of developers to work on C#.
It's also one of the better languages out there, in my opinion.
Comment
-
Originally posted by caligula View Post
Wrong. Ada predates C++ and Rust's borrow checker is something totally different..
The phrase Resource acquisition is initialization... is there anything in there that suggests it is impossible in any other language?
So long as you have access to knowledge about deterministic lifetime of the scope of an object, it is possible.
Microsoft has even shown that a purely garbage collected language "C++/clr:safe" can still utilize RAII.
If you reverse this generated code using ILDASM, you can see it really is just a try / catch statement within every function.
Heck, with a try / catch in every function you could do this in Java.
Now I am more than happy for RAII to be quite unique to C++. In fact C++ is the only language I would recommend because the solutions provided to a lot of problems *are* elegant and fairly portable compared to massive bloated GC languages like Java or .NET.
But in practice, I do understand that most technology (not even language at this point) is quite easy to share between languages.
Comment
-
-
Originally posted by atomsymbol
I originally (yesterday) wanted to post a longer response. That didn't work out. The short version is as follows:
I am hesitant to use std::weak_ptr because composition of std::weak_ptr is impossible. If the programmer puts a graph of std::shared_ptr behind std::weak_ptr, and the graph entrance is reachable only via weak pointers, then all the std::shared_ptr in the graph effectively become std::weak_ptr. The contradiction is:- The programmer cannot use std::weak_ptr in the graph because constructing/initializing the graph requires std::shared_ptr
- The programmer cannot use std::shared_ptr in the graph because that would lead to a memory leak
Solution with current state of C++ STL: The programmer has to manually write code computing the liveliness of the mentioned graph
1) In a hierarchical structure you would use std::shared_ptr downwards and std::weak_ptr upwards. That way you can have the graph "hanging off" the shared pointer root and individual branches.
2) a single flat list of shared_ptrs *and* then a graph structure, all of weak pointers.
Or am I missing what you mean?
Some might say that stating this "ownership" of data is manual memory management. I personally think that shared / weak pointers in the header just seem like useful annotation. One that I would even do in Lua scripts.
That said, the hybrid approach of reference counting *and* limited garbage collection would be the ideal case, then you could just use something like shared_ptr.
There are already some "stubs" in the standard to help facilitate this garbage collection (https://en.cppreference.com/w/cpp/me...lare_reachable) but no formal garbage collector yet.
The closest to this hybrid approach is probably UE4; although they err on the side of GC a little too much IMO.
Slightly off topic but I would also note that locking a weak pointer to get a shared pointer to go up the hierarchy is often cited to be "slow". However I find this quite amusing because in my tests, it is quite a bit faster to trivially increment a reference count and create a stack object than it is to go through all that machinery in C# to even call *any* managed function by the VM; and yet Java and .NET developers are always trying to suggest that non-native / jit languages can be on par with native C++ :/Last edited by kpedersen; 08 April 2019, 11:05 AM.
- Likes 1
Comment
-
Originally posted by kravemir View Post
Uhm.. No,.. The problem with Android apps is that they are bloated,.. if Google had picked c++ as the primary language for Android alps, then it would have proved how c++ is unstable, buggy, and memory eater (due to memory leaks). I personally saw android developers who don't care to write sane code even in Java.. I wouldn't like to see them writing c++ apps..
Comment
-
Originally posted by kravemir View Post
Uhm.. No,.. The problem with Android apps is that they are bloated,.. if Google had picked c++ as the primary language for Android alps, then it would have proved how c++ is unstable, buggy, and memory eater (due to memory leaks). I personally saw android developers who don't care to write sane code even in Java.. I wouldn't like to see them writing c++ apps..
- Likes 1
Comment
Comment