associative arrays: iteration is finally here
KennyTM~
kennytm at gmail.com
Thu Oct 29 09:57:33 PDT 2009
On Oct 29, 09 23:59, Bill Baxter wrote:
> On Thu, Oct 29, 2009 at 8:39 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail at 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
More information about the Digitalmars-d
mailing list