This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposed semantics for attributes in C++ (and in C?)
- From: Chris Lattner <clattner at apple dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Sun, 15 Oct 2006 16:46:07 -0700
- Subject: Re: Proposed semantics for attributes in C++ (and in C?)
- References: <4532B25F.9090207@codesourcery.com>
On Oct 15, 2006, at 3:12 PM, Mark Mitchell wrote:
A typedef declaration which adds semantic attributes to a POD class
type with no function members is valid, but creates an entirely new
type, different from all other types except others formed by adding
the same combination of semantic attributes to the same original
class type. In the example above, if the typedef adds a semantic
attribute, you may not pass an "S" to a function expecting a "T" or
vice versa. Neither may you pass an "S*" to a function expecting a
"T*", without an explicit reinterpret_cast. The name of "T", for
linkage purposes, is "T", and there is no implicit "T::S" type;
instead, however, there is a "T::T" type. (Various consequences
follow; for example, typeid(T) gives you a type_info object that
indicates that the name of the type is "T".)
Note that this is an ABI change for any code that uses these. I
agree that it seems cleaner to just disallow this practice entirely,
particularly if it is a recent invention. In any case, having the
compiler reject code that does not or will not work is a much better
position to be in than silently miscompiling code.
-Chris