General:
Don't use using directives at the top leel of header files (i.e. outside of a scope). This introduces everything in std:: into the global namespace for everything that includes that header.

Using this-> inside of a class/struct is redundant

Try to seperate the definitions and implementations of your classes. The way you have it now, verything is implicitly declared inline. The point struct's implementation can be moved to a .cpp file. The tree classes can be moved outside of the class (but as it's a template it should be kept in the header).

Instead of:

if(blah1 && blah2){return true;}else{return false;}

You can just write:

return blah1 && blah2;

You're using new style library headers everywhere, except for <time.h> (replaced by <ctime>


It would be better to use an initializer list in your constructors, rather than assigning each of the variables. Although this makes no speed difference in the case of built-ins, it is good practice and will be quicker for user defined types.

For struct point it would be better to have default constructor set x and y to 0.0f.



Don't hesitate to ask for clarifications/explantions.

It would just be a compiler optimisation. It would be able to recognise whether you are making good use of i++. For example:

int a = t++;

Here it is important that t++ is implemented because it is critical that the value a is a certain value. Where as when increasing an iterator in a for loop, like this:

for( unsigned int t;
t < 10;
t++ )
{
}

It isnt necessary to post increment, so the compile optimises this out.

ace

Quote:Original post by mike74
Ready4dis, how can MSVC++ generate identical code for ++i and i++?

mike
http://www.coolgroups.com/kdtree

If I'm not wrong, VC++ will know that the result of using ++i and i++ in a certain circumstance will be the same so it will optimize the code to use ++i.

Quote:Original post by mike74
Ready4dis, how can MSVC++ generate identical code for ++i and i++?

mike
http://www.coolgroups.com/kdtree

Because it's smart :). Seriously though, if you have a single line like so:

i++;
++b;

Each will be tranlsated into a single inc bp[x] assembly call. In borland turbo c/c++ the i++ was converted into:

mov ax, bp[x]
add ax, 1
mov bp[x], ax

while the ++b was converted as so:
inc bp[x]

As you can see, this was a big difference! But, nowadays compilers are smart enough to simply make them both into the same call, they just have to remember which order to put the increment depending on which side the ++ is on ;).

Quote:Original post by Ready4Dis
As you can see, this was a big difference! But, nowadays compilers are smart enough to simply make them both into the same call, they just have to remember which order to put the increment depending on which side the ++ is on ;).

One thing to keep in mind is that on build-in types they'll probably result in the same assembly code, but for a custom type it wont be able to change post-increment to pre-increment.


This is legal C++ code, even though it is not a good idea to write. Note that even if post-increment and pre-increment result in the same the C++ compiler wont change a post-increment to pre-increment since it has no way of checking that it always result in the same code. So with custom types you should always use pre-increment when you can.

Quote:Original post by CTar
Note that even if post-increment and pre-increment result in the same the C++ compiler wont change a post-increment to pre-increment since it has no way of checking that it always result in the same code. So with custom types you should always use pre-increment when you can.

However, they may both compile into the same assembly if you've got a smart compiler (since it will be able to tell that a given member isn't reused until after the temporary is gone anyways).

But you'll be laughed at by your peers for using postincrement when you "should" be using preincrement. And you may not be using a smart compiler. And even if you are right now, someday you might have to work with one that isn't. And god kills a kitten every time you use one. Say no to needless postponing of incrementation! Save the kittens!