lucifer

Hi
I have a little problem regarding inline functions ,does declaring a function inside the class definition make it inline or not.

__________________
"You're good... but me, I'm magic"

grumpy

Short answer is "Maybe".

If a function is declared within the class definition, but no definition (i.e. body) is supplied with that declaration, then the function is not typically inline .... although some aggressive compilers (or linkers) might inline the function anyway.

If the function is defined within the class definition (i.e. a body of the member function is given within the class declaration) that is normally a hint to the compiler to inline the function. However, the compiler is allowed to ignore that hint ... some compilers do, some don't.

If the function is explicitly declared inline (i.e. the function definition comes after the class declaration, and is prefixed by the inline keyword) then, again, the function might be inlined. Like any form of inlining, use of the inline keyword is a hint to the compiler and compilers are allowed to ignore that hint.

lucifer

thanks grumpy for your answer
so to be on safer side i should declare n define the small function inside the class

__________________
"You're good... but me, I'm magic"

grumpy

I suggested nothing of the sort. Inlining is not inherently a good (or safe) thing.

lucifer

why ??
if it makes your application faster why is it not good

__________________
"You're good... but me, I'm magic"

DaWei

Suppose you have a class in some file that has some defined interface, and that some method will be inlined in a second file. If the class author changes the class in some way that doesn't change its functionality or interface (perhaps just reorders or adds some variables), the inlined code in your second file is likely to break.

In other words, encapsulation failed. You now have to know when this useful library has changed, so that you can recompile all your code that uses it. If the method were not in-lined, everything would still work.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

lectricpharaoh

There are two main reasons that inlining can be bad. First, it often (though not always) causes a bit of code bloat (to be fair, this amount is usually minimal). Second, it can overflow cache lines, and cause cache misses (slowing thing down). Yes, a function call will probably outwiegh the effects of cache misses, but consider the following code:Now, imagine someFunction() is outline. It will only have an impact every tenth time through the loop. If it's inline, and big enough, it will prevent the loop from fitting in a cache line, and might yield overall slower performance.

These considerations depend heavily on the architecture involved, coupled with what other optimizations may be enabled (loop unrolling, for example, will also have an impact on whether or not this code is cache-friendly). This is precisely why the compiler only takes the 'inline' keyword as a hint; it will do whatever it determines as best. A similar issue exists with the use of the register keyword.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

grumpy

Additionally, inlining is also one of the tools of the programmer who I refer to as the "premature optimiser" who, in too many case, becomes the "excessive optimiser". Such a person believes that faster performance is inherently a good thing, and therefore spends a lot of time optimising the performance of their code. Behaviours of the premature optimiser include buffing and polishing of loops and attempting to inline everything as much as possible. In the premature optimiser also often focuses on performance so much that they compromise program correctness (the program runs fast, but wrong) or, even more commonly, take days crafting their code when colleagues may take hours. The effect is programs that take longer to develop, and more likely to have obscure bugs .... which often do not show up until the program is in the hands of users, because the test cases used by the premature optimiser are incomplete.

It is generally better to get the program correct (in terms of producing the results it needs to produce) before worrying about its speed. If a program produces the results it needs to produce, but is not fast enough, then tools like profilers can be used to find hotspots in code for optimisation of performance. Interestingly enough, in most non-trivial systems, the actual hotspots turn out to be something completely different from the places where a premature optimiser focuses attention.

The main exception to my position (focus on correctness first, rather than performance) arises in high-criticality code (eg safety critical) where timing performance can be a key to correct functioning -- there can be hard realtime constraints (both upper and lower bounds on execution times for some functions). In such systems, you will not get away with coding and performance tweaking of code ..... the expectation, in relevant standards, is that considerable design and analysis effort is MANDATORY before any LINE of code is cut. Essentially, in high criticality systems, the analysis effort needs to consider performance. And, if such analysis is applied to the process of developing a system in C/C++, it is possible but difficult to justify inlining of any functions. Code constructs that tap into discretionary behaviour of a compiler (i.e. even if asked to do inlining, the compiler may decide not to) is quite difficult to analyse. Premature optimisers, typically, do not find employment in development of high criticality systems.

Seif

No, they get jobs in they tend to get jobs in the game industry