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.

On Sunday, 17 March 2013 at 15:20:04 UTC, Jakob Ovrum wrote:
> 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.

Thx, that's some very usefull info...however curently "Unmanaged"
have its own leak tracer, basically it's a compiler switch that
allows to record every call to alloc(), realloc() and free().
Once again there must be a kind of misunderstanding about the
lib. It's made to bypass the GC...and it's not under everybody
nose ! I clearly state about this and the code is made for that
purpose.
Anyway, it's possible that I've been, until now, a bit naive
about the manual...For example in the win chm, object classinfo
pretends to have this member:
---
const(MemberInfo[]) getMembers(in char[] name);
Search for all members with the name 'name'. If name[] is null,
return all members".
---
Which is the most mysterious method ever...since it seems not
exist at all... ;)

On Sunday, 17 March 2013 at 15:20:04 UTC, Jakob Ovrum wrote:
> 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]);
> }

I know this was just a rough example, but I just wanted to point this out:  It is not a good idea to use enforceEx() here, since a) it uses new to allocate memory for the exception, and b) you shouldn't try to allocate at all when you're out of memory.  :)

Use core.exception.onOutOfMemory() to signal an allocation failure instead.  It throws a pre-allocated OutOfMemoryError.

Lars

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

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

On 2013-03-20 08:57, Benjamin Thaut wrote:

> 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.

Instead of having a special keyword like we have now. We could have, as has been suggested before, a regular function or method.

With a class, there's also the possibility to return a different type or a singleton:

class Foo
{
   Foo new ()
   {
       return Bar.new();
   }
}

class Bar : Foo {}

-- 
/Jacob Carlborg

Am 20.03.2013 13:42, schrieb Jacob Carlborg:
> On 2013-03-20 08:57, Benjamin Thaut wrote:
>
>> 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.
>
> Instead of having a special keyword like we have now. We could have, as
> has been suggested before, a regular function or method.
>
> With a class, there's also the possibility to return a different type or
> a singleton:
>
> class Foo
> {
>     Foo new ()
>     {
>         return Bar.new();
>     }
> }
>
> class Bar : Foo {}
>

But with a regular function you always have the problem that you need to pass the constructor argumnets along. If there are implict conversion form literals to constructor arguments neccessary this will fail as soon as you pass them through a function.

Kind Regards
Benjamin Thaut

-- 
Kind Regards
Benjamin Thaut

On Wednesday, 20 March 2013 at 15:50:27 UTC, Benjamin Thaut wrote:
> Am 20.03.2013 13:42, schrieb Jacob Carlborg:
>> On 2013-03-20 08:57, Benjamin Thaut wrote:
>>
>>> 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.
>>
>> Instead of having a special keyword like we have now. We could have, as
>> has been suggested before, a regular function or method.
>>
>> With a class, there's also the possibility to return a different type or
>> a singleton:
>>
>> class Foo
>> {
>>    Foo new ()
>>    {
>>        return Bar.new();
>>    }
>> }
>>
>> class Bar : Foo {}
>>
>
> But with a regular function you always have the problem that you need to pass the constructor argumnets along. If there are implict conversion form literals to constructor arguments neccessary this will fail as soon as you pass them through a function.
>
> Kind Regards
> Benjamin Thaut

Its too late...errors are made,anyway you got the stuff:
http://www.youtube.com/watch?v=KZKAVl_qX_Y. I Should wait a few
weeks before announcing "Unmanaged"...I feel quite shamefull
right now...

30.03.2013 22:38, D-Ratisueur пишет:
>
> Its too late...errors are made,anyway you got the stuff:
> http://www.youtube.com/watch?v=KZKAVl_qX_Y. I Should wait a few
> weeks before announcing "Unmanaged"...I feel quite shamefull
> right now...

Don't feel, you're good!

Am 30.03.2013 16:38, schrieb D-Ratisueur:
>
> Its too late...errors are made,anyway you got the stuff:
> http://www.youtube.com/watch?v=KZKAVl_qX_Y. I Should wait a few
> weeks before announcing "Unmanaged"...I feel quite shamefull
> right now...

This was no criticism on your project. I'm only pointing out issues in the language you can't really do anything about.

Kind Regards
Benjamin Thaut