Reply to Weed,
Christopher Wright ?????:
+ Sometimes allocation and freeing of memory in an arbitrary
unpredictable time unacceptable. (in game development or realtime
software, for example. One hundred million times discussed about
it there, I guess)
So you are optimizing for the uncommon case?
GC is an attempt of optimizing for the uncommon case )
I don't think so. Programmers have more important things to do than
write memory management systems. My boss would not be happy if I
produced an application that leaked memory at a prodigious rate, and
he would not be happy if I spent much time at all on memory
management.
You should use language with GC in this case.
that type of cases IS the normals case
And the best manual memory management that I am likely to write would
not be faster than a good garbage collector.
What sort of applications do you develop?
games, images processing
Have you used a garbage
collector in a large application?
I do not write really large applications
Small applications are NOT the normal case.
trying to design a language for large apps (one of the things D is targeted
at) based on what works in small apps is like say "I know what works for
bicycles so now I'll design a railroad train".
Yes there are programs where manual memory management is easy, they are generally
considered to be few and far between in real life. Many of them really have
no need for memory management at all as they die before they would run out
of ram anyway.
