Re: Proposed semantics for attributes in C++ (and in C?)

[Mark Mitchell <mark at codesourcery dot com>]

Geoffrey Keating wrote:

> > A typedef declaration which adds semantic attributes to a non-class
> > type is valid, but again creates an entirely new type. 

>> It is invalid to
> > do anything that would require either type_info or a mangled name for
> > "Q", including using it as an argument to typeid, thowing an exception
> > of a type involving "Q", or declaring a template to take a parameter
> > of a type involving "Q".  (We could relax some of these restrictions
> > in future, if we add mangling support for attributes.)
>
> Declaring a function which takes a 'Q' also requires the mangled name of 'Q'.

Good point!

> > where T is some invented type name different from all others in the program.
> >
> > For example given:
> >
> >    __attribute__((packed)) S v;
> >
> > the type of "&v" is "__attribute__((packed)) S *", and cannot be
> > passed to a function expecting an "S*", but can of course be passed to
> > a function expecting an "__attribute__((packed)) S *", or a typedef
> > for such a type.
>
> ... except that there can't be any such functions.  You could assign
> it to another variable of the same type, or a field of a class with
> that type.

Right.  And, since there seems to be consensus that you shouldn't be 
able to apply semantic attributes to class types, "packed" is a bad 
example there too.  (If you applied "packed" at the point of declaration 
of "S", then "S" has a different layout than it otherwise would, but we 
don't need to do anything regarding mangling, etc.)

Thanks,

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713