Topic: inline in C9X and C++
Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1999/09/22 Raw View
"Bill Wade" <bill.wade@stoner.com> writes:
>Clive D.W. Feather wrote in message <4QGYM9K$Ur43EwS7@romana.davros.org>...
>>> inline int foobar { return 0; } // In one file
>>
>>In C you can even write, in a third file:
>>
>> inline int foobar { return 2; }
>
>But if you do this it is unspecified (in at least one of the files) what
>value foobar() returns, making portable use of this "feature" problematic.
One potentially common and mostly portable use of this feature is as follows:
/* foo.h */
#include <assert.h>
inline void foo(int x) {
assert(x >= 0);
...
}
/* bar.c */
#include "foo.h"
void bar(int x) {
foo(x);
...
}
/* baz.c */
#define NDEBUG
#include "foo.h"
void baz(int x) {
foo(x);
...
}
In C++, this program is ill-formed, but no diagnostic is required;
the behaviour is undefined and furthermore the implementation can
refuse to translate the program (even if the functions foo(), bar()
and baz() will never be called). Still, in practice it is portable,
because current C++ implementations do the same thing here that
they would do if "inline" were replaced with "static".
In C9X, if the argument to foo() is always >= 0, then
the program (or at least this part of it) is strictly conforming.
If the argument to foo() is < 0, then it is unspecified whether or not
you get an assertion failure. But as far as portability goes, that
is not such a big concern, because assertion failures could only
happen if the program is buggy anyway.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]