Unmanaged - a D framework on github

[Paulo Pinto]

On Wednesday, 20 March 2013 at 07:57:13 UTC, Benjamin Thaut wrote:
> Am 17.03.2013 16:20, schrieb Jakob Ovrum:
>> On Saturday, 16 March 2013 at 14:40:58 UTC, D-ratiseur wrote:
>>> new is overriden in TUObject because the purpose of the 
>>> library is to
>>> bypass the garbage collector and  to bypass the GC you have to
>>> override new and delete.(at least according to the manual:
>>> articles,mem managment).
>>
>> The documentation on this is old and misleading.
>>
>> Overloading of new and delete is deprecated (the delete 
>> operator in its
>> entirety is deprecated).
>>
>> Having them overloadable was not a very good idea. The current 
>> approach
>> is to have "new" always mean GC memory, which is why there is 
>> no need
>> for delete. This way, code that uses 'new' won't break 
>> horribly or leak
>> depending on the type involved, important for generic code. 
>> Code that
>> doesn't use the GC has to be designed for it; you can't just 
>> remove the
>> GC under everyone's noses and expect things to work.
>>
>> For different kinds of memory, you should simply use a 
>> different
>> allocator. For example, here's a rough approximation of a pair 
>> of
>> functions using malloc/free for class allocation:
>>
>> T alloc(T)() if(is(T == class))
>> {
>>     enum size = __traits(classInstanceSize, T);
>>     auto p = enforceEx!OutOfMemoryError(malloc(size));
>>     return emplace!T(p[0 .. size]);
>> }
>>
>> void dealloc(T)(ref T obj) if(is(T == class))
>> {
>>     free(cast(void*)obj);
>>     obj = null;
>> }
>>
>> It can easily be overloaded to support all types.
>>
>> In the future, Phobos will have a custom memory allocator 
>> library, which
>> modules like std.container will use, though to which extent is 
>> not clear
>> (for example, will it also use the custom allocator for 
>> exception
>> objects?). Nevertheless it will probably be a good base for 
>> other
>> libraries to easily support non-GC allocators.
>
> You still can't replace evertything with custom alloc templates 
> and have nice syntax. There are at least two cases where it 
> does not work nicely:
>
> 1) Arrays (no new T [size] syntax)
> 2) Inner classes (a template can't automatically capture the 
> outer class)
>
> So I think overloading new and delete actually has its place. 
> But the way it is currently implemented in D is useless in my 
> eyes.
>
> Kind Regards
> Benjamin Thaut

The solution could be like in Turbo Pascal/Delphi, provide an API 
to set the memory manager for the runtime.

--
Paulo