The idea is this. I have an index array, and a value array. I want to get the index by searching through the index array, and then set the corresponding position in the value array to that something. There are two ways I can do this:
orCode:var_pos = get_index(var_names,search); var_vals[var_pos] = new_Value;
Which one's the prefered method?Code:var_vals[get_index(var_names,search)] = new_Value;
As far as efficiency goes, there's probably very little difference, and I would guess you don't even need to be optimizing at this point (that should be toward the end of the development process, generally). I would say it's more of a style or even a readability issue--the second method might end up being less readable, for example, otherwise it's probably not a big deal either way.
"Think not but that I know these things; or think
I know them not: not therefore am I short
Of knowing what I ought."
-John Milton, Paradise Regained (1671)
"Work hard and it might happen."
-XSquared
Strictly from the "My $0.02" department, I'd lose the separate arrays, and use a std::map<indexType, valueType>. That'll give you a LOT more efficiency.
Doesn't make much of a difference. Programmers discretion as to what he/she feels is more readable. Efficiency will be determined by your search algorithm [bubble sort; divide and conquer; etc.] + structure used [ hash table; tree; array; etc.].
Whether or not to bypass the variable var_pos is trivial to a computer. Its like asking Albert Einstein whats 1+1.
Good luck!
Well, now I have to mention that Einstein sucked at math and is well known for failing it. I guess that's beyond the point with 1+1, though.
Sent from my iPadŽ
Second is somewhat harder to read and only saves you a single assignment operation, which should take no more than a few CPU cycles.
Unless this happens in a very tight loop in which that assignment makes up a major portion of the duration for each iteration it's not going to make any noticable difference in performance.
>var_vals[get_index(var_names,search)] = new_Value;
I like this one better, but it's a programmer preference issue. Use the one you understand.
Efficiency wise, they are identical. The compiler will do the optimization.
Ah, okay. I was really just asking because that's in a source file I'd rather NOT have split (Because it has genuinely related functions. They're just a LOT of them). It's less readable, but it's also relatively easy to unfold for debugging purposesm and I'd rather just have it condensed so that I don't have a single, 2000 line source file.
As for get_index, if I take the bounds checking out, the entire code is:
With or without, it can get through ~70000 entries in 5 seconds. Which is roughly the same speed of just having -- erm, correction. Couting x each time makes it take five seconds. Not couting x until the operation is done takes about 1 second. It doesn't take two seconds until I increase the total number of entires to 699999. It needs to be 6999999* before major slowdown really occures. I don't know why anyone would sanely have seven million entries in a vector, though. So, er, no, it's not going to be really slow (or slow at all, really) unless the vector somehow gets really, really full of stuff.Code:while(x!= search) {x++;} return x;.
also, I can't find a way to instantiate maps to anything. Could be a problem.
* It might take less to get slower. Prolly does. I was just using things based out of 70 entries for some reason. 1 mill is still managable.
and you could condense that to x = x + search -1; which indeed is a lot faster than the loop you use now
