Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
bearophile wrote:
void bar(int n) {
scope int[] a = new int[n]; // stack-allocated
foo(a);
}
Why are you making such proposals, when one of the core developers
even thought about removing normal "scope"? It's almost 100%
guaranteed that nobody will listen.
I personally find it a good idea to find new ways to reduce
producing memory garbage. The D GC is slow and bad, so you'd
better avoid it.
Let's make this claim: it is impossible to write high performance
applications (that need to make use of dynamic memory allocation)
in D without resorting to "unsafe" techniques. That would include
allocating memory on the stack, or manually freeing memory.
I write high-performance code in D without resorting to unsafe
techniques. Much of my code allocates arrays only in the beginning
and uses them throughout.
I intended to exclude this case with applications "that need to make
use of dynamic memory allocation". But I guess this doesn't apply to
programs that only allocate on initialization.
So, how about programs that allocate/release memory while doing
computations?
"Oil is found in the minds of men."
Can you explain what this means in the context of the problem
mentioned above?
It means that if you start with the goal of making high performance
applications safe, you may achieve that. One guaranteed way to not get
there is to start with a claim that it can't be done.
I just wanted to leave that "claim" for anybody to attack. But in the
end, solutions to this problem will only be workarounds, and programs
will possibly be more convoluted than their C/C++ counterparts. E.g. you
could just use freelists (reusing memory without going through the
runtime memory manager), but then you'd lose constructors, etc...
That being said, I like stack-allocated and I asked Walter for a long
time to introduce them in the language. They have their problems though.
They can just be disabled in safe mode, if that's the problem.
Andrei
