Solved How to return myclass reference?
-
This post is deleted! -
@Wieland I think this is a search function so it must return a "reference" to the object with
contact.UID==UID
or null if it can't find the item.P.S.
If you find yourself using this function a lot, consider changingallContacts
into aQHash<int,Contact>
and use theUID
as key -
@VRonin said in How to return myclass reference?:
or null if it can't find the item.
No. Contact will be in my QList.
@VRonin said in How to return myclass reference?:
If you find yourself using this function a lot, consider changing allContacts into a QHash<int,Contact> and use the UID as key
I do not know about QHash <T, T>, It's faster than a binary search?
If my allContacts.size() == 10 000, 15 Checks i need maximum. -
-
@jsulm @VRonin Thank guys.
Also there are good example http://developers-club.com/posts/170017/@VRonin said in How to return myclass reference?:
If you find yourself using this function a lot, consider changing allContacts into a QHash<int,Contact> and use the UID as key
I think you are right. Thank.
how much seconds will be lost if I search an element in QList one milion times(if i use binary search) and how much will be reserved in QHash? -
@Taz742 said in How to return myclass reference?:
how much seconds will be lost if I search an element in QList one milion times and how much will be reserved in QHash?
Searching in a list is O(n). Statistically you will need n/2 comparisons to find what you're looking for. Hash is O(1) - so much faster. For lookup you should use QHash or QMap not QList.
You you want to see the difference then just write a small app and measure the time...
-
@Taz742 said in How to return myclass reference?:
how much seconds will be lost if I search an element in QList one milion times(if i use binary search) and how much will be reserved in QHash?
Algorithmic complexity isn't measured in seconds, but with the so called "big O notation" (asymptotic complexity). Provided you can do a binary search, which implies the list is kept at all times ordered, then the complexity of the search is
O(logN)
. For a hash it'sO(1)
with worst-caseO(N)
. Now, there are nuances, but most of the time a hash would fare better than a red-black tree (QMap
), which would be better than keeping an ordered list and doing a binary search on it. Of course the best is to have everything in a vector and just get the elements by index, but that's not always possible. -
- Simple code is better than complex code.
- Only sacrifice simplicity if you have proof that your code is too slow.
- The only way to prove that your code is too slow is by measuring execution time against real world data on the target machine.
- Don't just assume that algorithmic complexity dominates execution time; you have to measure it.
Just my 2 cents.
-
- Avoid premature pessimization - by default use data structures and algorithms which are right for the job, without sacrificing simplicity.
Otherwise you may get a death of thousand cuts for performance of your application, when it's not enough to fix a few bottlenecks because all code if uniformly slow.
-
Pleasant discussion.