deprecated delete and manual memory management

[Alexander]

On 26.04.2011 23:43, Timon Gehr wrote:

> But you understand why it is deprecated for GC memory?

  Sure, I do. Though, sometimes it is useful to immediately deallocate an object, instead of delegating this to GC (and most likely - to delay deallocation). There was a post concerning thoughts of Linus Torvalds about GC, and the keyword is -
"cache". Another possible use - in case of large objects, which are used for short period of time - it makes little sense to keep them around until next GC cycle, as this may lead to another request to OS, which may be unnecessary otherwise.

> The main thing to note is that the semantics of C++ 'new' and D 'new' are rather
> different.

  From programmer's point of view - not really. 'new' will allocate (and create) an object, which is not really different from C++. Or?

> D 'new' performs allocation on the GC heap by default. The only sane overloads of
> 'new' would therefore allocate the object on a custom GC heap, which you never
> want to do.

  Why it is the only "sane"? Why I couldn't allocate from somewhere else? If D is positioned as language for system programming (not only, but anyway), it is quite OK to use other (de)allocators.

> The argument for removing 'delete' overloading is trivial after taking that into consideration.

  Still, to be honest, I don't see, what is the argument. 'delete' looks quite OK for explicit deallocation, regardless of where the object was allocated.

> You can still create custom allocators by the means of template functions. (I do
> not think this is optimal though because they duplicate code that needn't be)

 This way, we delegate all this to the developer, as he has to care - where objects should be allocated. OTOH, some objects (in specific environments) may "know better", where they should be allocated - that's why I believe that overloading makes sense.

> They feel a little bit less natural though, which is not a problem, since in D, custom
> allocators and manual memory management in general, _are_ less natural.

  Why? In some cases (again - system and real-time programming) - explicit (de)allocation is a must. Why not leave things as is? Those who don't need it will never use them, those who do need - will always have the option to use.

> You don't gain anything by overloadable new/delete in D, because you cannot use
> the feature to quickly patch in a custom allocator to existing code as possible in
> C++ as a means of optimization. (this binds that allocator to a specific type,
> which does not make much sense in other context)

  Exactly the point - for specific (derived) types, for specific application, when D Runtime/Phobos
  are not used (partially or fully) - this makes sense, IMHO.

/Alexander