I've been reading through various delete topics in the past hour, but couldn't find any statement on how manual memory management would look, if the delete operator is deprecated. Something like the following seems really odd:

class foo {
	public new(size_t sz){ //language support
		return malloc(sz);
	}

	public void Delete(){ // no language support ??
		this.__dtor();
		free(this);
	}
}

auto fooInst = new foo(); //language support
fooInst.Delete(); //no language support ??
-- 
Kind Regards
Benjamin Thaut

On 4/26/11 12:36 PM, Benjamin Thaut wrote:
> I've been reading through various delete topics in the past hour, but
> couldn't find any statement on how manual memory management would look,
> if the delete operator is deprecated. Something like the following seems
> really odd:
>
> class foo {
> public new(size_t sz){ //language support
> return malloc(sz);
> }
>
> public void Delete(){ // no language support ??
> this.__dtor();
> free(this);
> }
> }
>
> auto fooInst = new foo(); //language support
> fooInst.Delete(); //no language support ??

You'd just define functions for object creation and disposal.

Andrei

On Tue, 26 Apr 2011 13:36:37 -0400, Benjamin Thaut <code@benjamin-thaut.de> wrote:

> I've been reading through various delete topics in the past hour, but couldn't find any statement on how manual memory management would look, if the delete operator is deprecated. Something like the following seems really odd:
>
> class foo {
> 	public new(size_t sz){ //language support
> 		return malloc(sz);
> 	}
>
> 	public void Delete(){ // no language support ??
> 		this.__dtor();
> 		free(this);
> 	}
> }
>
> auto fooInst = new foo(); //language support
> fooInst.Delete(); //no language support ??

IIUC, the custom allocator will be deprecated as well.

What I think you need to use instead is emplace (a phobos function, not sure where it is), clear, and GC.free.

Andrei hinted at a not-yet-written drop-in replacement for delete, but I'm not sure how that looks.

-Steve

Am 26.04.2011 19:59, schrieb Steven Schveighoffer:
> On Tue, 26 Apr 2011 13:36:37 -0400, Benjamin Thaut
> <code@benjamin-thaut.de> wrote:
>
>> I've been reading through various delete topics in the past hour, but
>> couldn't find any statement on how manual memory management would
>> look, if the delete operator is deprecated. Something like the
>> following seems really odd:
>>
>> class foo {
>> public new(size_t sz){ //language support
>> return malloc(sz);
>> }
>>
>> public void Delete(){ // no language support ??
>> this.__dtor();
>> free(this);
>> }
>> }
>>
>> auto fooInst = new foo(); //language support
>> fooInst.Delete(); //no language support ??
>
> IIUC, the custom allocator will be deprecated as well.
>
> What I think you need to use instead is emplace (a phobos function, not
> sure where it is), clear, and GC.free.
>
> Andrei hinted at a not-yet-written drop-in replacement for delete, but
> I'm not sure how that looks.
>
> -Steve

I don't want to use the GC at all, and clear() seems inefficent, since it reaintializes the object. This is unneccsary since I just want to throw it away anyway.

emplace only works for structs, it does not work for classes.

Could someone please write a small example how manual memory management would look without new / delete?

When the new operator can not be overloaded anymore, what happens when I dedicde to manualy manage the memory for a certain class? I then would have to search and replace every single new statement for that class. What happens when I forgett one? Some of my instances will then be on the GC heap and some on the self managed heap?

-- 
Kind Regards
Benjamin Thaut

On Tue, 26 Apr 2011 14:14:11 -0400, Benjamin Thaut <code@benjamin-thaut.de> wrote:

> Am 26.04.2011 19:59, schrieb Steven Schveighoffer:
>> On Tue, 26 Apr 2011 13:36:37 -0400, Benjamin Thaut
>> <code@benjamin-thaut.de> wrote:
>>
>>> I've been reading through various delete topics in the past hour, but
>>> couldn't find any statement on how manual memory management would
>>> look, if the delete operator is deprecated. Something like the
>>> following seems really odd:
>>>
>>> class foo {
>>> public new(size_t sz){ //language support
>>> return malloc(sz);
>>> }
>>>
>>> public void Delete(){ // no language support ??
>>> this.__dtor();
>>> free(this);
>>> }
>>> }
>>>
>>> auto fooInst = new foo(); //language support
>>> fooInst.Delete(); //no language support ??
>>
>> IIUC, the custom allocator will be deprecated as well.
>>
>> What I think you need to use instead is emplace (a phobos function, not
>> sure where it is), clear, and GC.free.
>>
>> Andrei hinted at a not-yet-written drop-in replacement for delete, but
>> I'm not sure how that looks.
>>
>> -Steve
>
> I don't want to use the GC at all, and clear() seems inefficent, since it reaintializes the object. This is unneccsary since I just want to throw it away anyway.

