brian@uw-june.UUCP (Brian Bershad) (12/15/87)
This is a followup to a question I posted several weeks ago asking
"when is an inline function not inlined." The answer back from BS was
- when it is virtual
- when its address is taken
- when an inline is used more than once in the same expression.
Given this, the following program highlights an error somewhere (either
in the compiler or in my interpretation of how the compiler is to behave).
class Lock {
int x;
public:
Lock()
{;}
inline int lock();
inline int unlock();
};
class Queue {
Lock *l;
#ifdef IGNORE_INLINE
int lock()
{ l->lock();}
int unlock()
{ l->unlock(); }
#else
inline int lock();
inline int unlock();
#endif
public:
Queue()
{ l = new Lock; }
inline int get();
};
inline int
Lock::lock()
{
return x = 0;
}
inline int
Lock::unlock()
{
return x = 1;
}
#ifndef IGNORE_INLINE
inline int
Queue::lock()
{
l->lock();
}
inline int
Queue::unlock()
{
l->unlock();
}
#endif
inline int
Queue::get()
{
int y;
lock(); // inline ignored here
y = 100;
unlock(); // and here
return y;
}
main()
{
Queue *q = new Queue;
int t;
t = q->get();
}
------
If you define IGNORE_INLINE, the program will make procedure
calls to the statics _Lock_lock and _Lock_unlock at the points
indicated in Queue::get(). If IGNORE_INLINE is not defined,
the emitted code is correct.
The problem is in the definitions for Queue::lock() and Queue::unlock().
If they are only declared in the class declaration as inline functions,
the compiler handles the subsequent ordering correctly. BUT, if they
are defined as inline functions referencing the lock and unlock operations
which have not yet been defined, the references, when themselves
inlined, turn into procedure calls. This seems wrong.
Since the compiler is not obligated to emit any code until it has at
least had the \opportunity/ to see all of the inline definitions, it would
seem that ordering should be unimportant.
This is all in cfront v. 1.2.
Is this
- a bug
- a feature
- or an example of confusing the way the compiler actually works
with how I would like it to work.
--
brian@june.cs.washington.edu Brian Bershad
{ihnp4,decvax,ucbvax}!uw-beaver!uw-june!brian Dept. of Computer Science, FR-35
University of Washington
Seattle, WA 98195