www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Meaning of .clear() for containers

reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Answering a question over on stack overflow I realized that clear() has 2
meanings.

TDPL says that clear should be used to free resources of the object and place
the object into an invalid state. That is failure can occur but memory
corruption is prevent, similar to null for pointer types.

However for container types clear() is used to empty the container. It is still
valid to use the container after calling clear(), but the definition from TDPL
suggest that this can not be expected.
Jan 04 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Jan 2011 11:53:59 -0500, Jesse Phillips  
<jessekphillips+D gmail.com> wrote:


 Answering a question over on stack overflow I realized that clear() has  
 2 meanings.

 TDPL says that clear should be used to free resources of the object and  
 place the object into an invalid state. That is failure can occur but  
 memory corruption is prevent, similar to null for pointer types.

 However for container types clear() is used to empty the container. It  
 is still valid to use the container after calling clear(), but the  
 definition from TDPL suggest that this can not be expected.


clear as a global function is for destroying a class/struct

clear as a member can do anything.  clear is not a keyword.

clear(container) -> same as delete container, but without freeing any  
memory.

container.clear() -> remove all elements

This has been brought up before as a problem, I'm not sure it's that  
terrible, but I can see why there might be confusion.

-Steve
Jan 04 2011
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Steven Schveighoffer wrote:

 On Tue, 04 Jan 2011 11:53:59 -0500, Jesse Phillips
 <jessekphillips+D gmail.com> wrote:
=20

 Answering a question over on stack overflow I realized that clear()
 has 2 meanings.

 TDPL says that clear should be used to free resources of the object
 and place the object into an invalid state. That is failure can occur
 but memory corruption is prevent, similar to null for pointer types.

 However for container types clear() is used to empty the container. It=





 is still valid to use the container after calling clear(), but the
 definition from TDPL suggest that this can not be expected.


=20
 clear as a global function is for destroying a class/struct
=20
 clear as a member can do anything.  clear is not a keyword.
=20
 clear(container) -> same as delete container, but without freeing any
 memory.
=20
 container.clear() -> remove all elements
=20
 This has been brought up before as a problem, I'm not sure it's that
 terrible, but I can see why there might be confusion.
=20


	Uniform function call syntax?

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jan 04 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Jan 2011 13:58:02 -0500, Jérôme M. Berger <jeberger free.fr>  
wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Jan 2011 11:53:59 -0500, Jesse Phillips
 <jessekphillips+D gmail.com> wrote:


 Answering a question over on stack overflow I realized that clear()
 has 2 meanings.

 TDPL says that clear should be used to free resources of the object
 and place the object into an invalid state. That is failure can occur
 but memory corruption is prevent, similar to null for pointer types.

 However for container types clear() is used to empty the container. It
 is still valid to use the container after calling clear(), but the
 definition from TDPL suggest that this can not be expected.


 clear as a global function is for destroying a class/struct

 clear as a member can do anything.  clear is not a keyword.

 clear(container) -> same as delete container, but without freeing any
 memory.

 container.clear() -> remove all elements

 This has been brought up before as a problem, I'm not sure it's that
 terrible, but I can see why there might be confusion.


 	Uniform function call syntax?


I don't expect this to be a huge problem.  Will people who more likely  
destroy an object with:

clear(obj);

or

obj.clear();

?  To me, the first looks like you are doing an operation to the object,  
where the second looks like you are having the object do an operation.

UFC is going to cause lots of these little corner cases.  Another I can  
think of is global properties.  with  property foo(int x), do you call  
this as foo = 1; or 1.foo?

-Steve
Jan 04 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Steven Schveighoffer wrote:

 I don't expect this to be a huge problem.  Will people who more likely
 destroy an object with:
=20
 clear(obj);
=20
 or
=20
 obj.clear();
=20
 ?  To me, the first looks like you are doing an operation to the object=


,

 where the second looks like you are having the object do an operation.
=20
 UFC is going to cause lots of these little corner cases.  Another I can=



 think of is global properties.  with  property foo(int x), do you call
 this as foo =3D 1; or 1.foo?
=20


	I believe this becomes a problem when you have *both* a free
standing function (to destroy the container) and a method (to empty
it). And yes, this will crop up a lot with UFC.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jan 06 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 06, 2011 10:47:11 J=E9r=F4me M. Berger wrote:

 Steven Schveighoffer wrote:

 I don't expect this to be a huge problem.  Will people who more likely
 destroy an object with:
=20
 clear(obj);
=20
 or
=20
 obj.clear();
=20
 ?  To me, the first looks like you are doing an operation to the object,
 where the second looks like you are having the object do an operation.
=20
 UFC is going to cause lots of these little corner cases.  Another I can
 think of is global properties.  with  property foo(int x), do you call
 this as foo =3D 1; or 1.foo?


=20
 	I believe this becomes a problem when you have *both* a free
 standing function (to destroy the container) and a method (to empty
 it). And yes, this will crop up a lot with UFC.


Yes. It would almost certainly have to make it so that the compiler used a=
=20
member function when there was a choice between a member function and a fre=
e-
standing function and overloading does not make it clear which to use.=20
Unfortunately, that would mean that which function would be called could ch=
ange=20
when a member function was added or removed, but I don't see any way around=
=20
that. Still, much as clear is a good name for both the free-standing functi=
on=20
and the member function. Perhaps one of them should be changed, regardless =
of=20
the state of UFC.

In theory, we're going to get UFC at some point, but this sort of issue may=
 make=20
it unreasonable to implement. We'll just have to wait and see until it's=20
actually implemented, I suppose.

