www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - delete hash[key] deprecated???

reply Leandro Lucarella <llucax gmail.com> writes:
I have this example code:

class C { ... }

C[string] hash;

auto c = new C;
hash["x"] = c;

// other place
delete hash["x"];
hash.remove("x");

And I got: Error: delete aa[key] deprecated, use aa.remove(key)

I don't want to remove the element of the array, I want to destroy the
object stored at key "x". Does hash.remove("x") remove the item from the
hash *and* delete c? I found that a little odd. If not, do I have to do:
auto c = hash["x"];
hash.remove["x"];
delete c;

I find that a little odd too.

And yes, I want to explicitly delete the object because I want to minimize
the GC activity since my program is kinda RT :)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Peperino nos enseña que debemos ofrendirnos con ofrendas de vino si
queremos obtener la recompensa de la parte del medio del vacío.
	-- Peperino Pómoro
Feb 11 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20080211130722.GA18729 burns.springfield.home...


 And I got: Error: delete aa[key] deprecated, use aa.remove(key)


As the error suggests, the first syntax was used before the second was 
introduced.  The funny thing is, the 'remove' syntax was partially 
introduced to allow exactly what you're trying to do.  X(


 I don't want to remove the element of the array, I want to destroy the
 object stored at key "x". Does hash.remove("x") remove the item from the
 hash *and* delete c?


No.


 If not, do I have to do:
 auto c = hash["x"];
 hash.remove["x"];
 delete c;


Yeah, you do.
Feb 11 2008
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el 11 de febrero a las 08:50 me escribiste:

 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20080211130722.GA18729 burns.springfield.home...
 

 And I got: Error: delete aa[key] deprecated, use aa.remove(key)


 
 As the error suggests, the first syntax was used before the second was 
 introduced.  The funny thing is, the 'remove' syntax was partially 
 introduced to allow exactly what you're trying to do.  X(
 

 I don't want to remove the element of the array, I want to destroy the
 object stored at key "x". Does hash.remove("x") remove the item from the
 hash *and* delete c?


 
 No.
 

 If not, do I have to do:
 auto c = hash["x"];
 hash.remove["x"];
 delete c;


 
 Yeah, you do. 


Ugly :(

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
You are the very reason why everything happens to you
Feb 11 2008
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:fopjrt$1b2c$1 digitalmars.com...
<snip>

 If not, do I have to do:
 auto c = hash["x"];
 hash.remove["x"];
 delete c;


 Yeah, you do.



No I don't.

    delete * cast(Object*) &hash["x"];

Test code:
----------
import std.stdio;

class Test {
    ~this() { writefln("Object destroyed"); }
}

void main() {
    Test[int] aa;

    aa[42] = new Test;
    delete * cast(Object*) &aa[42];
    writefln(42 in aa);
}
----------

The last statement is as much to show that it is actually deleted there and 
then as to show that it suppresses removal of the AA key.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 14 2008
parent reply Leandro Lucarella <llucax gmail.com> writes:
Stewart Gordon, el 15 de julio a las 01:14 me escribiste:

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:fopjrt$1b2c$1 digitalmars.com...
 <snip>

If not, do I have to do:
auto c = hash["x"];
hash.remove["x"];
delete c;


Yeah, you do.


 
 
 No I don't.
 
    delete * cast(Object*) &hash["x"];


Phew! That's much better! (!) o_O

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
More people die from a champagne-cork popping,
than from poison spiders
Jul 15 2008
parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Tue, 15 Jul 2008 11:13:33 -0300, Leandro Lucarella
<llucax gmail.com> wrote:


Stewart Gordon, el 15 de julio a las 01:14 me escribiste:

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:fopjrt$1b2c$1 digitalmars.com...
 <snip>

If not, do I have to do:
auto c = hash["x"];
hash.remove["x"];
delete c;


Yeah, you do.


 
 
 No I don't.
 
    delete * cast(Object*) &hash["x"];


Phew! That's much better! (!) o_O


An alternative hack:

delete *("x" in hash);
Jul 15 2008
parent reply Leandro Lucarella <llucax gmail.com> writes:
Max Samukha, el 15 de julio a las 17:54 me escribiste:

If not, do I have to do:
auto c = hash["x"];
hash.remove["x"];
delete c;


Yeah, you do.


 
 
 No I don't.
 
    delete * cast(Object*) &hash["x"];


Phew! That's much better! (!) o_O


 
 An alternative hack:
 
 delete *("x" in hash);


It just gets better and better ;)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
22% of the time a pizza will arrive faster than an ambulance in Great-Britain
Jul 15 2008
next sibling parent reply "Koroskin Denis" <2korden+dmd gmail.com> writes:
On Tue, 15 Jul 2008 20:40:07 +0400, Leandro Lucarella <llucax gmail.com>  
wrote:


 Max Samukha, el 15 de julio a las 17:54 me escribiste:

