Smart pointers instead of GC?

[woh]

  ur right I never thought of that, I bet all them game devs never 
thought of it either, they so dumb.  I bet they never tried to 
use a GC, what fools!  Endless graphs of traced objects, oh yes 
oh yes!  It only runs when I allocate, oh what a fool I've been, 
please castigate me harder!

  Adam pls tell me more of this c# and that amazing gc it sounds 
so good




On Monday, 3 February 2014 at 21:42:59 UTC, Shammah Chancellor 
wrote:
> On 2014-02-01 07:35:44 +0000, Manu said:
>
>> On 1 February 2014 16:26, Adam Wilson <flyboynw at gmail.com> 
>> wrote:
>> On Fri, 31 Jan 2014 21:29:04 -0800, Manu <turkeyman at gmail.com> 
>> wrote:
>> 
>> On 26 December 2012 00:48, Sven Over <dlang at svenover.de> wrote:
>> 
>>  std.typecons.RefCounted!T
>> 
>> core.memory.GC.disable();
>> 
>> 
>> Wow. That was easy.
>> 
>> I see, D's claim of being a multi-paradigm language is not 
>> false.
>> 
>> 
>> It's not a realistic suggestion. Everything you want to link 
>> uses the GC,
>> and the language its self also uses the GC. Unless you write 
>> software in
>> complete isolation and forego many valuable features, it's not 
>> a solution.
>> 
>> 
>>  Phobos does rely on the GC to some extent. Most algorithms 
>> and ranges do
>> not though.
>> 
>> 
>> Running (library) code that was written with GC in mind and 
>> turning GC off
>> doesn't sound ideal.
>> 
>> But maybe this allows me to familiarise myself more with D. 
>> Who knows,
>> maybe I can learn to stop worrying and love garbage collection.
>> 
>> Thanks for your help!
>> 
>> 
>> I've been trying to learn to love the GC for as long as I've 
>> been around
>> here. I really wanted to break that mental barrier, but it 
>> hasn't happened.
>> In fact, I am more than ever convinced that the GC won't do. 
>> My current #1
>> wishlist item for D is the ability to use a reference counted 
>> collector in
>> place of the built-in GC.
>> You're not alone :)
>> 
>> I write realtime and memory-constrained software (console 
>> games), and for
>> me, I think the biggest issue that can never be solved is the
>> non-deterministic nature of the collect cycles, and the 
>> unknowable memory
>> footprint of the application. You can't make any guarantees or 
>> predictions
>> about the GC, which is fundamentally incompatible with 
>> realtime software.
>> Language-level ARC would probably do quite nicely for the 
>> miscellaneous
>> allocations. Obviously, bulk allocations are still usually 
>> best handled in
>> a context sensitive manner; ie, 
>> regions/pools/freelists/whatever, but the
>> convenience of the GC paradigm does offer some interesting and 
>> massively
>> time-saving features to D.
>> Everyone will always refer you to RefCounted, which mangles 
>> your types and
>> pollutes your code, but aside from that, for ARC to be useful, 
>> it needs to
>> be supported at the language-level, such that the 
>> language/optimiser is
>> able to optimise out redundant incref/decref calls, and also 
>> that it is
>> compatible with immutable (you can't manage a refcount if the 
>> object is
>> immutable).
>> 
>> The problem isn't GC's per se. But D's horribly naive 
>> implementation, games are written on GC languages now all the 
>> time (Unity/.NET). And let's be honest, games are kind of a 
>> speciality, games do things most programs will never do.
>> 
>> You might want to read the GC Handbook. GC's aren't bad, but 
>> most, like the D GC, are just to simplistic for common usage 
>> today.
>> 
>> Maybe a sufficiently advanced GC could address the performance 
>> non-determinism to an acceptable level, but you're still left 
>> with the memory non-determinism, and the conundrum that when 
>> your heap approaches full (which is _always_ on a games 
>> console), the GC has to work harder and harder, and more often 
>> to try and keep the tiny little bit of overhead available.
>> A GC heap by nature expects you to have lots of memory, and 
>> also lots of FREE memory.
>> 
>> No serious console game I'm aware of has ever been written in 
>> a language with a GC. Casual games, or games that don't 
>> attempt to raise the bar may get away with it, but that's not 
>> the industry I work in.
>
> You can always force the GC to run between cycles in your game, 
> and
> turn off automatic sweeps.  This is how most games operate 
> nowadays.
> It's also probably possible to create a drop-in replacement for 
> the GC
> to do something else.   I could see if being *VERY* useful to 
> make the
> GC take a compile-time parameter to select which GC engine is 
> used.