Invisible <voi### [at] devnull> wrote:
> >    As for increasing the size of the executable, who cares? If the executable
> > gets a few hundreds of bytes larger, big deal.

> Yeah, that's the really puzzling bit. I mean, unless the function is 
> huge [which is a bad idea anyway], or is called from a bazillion places, 
> why would inlining it "bring its own performance costs"? I don't get that.

  In fact, inlining can actually sometimes reduce the size of the executable
(because a function call may be replaced with an expression that gets
calculated at compile time and optimized away).

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

> The book claims that if you write a function body inside a class 
> definition, that makes the method inline. Is this true? I thought there 
> was no difference either way...

  A function definition inside a class definition is implicitly 'inline'
(without having to explicitly use the keyword; you could specify it, but
it would be redundant.)

  Likewise template functions are implicitly 'inline' without having to
explicitly say so.

> Even so, there might be 15^2 function calls, but only at most 15 of them 
> will be /active/ simultaneously - which means only 15 stack frames at 
> once. No?

  You may be right.

> Well, yes. As I understand it, by default C++ doesn't reserve a whole 
> lot of stack space, so you're likely to overflow it quite quickly.

  It depends on the OS. (In most unixes you can actually set how much
stack is given to a process.)

-- 
                                                          - Warp

Post a reply to this message