> > 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?
> > 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.
> 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."
Yes, I know what the 'ANSI guidelines' and also what Stroustrup says in
his book. They are dead wrong on this point, however.
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
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.