|
Thanks Dave,
fisrt COM component loaded fine in C#.net exe framework. My problem is to load another COM component into same C#.net exe framework, and this second COM component will be called from first COM component.
Hope you understand my problem.
Any idea?
|
|
|
|
|
Exactly the same as before. You add a reference to it.
You're problem is that your COM componets should not be calling into each other. That would be a hard-code tie where you couldn't use one component without the other. That's just a bad design.
|
|
|
|
|
I need to use a generic collection of keyvalue pair. I need thr folloeing:
1) should be generic because my values are a customized class
2) iterating should keep the order in which I added Items
3) I should be able to find the index of the element
4) I need access via Key
A dictionary is ok for 1,2,4 but not for 3
SortedList and SortedDictionary are ok for 1, 3, 4 but not for 2.
If I create a
List<keyvaluepair> it is ok for 1,2,3 but not for 4 ( I mean not directly)
SortedList<string, double> d = new SortedList<string, double>();
d.Add("z", 1);
d.Add("a", 2);
d.Add("c", 3);
d.Add("b", 4);
foreach (KeyValuePair<string,double> k in d)
{
Console.WriteLine(k.Key + " " + k.Value);
}
KeyValuePair<string, double> i_item = d.ElementAt(2);
Any suggestion?
Thanks for your time
|
|
|
|
|
If I change your code to use a Dictionary it works for me... 
If you directly want to access a value you can also do this:
var value = d["c"];
whil returns the value 3 in this case.
What error do you get when using the Dictionary class?
|
|
|
|
|
KeyValuePair<string, double> i_item = d.ElementAt(2);
may be I was not clear I can't get item from index value. For example I need the second element How can I ask the Dictionary the second element?
The dictionary is an unsorted collection
|
|
|
|
|
An unsorted collection is what you're looking for if you want to prevent the order in which the items were added.
And I don't know what error you're getting when calling
KeyValuePair<string, double> i_item = d.ElementAt(2);
as this works just fine for me with a dictionary
|
|
|
|
|
thanks you are right sorry. Basically I need to find the index from the key and viceversa.
How can I find the index related to the key "3", from the dictionary. It should be 2
|
|
|
|
|
Why do you need to be able to get the index of a KeyValuePair if you already got the key?
Maybe take a look at the hint from Keith.
Note: As I just saw after a bit of researching, the Dictionary uses some hashing of the keys to create some order which means it does not necessarily return the items in the order in which they were added
Source: http://msdn.microsoft.com/en-us/library/xfhwa508.aspx[^]
Quote: For purposes of enumeration, each item in the dictionary is treated as a KeyValuePair<tkey, tvalue=""> structure representing a value and its key. The order in which the items are returned is undefined.
|
|
|
|
|
|
But its not Generic 
Well one could create a Generic wrapper for it 
|
|
|
|
|
 I'll get me coat.
