A hard code choice...

Hi...

I've done a command which is used to test a point in a specific shape (rectangle). After that, I'm trying making many similar functions that can do this. There are many different choices and many various styles and I can't figure out which is best. Should be function or anything else???? -?!?!?!?!?!!?!?!?!?!??!?!??!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
/// Testing a point with a rectangle
bool TestPtCollision(float x, float y, float x1, float x2, float y1, float y2){
if(!(x >= x1) || !(x < x2) || !(y >= y1) || !(y < y2))return true;return false;}
////////////////////////////////////////////////////////////////////////////////
bool TestPtCollision(float x, float y, float x1, float x2, float y1, float y2){
if(!(x < x1) && !(x >= x2) && !(y < y1) && !(y >= y2))return true;return false;}
////////////////////////////////////////////////////////////////////////////////
bool TestPtCollision(float x, float y, float x1, float x2, float y1, float y2){
if(x < x1 || x >= x2 || y < y1 || y >= y2)return true;return false;}
////////////////////////////////////////////////////////////////////////////////
bool TestPtCollision(float x, float y, float x1, float x2, float y1, float y2){
if(x >= x1 && x < x2 && y >= y1 && y < y2)return true;return false;}
////////////////////////////////////////////////////////////////////////////////
inline bool TestPtCollision(float x, float y, float x1, float x2, float y1, float y2){
return (!(x >= x1) || !(x < x2) || !(y >= y1) || !(y <= y2));}
////////////////////////////////////////////////////////////////////////////////
inline bool TestPtCollision(float x, float y, float x1, float x2, float y1, float y2){
return(!(x < x1) && !(x >= x2) && !(y < y1) && !(y >= y2));}
////////////////////////////////////////////////////////////////////////////////
inline bool TestPtCollision(float x, float y, float x1, float x2, float y1, float y2){
return (x < x1 || x >= x2 || y < y1 || y >= y2);}
////////////////////////////////////////////////////////////////////////////////
inline bool TestPtCollision(float x, float y, float x1, float x2, float y1, float y2){
return(x >= x1 && x < x2 && y >= y1 && y < y2);}
////////////////////////////////////////////////////////////////////////////////
inline bool TestPtCollision(float x, float y, float x1, float x2, float y1, float y2){
return (x1 < x < x2 && y1 < y < y2);}
//////////////////////////////////////////////////////////////////////////////// 

The code is becoming simpler, shorter... and (maybe) faster ???
Which is fastest ??? And any better solution... ???...please...

?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?
?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!?!!?!?!?!?!??!?!
Last edited on
Should be function or anything else????

It should definitely be a function.

Your line 26 version will not return the right value, you'll have to test x with x1 and x with x2 in two seperate conditions that you want to 'and' (&&) together, like you do further up. I also note that in several of your versions you do not take equalities properly into account, such as x=x1, y=y1. For returning "true", you'd want to have "less or equal" in both parts of your x and y checks ( (x1<=x) (x<=x2) (y1<=y) (y<=y2) ), so that you account for x=x1, x=x2, y=y1 and y=y2 (or, if you do not want the border included as a collision, then add a condition in your function to take care for such an eventuality). For example, in the line 23 version, x=x2 would not return as a collision, but x=x1 would, same for y=y2 and y=y1 (so half the border is part of the collision surface and the rest isn't). The line 26 version doesn't account for equalities at all, etc.

It is good to try and use parentheses () to make sure you divide your conditions properly, it's also easier to read. For instance, if you wrote
((x>=x1)&&(x<=x2)&&(y>=y1)&&(y<=y2)) this would be equally fast and also much less likely to cause a problem.

Note: keep in mind that your C++ code gets compiled, which means that slightly different variations of writing the same thing/command do not necessarilly have a difference in the compiled executable -- the variation sometimes simply helps the programmer in using the form most comfortable to him/her while the result does not differ after compilation.

You should definitely have these parameters you already have (point's x and y, and rectangle's xs and ys). Perhaps if you're interested in implementing rotated rectangles later on, you may want to pass the rectangle itself in your function as a parameter like so:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
class rectangle
{
public:
	rectangle::rectangle();
	rectangle::~rectangle();

	float x;
	float y;
        float width;
        float height;
	float rotAngle; //assume counterclockwise rotation
}

class point
{
public:
	point::point();
	point::~point();

	float x;
	float y;
}

bool TestPtCollision(point testPoint, rectangle testRect)
{
	//test for collision, 'return true' if found, 'return false' if not
	//...
}

int main()
{
	point myPoint;
	rectangle myRect;
	
	if(TestPtCollision(myPoint, myRect))
	{
		//collision found between myPoint and myRect
		//...
	}

	return 0;
}



Generally speaking, to determine optimizational effects in your program you can set a timer, get the time before and after executing your function and then get the time difference (dt), which would tell you how much time the function took to complete the process.

Also, since C++ code is compiled and results into an executable program, if you compile your function in a test program and then input your compiled executable in a dissassembler you can actually compare the amount of assembly commands generated for different versions of your function (less assembly commands naturally run somewhat faster, unless your program involves lots of iterations and sub-functions, in which case the determination of efficiency becomes more complex than simply checking what does your code translate into in assembly terms -- and you need to consider memory allocation, required iterations, etc. ). What inline does is it hints to the compiler to try and "paste" the function's code in place when a call to that function is made, rather than make a call to it in it's place of original definition. So this can potentially make execution faster, although it can have other negative effects, the most common being that it will increase your binary file size.

However, returning to the topic at hand, everything you put inside your return (...) in your functions above is determined by boolean algebra that sequentially compares 'true' and 'false' values between themselves, as each comparison operator you use ('<', '>', '>=', '==', etc) results in a 'true' or 'false' and then these boolean values are mutually operated on by bollean algebra in the way specified by the connecting '&&'s and '||'s. So dividing up the content in parentheses with '&&' (or, if you use different conditions, '||') would result in the same thing after compilation.

EDIT: Additional note: You also seem to try to avoid changing lines. Much like I mentioned above, shorter C++ code does not necessarilly affect the compiled version of your program. Brackets, parentheses, tabs, new-lines -- all these do not reach the binary executable, they are there for making the code easier to read (in cases where they are optional). So all the following will produce exactly the same binary result:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
bool myBool = true;

// #1 ---------------------------------
if(myBool)
{
        return true;
}

// #2 ---------------------------------
if(myBool)
{


                             return true;


}

// #3 ---------------------------------
if(myBool)
return true;


The file size of your .cpp files will not be the same (of course), but it is generally a good idea to make well-indented and easily readable code as it will make editing, maintaining and debugging a lot easier.
Last edited on
Topic archived. No new replies allowed.