If not, do I have to do:
auto c = hash["x"];
hash.remove["x"];
delete c;


Yeah, you do.



 No I don't.

    delete * cast(Object*) &hash["x"];


Phew! That's much better! (!) o_O


 An alternative hack:

 delete *("x" in hash);


 It just gets better and better ;)


But you still have to remove a dead pointer from a collection:

delete *("x" in hash);
hash.remove("x");
Jul 15 2008
parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Wed, 16 Jul 2008 01:23:30 +0400, "Koroskin Denis"
<2korden+dmd gmail.com> wrote:


But you still have to remove a dead pointer from a collection:

delete *("x" in hash);
hash.remove("x");


If 'remove' was modified to return the removed value, more compact
syntax would be possible:

delete hash.remove("x");

Also, there would be no need to search for the value twice and
introduce a temporary when the removed value is needed for further
processing:

// do something with the value, for example, pass it to a function
foo(hash.remove("x"));

instead of:
auto v = hash["x"];
hash.remove("x");
foo(v);
Jul 15 2008
next sibling parent reply JAnderson <ask me.com> writes:
Max Samukha wrote:

 On Wed, 16 Jul 2008 01:23:30 +0400, "Koroskin Denis"
 <2korden+dmd gmail.com> wrote:
 

 But you still have to remove a dead pointer from a collection:

 delete *("x" in hash);
 hash.remove("x");


 
 If 'remove' was modified to return the removed value, more compact
 syntax would be possible:
 
 delete hash.remove("x");
 
 Also, there would be no need to search for the value twice and
 introduce a temporary when the removed value is needed for further
 processing:
 
 // do something with the value, for example, pass it to a function
 foo(hash.remove("x"));
 
 instead of:
 auto v = hash["x"];
 hash.remove("x");
 foo(v);


I think this is a good idea.

-Joel
Jul 15 2008
parent reply Regan Heath <regan netmail.co.nz> writes:
JAnderson wrote:

 Max Samukha wrote:

 On Wed, 16 Jul 2008 01:23:30 +0400, "Koroskin Denis"
 <2korden+dmd gmail.com> wrote:


 But you still have to remove a dead pointer from a collection:

 delete *("x" in hash);
 hash.remove("x");


 If 'remove' was modified to return the removed value, more compact
 syntax would be possible:

 delete hash.remove("x");

 Also, there would be no need to search for the value twice and
 introduce a temporary when the removed value is needed for further
 processing:

 // do something with the value, for example, pass it to a function
 foo(hash.remove("x"));

 instead of:
 auto v = hash["x"];
 hash.remove("x");
 foo(v);


 
 I think this is a good idea.


Seconded!

Regan Heath
Jul 16 2008
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Regan Heath <regan netmail.co.nz> wrote:


 JAnderson wrote:

 Max Samukha wrote:

 On Wed, 16 Jul 2008 01:23:30 +0400, "Koroskin Denis"
 <2korden+dmd gmail.com> wrote:


 But you still have to remove a dead pointer from a collection:

 delete *("x" in hash);
 hash.remove("x");


 If 'remove' was modified to return the removed value, more compact
 syntax would be possible:

 delete hash.remove("x");

 Also, there would be no need to search for the value twice and
 introduce a temporary when the removed value is needed for further
 processing:

 // do something with the value, for example, pass it to a function
 foo(hash.remove("x"));

 instead of:
 auto v = hash["x"];
 hash.remove("x");
 foo(v);


  I think this is a good idea.


 Seconded!

 Regan Heath


Thirded!

-- Simen
Jul 18 2008
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Max Samukha" <samukha voliacable.com.removethis> wrote in message 
news:9d2r74tuopl0dt05sgnkagss4gu4824k9m 4ax.com...
<snip>

 If 'remove' was modified to return the removed value, more compact
 syntax would be possible:

 delete hash.remove("x");


<snip>

