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