[Exceptional C++ Style] Exception C++ Style - Item 25: inline Redux.

[Atul_Khot at i2.com]

effective-cpp-bounces at accu.org wrote on 01/28/2005 02:22:48 PM:

[ Snip ]

>
> Ahem. Not unconditionally, I think. Sure, it has more information to make
> the decision at that point, but e.g. link-time inlining is _not_
equivalent
> to compile-time inlining. With compile-time inlining, inlining the
function
> call leads to longer stretches of code available to the optimiser, and
this
> may result in a more dramatic improvement than simply the inlining
itself.

I would not worry about all this. ( Or should I? ) The uppermost things
in my mind would be clarity, simplicity, refactoring, use standard lib
functions where possible.
      I agree with the advice here. I never usually inline intentionally
( Inlining methods implicitly is a bad practice IMHO as refactoring is very
hard because of build times ).

>
> > And it is better done by the tools than us.
>
> That I would tend to agree with. :)
>

I agree with the advice here. I have not seen anything in practice that
goes against this. As K & P illustrate with an example in "Practice Of
Programming"
- optimizations should be done only rarely - and - should stop after some
time
- why over engineer?

- ciao,
  _
 /_|  _/         /
(   |  /   (_/  (

my i2 mail id scrawl .... :-)

printf "%d\n" 97 116 117  108 95 107 104 111 116 64 105 50 46 99 111 109 |
{ dd cbs=80 conv=block 2>/dev/null; echo; } | perl -pe 's/(\d+)/chr($1)/eg'