Smart pointers instead of GC?

[Frustrated]

On Wednesday, 2 January 2013 at 22:46:20 UTC, pjmlp wrote:
> On Wednesday, 2 January 2013 at 11:41:33 UTC, 
> DythroposTheImposter wrote:
>> I'm interested in how the new LuaJIT GC ends up performing. 
>> But overall I can't say I have much hope for GC right now.
>>
>> GC/D = Generally Faster allocation. Has a cost associated with 
>> every living object.
>>
>> C++ = Generally Slower allocation, but while it is alive there 
>> is no cost.
>>
>> So as the heap grows, the GC language falls behind.
>>
>> This seems to be the case in every language I've looked at 
>> this uses a GC.
>
> As a former user from Native Oberon and BlueBottle OS back in 
> the late 90's, I can attest that the GC was fast enough for 
> powering a single user desktop operating system.
>
> Surely there are cases where it is an issue, mainly due to 
> hardware constraints.
>
> While I am a GC supporter, I wouldn't like to fly in an 
> airplane with a GC system, but a few missile radar systems are 
> controled with GC based systems (Ground Master 400). So who 
> knows?!
>
> --
> Paulo


The problem isn't stability, as you manual management can be just
or even more error prone. The problem is with real time. If the
GC must stop the world then it might be a stability issue with
respect to the design. Audio and gaming are critical. While in
some instances it is only superficial, such as video games, but
absolutely a deal breaker with professional audio... even though
in a sense these are not as critical as, say, a missile system,
they are used much more often so are put to the test much more.
There is, also, redundancy built into such critical systems as
military defense... not so in a digital mixer for a PA that can't
pop and click because the GC has to compact the heap. Your
audience is going to be quite annoyed when they here a loud
pop(due to the audio cutting off and potentially going from a
high value to a low value which produces a very loud click) every
30 seconds, minute or so. Not to mention what that would do to
their hearing over the course of a night.

What if the GC decides to pause just at the wrong time when you
only needed just a little bit more time to get the audio buffer
filled? You are screwed. Manual management or ARC or whatever is
at least much more predictable. Sure you can disable the GC but
when you do that you just make things worse(potentially takes
longer to catch up).

I think with proper management these things can be avoided, but
as of now, since the D core relies so much on the GC, it's kinda
pointless unless you avoid all the goodies it provides. The
mindset that the GC is the ultimate way to deal with memory
management has led to the issues with D and the GC and why some
avoid D. If it would have been designed as optional, we wouldn't
be talking about these problems.