Should this function be a inline function?

Quote:

---

Originally Posted by h3ro

So inlining is just for optimization?

Its for a school assignment so I wanted to show off that I understood inline (at least I think I do)

---

Yes, that's what it's for. Instead of making the function call each time, the compiler expands it "inline" in the code where it was called. As you might expect, too much inlining can bloat your code.

It's good that you are inquisitive and want to learn new things. I wasn't trying to bust your chops.

If you *really* want to impress your teacher, though, download UnitTest++ and verify that your code works with automated unit tests. Or code up your own test harness to drive your code and validate it.

Quote:

---

Originally Posted by iMalc

Don't prematurely inline.

If you don't know that you need to, then you shouldn't do it.

---

There are other ways of "knowing" than resorting to a profiler. Experience is a valid way of knowing.

Quote:

---

Originally Posted by cpjust

I've always wondered why the inline keyword exists, since compilers can inline without it and they can refuse to inline even if you specify inline?
Does specifying a function as inline make it more likely that the compiler will actually inline it?

---

Compilers are/were generally designed to compile each source file separately. With this practice, it is impossible for a compiler to inline a function that written in a different source file. The solution: have potential inline candidates be included in header files. The problem with that is multiple definition errors. So the inline key word was invented to allow multiple definitions for functions intended to be inlined.

People say that gcc is smart about figuring out which functions to inline, as far as I can tell, it cannot possibly inline a function unless a) it is declared inline, and included in a header, or b) it is declared in the source file unit that it is used in. Basically it boils down to a gcc can't inline a function call if the function being called is not included in the same compilation unit.

Quote:

---

Originally Posted by brewbuck

There are other ways of "knowing" than resorting to a profiler. Experience is a valid way of knowing.

---

Either way, it's still premature if you do it without performance mandating it.

Quote:

---

Originally Posted by medievalelks

Either way, it's still premature if you do it without performance mandating it.

---

That would be the case if it were somehow easier to not declare it inline than otherwise. But it requires no measurable additional effort to declare a function inline. In fact, for very simple classes, declaring every function in a class inline requires less effort, because you then don't need to create a source file at all.

Quote:

---

Originally Posted by King Mir

That would be the case if it were somehow easier to not declare it inline than otherwise. But it requires no measurable additional effort to declare a function inline. In fact, for very simple classes, declaring every function in a class inline requires less effort, because you then don't need to create a source file at all.

---

I didn't say it was bad in that case, just that optimization without measurement (formal or informal) is by definition premature.

Quote:

---

Originally Posted by medievalelks

Either way, it's still premature if you do it without performance mandating it.

---

Don't misunderstand the principle. The purpose of the premature optimization rule of thumb is to prevent the growth of overly intricate, difficult-to-understand code. (EDIT: It's not like there is some principle which says, "Write the slowest code possible until proven otherwise") However, the inline optimization is categorically different. Does the addition of the keyword "inline" suddenly cause a function to become hard to understand?

And the argument that it produces code bloat is flawed, because a non-stupid compiler will not inline functions when it would lead to code bloat in the first place, regardless of whether you've hinted at it with "inline."

Quote:

---

I didn't say it was bad in that case, just that optimization without measurement (formal or informal) is by definition premature.

---

Experience could count as an informal measurement. I guess that this could be related to preferring ++i over i++, or passing objects of class types by (const) reference instead of by value by default.

I think that in this case one has the compiler's judgment as a safety net, so even if one's experience proves inapplicable, the compiler may nudge things along the right path anyway.

Quote:

---

Does specifying a function as inline make it more likely that the compiler will actually inline it?

---

not necessarily. if the function is completely contained in the only source file that it's called from I've noticed vs2005 will attempt to inline it, regardless of whether it's declared using the inline specifier.

Quote:

---

Don't misunderstand the principle. The purpose of the premature optimization rule of thumb is to prevent the growth of overly intricate, difficult-to-understand code. (EDIT: It's not like there is some principle which says, "Write the slowest code possible until proven otherwise") However, the inline optimization is categorically different. Does the addition of the keyword "inline" suddenly cause a function to become hard to understand?

---

Quote:

---

Originally Posted by laserlight

Experience could count as an informal measurement. I guess that this could be related to preferring ++i over i++, or passing objects of class types by (const) reference instead of by value by default.

---

Uncle :-)

Quote:

---

Originally Posted by medievalelks

I didn't say it was bad in that case, just that optimization without measurement (formal or informal) is by definition premature.

---

What I'm saying is that it doesn't count as optimization, because there in no extra effort involved in implementing it.

Even if an application is not speed critical, it is still perfectly fine to inline code, provided that no special effort is devoted to doing so.

Quote:

---

Originally Posted by King Mir

Compilers are/were generally designed to compile each source file separately. With this practice, it is impossible for a compiler to inline a function that written in a different source file. The solution: have potential inline candidates be included in header files. The problem with that is multiple definition errors. So the inline key word was invented to allow multiple definitions for functions intended to be inlined.

People say that gcc is smart about figuring out which functions to inline, as far as I can tell, it cannot possibly inline a function unless a) it is declared inline, and included in a header, or b) it is declared in the source file unit that it is used in. Basically it boils down to a gcc can't inline a function call if the function being called is not included in the same compilation unit.

---

There are, of course, further optimizations. I don't know if it applies to inline, but the linker can also perform optimizations on code after the compiler. These optimizations are at least available in Visual Studio.