|
|
|
|
|
|
I really like (and upvoted) your question; it was fun to see what I could implement quickly, and I'm going to post the code here before I read the other responses on the thread, since I feel I can learn something from knowing whether or not the code I post actually meets your requirements, and, possibly, learning from other people's responses.
I wonder if I have not just duplicated the functionality of a Dictionary<K, V> ? Also, I suspect Linq queries could be used in some way, efficiently here, rather than, as I did, creating two Lists in the class (memory cost ?).
Disclaimer: I've tested only with KeyValuePair<string, double> since that's what you used. Testing with instances of a custom class as K, or V: that's on my list 
Here's the revised class:
public class IndexedKVPList<K, V> : List<KeyValuePair<K, V>>
{
private readonly List<K> keyList = new List<K>();
private readonly List<V> valueList = new List<V>();
new public void Add(KeyValuePair<K, V> newKVP)
{
keyList.Add(newKVP.Key);
valueList.Add(newKVP.Value);
base.Add(newKVP);
}
new public void Remove(KeyValuePair<K, V> killKVP)
{
if(! this.Contains(killKVP)) throw new Exception("error in Remove in IndexedKVPPair");
keyList.Remove(killKVP.Key);
valueList.Remove(killKVP.Value);
base.Remove(killKVP);
}
public KeyValuePair<K, V> GetKVPByValue(V theValue)
{
return this[valueList.IndexOf(theValue)];
}
public K GetKeyByValue(V theValue)
{
return this[valueList.IndexOf(theValue)].Key;
}
public int GetIndexByKVP(KeyValuePair<K, V> theKVPPair)
{
return this.IndexOf(theKVPPair);
}
public int GetIndexByValue(V theValue)
{
return (valueList.IndexOf(theValue));
}
public KeyValuePair<K, V> GetKVPByKey(K theKey)
{
return this[keyList.IndexOf(theKey)];
}
public V GetValueByKey(K theKey)
{
return this[keyList.IndexOf(theKey)].Value;
}
public int GetIndexByKey(K theKey)
{
return (keyList.IndexOf(theKey));
}
}Here's the revised test:
private void TestIKVP()
{
var iKVList = new IndexedKVPList<string, double>();
for (int i = 0; i < 10; i++)
{
iKVList.Add(new KeyValuePair<string, double>("Key: " + i, i));
}
var kvp1 = iKVList.GetKVPByKey("Key: 8");
var kvp2 = iKVList.GetKVPByValue(6);
Console.WriteLine(kvp1 + " " + kvp2);
// test Remove function
iKVList.Remove(iKVList[4]);
foreach (var theKVP in iKVList)
{
Console.WriteLine(theKVP.Key + " Value:" + theKVP.Value.GetType());
}
Console.WriteLine(iKVList.GetIndexByKVP(kvp2));
Console.WriteLine(iKVList.GetIndexByKey("Key: 9"));
Console.WriteLine(iKVList.GetIndexByValue(3));
}
~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
modified 22-Jul-13 7:06am.
|
|
|
|
|
Thanks a lot, I did a workaround using a syncronized List..
Then I found the following solution
Dictionary<string, double> d = new Dictionary<string, double>();
d.Add("z", 1);
d.Add("a", 2);
d.Add("c", 3);
d.Add("b", 4);
foreach (KeyValuePair<string, double> k in d)
{
Console.WriteLine(k.Key + " " + k.Value);
}
KeyValuePair<string, double> i_item = d.ElementAt(2);
int myIndex = Array.IndexOf(d.Keys.ToArray<string>(), "a");
|
|
|
|
|
It may be a little faster to get the index using:
private int theIndex;
theIndex = dictionaryStringInt.Keys.ToList<string>().IndexOf("KeyString");However, note that in using both 'ElementAt, and 'ToArray ... or 'ToList ... you are using Linq functions that are, internally, going to do an enumeration.
If the entries in the dictionary are not being removed, moved around, etc., then you could create a List<keytype> once from the Keys collection, however, I doubt that's the case you want here.
I will add some extra functions that return an index to my first answer above, with the hope some of our members here who have more formal computer science training (than I do) will comment on the relative cost / lookup-times, of the example I've given.
good luck, Bill
~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
|
|
|
|
|
|
That doesn't work. Or rather, it may work - accidentally.
But see http://msdn.microsoft.com/en-us/library/yt2fy5zk.aspx[^]:
The order of the keys in the Dictionary<tkey, tvalue="">.KeyCollection is unspecified It is not (necessarily) in the order that you added the items.
It often works. But it isn't guaranteed to.
edit: it turns out that, in the current implementation (which may change!) it will indeed work as long as you never delete anything. That's just an implementation detail, it would be foolish to rely on it. It could change in any update.
Also, of course, you're doing a linear search through a list. That is not ideal.
modified 22-Jul-13 7:17am.
|
|
|
|
|
|
harold aptroot wrote: you're doing a linear search through a list.
Hi Harold,
I am curious: do you know for a fact that using Linq 'ElementAt, or using the (not Linq) 'IndexOf on an Array, or List, internally performs a linear search ?
In the case of 'ElementAt on a Dictionary, I am assuming there's some cost of some kind of internal conversion since Dictionary doesn't inherently support "sequential" indexing by integer.
thanks, Bill
~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
|
|
|
|
|
The IndexOf of a List uses the IndexOf of Array, and that ones's a linear search (I checked it just be sure, but really there's no other choice anyway).
What ElementAt does depends on the thing you're applying it to, it will use IList<T>'s indexer if that interface is implemented (Dictionary does not implement it, so ElementAt would scan through the enumerator).
So in conclusion, that code was pretty inefficient.
|
|
|
|
|
Thanks for your reply, Harold, that is very interesting to know.
It makes me wonder: if you were dealing with a really big generic List, or a huge Dictionary, if you could implement a much more efficient solution than the current operators, and, if so, why MS has not done that.
I would have thought that Linq operators, particularly, were highly optimized with the latest algorithms: reminds me I should never assume anything about software tools.
yours, Bill
~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
|
|
|
|
|
There aren't many options there.. (there are some, discussed below) I mean, say you have an array and you want to know the index of some value and you have an algorithm that does not potentially look at all elements, how can it know the thing it's trying to find isn't in the part that it hasn't looked at?
Clearly it can't, so in the worst case you're always looking at all elements anyway. Leaving the "standard complexity model" behind for a moment, you can do a lot better than O(n): divide the array in m parts, search each part in parallel, then do a Min-Reduction phase on all the results. That's O(log m) in PRAM (where the assumption m = n is allowed), but PRAM is not a realistic model for present-day CPU computing.
In the CPU world that same algorithm is still O(n) (because it's really O(n/m + log m) and m is a constant now), which doesn't necessarily have to be a bad thing, not all O(n)'s are created equally after all. But this isn't a particularly awesome algorithm:
1) it spends a lot of time just fetching things from memory, and doesn't do a whole lot with them. (of course the normal algorithm does that too, that it will be a worse bottleneck when multiple threads are doing it)
2) even if you abort the threads working on the higher ranges (or if you want any index, not just the lowest: all other threads) when you find the item, you will have wasted work, so even when it's faster it takes more resources.
3) it has a lot of overhead from all the thread business.
In a quick test, this algorithms start pulling ahead on average for an array of a million integers, and then only when the item is not actually in the array (the worst case for the simple linear search).
It almost reaches a speedup of 4x on my machine (which isn't that bad considering it's a quad core + hyperthreading) but each time an item actually is in the array, the multithreaded algorithm loses or almost loses, no matter how big I make the array (tested up to an array of 228 ints).
So it's not really suitable as a default algorithm for libraries: it's terrible in the common case that the item is actually in the array.
modified 23-Jul-13 11:42am.
|
|
|
|
|
Once again, thanks, for that very illuminating reply !
I'd say if you tested up to 228, that would cover most non-astronomical level scenarios !
Of more interest, and something I actually intend to explore, is what happens when have compound structures with KeyValue pairs, and both Key and Value Types are complex classes, not just ValueTypes.
... edit ... on second thought: if K and V are complex classes, I think it's just a case of comparing pointers in any IndexOf, or ElementAt, type operation, so: no difference than if K and V were .NET ReferenceTypes (?) ...
Please come to northern Thailand (in late-October~early-January is best), and let me take you, and your family, elephant riding in the jungle 
yours, Bill
~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
modified 24-Jul-13 0:42am.
|
|
|
|
|
BillWoodruff wrote: Of more interest, and something I actually intend to explore, is what happens when have compound structures with KeyValue pairs, and both Key and Value Types are complex classes, not just ValueTypes.
It depends, it calls Equals(T other) when IEquatable<T> is implemented (in that type or a base class), regular Equals otherwise which might default to Object.Equals, in that case it uses Reference Equality for reference types and Bitwise Equality for value types (that's how the official documentation puts it), which could be restated as "always bitwise equality, so if you give it a reference it's bitwise equality on the reference itself" (that might help a person who thinks in pointers, it would probably confuse someone who thinks in objects).
The code where it tests to see which case it's in and then makes an EqualityComparer uses a lot of reflection, by the way.
Thanks for inviting me by the way, but I've found that jungles aren't my thing, so I don't think I'll do anything with that..
|
|
|
|
|
Often when you have a problem that looks like "I need a data structure that has the properties of A and of B" where A and B are some data structure, there's an obvious way to just combine A and B and wrap them a little thing that keeps them synchronized.
Such as here, it looks like a List and like a Dictionary.. what can you do? Well you can make a List<Tvalue> and a Dictionary<Tkey, int> and let the dictionary map keys to indexes in the list.
If you also want removal, you can use a linked list instead of a list, and let the dictionary map keys to nodes in the linked list.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
