deprecated delete and manual memory management

[Steven Schveighoffer]

On Wed, 27 Apr 2011 18:15:26 -0400, Alexander <aldem+dmars at nk7.net> wrote:

> On 27.04.2011 22:42, Steven Schveighoffer wrote:
>
>> For non-garbage-collected languages, yes.  For GC languages, delete is  
>> to be discouraged (that is what the GC is for).
>
>   delete() is 99% of the cases O(1) operation (thanks to free lists),

Not exactly, it still needs to update the metadata for the block, which  
involves a binary search (O(lgn)) + you have to take the global lock,  
which means you could be making your multi-threaded application worse than  
a single-threaded one.  I have seen this in practice when one uses memory  
allocation or deallocation frequently.

clear is definitely O(1) (well, as much as you thought delete was O(1), it  
depends on the dtor).

> while invocation of GC is O(?) (no one knows how many objects are  
> pending deallocation, and when exactly it will be invoked).

The point is that it runs infrequently enough to avoid hindering  
performance.  D's GC is pretty horrible at performance, so there are  
definitely improvements yet to be seen there (David recently fixed some  
really bad ones, the next version of dmd should be much faster at  
allocation).

Yes, if you run the collector every time you are done using an object,  
performance will be much worse than using delete to destroy the object,  
but that is also not encouraged.

>   I agree that in normal applications (mostly) this is rarely an issue,  
> but there are not normal applications, which I mentioned previously - RT  
> & OS, and some others.

As mentioned, RT applications and OS kernels would need a specialized  
runtime, D does not support that with the current GC/runtime.  This does  
not mean that you would be using delete for those, you'd probably use a  
specialized runtime function using that specialized runtime.

>   Additionally, memory management hooks supported by the compiler are  
> faster than any other solution (templates & co).

Absolutely untrue.  Runtime hooks cannot be inlined for instance.

>> Java and C# code do not have much use for delete either
>
>   What about those coming from C++ and D1 (including D2 up to this  
> point)?

C++ users will have to adjust to an environment that provides a GC.  D1/D2  
users should use delete sparingly anyways.  Migrating those few cases to  
use a new method shouldn't be too difficult.

>   But, actually, I am really interested in only one thing... I agree,  
> that some may feel discomfort using delete, but what is the reason to  
> remove it from the language? Probably, I've missed something, but why  
> not to leave it as is for those who need it?

I think (and I'm not sure, Andrei was the one behind this) that the issue  
is that a keyword operation is very simple/easy to write, and deleting  
memory should be discouraged.  Having a dedicated keyword makes it seem  
sanctioned and promoted by the language, when in fact, it should almost  
never be used.

-Steve