And what would remove do if the key is already not in the AA?  Return 
ValueType.init?  Throw an exception?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 18 2008
parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon"
<smjg_1998 yahoo.com> wrote:


"Max Samukha" <samukha voliacable.com.removethis> wrote in message 
news:9d2r74tuopl0dt05sgnkagss4gu4824k9m 4ax.com...
<snip>

 If 'remove' was modified to return the removed value, more compact
 syntax would be possible:

 delete hash.remove("x");


<snip>

And what would remove do if the key is already not in the AA?  Return 
ValueType.init?  Throw an exception?

Stewart.


Three options:

1. Throw an assert exception if the program was built with a debug
switch
2. Always throw an exception
3. Make 'remove' return a pointer to the value
4. Continue silently 

I prefer the first option. Option 4 (current semantics)  is the least
acceptible, in my opinion.
Jul 19 2008
next sibling parent Max Samukha <samukha voliacable.com.removethis> writes:
On Sat, 19 Jul 2008 10:35:01 +0300, Max Samukha
<samukha voliacable.com.removethis> wrote:


On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon"
<smjg_1998 yahoo.com> wrote:


"Max Samukha" <samukha voliacable.com.removethis> wrote in message 
news:9d2r74tuopl0dt05sgnkagss4gu4824k9m 4ax.com...
<snip>

 If 'remove' was modified to return the removed value, more compact
 syntax would be possible:

 delete hash.remove("x");


<snip>

And what would remove do if the key is already not in the AA?  Return 
ValueType.init?  Throw an exception?

Stewart.


Three options:


I meant four options.
Jul 19 2008
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Max Samukha" <samukha voliacable.com.removethis> wrote in message 
news:d85384p9e1heua1f8f6vn2cesd9cosjlrc 4ax.com...

 On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon"
 <smjg_1998 yahoo.com> wrote:


"Max Samukha" <samukha voliacable.com.removethis> wrote in message
news:9d2r74tuopl0dt05sgnkagss4gu4824k9m 4ax.com...
<snip>

 If 'remove' was modified to return the removed value, more compact
 syntax would be possible:

 delete hash.remove("x");


<snip>

And what would remove do if the key is already not in the AA?  Return
ValueType.init?  Throw an exception?

Stewart.


 Three options:

 1. Throw an assert exception if the program was built with a debug
 switch


And do what if the program wasn't built with a "debug switch"?  Moreover, I 
personally think that debug switches should be saved for programmer-defined 
debug code.


 2. Always throw an exception
 3. Make 'remove' return a pointer to the value


And so if the key isn't present, return null.  Hmm....  I guess it would be 
the programmer's responsibility not to keep lots of these pointers alive and 
thereby prevent the AA nodes from being GC'd.  Hmm....


 4. Continue silently


But .remove has to return something.  So how is this possible?


 I prefer the first option. Option 4 (current semantics)  is the least
 acceptible, in my opinion.


Hang on ... is 4 meant to be an option under the premise that we want 
.remove to return the removed value, or the option of not implementing this 
feature at all?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 19 2008
next sibling parent reply "Koroskin Denis" <2korden+dmd gmail.com> writes:
On Sat, 19 Jul 2008 16:39:18 +0400, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:


 But .remove has to return something.  So how is this possible?


It doesn't return anything now.


 And what would remove do if the key is already not in the AA?  Return 
 ValueType.init?  Throw an exception?


I think returning null is ok. Otherwise a redundant check and a lookup  
will be necessary:

Object[char[]] map;
if (auto o = "test" in map) { // this is redundant, in my opinion
     delete map.remove("test");
}

and it is exactly the same as:

if (auto o = "test" in map) {
    map.remove("test");
    delete *o;
}
Jul 19 2008
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Koroskin Denis" <2korden+dmd gmail.com> wrote in message 
news:op.uejmwq0sn8fdl4 korden...

 On Sat, 19 Jul 2008 16:39:18 +0400, Stewart Gordon <smjg_1998 yahoo.com> 
 wrote:


 But .remove has to return something.  So how is this possible?


 It doesn't return anything now.


Are you missing my point, or guessing what Max meant?


 And what would remove do if the key is already not in the AA?  Return 
 ValueType.init?  Throw an exception?


 I think returning null is ok. Otherwise a redundant check and a lookup 
 will be necessary:


What if the value type has no null?


 Object[char[]] map;
 if (auto o = "test" in map) { // this is redundant, in my opinion
     delete map.remove("test");
 }