This is no longer the case for classes.  It actually runs the same function that delete runs (rt_finalize).  Though, I'm not sure it's in 2.052...

> emplace only works for structs, it does not work for classes.

I have not used it, but I'm under the impression from Andrei that it is to replace scope classes, so I would guess it has to work for them.

> Could someone please write a small example how manual memory management would look without new / delete?

I think that is a good idea.

> When the new operator can not be overloaded anymore, what happens when I dedicde to manualy manage the memory for a certain class? I then would have to search and replace every single new statement for that class. What happens when I forgett one? Some of my instances will then be on the GC heap and some on the self managed heap?
>

disable the constructor, then use a static factory method to initialize the class with the correct heap.

If this isn't satisfactory, someone else will have to answer, I'm not really one of those who ever used custom allocators or emplace.

-Steve

Am 26.04.2011 20:23, schrieb Steven Schveighoffer:
> On Tue, 26 Apr 2011 14:14:11 -0400, Benjamin Thaut <code@benjamin-thaut.de> wrote:
> 
>> Am 26.04.2011 19:59, schrieb Steven Schveighoffer:
>>> On Tue, 26 Apr 2011 13:36:37 -0400, Benjamin Thaut <code@benjamin-thaut.de> wrote:
>>>
>>>> I've been reading through various delete topics in the past hour, but couldn't find any statement on how manual memory management would look, if the delete operator is deprecated. Something like the following seems really odd:
>>>>
>>>> class foo {
>>>> public new(size_t sz){ //language support
>>>> return malloc(sz);
>>>> }
>>>>
>>>> public void Delete(){ // no language support ??
>>>> this.__dtor();
>>>> free(this);
>>>> }
>>>> }
>>>>
>>>> auto fooInst = new foo(); //language support
>>>> fooInst.Delete(); //no language support ??
>>>
>>> IIUC, the custom allocator will be deprecated as well.
>>>
>>> What I think you need to use instead is emplace (a phobos function, not sure where it is), clear, and GC.free.
>>>
>>> Andrei hinted at a not-yet-written drop-in replacement for delete, but I'm not sure how that looks.
>>>
>>> -Steve
>>
>> I don't want to use the GC at all, and clear() seems inefficent, since it reaintializes the object. This is unneccsary since I just want to throw it away anyway.
> 
> This is no longer the case for classes.  It actually runs the same function that delete runs (rt_finalize).  Though, I'm not sure it's in 2.052...
> 
>> emplace only works for structs, it does not work for classes.
> 
> I have not used it, but I'm under the impression from Andrei that it is to replace scope classes, so I would guess it has to work for them.
> 

It *does* work for classes (as of dmd 2.052).

>> Could someone please write a small example how manual memory management would look without new / delete?
> 
> I think that is a good idea.
> 

Not a tutorial, just a simple example using C malloc/free: http://pastebin.com/HSBrk5kA

Cheers,
- Daniel

Am 26.04.2011 21:26, schrieb Daniel Gibson:
> Am 26.04.2011 20:23, schrieb Steven Schveighoffer:
>> On Tue, 26 Apr 2011 14:14:11 -0400, Benjamin Thaut
>> <code@benjamin-thaut.de>  wrote:
>>
>>> Am 26.04.2011 19:59, schrieb Steven Schveighoffer:
>>>> On Tue, 26 Apr 2011 13:36:37 -0400, Benjamin Thaut
>>>> <code@benjamin-thaut.de>  wrote:
>>>>
>>>>> I've been reading through various delete topics in the past hour, but
>>>>> couldn't find any statement on how manual memory management would
>>>>> look, if the delete operator is deprecated. Something like the
>>>>> following seems really odd:
>>>>>
>>>>> class foo {
>>>>> public new(size_t sz){ //language support
>>>>> return malloc(sz);
>>>>> }
>>>>>
>>>>> public void Delete(){ // no language support ??
>>>>> this.__dtor();
>>>>> free(this);
>>>>> }
>>>>> }
>>>>>
>>>>> auto fooInst = new foo(); //language support
>>>>> fooInst.Delete(); //no language support ??
>>>>
>>>> IIUC, the custom allocator will be deprecated as well.
>>>>
>>>> What I think you need to use instead is emplace (a phobos function, not
>>>> sure where it is), clear, and GC.free.
>>>>
>>>> Andrei hinted at a not-yet-written drop-in replacement for delete, but
>>>> I'm not sure how that looks.
>>>>
>>>> -Steve
>>>
>>> I don't want to use the GC at all, and clear() seems inefficent, since
>>> it reaintializes the object. This is unneccsary since I just want to
>>> throw it away anyway.
>>
>> This is no longer the case for classes.  It actually runs the same
>> function that delete runs (rt_finalize).  Though, I'm not sure it's in
>> 2.052...
>>
>>> emplace only works for structs, it does not work for classes.
>>
>> I have not used it, but I'm under the impression from Andrei that it is
>> to replace scope classes, so I would guess it has to work for them.
>>
>
> It *does* work for classes (as of dmd 2.052).
>
>>> Could someone please write a small example how manual memory
>>> management would look without new / delete?
>>
>> I think that is a good idea.
>>
>
> Not a tutorial, just a simple example using C malloc/free:
> http://pastebin.com/HSBrk5kA
>
> Cheers,
> - Daniel

