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