<snip>

Indeed, the "auto o =" bit is unnecessary here.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 19 2008
next sibling parent "Koroskin Denis" <2korden+dmd gmail.com> writes:
On Sat, 19 Jul 2008 19:25:15 +0400, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:


 "Koroskin Denis" <2korden+dmd gmail.com> wrote in message  
 news:op.uejmwq0sn8fdl4 korden...

 I think returning null is ok. Otherwise a redundant check and a lookup  
 will be necessary:


 What if the value type has no null?


Hmm.. I missed that. At first, I though than remove() behaviour should be  
consistent with opIn(), i.e. it should return a pointer to a value, but it  
is not possible.

Looks like the best guess is to return the stored value or T.init, if no  
value is found (i.e. null for ref types and some default value for value  
types).
Jul 19 2008
prev sibling parent JAnderson <ask me.com> writes:
Stewart Gordon wrote:

 "Koroskin Denis" <2korden+dmd gmail.com> wrote in message 
 news:op.uejmwq0sn8fdl4 korden...

 On Sat, 19 Jul 2008 16:39:18 +0400, Stewart Gordon 
 <smjg_1998 yahoo.com> wrote:


 But .remove has to return something.  So how is this possible?


 It doesn't return anything now.


 
 Are you missing my point, or guessing what Max meant?
 

 And what would remove do if the key is already not in the AA?  Return 
 ValueType.init?  Throw an exception?


 I think returning null is ok. Otherwise a redundant check and a lookup 
 will be necessary:


 
 What if the value type has no null?


I think the compiler should remove the extra delete so that writing 
generic code is easy.  Alternatively the compiler could report an error 
if delete doesn't work with the given type however I less like that 
option.  Also you could do this if remove returned something:

auto value = map.remove("test");
assert(value); //Value not found.
delete value;


 

 Object[char[]] map;
 if (auto o = "test" in map) { // this is redundant, in my opinion
     delete map.remove("test");
 }


 <snip>
 
 Indeed, the "auto o =" bit is unnecessary here.
 
 Stewart.
 


I
Jul 19 2008
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Stewart Gordon, el 19 de julio a las 13:39 me escribiste:

 
 "Max Samukha" <samukha voliacable.com.removethis> wrote in message
news:d85384p9e1heua1f8f6vn2cesd9cosjlrc 4ax.com...

On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon"
<smjg_1998 yahoo.com> wrote:


"Max Samukha" <samukha voliacable.com.removethis> wrote in message
news:9d2r74tuopl0dt05sgnkagss4gu4824k9m 4ax.com...
<snip>

If 'remove' was modified to return the removed value, more compact
syntax would be possible:

delete hash.remove("x");


<snip>

And what would remove do if the key is already not in the AA?  Return
ValueType.init?  Throw an exception?

Stewart.


Three options:

1. Throw an assert exception if the program was built with a debug
switch


 
 And do what if the program wasn't built with a "debug switch"?  Moreover, I
personally think that debug switches should be saved for programmer-defined
debug 
 code.


If the idea was to add an assert in the remove code, I guess he meant not
to raise an assert exception if compiled with the release flag.

In case the exception is not raised that could just be undefined behavior
(SIGSEGV or whatever).


2. Always throw an exception
3. Make 'remove' return a pointer to the value


 
 And so if the key isn't present, return null.  Hmm....  I guess it would be
the programmer's responsibility not to keep lots of these pointers alive and 
 thereby prevent the AA nodes from being GC'd.  Hmm....


I think this solution can be perfectly viable too.

But I still think delete hash["x"]; should just work =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Software is like sex: it's better when it's free.
	-- Linus Torvalds
Jul 19 2008
prev sibling parent Max Samukha <samukha voliacable.com.removethis> writes:
On Sat, 19 Jul 2008 13:39:18 +0100, "Stewart Gordon"
<smjg_1998 yahoo.com> wrote:


"Max Samukha" <samukha voliacable.com.removethis> wrote in message 
news:d85384p9e1heua1f8f6vn2cesd9cosjlrc 4ax.com...

 On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon"
 <smjg_1998 yahoo.com> wrote:


"Max Samukha" <samukha voliacable.com.removethis> wrote in message
news:9d2r74tuopl0dt05sgnkagss4gu4824k9m 4ax.com...
<snip>

 If 'remove' was modified to return the removed value, more compact
 syntax would be possible:

 delete hash.remove("x");


