I recently read an article about inlined functions that basically said that all that happens with an inlined function is that the code is just inserted at the call point. Obviously this is the idea of inlining a function. However, the article goes on to mention that all the setup for calling the function is still done (ie. pushing vars to the stack), and all the cleanup after the call is done (ie. cleaning up the stack). In light of this, I can''t really see that inlining functions buy that much performance increase. I''m thinking of violating OOP in the worst way now that I know this.. Using access functions is fine if inlining truly does get rid of the performance penalty, but if all the stack work is still being done, then I''m not going to bother. Is this info accurate? How many others prefer to violate OOP ?? -------------------------- I guess this is where most people put a famous quote... "Everything is funnier with monkey''''s" - Unknown

This is inaccurate.

An inlined function eliminates the overhead of the function call. As far as the compiler is concerned, an inlined call is simply another section of code. So your access functions are fine.

The only thing I can think the article is mistaken on is that inline is a request keyword, not an imperative. Your function is inlined only if the compiler is able to. Unless you''ve got a massive and complex code block, it should work.

Radhil Trebors
Persona Under Construction

This is how I have understood inline functions :-

The compiler makes a copy of the code into the memory at required points so instead of calling the function it calls the copy instead so eliminates the calling of function again and again. If your code has for, while if stuffs then the compiler will warn you that it cannot be made inline. So I think it just comes down to make the function inline if it is called lots of times and it should be small.

Eg :-

inline int function() { return something; }

Also I have seen some books put function definition in the class defintion itself, this isn''t good cause then compiler tries to make the function inline and its not good in big programming and its not a good practice.

What''s wrong with putting function definitions in the class definition? It doesn''t violate the OO principle. Of course, common sense will tell you not to put a function of 3000 lines in the class definition, but for other functions? Your statement is a little too vague....

The problem is that you increase your compile-time, since your header files are the ones that gets included, if you change one header file, a big amount of cpp-files may need recompilation, that otherwise were just fine.
No, it doesn''t violate OO principles, but as flame_warrior says in big projects it''s not a good practice for the above reason.

hi,
try the followin in a class :-

void test() { while(x != 0) { cout << x; x++; } }

Will give you a warning(please note - not an error only a warning) if it is defined in a class saying cannot inline functions which have while. Meaning it tries to inline your whole code. this isn''t memory efficient nor good programming practice.

I don''t see why you disagree with putting functions in the header. I feel it should be standard practice. On a small code snippet:

class vector
{
float v[4];

public:
inline void setX(float xIn) { v[0] = xIn};
inline void setY(float yIn) { v[1] = yIn};
// etc. etc.
};

I would hope most compilers would inline those automatically, but you never know. I think data protection is a Good Thing.

Friend functions should be outside the include file but the operators, and data functions should be in there. As a general rule things you call a lot should be in the .h file and the rest of the crap (debug stuff) should be elsewhere.


Stay Lucky, Graham "Mournblade" Reeds,
ICQ: 30514803
http://homepage.dtn.ntl.com/grahamr

quote:

---

Original post by amag

The problem is that you increase your compile-time, since your header files are the ones that gets included, if you change one header file, a big amount of cpp-files may need recompilation, that otherwise were just fine.
No, it doesn''t violate OO principles, but as flame_warrior says in big projects it''s not a good practice for the above reason.

---

Woo. Increase your compile time. It''s like MP3s. Who cares how long it takes to compile - the enduser is only interested in how it plays. Besides, even on my ageing o/c iP300 compile times are very quick on .c or .C.



Stay Lucky, Graham "Mournblade" Reeds,
ICQ: 30514803
http://homepage.dtn.ntl.com/grahamr

quote:

---

Original post by NuffSaid

What''s wrong with putting function definitions in the class definition? It doesn''t violate the OO principle. Of course, common sense will tell you not to put a function of 3000 lines in the class definition, but for other functions? Your statement is a little too vague....

---

True, it doesn''t violate OOP, but there ARE problems with putting function definitions in your .h file

1) Extra compilation time as amag mentioned
2) You expose source even if you just want to give a .lib/.h file for someone else to use (read: third party libraries)
3) Makes it tough to find functions. Don''t know how many times I''ve did a search for a function in a .cpp I thought was there, just to find out it was actually defined in the .h file.


- Houdini

quote:

---

Original post by Promiscuous Robot

Obviously this is the idea of inlining a function. However, the article goes on to mention that all the setup for calling the function is still done (ie. pushing vars to the stack), and all the cleanup after the call is done (ie. cleaning up the stack).

Is this info accurate?

---

Almost. All variables are created on the stack, so it is almost correct (loop counters are usually created in a register and a couple of other exceptions). Obviously the compiler are going to need the registers to create move the vars into after they are created so it will push everything, create the variables on the stack, move the variables from the stack into the registers and then pop the vars back from the stack once the code is complete. The problem with PCs. A crap number of registers.


Stay Lucky, Graham "Mournblade" Reeds,
ICQ: 30514803
http://homepage.dtn.ntl.com/grahamr