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. :-(
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?
-Sandra