Very Computer

I think that it is a dirty trick for CW C/C++ to second guess me and
to not bother inlining something that I explicitly requested it to
inline, and even worse to do it quietly.  It's one thing if I have the
option checked 'don't inline', but quite another if CW ignores my
request for some other reason.

--Jeff

  This is a language thing, not a CW thing. 'inline' is a suggestion and
request to the compiler, nothing more. The compiler decides if the routine
is really too long to inline; it can also decide not to inline the
function if references to it appear before the 'inline' (although this
should generate a warning).

  I think there was a #pragma to allow unlimitted size inlines, but my
copy of Inside CW is at work so I can't say for sure.

Cheers,

Bob

Bob Hablutzel
Hablutzel Consulting

Phone: 603 749-1128
Fax:   603 749-1186

MLS

PS to Dr. Baker: sorry I refused to work with you on income tax return
preparation software back in 1979 -- the idea of programming for profit
offended me in my idealistic youth.  I guess we were both ahead of our
time in our respective ways.  I've changed my philosophies, though.  Hope
you haven't!

I suggest that you check the function to see if it is to large, recursive,
invoked before being defined, or if it contains a loop, switch, etc.

Sylvester

Quote:> CW is following the ANSI guidelines.  Inline is only a "hint" which the
> compiler is free to ignore.  "The inline specifier is a hint to the
> compiler that inline substitution of the function body is to be preferred
> to the usual function call implementation.  The hint may be ignored...It
> is necessary to allow a compiler to ignore that hint.  Determining whether
> a function can be inlined or not is in general not possible."

The main reason for the allowing compilers to ignore the hint is that if you are converting from C++
to C, it can be _very_ hard to inline certain functions (such as functions which return a value, and
also contain a loop).

OK, so it is _legal_ for CW to ignore the hint. That doesnt mean it should.

----------------------------------------

Register allocation has indeed reached a high level -- the CW6 compiler
is a typical example.  However, function iinlining has not reached a
very high level -- the CW6 compiler is again a typical example.

There are good theoretical reasons why compilers will never be as good
at function inlining as they are at register allocation.  Probably the
most pragmatic reason is that they look at only a single file in isolation,
and cannot get a global outlook on the entire application.

It was my understanding that 'inlining' in C++ was one way that Stroustrup
was trying to wean C programmers from C preprocessor macros.  However, this
weaning will fail if C++ compilers are allowed to quietly ignore the 'inline'
request.  We'll be forced to go back and use those ugly, error-prone
preprocessor macros.

I don't want to argue with an implementation about whether inlining is a
good idea in a particular instance or not.  If a particular 'inline'
request turns out to be non-optimal, I'll find out soon enough if the
implementation allows me to perform the experiment.  In any case, one
can hardly blame the implementation if the programmer specified 'inline'
and the inlining turned out to be non-optimal.

If I go to the trouble to optimize a set of routines based on their
being inlined, I'd like to be warned by the compiler if I later inadvertently
change something to cause them to no longer be inlined.  Ditto if I get
a new version of CW which no longer inlines things that a previous version
used to inline.

--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html

: The compiler decides if the routine
: is really too long to inline; it can also decide not to inline the
: function if references to it appear before the 'inline' (although this
: should generate a warning).

In my experience, this should (and does) constitute an error.  According
to section 7.1.2 of the draft standard (dcl.fct.spec) verse 3, the
definition of an inline function must appear before any use of it or the
program is ill-formed.

Implementor, Intrigue Corporation     AppleLink: INTRIGUE

Quote:> CW is following the ANSI guidelines.  Inline is only a "hint" which the
> compiler is free to ignore.  "The inline specifier is a hint to the
> compiler that inline substitution of the function body is to be preferred
> to the usual function call implementation.  The hint may be ignored...It
> is necessary to allow a compiler to ignore that hint.  Determining whether
> a function can be inlined or not is in general not possible."

CW6 won't inline this:

template <class T> inline T Abs( T const a) { return (a>=0 ? a : -a); }

or even this:

inline short Abs( short a) { return (a>=0 ? a : -a);

Guess what my solution was:

#define Abs( a ) ((a)>=0?(a):(-a))

Sure am glad I bought a fancy C++ compiler. :b

This piece of code is being used in a digital signal processing routine.  
I don't need to tell you it needs to be fast.  Unfortunately the compiler
can't take a HINT and would rather ruin my code (and my company) than
"waste" 40 bytes.  Maybe I should buy a compiler that will inline when I
order it to instead of one thats thumbs its nose at me and sticks a
function call in a time critical loop?

--
Authoring steam-powered signal processing for not-so-super computers.

Quote:>Is there any way that CW C/C++ can warn me when it can not/will not
>'inline' a function that I specifically requested it to inline?

Below is a list of the current CW/6 function inlining limitations. This
list will change in the future. In particular engineering hopes to remove
the first and the last restriction for CW7.

================
Limitations for function inlining:

- Functions that do not return results in a register (ie. functions that
  return data structures) are not inlined.

- Functions with variable argument lists are not inlined.

- Functions with class arguments with destructors are not inlined.

- A statement-level inline function call is always inlined.

- An expression-level inline function call is only inlined if it does
  not contain any control statements (ie. if, while, etc. ).

 extern int i;
 inline int foo()
 {
  if(i<10) i++;
  return i;
 }
 inline int bar()
 {
  (i<10)?i++:0;
  return i;
 }
 extern void foobar()
 {
  foo();  // inlined (statement-level)
  bar();  // inlined (statement-level)
  i=foo(); // not inlined (expression-level)
  i=bar(); // inlined (expression-level)
 }

Ron

   METROWERKS               Ron Liechty

<
<> CW is following the ANSI guidelines.  Inline is only a "hint" which the
<> compiler is free to ignore.  "The inline specifier is a hint to the
<> compiler that inline substitution of the function body is to be preferred
<> to the usual function call implementation.  The hint may be ignored...It
<> is necessary to allow a compiler to ignore that hint.  Determining whether
<> a function can be inlined or not is in general not possible."
<
<I think it sucks!!!!!  The ANSI guidelines don't say that "inline" will be
<ALWAYS ignored.
<
<CW6 won't inline this:
<
<template <class T> inline T Abs( T const a) { return (a>=0 ? a : -a); }
<
<or even this:
<
<inline short Abs( short a) { return (a>=0 ? a : -a);
<
<--
<Authoring steam-powered signal processing for not-so-super computers.

It inlines those sorts of things for me.  I have similar Min and Max
inline template functions in a header file and they are inlined.  Are
these templates in a header file?

____________________________________________________________________

Toolbox commando and Menu bard.             Will FlushCache for Cash