Inline Functions

Would these two functions be good candidates for Inlining?

Code:

---

void SetCursor(int x, int y)
{
    Position.X=x;
    Position.Y=y;
    SetConsoleCursorPosition(hOut, Position);
    return;
}


string ReadCursor(int x, int y, int z)
{
    Position.X = x;
    Position.Y = y;
    char tempchar[25] = "\0"; 
    string tempstring;
    ReadConsoleOutputCharacter(hOut,
                              tempchar,
                              z,
                              Position,
                              &NumRead);
    tempstring.assign(tempchar, 25);
    return tempstring;
}

---

Quote:

---

Originally Posted by rwmarsh

Code:

---

void SetCursor(int x, int y)
{
    Position.X=x;
    Position.Y=y;
    SetConsoleCursorPosition(hOut, Position);
    return;
}

---

---

Why do you use an return at the end of the function?

I always thought the syntax required a return at the end of function definitions.

Your compiler likely does a better job than you at optimisation. Usually the only functions that I inline are 1-4 liners, but I'm sure the compiler does it anyway - inline is only a hint, like register.

>> tempstring.assign(tempchar, 25);
You should use tempstring = tempchar; unless you really want the string to have exactly 25 characters. If tempchar is a string with less than 24 characters, then after the terminating null there will be garbage characters. The assign function will copy the terminating null and those garbage characters into tempstring and tempstring's length will be 25 no matter what. If you use the assignment operator, tempstring will only receive the string contents of tempchar. Output tempstring.length() to verify if the string is getting the correct data.

>> Would these two functions be good candidates for Inlining?
Probably not, unless you've profiled your program and found that those functions are called a ton of times and the overhead is slowing your program down.

>> I always thought the syntax required a return at the end of function definitions.
On void functions that obviously don't return anything it is not necessary.

Quote:

---

Originally Posted by rwmarsh

I always thought the syntax required a return at the end of function definitions.

---

Not a requirement, but it doesn't hurt either. If you like it, use it.

Any function is a candidate for you to attempt to inline if you care about the performance when using it a lot more than you care about with other functions.

As to whether you will get a benefit from inlining, that depends on the compiler and whether it takes the hint when you've inlined the funcion. Some compilers refuse to inline any functions that do more than get or set a variable (i.e. setters and getters). Some compilers refuse to inline functions that include any looping constructs.

If your function calls are costing you precious milliseconds, the overall overhead runs into whole seconds, they are mostly wrapper/nearly-do-nothing functions, they do not use up much memory, and (most importantly) you feel they should be inlined, then go ahead.

Short answer, based on what you've posted so far: go ahead.

Note: some compilers will refuse to inline functions that are too big (think 10s of lines and involving some graphics card driver manipulation), no matter how much you want them to.

I would say You have to play with it to see what is best ;)

I remember reading this on one of the C++ usenet groups a while ago

Quote:

---

The first rule of optimisation : Don't!

---

:D

(Of course - this is in reference to the fact that one should always iron out all bugs in their code and test vigourously before attempting any sort of optimisation)

The basic intent of the first rule of optimisation is to avoid the phenomenon of premature optimisation --- people wasting lots of time trying to optimise something when there is no need to.

The time to do optimisation is when you have developed a program and have it running correctly. At that point you can identify any performance shortfalls, and identify the main contributors to any poor performance (eg using a profiler to identify what code the program is executing when it runs too slowly). Once you've identified the main contributors (often described as "hot spots") you optimise them.

Unfortunately, a beginners trap is start optimising too soon, and waste a lot of time hand-crafting code to optimise everything. That is a waste of time as it usually means optimising things that don't need to be optimised, and often also misses the real hotspots anyway (hotspots often turn out to be very small areas of code which, when optimised, give significant returns on effort).