deprecated delete and manual memory management

[Dmitry Olshansky]

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