Invisible <voi### [at] devnull> wrote:
>    "Note that inline functions can bring a heavy cost. If the function 
> is called 10 times, the inline code is copied into the calling functions 
> each of those 10 times. The tiny improvement in speed you might achieve 
> is more than swamped by the increase in the size of the executable 
> program.

  He seems to think that the 'inline' keyword forces the compiler to inline.
It doesn't. The compiler is completely free to not inline it, if it decides
that it would be detrimental.

  As for increasing the size of the executable, who cares? If the executable
gets a few hundreds of bytes larger, big deal.

  The 'inline' keyword has a secondary, but much more important role,
though: It's an instruction for the compiler that says, basically, "if
this function appears in more than one compilation unit, don't give me
a linker error; instead merge them into one".

  Anyways, 'inline' should usually only be used for very short functions
that are absolutely crucial for speed. Otherwise there's little benefit.

> Now, I'm used to programming languages where the decision to inline 
> something or not is down to the compiler. It's not something an 
> application programmer would ever have to worry about. And it seems that 
> the inline directive is only a "hint" in C++ anyway, so I have to 
> wonder, whether this particular directive is now obsolete.

  Some newer compilers (such as the newest version of gcc) are able to
inline functions between compilation units. However, this is a rare,
quite advanced feature. (AFAIK only gcc implements this so far.)

  Traditionally, if you need a short function to be as fast as possible,
you need to define it in the module's header file, and then it *must* be
declared 'inline' (or else you'll get linker errors).

> I love the dire warnings that you could use a number less than 15, 
> because otherwise the program might consume a vast amount of memory. 
> (For goodness' sake, how much RAM does 15 stack frames take up?!)

  That would probably be 15^2. The author might have been using a 16-bit
DOS compiler.

>    "Recursion is not used often in C++ programming, but it can be a 
> powerful and elegant tool for certain needs. Recursion is a tricky part 
> of advanced programming. It is presented here because it can be useful 
> to understand the fundamentals of how it works, but don't worry too much 
> if you don't fully understand all the details."

> In other words, yet again, "now you know how this works, you don't need 
> to actually use it".

  Recursion is often handy to implement algorithms that are very recursive
in nature, but one should be careful to not use too much stack space.
(Generally speaking C++ compilers do not perform tail recursion
optimizations. I'm not completely sure why.)

  If your recursion depth is O(log n), then it's usually safe. If it starts
being O(n), then it's more worrisome. (Well, depending on the expected
amount of data, of course.)

  Usually recursion is also slower than an equivalent iterative solution
(*especially* if the iterative solution works with O(1) extra memory.)

>    "Registers are a special area of memory built right into the CPU."

> Erm...

  Even C programmers stopped worrying about CPU registers somewhere in the
early 80's. In C++ they have never been an issue. It's a headache of the
compiler, not the programmer.

> Still, it does answer something I've always wondered about: What *is* 
> the C calling convention?

  It actually depends on the OS.

  You don't need to worry about calling conventions unless you are
implementing something really, *really* low-level. Machine-code level.
(One example would be if you are writing a compiler.)

-- 
                                                          - Warp

Post a reply to this message