akwright@watdragon.waterloo.edu (Andrew K. Wright) (12/16/88)
Since there has been a discussion ongoing about macros and inline
functions, and it has been several years since i last posted this problem,
i will post this again.
One major difference between macros and inline functions is that
the arguments to a function are evaluated *once*, whereas
the arguments to a macro is evaluated for each occurrence in the body.
Every C programmer learns this when they try putchar(x++);
So in this respect, using inline functions may be considered superior.
However, in inlining a function the compiler must be very careful
not to introduce a related problem: aliasing.
Well, the 1.2 version of cfront is not careful enough. The following
trivial program generates different output if the "inline" keyword
is deleted.
inline increment( int *p, int v ) {
*p += v;
return v;
}
main() {
int x = 2;
int y = 3;
cout << increment( &x, y ) << "\n";
cout << increment( &x, x ) << "\n";
}
Sure the aliasing is obvious in this example, but in general in C++
detection of aliasing is impossible. By weakening the compiler's
assumptions, we can detect when aliasing *might* occur, and ignore
the inline keyword in this case. But if the compiler is not sufficiently
intelligent, this will result in many "inline" functions not being generated
inline. The other choice (as exemplified by cfront) is to assume
that there is no aliasing, and risk changing the semantics of the program.
Any serious compiler writer, including Bjarne I am sure, is aware of this
problem. Curiously tho, his C++ book makes no mention that I can find
of this danger. I suspect that many C++ programmers may be unaware
of this problem.
Q. Are there any other C++ compilers out there that attempt to "solve"
the problem? (any compiler which simply ignores the inline keyword
is trivially a member of this class)
Q. Bjarne, what is AT&T doing about this in new C++ releases?
Andrew K. Wright akwright@watmath.waterloo.edu
CS Dept., University of Waterloo, Ont., Canada.schmidt@siam.ics.uci.edu (Doug Schmidt) (12/19/88)
In article <10469@watdragon.waterloo.edu> akwright@watdragon.waterloo.edu (Andrew K. Wright) writes: >Q. Are there any other C++ compilers out there that attempt to "solve" > the problem? (any compiler which simply ignores the inline keyword > is trivially a member of this class) > G++ 1.31 gets this right, ( it outputs 3 and 5, rather than 3 and 10 ) and it appears to generate calls to ``increment'' as inlines, too. If you are interested in seeing how this is done check out the 1.31 source code! Doug -- schmidt@ics.uci.edu (ARPA) | Per me si va nella citta' dolente. office: (714) 856-4043 | Per me si va nell'eterno dolore. | Per me si va tra la perduta gente. | Lasciate ogni speranza o voi ch'entrate.
jaa@hutcs.uucp (Jari Alasuvanto) (04/21/89)
I ran into following while porting software from sun3 into sun386. In both
machines I had the designer C++ but different versions.
For example:
class foo: {
int val ;
public:
foo() ;
value() { return val ;}
} ;
produces a warning for member "value" not being defined as an inline in class
when compiled in sun386. My questions is: Should it be defined (according
to the book or some other reference) as inlines. At least the libraries we
use (OOPS and InterViews) do not define functions like this as inlines
which causes a lot warnings.
Any ideas which one is right ?
Jari Alasuvanto, Helsinki Univ. of Techology, Finland
Internet: jaa@hutcs.hut.fi
Bitnet: jaa%finhutcs.bitnet host name for hutcs in bitnet is finhutcs
tel: +358-0-451 3236 fax: +358-0-465 077