Smart pointers instead of GC?

Frustrated c1514843 at drdrb.com
Mon Feb 3 15:26:22 PST 2014


On Monday, 3 February 2014 at 21:42:59 UTC, Shammah Chancellor
wrote:
>
> 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.


This is just non-sense. Maybe this is why modern games suck then?
How do you guarantee that the GC won't kick in at the most
inopportune times? Oh, you manually trigger it? When? Right at
the moment when the player is about to down the boss after a 45
min fight?

Oh, right.. you just segfault cause there is no memory left.

On Monday, 3 February 2014 at 22:51:50 UTC, Frank Bauer wrote:

> I'm not quite sure that I understand what you mean by GC 
> avoidance being a major focus of 2014 though. In the long term, 
> can I look forward to writing an absolutely, like in 100 %, 
> like in guaranteed, GC free D app with all of current D's and 
> Phobos' features if I choose to? Or does it mean: well for the 
> most part it will avoid the GC, but if you're unlucky the GC 
> might still kick in if you don't pay attention and when you 
> least expect it?

It's either got to be 100% or nothing. The only issue of the GC
is the non-determinism.... or if you do corner it and trigger it
manually you end up with exactly the types of problems Mr.
Chancellor thinks doesn't exist... i.e., the longer you have to
put off the GC the worse it becomes(the more time it takes to run
or the less memory you have to work with).

It might work ok with some concurrent AGC that you can use for
non-critical parts. e.g., have phobo's use the GC for non-real
time sections of the app(boot up, menu's for games, etc...) then
disable it and use ARC for when the app is meant for optimal
and/or deterministic performance.

One could argue that if one goes this around why not use ARC or
manual memory mangement(MMM?) the whole time... but by using the
GC during the non-critical parts of the program one can focus
less on memory leaks as usual with the GC.

What would be nice is to be able to write code that is oblivious
to how it's memory is managed, but be able to switch between
different methods.

[Sartup->menu's and other non-performance section of the game] <-
use GC
[real-time areas of game] <- use ARC or manual



More information about the Digitalmars-d mailing list