Path: utzoo!attcan!utgpu!watmath!watdragon!akwright
From: akwright@watdragon.waterloo.edu (Andrew K. Wright)
Newsgroups: comp.lang.c++
Subject: inline
Message-ID: <10469@watdragon.waterloo.edu>
Date: 16 Dec 88 14:32:38 GMT
Distribution: comp
Organization: U of Waterloo, Ontario
Lines: 48

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.