<snip>

And what would remove do if the key is already not in the AA?  Return
ValueType.init?  Throw an exception?

Stewart.


 Three options:

 1. Throw an assert exception if the program was built with a debug
 switch


And do what if the program wasn't built with a "debug switch"?


I agree, "debug switch" is BS. What I meant is non-release builds.
Trying to remove non-existent elements would result in undefined
behavior in release builds.


 Moreover, I 
personally think that debug switches should be saved for programmer-defined 
debug code.


It has been proposed that array bounds checking should be controlled
by a separate switch. 



 2. Always throw an exception
 3. Make 'remove' return a pointer to the value


And so if the key isn't present, return null.  Hmm....  I guess it would be 
the programmer's responsibility not to keep lots of these pointers alive and 
thereby prevent the AA nodes from being GC'd.  Hmm....


I don't think that is an issue. Why would there be "lots of these
pointers"? Most of the time the return values of 'remove' wouldn't be
used at all. Anyway, as pointers are nowadays in dishonor, this option
is not going to be accepted.


 4. Continue silently


But .remove has to return something.  So how is this possible?


 I prefer the first option. Option 4 (current semantics)  is the least
 acceptible, in my opinion.


Hang on ... is 4 meant to be an option under the premise that we want 
.remove to return the removed value, or the option of not implementing this 
feature at all?


You are right. This is not an option.
Jul 19 2008
prev sibling parent Moritz Warning <moritzwarning web.de> writes:
On Tue, 15 Jul 2008 13:40:07 -0300, Leandro Lucarella wrote:


 Max Samukha, el 15 de julio a las 17:54 me escribiste:

If not, do I have to do:
auto c = hash["x"];
hash.remove["x"];
delete c;


Yeah, you do.


 
 
 No I don't.
 
    delete * cast(Object*) &hash["x"];


Phew! That's much better! (!) o_O


 
 An alternative hack:
 
 delete *("x" in hash);


 
 It just gets better and better ;)


FWIW:
I'm used to include this little helper in my code:
V get(V, K)(V[K] aa, K key)
{
	auto ptr = (key in aa);
	return ptr ? (*ptr) : null;
}

It boils down to:
delete aa.get("x");


I would appreciate if an associative array would return the plain value,
from a practical point.
The problem comes if you want to store 0, or null as key by purpose.
But I think it is programmers task in these rare circumstances to
insert a wrapped pointer.

-my2cents
Jul 16 2008
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Leandro,


 I have this example code:
 
 class C { ... }
 
 C[string] hash;
 
 auto c = new C;
 hash["x"] = c;
 // other place
 delete hash["x"];
 hash.remove("x");
 And I got: Error: delete aa[key] deprecated, use aa.remove(key)
 
 I don't want to remove the element of the array, I want to destroy the
 object stored at key "x". Does hash.remove("x") remove the item from
 the
 hash *and* delete c? I found that a little odd. If not, do I have to
 do:
 auto c = hash["x"];
 hash.remove["x"];
 delete c;
 I find that a little odd too.
 
 And yes, I want to explicitly delete the object because I want to
 minimize the GC activity since my program is kinda RT :)
 


you might have luck with "delete (hash["x"]);" but I to lazy to check.
Feb 11 2008
parent Leandro Lucarella <llucax gmail.com> writes:
BCS, el 11 de febrero a las 20:23 me escribiste:

 Reply to Leandro,
 

I have this example code:
class C { ... }
C[string] hash;
auto c = new C;
hash["x"] = c;
// other place
delete hash["x"];
hash.remove("x");
And I got: Error: delete aa[key] deprecated, use aa.remove(key)
I don't want to remove the element of the array, I want to destroy the
object stored at key "x". Does hash.remove("x") remove the item from
the
hash *and* delete c? I found that a little odd. If not, do I have to
do:
auto c = hash["x"];
hash.remove["x"];
delete c;
I find that a little odd too.
And yes, I want to explicitly delete the object because I want to
minimize the GC activity since my program is kinda RT :)


 
 you might have luck with "delete (hash["x"]);" but I to lazy to check.


