On 28.04.2011 2:19, Alexander wrote:
On 27.04.2011 22:46, Dmitry Olshansky wrote:
- there is an awful lot of operations which allocate GC memory implicitly aka
arr1 ~ arr2, so it's not like you can pass the allocator and prevent the
function from allocating _somewhere_ else
This is solvable by using different runtime or class hierarchy, thus overriding
"~"& co. Another option is to avoid constructs which may invoke GC (those are
well-described).
I think you might be surprised how many there are.
- I still fail to see how passing allocator would allow the function to decide
on whether it's GC-like allocation or not, i.e. manual memory management
implies the certain way function does its job (more generally the whole
program, framework, module
etc. it's not something decided at single call point)
Again - different runtime and/or specialized class hierarchy. Custom
(de)allocators are inherited, so one base class will do.
That's your C++ experience speaking ;) It seems you just like manual
memory management in c++ and can't see other ways.
So I gather, the solution is to dump GC ? Hardly very useful. Also
dropping language constructs is no go. (this 'avoid' is too vague)
OK, fighting implicit allocation. With what - refcounting? Imagine array
slices and such, when can you tell there is no references to this memory
block ? Well, if you know what you are doing you could try and hack
druntime to use refcounting, there was talk about it.
Anyway, I just want to make sure you get the idea that GC is the
default thing in D, not 'possible under certain circumstances' thing
like it is in C++.
/Alexander
--
Dmitry Olshansky
