> trying to design an effiecient interface, where I can pass an
> IDictionary<int,string^> to a method. int is some id and string^ is
[quoted text clipped - 35 lines]
> Thanks in advance!
> vcq
any suggestions?
> trying to design an effiecient interface, where I can pass an
> IDictionary<int,string^> to a method. int is some id and string^ is
[quoted text clipped - 18 lines]
> as on the second pass of the loop, the code above will throw since the
> colleciton is modified.
You could file a bug against this, as it's improper behavior. Iterators
should only be invalidated when the morphology (shape) of the collection
changes, and updating a value doesn't do that. The version number
increment, which is causing that exception, should only be done when an item
is added or removed.
BTW KeyValuePair is a value type, so you shouldn't use ^ with it (doing so
isn't outright wrong, but it does slow you down because of boxing and
unboxing).
> Thus, it looks like I need 2 passes, where I'd make a list of ids in
> the first pass and on the second pass, I'd do something
[quoted text clipped - 10 lines]
> Thanks in advance!
> vcq
vcquestions - 14 Sep 2007 21:15 GMT
> > trying to design an effiecient interface, where I can pass an
> > IDictionary<int,string^> to a method. int is some id and string^ is
[quoted text clipped - 47 lines]
>
> - Show quoted text -
Thanks Ben! On the iteration ( 1-st question ) do you see a clean
workaround ( a different method of iterating through collection &
updating values )?
Also, thanks for pointing out the KeyValuePair issue!
Ben Voigt [C++ MVP] - 14 Sep 2007 21:21 GMT
>> > Thanks in advance!
>> > vcq- Hide quoted text -
[quoted text clipped - 7 lines]
> updating values )?
> Also, thanks for pointing out the KeyValuePair issue!
As I said, I think it is a bug in the BCL Dictionary<TKey,TValue>::Insert
helper function. There are two code paths, one for when the key already
exists, and one where it does not. The first of those should not increment
the private version variable which effectively kills all existing
enumerators.
If you submit a bug on Connect, post the link here. I will validate it and
vote for it.
vcquestions - 14 Sep 2007 22:36 GMT
> >> > Thanks in advance!
> >> > vcq- Hide quoted text -
[quoted text clipped - 16 lines]
> If you submit a bug on Connect, post the link here. I will validate it and
> vote for it.
I got the bug part - I just refused to believe that MSFT gives us such
pleasant surprises -:) ( but after Debug::Assert( 0 ) showing up in
release mode - oh well... )
here's the link:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID
=298166
Ben Voigt [C++ MVP] - 28 Sep 2007 19:23 GMT
>> >> > Thanks in advance!
>> >> > vcq- Hide quoted text -
[quoted text clipped - 25 lines]
> here's the link:
> https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID
=298166
They appear to be hiding behind "It's not wrong, because we choose to define
the correct behavior as the way it works". I've added a bunch of counter
examples -- in C++/CLI -- to the bug report in the hope that somebody
realizes that there's value in having .NET collections act the same way
every other collection in the world does.
vcquestions - 29 Sep 2007 17:23 GMT
Thanks Ben! Frankly, I was not even familiar with Connect before this
issue come up. I always open bugs with MSFT by calling Dev. support
and shelling out $250 ( then they refund it eventually ). Obviously,
this enthusiasm could go only so far...:) We'll see if this could get
escalated.
> >> >> > Thanks in advance!
> >> >> > vcq- Hide quoted text -
[quoted text clipped - 33 lines]
>
> - Show quoted text -