I tried and I failed :(

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Pity's very underrated. I like pity. It's good.
	-- George Constanza
Feb 11 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Leandro Lucarella wrote:

 I have this example code:
 
 class C { ... }
 
 C[string] hash;
 
 auto c = new C;
 hash["x"] = c;
 
 // other place
 delete hash["x"];
 hash.remove("x");
 
 And I got: Error: delete aa[key] deprecated, use aa.remove(key)
 
 I don't want to remove the element of the array, I want to destroy the
 object stored at key "x". Does hash.remove("x") remove the item from the
 hash *and* delete c? I found that a little odd. If not, do I have to do:
 auto c = hash["x"];
 hash.remove["x"];
 delete c;
 
 I find that a little odd too.
 
 And yes, I want to explicitly delete the object because I want to minimize
 the GC activity since my program is kinda RT :)
 


I see another, much bigger, problem with "delete hash[x]" meaning 
"hash.remove(x)" that goes against the D philosophy. One of the most 
important things about D is that it is generally unambiguously parsed 
without requiring semantic analysis. However, this is not so in the case 
of a DeleteExp, which can either actually refer to a delete expression 
or a function call. In other words, there are two semantic entities for 
things that are syntactically identical (in that case "delete 
[expression]"), and the effect of that depends not on the expression 
itself, but, in fact, only a piece of the expression.

Someone correct me if I'm misjudging this.
Feb 11 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:for70f$2vf0$1 digitalmars.com...


 I see another, much bigger, problem with "delete hash[x]" meaning 
 "hash.remove(x)" that goes against the D philosophy. One of the most 
 important things about D is that it is generally unambiguously parsed 
 without requiring semantic analysis. However, this is not so in the case 
 of a DeleteExp, which can either actually refer to a delete expression or 
 a function call. In other words, there are two semantic entities for 
 things that are syntactically identical (in that case "delete 
 [expression]"), and the effect of that depends not on the expression 
 itself, but, in fact, only a piece of the expression.

 Someone correct me if I'm misjudging this.


The "delete aa[x]" syntax to mean "remove the key x from aa" was deprecated 
in 0.126, that is, June of 2005, for the exact reasons you mention.  Hence 
the "deprecated" error message.  That the "deprecated" error message has not 
yet been removed after two and a half years seems to me more of an oversight 
than anything else.
Feb 11 2008
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:for9g5$2q7$1 digitalmars.com...
<snip>

 The "delete aa[x]" syntax to mean "remove the key x from aa" was 
 deprecated in 0.126, that is, June of 2005, for the exact reasons you 
 mention.  Hence the "deprecated" error message.  That the "deprecated" 
 error message has not yet been removed after two and a half years seems to 
 me more of an oversight than anything else.



Why should this means of removing an AA element have been de-deprecated?

If OTOH, you meant that it should have been redefined by now to delete the 
object, then maybe....

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 14 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:g5gq00$2jfu$1 digitalmars.com...

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:for9g5$2q7$1 digitalmars.com...
 <snip>

 The "delete aa[x]" syntax to mean "remove the key x from aa" was 
 deprecated in 0.126, that is, June of 2005, for the exact reasons you 
 mention.  Hence the "deprecated" error message.  That the "deprecated" 
 error message has not yet been removed after two and a half years seems 
 to me more of an oversight than anything else.



 Why should this means of removing an AA element have been de-deprecated?

 If OTOH, you meant that it should have been redefined by now to delete the 
 object, then maybe....


Yes, that's what I mean.  It doesn't make sense for a questionable design 
decision that was removed a year and a half before the language went 1.0 to 
prevent you from doing something completely reasonable today.
Jul 14 2008
prev sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
Simen Kjaeraas wrote:

 JAnderson wrote:

 Max Samukha wrote:

 On Wed, 16 Jul 2008 01:23:30 +0400,






 "Koroskin Denis"

 <2korden+dmd gmail.com> wrote:


 But you still have to remove a dead








 pointer from a collection:

 delete *("x" in hash);
 hash.remove("x");


 If 'remove' was modified to return the






 removed value, more compact

 syntax would be possible:

 delete hash.remove("x");

 Also, there would be no need to search for the






 value twice and

 introduce a temporary when the removed value






 is needed for further

 processing:

 // do something with the value, for example,






 pass it to a function

 foo(hash.remove("x"));

 instead of:
 auto v = hash["x"];
 hash.remove("x");
 foo(v);


  I think this is a good idea.


 Seconded!

 Regan Heath


 
 Thirded!


 I'm always interested in using more compact and more general versions of
functions, rather than having to take more steps, so Fourthed!
Jul 19 2008