=2D Jonathan M Davis
Jan 06 2011
prev sibling next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Steven Schveighoffer Wrote:


 On Tue, 04 Jan 2011 11:53:59 -0500, Jesse Phillips  
 <jessekphillips+D gmail.com> wrote:
 

 Answering a question over on stack overflow I realized that clear() has  
 2 meanings.

 TDPL says that clear should be used to free resources of the object and  
 place the object into an invalid state. That is failure can occur but  
 memory corruption is prevent, similar to null for pointer types.

 However for container types clear() is used to empty the container. It  
 is still valid to use the container after calling clear(), but the  
 definition from TDPL suggest that this can not be expected.


 
 clear as a global function is for destroying a class/struct
 
 clear as a member can do anything.  clear is not a keyword.
 
 clear(container) -> same as delete container, but without freeing any  
 memory.
 
 container.clear() -> remove all elements
 
 This has been brought up before as a problem, I'm not sure it's that  
 terrible, but I can see why there might be confusion.
 
 -Steve


Then the answer I gave was wrong, and am curious what the correct answer is:

"Delete is not to be used with D version 2 and intended to be removed from the
language. What the hold up is, I am not sure. Instead you use a function, I
believe clear(), which resets your object to and empty state (frees resources
that isn't GC memory). This is explained in The D Programming Language book,
which I don't have handy right now."

http://stackoverflow.com/questions/4589114/when-to-delete-in-d
Jan 04 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Jan 2011 17:56:51 -0500, Jesse Phillips  
<jessekphillips+D gmail.com> wrote:


 Steven Schveighoffer Wrote:


 On Tue, 04 Jan 2011 11:53:59 -0500, Jesse Phillips
 <jessekphillips+D gmail.com> wrote:


 Answering a question over on stack overflow I realized that clear()  


 has

 2 meanings.

 TDPL says that clear should be used to free resources of the object  


 and

 place the object into an invalid state. That is failure can occur but
 memory corruption is prevent, similar to null for pointer types.

 However for container types clear() is used to empty the container. It
 is still valid to use the container after calling clear(), but the
 definition from TDPL suggest that this can not be expected.


 clear as a global function is for destroying a class/struct

 clear as a member can do anything.  clear is not a keyword.

 clear(container) -> same as delete container, but without freeing any
 memory.

 container.clear() -> remove all elements

 This has been brought up before as a problem, I'm not sure it's that
 terrible, but I can see why there might be confusion.

 -Steve


 Then the answer I gave was wrong, and am curious what the correct answer  
 is:

 "Delete is not to be used with D version 2 and intended to be removed  
 from the language. What the hold up is, I am not sure. Instead you use a  
 function, I believe clear(), which resets your object to and empty state  
 (frees resources that isn't GC memory). This is explained in The D  
 Programming Language book, which I don't have handy right now."


That answer looks fine to me.

-Steve
Jan 05 2011
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Steven Schveighoffer Wrote:


 Then the answer I gave was wrong, and am curious what the correct answer  
 is:

 "Delete is not to be used with D version 2 and intended to be removed  
 from the language. What the hold up is, I am not sure. Instead you use a  
 function, I believe clear(), which resets your object to and empty state  
 (frees resources that isn't GC memory). This is explained in The D  
 Programming Language book, which I don't have handy right now."


 
 That answer looks fine to me.
 
 -Steve


K, pulled the book out. What I missed is that clear(object) calls the
destructor which is the function that frees the resources.
Jan 05 2011
prev sibling parent reply so <so so.do> writes:
 clear as a global function is for destroying a class/struct

 clear as a member can do anything.  clear is not a keyword.

 clear(container) -> same as delete container, but without freeing any  
 memory.

 container.clear() -> remove all elements

 This has been brought up before as a problem, I'm not sure it's that  
 terrible, but I can see why there might be confusion.


Thanks for the example, this semantical issue was bugging me for a while  
(not the OOP vs whatever flamewar).

Is there a semantical difference between "function(obj)" and  
"obj.function()"?
If we are not clear on this simple thing, we should just stop here :)
Jan 07 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 07 Jan 2011 07:54:06 -0500, so <so so.do> wrote:


 clear as a global function is for destroying a class/struct

 clear as a member can do anything.  clear is not a keyword.

 clear(container) -> same as delete container, but without freeing any  
 memory.

 container.clear() -> remove all elements

 This has been brought up before as a problem, I'm not sure it's that  
 terrible, but I can see why there might be confusion.


 Thanks for the example, this semantical issue was bugging me for a while  
 (not the OOP vs whatever flamewar).

 Is there a semantical difference between "function(obj)" and  
 "obj.function()"?
 If we are not clear on this simple thing, we should just stop here :)


Yes, there is a huge semantic difference.  One is a member function the  
other is a free function.  Currently, you must use function(obj) for a  
free function and obj.function() for a member function.

The one exception is for arrays, for which arr.fn() is translated to  
fn(arr).

Theoretically, we are going to get something called uniform function call  
syntax, where that property of arrays is spread to all types (including  
classes and structs), and at that point, we are going to start having  
conflicts.  The obvious thing to do in this case is that an actual member  
function always overrides a free function.  But this would cause confusion  
with things like 'clear', where a member function can override the  
semantic meaning of a common function.

My personal opinion is that UFC is likely going to be more trouble than  
it's worth (recent developments have significantly lowered the value of  
UFC, such as final interface functions), but it is in TDPL, so we'll see  
if D sticks to that plan.

-Steve
Jan 07 2011