<div dir="ltr"><br><br><div class="gmail_quote">2008/7/29 Michael Zillich <span dir="ltr"><<a href="mailto:zillich@acin.tuwien.ac.at">zillich@acin.tuwien.ac.at</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br>
<br>
It seems to me that one could change in the function _M_find_within_range<br>
*__out++ = _S_value(__N);<br>
to<br>
__out = _S_value(__N);<br>
<br>
as operator++() has not effect on a back_insert_iterator and operator*()<br>
simply returns *this.<br>
At least this is the case for the STL back_insert_iterator.<br>
Don't know if that would result in any speedup though. Just thought it "looks"<br>
faster :)<br>
</blockquote><div><br>it must always work with something like a plain array... eg, in fudged code...<br><br><br>Node nodes[1000];<br><br>Node* last_found = find_within_range( blah blah, &nodes[0] );<br><br>this approach would be desirable for cases where the tree has (in this case) 1000 leaves (or at least, couldn't possibly find more than 1000 nodes within the range - so no danger of overflow but that is up to the programmer to decide), and would be faster than pushing the nodes into a blank vector.<br>
<br>this would not work without *__out++<br><br><br>of course, a better design would be<br><br>vector<Node> nodes(1000);<br>nodes.reserve(1000); // or remove 1000 above and use reserve<br>find_within_range( blah blah, back_inserter(nodes) );<br>
<br>but sometimes the programmer has no choice in where the data is written to.<br><br><br></div></div>note also that if there is no effect, then the compiler will optimise away (remove) the extra work.<br><br><br>if you are itching for something to do to kdtree, i have some changes pending since last year that need reviewing...<br>
<br><br>see ya<br>Paul<br><br></div>