<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Hey, and they also talk about exceptions (cool)...<br>
<br>
<a href="http://www.boost.org/development/requirements.html#Exception-specification" target="_blank">http://www.boost.org/development/requirements.html#Exception-specification</a><br>
<br>
...and made me realize I was completely wrong about the good and bad<br>
of exception-specification when it comes to performance.<br>
<br>
So I go on to the second point. I also completely agree to remove all<br>
the exception-specifications from the library :)<br>
</blockquote><div><br>i think for us, the key thing is to ensure that if *any* call will throw an exception, then our library is not left in an inconsistent state. one place is in the create-new-node, which should be ok. <br>
<br>we should also ensure that optimise() is not able to leave the tree in an inconsistent state (or if it is, it should be obvious to user that the tree is now hosed).<br><br>optimise() could throw if the user's datatype's accessor threw an exception... then one of the comparisons while building the tree may throw us out half way through an optimise. if we design it right, even if an exception is thrown, the tree would still be in a consistent state (although not balanced).<br>
<br><br>it would be nice to get lots of tests written up before making more changes. i am currently using cmake for another project, i think i'll have a go at adding cmake support for kdtree, and i'll see if i can add in ctest too (i haven't tried it out yet). <br>
</div></div><br>can anyone help, or have any tests to contribute?<br><br>