On Oct 29, 09 23:59, Bill Baxter wrote:
On Thu, Oct 29, 2009 at 8:39 AM, Andrei Alexandrescu
<seewebsiteforem...@erdani.org>  wrote:
Leandro Lucarella wrote:

Andrei Alexandrescu, el 28 de octubre a las 20:29 me escribiste:

Your test looks something up and then removes it.


Andrei

Well, my extended test case looks something up, manipulates the
found value, and then possibly removes it.

Ok, I understand your points, thanks for explaining.

What about and overload of remove() like this:
bool remove(in T key, out U value);

If the element was present, it's returned in "value", so you can
manipulate it. I thought about just returning a pointer:
U* remove(in T key);

But I guess that pointer would point to the element stored in the the AA
private data, but that element was just removed, so bad things would
happen, that's why the only option is to copy the data, right?

I think this all is overdoing it. First, I disagree that remove should ever
throw an exception. It's not a code that the user is supposed to check (with
dire consequences if she doesn't), it's just additional information just in
case you need it.

I think bool remove(key) is better than all other designs suggested so far.

I agree with the folks who say it's error-prone.  I can just see
myself now removing a key I know is in the dictionary and being
baffled when my program fails somewhere later on because I typed
aa.remove("theKey") when it should have been aa.remove("thekey").  I
knew it was there so I didn't want to clutter up my code with a check
for it.

Um what? aa["theKey"] = 1 doesn't fail, why should aa.remove("theKey") be special?

(Meanwhile, C++'s map::erase returns the number of elements removed, C#'s (CLR in general) Dictionary.Remove returns a bool, Javascript's delete x[y] returns a bool, Perl, Ruby, Objective-C, Java, etc. all won't throw exceptions (Python being the only exceptional case). Do all languages clutter up with checks?)


So the advice would be to always check to make sure the key you remove
got removed to be on the safe side.   If that's the case I'd rather
just have the darn thing throw an exception so I don't have to bother
to write things like
      if (!aa.remove("theKey")) assert(false);
everywhere just to be on the safe side.


void discard(K,V)(ref V[K] aa, in K key) {
  if (!aa.remove(key)) assert(false);
}

...

aa.discard("theKey");



--bb

Reply via email to