Topic: Inline Hint and the One Definition Rule
Author: "John Hickin" <hickin@nortelnetworks.com>
Date: 2000/10/18 Raw View
If two translation units see different inlining hints for the same class
does this break the one definition rule? to be specific, consider the
following example (modulo #ifdefs to prevent multiple inclusion of
headers)
H.h
===
struct Foo { void bar(); }
Impl.cc
=======
#include <H.h>
inline void Foo::bar() { ... }
...
use Foo::bar() [but don't take its address]
AnotherClient.cc
================
#include <H.h>
use Foo::bar()
In effect, the translation unit Impl.cc sees Foo::bar as inline while
other clients don't. In practice this seems to work (with a popular
compiler) but with aggressive optimization you may see no code generated
and end up with unresolved references for Foo::bar. This makes sense to
me but I'm starting to feel that the whole approach violates the one
definition rule.
Comments?
TIA, John.
---
[ 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://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]
Author: wmm@fastdial.net
Date: 2000/10/18 Raw View
In article <39EDBBD9.517B9AB4@nortelnetworks.com>,
"John Hickin" <hickin@nortelnetworks.com> wrote:
>
> If two translation units see different inlining hints for the same
class
> does this break the one definition rule? to be specific, consider the
> following example (modulo #ifdefs to prevent multiple inclusion of
> headers)
>
> H.h
> ===
> struct Foo { void bar(); }
>
> Impl.cc
> =======
> #include <H.h>
> inline void Foo::bar() { ... }
>
> ...
> use Foo::bar() [but don't take its address]
>
> AnotherClient.cc
> ================
> #include <H.h>
> use Foo::bar()
>
> In effect, the translation unit Impl.cc sees Foo::bar as inline while
> other clients don't. In practice this seems to work (with a popular
> compiler) but with aggressive optimization you may see no code
generated
> and end up with unresolved references for Foo::bar. This makes sense
to
> me but I'm starting to feel that the whole approach violates the one
> definition rule.
Yes, it does. 3.2p3: "An inline function shall be defined
in every translation unit in which it is used." Also, though
not in the ODR section, is 7.1.2p4, which is more directly
applicable: "If a function with external linkage is declared
inline in one translation unit, it shall be declared inline
in all translation units in which it appears; no diagnostic
is required."
--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)
Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]