www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deterministic resource freeing - delete deprecation (again)

reply =?UTF-8?B?TWFyaXVzeiBHbGl3acWEc2tp?= <alienballance gmail.com> writes:
Hello,
I'm next person, which isn't necessarily happy about delete operator 
deprecation.
Because constructors / destructors are frequently used not only for 
application controlled memory management, how would You implement 
something like following code without delete operator?

<code>
void main(string[] args) {
     auto res = new Resource();
     auto s1 = new FirstSystem(res);
     delete s1;
     auto s2 = new SecondSystem(res);
}
class FirstSystem {
     this(Resource res) {
         res.referenced = true;
     }
     ~this() {
         res.referenced=false;
     }
}
class SecondSystem {
     this(Resource res) {
         assert(!res.referenced);
     }
}
</code>

Next questions would be:
* Are you going to drop destructor as well, or maybe destructor is going 
to be confusing feature with non-deterministic behaviour? (How would i 
know when heap allocated Socket will be destructed -> when connection 
will be closed -> if my system gonna be DoS'ed?)
* Are you going to stop supporting object oriented programming? (Well, 
if *deterministic* resource managing can be only inside function, and 
not object boundaries, that's my conclusion).

And finally, don't get me wrong. I'm just caricaturizing my current 
worries about the language, and if I'm missing something - please hint 
me what.

Sincerely,
Mariusz Gliwiński
Apr 27 2011
next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Apr 27, 11 19:42, Mariusz Gliwiński wrote:

 Hello,
 I'm next person, which isn't necessarily happy about delete operator
 deprecation.


I don't get the recent resistant against deletion of 'delete' which has 
been decided months before (before TDPL). The operator is removed does 
not mean the destructor can't be invoked at all.


 Because constructors / destructors are frequently used not only for
 application controlled memory management, how would You implement
 something like following code without delete operator?


Use 'scoped' or a 'struct' if you want to constrain 's1' in a scope

import std.typecons;
void main(string[] args) {
     auto res = new Resource();
     {
         auto s1 = scoped!FirstSystem(res);
     }
     auto s2 = new SecondSystem(res);
}

<or>

void main(string[] args) {
     auto res = new Resource();
     {
         auto s1 = FirstSystem(res);
     }
     auto s2 = new SecondSystem(res);
}
struct FirstSystem {
     private Resource res;
     this(Resource res) {
         this.res = res;
         res.referenced = true;
     }
     ~this() {
         res.referenced=false;
     }
}
class Resource {
     public bool referenced;
}

Or use 'clear' to replace 'delete' as told in many posts already

void main(string[] args) {
     auto res = new Resource();
     auto s1 = new FirstSystem(res);
     // many miles away
     clear(s1);
     auto s2 = new SecondSystem(res);
}


 <code>


[snip]

 </code>

 Next questions would be:
 * Are you going to drop destructor as well, or maybe destructor is going
 to be confusing feature with non-deterministic behaviour? (How would i
 know when heap allocated Socket will be destructed -> when connection
 will be closed -> if my system gonna be DoS'ed?)


The allocators (http://d-programming-language.org/class.html#allocators) 
and deallocators 
(http://d-programming-language.org/class.html#deallocators) are going 
away. The destructors 
(http://d-programming-language.org/class.html#destructors) are not.


 * Are you going to stop supporting object oriented programming? (Well,
 if *deterministic* resource managing can be only inside function, and
 not object boundaries, that's my conclusion).


'delete' only governs memory management. Since when deterministic 
*memory* management becomes a requirement of OOP? If you need 
deterministic resource management, you could use the dispose pattern. 
Java doesn't have a 'delete' operator either, that doesn't make Java a 
non-OOP language.


 And finally, don't get me wrong. I'm just caricaturizing my current
 worries about the language, and if I'm missing something - please hint
 me what.

 Sincerely,
 Mariusz Gliwiński
Apr 27 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 27 Apr 2011 07:42:22 -0400, Mariusz Gliwiński  
<alienballance gmail.com> wrote:


 Hello,
 I'm next person, which isn't necessarily happy about delete operator
 deprecation.
 Because constructors / destructors are frequently used not only for
 application controlled memory management, how would You implement
 something like following code without delete operator?


You can use clear to call the destructor of a class, and then GC.free (if  
you wish) to free the memory.  The recommendation is to only use clear,  
and then let the GC clean up the memory at its leisure.


 <code>
 void main(string[] args) {
      auto res = new Resource();
      auto s1 = new FirstSystem(res);
      delete s1;
      auto s2 = new SecondSystem(res);
 }
 class FirstSystem {
      this(Resource res) {
          res.referenced = true;
      }
      ~this() {
          res.referenced=false;
      }
 }
 class SecondSystem {
      this(Resource res) {
          assert(!res.referenced);
      }
 }
 </code>


Note there is a serious flaw in your destructor.  Destructors cannot  
access GC managed memory because if the destructor is called inside the  
GC, the GC managed memory being referenced may have already been destroyed.


 Next questions would be:
 * Are you going to drop destructor as well, or maybe destructor is going
 to be confusing feature with non-deterministic behaviour? (How would i
 know when heap allocated Socket will be destructed -> when connection
 will be closed -> if my system gonna be DoS'ed?)


If the Socket closes its resources in the finalizer, then use clear().  If  
the destructor does not close the resource (as could be the case if the  
resource is GC managed), you must implement a deterministic destructor  
member (with a different name, like close()) that you can call separately  
 from the finalizer.  There is no formal design for this, I really think  
there should be.


 * Are you going to stop supporting object oriented programming? (Well,
 if *deterministic* resource managing can be only inside function, and
 not object boundaries, that's my conclusion).


I assume this is rhetorical.

-Steve
Apr 27 2011
next sibling parent reply Alexander <aldem+dmars nk7.net> writes:
On 27.04.2011 15:15, Steven Schveighoffer wrote:


 You can use clear to call the destructor of a class, and then GC.free (if you
wish) to free the memory. 


  BTW, why it is called clear()? To me, clearing something is not destruction.
For instance, some buffer object may be cleared to empty the buffer, so the
action of clear() is counter-intuitive, IMHO.

/Alexander
Apr 27 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 27.04.2011 15:37, schrieb Alexander:

 On 27.04.2011 15:15, Steven Schveighoffer wrote:


 You can use clear to call the destructor of a class, and then GC.free (if you
wish) to free the memory.


    BTW, why it is called clear()? To me, clearing something is not
destruction. For instance, some buffer object may be cleared to empty the
buffer, so the action of clear() is counter-intuitive, IMHO.

 /Alexander


clear() also works for simple types and pointers - it just resets them 
to type.init.
Which sucks when it's a pointer to a struct and the pointer is set to 
null instead of calling the structs destructor.

Maybe a function called "destroy()" that only works for classes and 
structs (with destructors? or just null other kinds of structs or 
something?) may help. It's a better name and it could work more like 
you'd expect for pointers to structs.


Cheers,
- Daniel
Apr 27 2011
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Apr 27, 11 21:37, Alexander wrote:

 On 27.04.2011 15:15, Steven Schveighoffer wrote:


 You can use clear to call the destructor of a class, and then GC.free (if you
wish) to free the memory.


    BTW, why it is called clear()? To me, clearing something is not
destruction. For instance, some buffer object may be cleared to empty the
buffer, so the action of clear() is counter-intuitive, IMHO.

 /Alexander


Because Andrei chose to call it clear() :)

Well according to 
http://www.digitalmars.com/d/archives/digitalmars/D/clear_97688.html, 
because the function "clears the state of
an object.".

I'd rather it called destroy(), or when 'delete' is no longer a keyword, 
delete(), as .clear() is a container method for a different action 
(http://www.digitalmars.com/d/archives/digitalmars/D/Meaning_of_.clear_for_containers_126094.html).
Apr 27 2011
parent Alexander <aldem+dmars nk7.net> writes:
On 27.04.2011 15:46, KennyTM~ wrote:


 Because Andrei chose to call it clear() :)


  Well, this is bad choice, IMHO... I would expect that this will zeroize all
data (for arrays/structs at least), but for objects...


 ...because the function "clears the state of an object.".


  ...which is (from definition) doesn't imply destruction. Oh-oh...

/Alexander
Apr 27 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-27 15:15, Steven Schveighoffer wrote:

 On Wed, 27 Apr 2011 07:42:22 -0400, Mariusz Gliwiński
 <alienballance gmail.com> wrote:


 Hello,
 I'm next person, which isn't necessarily happy about delete operator
 deprecation.
 Because constructors / destructors are frequently used not only for
 application controlled memory management, how would You implement
 something like following code without delete operator?


 You can use clear to call the destructor of a class, and then GC.free
 (if you wish) to free the memory. The recommendation is to only use
 clear, and then let the GC clean up the memory at its leisure.


 <code>
 void main(string[] args) {
 auto res = new Resource();
 auto s1 = new FirstSystem(res);
 delete s1;
 auto s2 = new SecondSystem(res);
 }
 class FirstSystem {
 this(Resource res) {
 res.referenced = true;
 }
 ~this() {
 res.referenced=false;
 }
 }
 class SecondSystem {
 this(Resource res) {
 assert(!res.referenced);
 }
 }
 </code>


 Note there is a serious flaw in your destructor. Destructors cannot
 access GC managed memory because if the destructor is called inside the
 GC, the GC managed memory being referenced may have already been destroyed.


 Next questions would be:
 * Are you going to drop destructor as well, or maybe destructor is going
 to be confusing feature with non-deterministic behaviour? (How would i
 know when heap allocated Socket will be destructed -> when connection
 will be closed -> if my system gonna be DoS'ed?)


 If the Socket closes its resources in the finalizer, then use clear().
 If the destructor does not close the resource (as could be the case if
 the resource is GC managed), you must implement a deterministic
 destructor member (with a different name, like close()) that you can
 call separately from the finalizer. There is no formal design for this,
 I really think there should be.


You mean like "dispose" in Tango. That's called when "delete" or "scope" 
is used.


 * Are you going to stop supporting object oriented programming? (Well,
 if *deterministic* resource managing can be only inside function, and
 not object boundaries, that's my conclusion).


 I assume this is rhetorical.

 -Steve



-- 
/Jacob Carlborg
Apr 27 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 27 Apr 2011 10:18:39 -0400, Jacob Carlborg <doob me.com> wrote:


 On 2011-04-27 15:15, Steven Schveighoffer wrote:



 If the Socket closes its resources in the finalizer, then use clear().
 If the destructor does not close the resource (as could be the case if
 the resource is GC managed), you must implement a deterministic
 destructor member (with a different name, like close()) that you can
 call separately from the finalizer. There is no formal design for this,
 I really think there should be.


 You mean like "dispose" in Tango. That's called when "delete" or "scope"  
 is used.


Yes, that is exactly what I was thinking of (couldn't think of the  


-Steve
Apr 27 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 27.04.2011 16:25, Steven Schveighoffer wrote:


 You mean like "dispose" in Tango. That's called when "delete" or "scope" is
used.


 
 Yes, that is exactly what I was thinking of (couldn't think of the name!). 




unmanaged resources, which are referenced by object, but not the memory
allocated to object itself.

/Alexander
Apr 27 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 27 Apr 2011 10:32:57 -0400, Alexander <aldem+dmars nk7.net> wrote:


 On 27.04.2011 16:25, Steven Schveighoffer wrote:


 You mean like "dispose" in Tango. That's called when "delete" or  
 "scope" is used.


 Yes, that is exactly what I was thinking of (couldn't think of the  




 unmanaged resources, which are referenced by object, but not the memory  
 allocated to object itself.


dispose is supposed to be called deterministically (i.e. not by the GC),  
so yeah, it's the same thing.

basically, dispose cleans up resources *knowing* that all its references  
are still valid.

The destructor (finalizer) cleans up only resources it knows are not GC  
managed.

So for instance, if you have a Socket class which contains a file  
descriptor, and a SocketStream class that contains a Socket,  
SocketStream.dispose would call Socket.dispose, which would close the file  
descriptor.  But the destructor of SocketStream would not call  
Socket.dispose, since it does not know if the destructor could be called.

The deallocation of object memory is a separate thing (outside dispose or  
the destructor).

-Steve
Apr 27 2011
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 27 Apr 2011 10:48:08 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 So for instance, if you have a Socket class which contains a file  
 descriptor, and a SocketStream class that contains a Socket,  
 SocketStream.dispose would call Socket.dispose, which would close the  
 file descriptor.  But the destructor of SocketStream would not call  
 Socket.dispose, since it does not know if the destructor could be called.


This should have read "since it does not know if the Socket memory is  
still valid"

-Steve
Apr 27 2011
prev sibling parent reply Alexander <aldem+dmars nk7.net> writes:
On 27.04.2011 16:48, Steven Schveighoffer wrote:


 basically, dispose cleans up resources *knowing* that all its references are
still valid.


  Right, but cleaning of resources doesn't mean that object will be destructed
- it can be reused afterwards (connection reestablished, file reopened etc).


 The deallocation of object memory is a separate thing (outside dispose or the
destructor).


  That's why I think that clear() is bad name choice, when it leads to
destruction :)

/Alexander
Apr 27 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 27 Apr 2011 11:08:23 -0400, Alexander <aldem+dmars nk7.net> wrote:


 On 27.04.2011 16:48, Steven Schveighoffer wrote:


 basically, dispose cleans up resources *knowing* that all its  
 references are still valid.


   Right, but cleaning of resources doesn't mean that object will be  
 destructed - it can be reused afterwards (connection reestablished, file  
 reopened etc).


I don't think reuse is a requirement of dispose.  It might be that those  
resources are only allocated on construction, which would require you to  
re-construct the object.  I think the only difference between the  
destructor (finalizer) and dispose is that dispose is guaranteed that all  
the memory is still allocated, whereas the finalizer is not given that  
guarantee.


 The deallocation of object memory is a separate thing (outside dispose  
 or the destructor).


   That's why I think that clear() is bad name choice, when it leads to  
 destruction :)


The name choice is no longer up for debate.  It's already set in print,  
and in the language.

-Steve
Apr 27 2011
next sibling parent Francisco Almeida <francisco.m.almeida gmail.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 On Wed, 27 Apr 2011 11:08:23 -0400, Alexander <aldem+dmars nk7.net> wrote:
 [...]
 The name choice is no longer up for debate.  It's already set in print,
 and in the language.
 -Steve


clear() is a library function which is itself having its behavior changed for
the
next DMD release. I think changing it to a more descriptive name such as
destroy()
is feasible. Especially when there are existing class methods already called
clear(). Even newcomers from C++ are used to clear() as a common method name
from
STL classes.
Apr 27 2011
prev sibling parent reply Alexander <aldem+dmars nk7.net> writes:
On 27.04.2011 17:23, Steven Schveighoffer wrote:


 I think the only difference between the destructor (finalizer) and dispose is
 that dispose is guaranteed that all the memory is still allocated, whereas the
finalizer is not given that guarantee.


  Not really. Dispose() may be called more than once, there is no guarantee
that resources are still allocated.


 The name choice is no longer up for debate.  It's already set in print, and in
the language.


  Well, it took me some time to find it out "in print" and "in the language",
given that everywhere on site no single reference to it, and in most recent D2
it doesn't work correctly.

  Not to mention that it conflicts with std.container and std.array, where
semantics of clear() is quite different (removes elements) - are those will be
changed too?

/Alexander
Apr 27 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-27 17:41, Alexander wrote:

 On 27.04.2011 17:23, Steven Schveighoffer wrote:


 I think the only difference between the destructor (finalizer) and dispose is
 that dispose is guaranteed that all the memory is still allocated, whereas the
finalizer is not given that guarantee.


    Not really. Dispose() may be called more than once, there is no guarantee
that resources are still allocated.


What I think Steven meant in this case is that when calling dispose, in 
Tango, any object will still be valid, i.e. the garbage collector hasn't 
collected it yet.


 The name choice is no longer up for debate.  It's already set in print, and in
the language.


    Well, it took me some time to find it out "in print" and "in the language",
given that everywhere on site no single reference to it, and in most recent D2
it doesn't work correctly.

    Not to mention that it conflicts with std.container and std.array, where
semantics of clear() is quite different (removes elements) - are those will be
changed too?

 /Alexander



-- 
/Jacob Carlborg
Apr 27 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 27 Apr 2011 12:26:38 -0400, Jacob Carlborg <doob me.com> wrote:


 On 2011-04-27 17:41, Alexander wrote:

 On 27.04.2011 17:23, Steven Schveighoffer wrote:


 I think the only difference between the destructor (finalizer) and  
 dispose is
 that dispose is guaranteed that all the memory is still allocated,  
 whereas the finalizer is not given that guarantee.


    Not really. Dispose() may be called more than once, there is no  
 guarantee that resources are still allocated.


 What I think Steven meant in this case is that when calling dispose, in  
 Tango, any object will still be valid, i.e. the garbage collector hasn't  
 collected it yet.


Yes, that is exactly right.  I meant literally memory, not all resources.


 The name choice is no longer up for debate.  It's already set in  
 print, and in the language.


    Well, it took me some time to find it out "in print" and "in the  
 language", given that everywhere on site no single reference to it, and  
 in most recent D2 it doesn't work correctly.




There is a recently filed report on the lack of documentation.


    Not to mention that it conflicts with std.container and std.array,  
 where semantics of clear() is quite different (removes elements) - are  
 those will be changed too?




clear is not a keyword, it is possible to name a member clear, and also  
have a clear global function.

-Steve
Apr 27 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 27.04.2011 19:13, Steven Schveighoffer wrote:


 clear is not a keyword, it is possible to name a member clear, and also have a
clear global function.


  Sure it is, though it is counter-intuitive - to use same name with quite
different meaning. As for me, if this will really be in final spec, I'll always
alias it to destroy().

  BTW, could you please point me to "the ultimate authority"? I am referring to
your "The name choice is no longer up for debate.  It's already set in print,
and in the language." - so far, I was thinking that DigitalMars website is the
one, but your
words make me wonder, if this is still true.

  And, since there is a phrase: "It is not governed by a corporate agenda or
any overarching theory of programming. The needs and contributions of the D
programming community form the direction it goes." I would like to know, how
"the community" come
to this choice, which is quite confusing, at least.

/Alexander
Apr 27 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 27 Apr 2011 17:30:54 -0400, Alexander <aldem+dmars nk7.net> wrote:


 On 27.04.2011 19:13, Steven Schveighoffer wrote:


 clear is not a keyword, it is possible to name a member clear, and also  
 have a clear global function.


   Sure it is, though it is counter-intuitive - to use same name with  
 quite different meaning. As for me, if this will really be in final  
 spec, I'll always alias it to destroy().


That has been pointed out before.  Yes, it is considered a bad idea to do  
that, but we have no choice now, clear is the name.

I probably would consider changing the name of dcollections' function that  
empties all elements.  Clear is a very good name for that, but maybe it  
should be something else to avoid confusion.


   BTW, could you please point me to "the ultimate authority"? I am  
 referring to your "The name choice is no longer up for debate.  It's  
 already set in print, and in the language." - so far, I was thinking  
 that DigitalMars website is the one, but your
 words make me wonder, if this is still true.


http://www.amazon.com/gp/reader/0321635361/ref=sib_dp_pt#reader-link


   And, since there is a phrase: "It is not governed by a corporate  
 agenda or any overarching theory of programming. The needs and  
 contributions of the D programming community form the direction it  
 goes." I would like to know, how "the community" come
 to this choice, which is quite confusing, at least.


clear is Andrei's idea, he proposed it on the newsgroups.

Here was the first mention of it.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=97688

I'm not sure if anyone really debated the name until it was already part  
of the language, not much was said about the name in that thread.  I know  
many people have questioned the name of it after it was already in the  
language.  It may have caught some by surprise.

-Steve
Apr 28 2011
parent reply Francisco Almeida <francisco.m.almeida gmail.com> writes:
On 28-04-2011 17:09, Steven Schveighoffer wrote:

 On Wed, 27 Apr 2011 17:30:54 -0400, Alexander <aldem+dmars nk7.net> wrote:


 On 27.04.2011 19:13, Steven Schveighoffer wrote:


 clear is not a keyword, it is possible to name a member clear, and
 also have a clear global function.


 Sure it is, though it is counter-intuitive - to use same name with
 quite different meaning. As for me, if this will really be in final
 spec, I'll always alias it to destroy().


 That has been pointed out before. Yes, it is considered a bad idea to do
 that, but we have no choice now, clear is the name.


We have no choice? Since when is a function "part of the language"? It 
could still be renamed with minimal to no impact on Phobos. If it 
*really* cannot be renamed (which I doubt), then ok, I guess we'll have 
to live with it.
Apr 29 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Apr 2011 15:18:23 -0400, Francisco Almeida  
<francisco.m.almeida gmail.com> wrote:


 On 28-04-2011 17:09, Steven Schveighoffer wrote:

 On Wed, 27 Apr 2011 17:30:54 -0400, Alexander <aldem+dmars nk7.net>  
 wrote:


 On 27.04.2011 19:13, Steven Schveighoffer wrote:


 clear is not a keyword, it is possible to name a member clear, and
 also have a clear global function.


 Sure it is, though it is counter-intuitive - to use same name with
 quite different meaning. As for me, if this will really be in final
 spec, I'll always alias it to destroy().


 That has been pointed out before. Yes, it is considered a bad idea to do
 that, but we have no choice now, clear is the name.


 We have no choice? Since when is a function "part of the language"? It  
 could still be renamed with minimal to no impact on Phobos. If it  
 *really* cannot be renamed (which I doubt), then ok, I guess we'll have  
 to live with it.


It's already in the official book describing the language (IIRC, there's  
quite a bit of text on it).  At some point, we have to stop changing parts  
of the spec/design so people can have a stable environment.  The decision  
was to avoid changing things that are covered in TDPL as much as possible.

Is it possible to change?  Yes.  But you will have to convince Andrei and  
Walter, and really, this is a naming issue.  It's not tantamount to the  
language's functionality.

You are more likely to see the clear function in std.container change.

-Steve
Apr 29 2011
prev sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 27/04/11 12:42 PM, Mariusz Gliwiński wrote:

 Hello,
 I'm next person, which isn't necessarily happy about delete operator
 deprecation.
 <snip>
 Sincerely,
 Mariusz Gliwiński


Perhaps someone with knowledge about the answer to this question should 
add it to the D FAQ. It is a frequently asked question after all. Might 
be good under the 'Rationale' section.
Apr 27 2011