The criticism of Walter on C++ is just about right. The conclusions drawn from the lackings of C++ and their implementation in D is also mostly right. Now the topic of this thread is "D and Game Programming". When D is a mature language, I would love to use it for large scale game projects. But my needs are not completely met with D as it is today:

    (1) D would need the ability to create an operator overloaded vector and
matrix class (besides others) that allows the creation of uninitialized (!)
temporary objects, and also allows objects on the stack.

    (2) D would need the ability to give a timeout to the garbage collector.

Ad (1):
Well this is really a convenience issue as one can certainly do without any
vector or matrix "class". What I have demanded is almost there. D has
structs that can be allocated on the stack as temporary objects and that are
not initialized if I do not explicitly say so (am I right?). What's missing
is the operator overloading that makes the code soooo more readable (which
is in discussion anyway, right?). Besides, why is it important that I can
have uninitialized vectors on the stack? Well, vectors arise in legions as
intermediate results in calculations. I don't want them to be allocated on
the heap, and I don't want them to be initialized when they are filled with
content right away. Also, I want to have uninitialized arrays of vectors for
geometry transformation and similar stuff.

Ad (2):
I agree that garbage collection is not evil in itself. But the prospect of
having the garbage collector put in a break at unpredictable times scares me
and certainly would lower the entertainment value of the software :-) But
the garbage collector doesn't need to make a *perfect* collection run each
time. It only needs to make sure that the memory isn't leaking on average.
So I would like to assign a variable portion of the frame time to the
garbage collector, and have a feedback mechanism to get to know if I must
assign more time to the garbage collector to prevent a runaway condition.
This way, heavy garbage collection activity may manifest itself in a dropped
frame rate, but not in an arbitrary pause.

> Ad (2):
> I agree that garbage collection is not evil in itself. But the prospect of
> having the garbage collector put in a break at unpredictable times scares me
> and certainly would lower the entertainment value of the software :-) But
> the garbage collector doesn't need to make a *perfect* collection run each
> time. It only needs to make sure that the memory isn't leaking on average.
> So I would like to assign a variable portion of the frame time to the
> garbage collector, and have a feedback mechanism to get to know if I must
> assign more time to the garbage collector to prevent a runaway condition.
> This way, heavy garbage collection activity may manifest itself in a dropped
> frame rate, but not in an arbitrary pause.
> 
> 
> 
> 

Personally I think allowing control of the garbage collector would enhance D's use in a few places.  Providing timeout + a way to take manual control of when the garbage collector runs would provide advantages over existing garbage collected languages.  This should *not* be the default and should be used sparingly.  I can say this should be rather difficult to make happen.

-Andy

"andy" <acoliver@apache.org> wrote in message news:3CF6D96C.6040607@apache.org...
> Personally I think allowing control of the garbage collector would enhance D's use in a few places.  Providing timeout + a way to take manual control of when the garbage collector runs would provide advantages over existing garbage collected languages.  This should *not* be the default and should be used sparingly.  I can say this should be rather difficult to make happen.

It's already there. You can manually run it, or disable/enable it. Of course, if you run out of memory when it is disabled, it will throw an exception.

When the garbage collector is off does it still track memory allocations? In some situations this could be a "Turn Off". But I'm probably talking out of my #%$#@.

"Walter" <walter@digitalmars.com> wrote in message news:ad6nfq$1445$1@digitaldaemon.com...
>
> "andy" <acoliver@apache.org> wrote in message news:3CF6D96C.6040607@apache.org...
> > Personally I think allowing control of the garbage collector would enhance D's use in a few places.  Providing timeout + a way to take manual control of when the garbage collector runs would provide advantages over existing garbage collected languages.  This should *not* be the default and should be used sparingly.  I can say this should be rather difficult to make happen.
>
> It's already there. You can manually run it, or disable/enable it. Of course, if you run out of memory when it is disabled, it will throw an exception.
>
>

Walter wrote:
> "andy" <acoliver@apache.org> wrote in message
> news:3CF6D96C.6040607@apache.org...
> 
>>Personally I think allowing control of the garbage collector would
>>enhance D's use in a few places.  Providing timeout + a way to take
>>manual control of when the garbage collector runs would provide
>>advantages over existing garbage collected languages.  This should *not*
>>be the default and should be used sparingly.  I can say this should be
>>rather difficult to make happen.
> 
> 
> It's already there. You can manually run it, or disable/enable it. Of
> course, if you run out of memory when it is disabled, it will throw an
> exception.
> 
> 

Can I turn it back on though?

"anderson" <anderson@firestar.com.au> wrote in message news:ad6shf$19n3$1@digitaldaemon.com...
> When the garbage collector is off does it still track memory allocations?
In
> some situations this could be a "Turn Off". But I'm probably talking out
of
> my #%$#@.

What do you mean? If you mean scan, no, it doesn't. The mark & sweep happens only during an actual collection.

"andy" <acoliver@apache.org> wrote in message news:3CF7099F.8080302@apache.org...
> Walter wrote:
> > "andy" <acoliver@apache.org> wrote in message news:3CF6D96C.6040607@apache.org...
> >>Personally I think allowing control of the garbage collector would enhance D's use in a few places.  Providing timeout + a way to take manual control of when the garbage collector runs would provide advantages over existing garbage collected languages.  This should *not* be the default and should be used sparingly.  I can say this should be rather difficult to make happen.
> > It's already there. You can manually run it, or disable/enable it. Of course, if you run out of memory when it is disabled, it will throw an exception.
> Can I turn it back on though?

Of course:
    gc.enable();

> 
> 
> Of course:
>     gc.enable();
> 
> 


Right what I'm saying is a middle ground should be reached.  Meaning where I turn garbage collection off, then turn it on and have everything that would have been garbage collected had it been on, collected.  Is that possible?

-Andy

"andy" <acoliver@apache.org> wrote in message news:3CF7A6CB.4000305@apache.org...
> > Of course:
> >     gc.enable();
> Right what I'm saying is a middle ground should be reached.  Meaning where I turn garbage collection off, then turn it on and have everything that would have been garbage collected had it been on, collected.  Is that possible?

That's how it works.

Walter wrote:
> "andy" <acoliver@apache.org> wrote in message
> news:3CF7A6CB.4000305@apache.org...
> 
>>>Of course:
>>>    gc.enable();
>>
>>Right what I'm saying is a middle ground should be reached.  Meaning
>>where I turn garbage collection off, then turn it on and have everything
>>that would have been garbage collected had it been on, collected.  Is
>>that possible?
> 
> 
> That's how it works.
> 
> 

Then that happens to be awesome.  Thanks.