Thanks for the example, thats exactly what I needed.

I still don't understand why the delete operator is deprecated completely. It could be defined, that it is only useable if the new and delete operator have been overloaded in the class or struct that is tried to be deleted.

-- 
Kind Regards
Benjamin Thaut

On 26.04.2011 21:48, Benjamin Thaut wrote:

> I still don't understand why the delete operator is deprecated completely.

  Me too, to be honest. Any pointers to this discussion? Custom new/delete ops could be *very* useful (and natural) for system-level programming (kernels & co), also for just manual MM (which is useful sometimes).

/Alexander

Am 26.04.2011 21:48, schrieb Benjamin Thaut:
> Am 26.04.2011 21:26, schrieb Daniel Gibson:
>> Am 26.04.2011 20:23, schrieb Steven Schveighoffer:
>>> On Tue, 26 Apr 2011 14:14:11 -0400, Benjamin Thaut <code@benjamin-thaut.de>  wrote:
>>>> Could someone please write a small example how manual memory management would look without new / delete?
>>>
>>> I think that is a good idea.
>>>
>>
>> Not a tutorial, just a simple example using C malloc/free: http://pastebin.com/HSBrk5kA
>>
>> Cheers,
>> - Daniel
> 
> Thanks for the example, thats exactly what I needed.
> 
> I still don't understand why the delete operator is deprecated completely. It could be defined, that it is only useable if the new and delete operator have been overloaded in the class or struct that is tried to be deleted.
> 

This way it's much more flexible. Note that you don't have to change the
classes at all (i.e. you don't have to provide new() and delete()) to
use a custom allocator. This means
1. you can use custom allocators with classes you didn't write yourself
2. you can even use different custom allocators for the same class at
the same time (you'd have to be really careful not to screw that up by
using the wrong deallocator for an Object)
3. you only have to write an (de)allocator once and you can use it for
any class, even if they're not derived from each other

Also, and I think this is really a great feature for performance that isn't available with overloaded new and delete operators, you can create an array of objects that really lie next to each other in memory (like an array of structs), so you can benefit from CPU cache effects.

This is a very simple example doing that: http://pastebin.com/98mGU7y1
However you have to be careful with it if, i.e. don't put new objects in
it, don't slice it (you have to at least feed the original array to
myDeleteArr()) etc.
To really use something like this probably a struct that enforces this
(by conservatively overloading opIndex, opAssign etc) would be better
than a function returning a dynamic array that happens to point to
objects that are adjacent in memory.

Cheers,
- Daniel

> On 26.04.2011 21:48, Benjamin Thaut wrote:
>
>> I still don't understand why the delete operator is deprecated completely.
>
>  Me too, to be honest. Any pointers to this discussion? Custom new/delete ops >
could be *very* useful (and natural) for system-level programming (kernels & >
co), also for just manual MM (which is useful sometimes).
>
> /Alexander

But you understand why it is deprecated for GC memory?

The main thing to note is that the semantics of C++ 'new' and D 'new' are rather
different.
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. So there is absolutely no way to overload the 'new' operator
meaningfully inside the D language. The argument for removing 'delete' overloading
is trivial after taking that into consideration.

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

Benjamin Thaut wrote:
> I still don't understand why the delete operator is deprecated completely. It could be defined, that it is only useable if the new and delete operator have been overloaded in the class or struct that is tried to be deleted.
hich
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) I agree that new/delete is nicer
to look at than the template-based version, but as discussed above, that does not
really help.

Timon