James Kanze
11/7/2008 5:58:00 PM
On Nov 7, 4:52 pm, Al Grant <algr...@myrealbox.com> wrote:
> Consider two translation units, (1):
> namespace { struct S { }; }
> struct D: S { virtual int f(void); };
> and (2):
> #include <typeinfo>
> struct D;
> char const *f(D *p) { return typeid(p).name(); }
> Does 'D' name the same type in (1) and (2)? The RTTI for D*
> will reference an RTTI definition for D. Every ABI I've seen
> will give D (and its RTTI) a well-defined name (e.g. _ZTI1D in
> gABI), allowing external linkage to work here. But does the
> standard guarantee that?
> There's no ODR violation here, though a second definition of D
> would presumably violate the ODR.
> GCC 4.2 warns about deriving from a class in an anonymous
> namespace, as if it was something to be ashamed of. VC++ and
> Comeau don't warn.
It's a warning, not an error. In practice, either the
definition of D is in a header, in which case, including it in
two different translation units is undefined behavior, or it's
in a source file, in which case, D could also be in the unnamed
namespace. There are exceptions, though; I've done this a few
times when `D' was actually SomeClass::Impl and I wanted to
share the Impl (friend, second derived class, etc.) with other
classes in the source file, without making it publicly available
in the header. So all of the implementation was actually in the
class in the unnamed namespace, and SomeClass::Impl derived from
it. It's a fairly exceptional case, but IMHO reasonable enough
that the compiler shouldn't warn about it.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34