General Problems for GC'ed Applications?

[Dave]

Karen Lanrap wrote:
> Dave wrote:
>> You're making the original assertion that it's a problem - I
>> believe the onus is on you to prove that it would apply to
>> efficient design patterns using D <g>
> 
> If efficient design patterns using D forbid memory leaks, then there 
> will never occur any garbage in any application.
> 
> This would rise the question why the GC is enabled by default.
> 
> If on the other hand memory leaks do appear I have a running example 
> that shows a side effect of enabling the GC similar to what I have 
> brain stormed.
> 
> As far as I can see, this side effect is neither documented here nor 
> have I found any mentioning in other resources on the net.
> 
> But according to those Unknown guys here, its of no interest here 
> anyway.

Don't assume that - I don't think any of us are trying to shut the door 
on anything. If you have some code to post that'd be great. It's just 
that (as I read it) you made some strong general and sweeping assertions 
about GC in general that I don't think reflect general use of the GC.

Many of the long-term contributors to this group are aware of some 
issues with the "first generation" GC, and no one's ever claimed GC is a 
panacea, especially for a systems language like D. Only that using the 
GC shouldn't be ruled out for general programming chores unless proved 
otherwise. Yes, the primary mode of memory mgmt. for D is GC but of 
course it's not the only one precisely because it will never be perfect 
for every job.