On 12/4/18 8:49 PM, Sandra Loosemore wrote:
On 12/4/18 8:13 PM, Martin Sebor wrote:
On 12/4/18 2:04 PM, Sandra Loosemore wrote:
On 12/4/18 9:26 AM, Martin Sebor wrote:
[snip]
+The keyword @code{__attribute__} allows you to specify various special
+properties of types. Some type attributes apply only to structure and
+union types, and in C++, also class types, while others can apply to
+any type defined via a @code{typedef} declaration. Unless otherwise
+specified, the same restrictions and effects apply to attributes
regardless
+of whether a type is a trivial structure or a C++ class with
user-defined
+constructors, destructors, or a copy assignment.
And here I would really prefer to use standard terminology than
trying to inaccurately summarize what the terminology means. E.g.
"...whether or not a class is trivial (in the C++11 sense) or POD (in
C++98)."
This doesn't say what we want to say (nor is it accurate).
Here are the user's questions again:
The documentation should clarify how it handles structs/
classes/unions and references. Does it threat references
like pointers? Does it only allow PODs/trivial types to be
returned, or does it invoke the copy constructor, when it
is used again?
They were about const/pure but the same questions could be asked
about other attributes as well. The simple answer I'm trying to
give is that it doesn't matter: (unless the manual says otherwise)
references [to pointers] are treated the same as pointers, and
there is no difference between functions that take arguments or
return classes with user-defined ctors and plain old C structs,
or between attributes applied to such types. It doesn't help
to use C++ standard terms when they are subtly or substantially
different between C++ revisions, and then try to draw
a distinction between those different terms, when they don't
matter.
I'm getting even more confused about what you're trying to communicate
here. :-(
I explained the intent above: "The simple answer I'm trying to
give is that [whether an attribute applies to a struct or a C++
class] doesn't matter."
It's really that simple so I'm not sure why we are spending so
much time on it. Far more time even than it took me to explain
it to the user.
What is the "it" referenced in the user's questions you quoted? The
const/pure attributes? Those are function attributes. The text you are
adding is in the type attribute section, so it seemed like it was trying
to address a different problem: stating that you can attach type
attributes to any struct/class type whether or not it is a "trivial"
class, by some definition of that term. If that's not the purpose of
this paragraph, what is it?
Again: the purpose is to explain that it doesn't matter whether
an attribute applies to a struct or a C++ class with ctors, in
any context with any attribute, either function, or variable,
or even type(*).
I answered the user's question below (and I CC'd you on it for
context):
https://gcc.gnu.org/ml/gcc/2018-11/msg00146.html
The "it" in the question refers to GCC in the context of
the const and pure attributes. As I explained above, the same
question could be asked about other attributes, including type
attributes. The manual has historically referred to C structs
and hasn't consistently mentioned C++ classes so I can see how
someone might wonder if they are treated differently.
The purpose of this change is to make it clear that they
are not.
Martin
[*] For instance, that the effect of the attribute here:
struct __attribute__ ((aligned (32))) A
{
int i;
};
is the same as its effect here:
class __attribute__ ((aligned (32))) B
{
public:
B ();
~B ();
int i;
};
The description of the aligned attribute in the Common Type
Attributes chapter of the manual refers to "the alignment of
any given struct or union type" and doesn't mention classes,
so one might wonder whether the attribute has a different
effect on those. Note that this is in contrast to the packed
attribute in the same chapter which does mention C++ classes:
This attribute, attached to a struct, union, or C++ class
type definition, ...
To make things clear, we could (and at some point perhaps
should) also go and edit all the places that talk about
structs and unions and mention C++ classes. It won't
unambiguously answer the user's question about PODs vs
non-trivial classes with ctors, but it would help.
