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.     ]