[cfe-dev] Standards interpretation question wrt to Clang trunk

Richard Smith richard at metafoo.co.uk
Thu Nov 22 02:14:51 PST 2012


On Wed, Nov 21, 2012 at 9:52 PM, Ryan Molden <ryanmolden at gmail.com> wrote:
> Is this the right alias for discussion of Clang implementation specifics? Or
> would that be better over on cfe-commits?

This is the right place.

> Assuming this is an appropriate alias (or that I can simply forward this on
> if not), I am fixing some missing compiler intrinsics that Clang doesn't
> provide but the VS 2012 STL headers require for some of their type traits
> implementations.
>
> In doing this I have found a couple of things in Clang's current type trait
> support that seem incorrect by my reading of the standards, but I wanted to
> run this by other people before I changed anything.
>
> The first issue is this code:
>
> struct NotTrivial {
>   NotTrivial() = delete;
> };
>
> int main(int,char**)
> {
>     static_assert(!__is_trivial(NotTrivial), "A class with no default
> constructor doesn't meet the definition of a trivial class");
>     return 0;
> }
>
> This fires today in Clang trunk.
>
> Looking at the standard I see this:
>
> The definition of a trivial type is n3376 3.9 [basic.types]/9
>
> Arithmetic types (3.9.1), enumeration types, pointer types, pointer to
> member types (3.9.2), std::nullptr_t, and cv-qualified
> versions of these types (3.9.3) are collectively called scalar types. Scalar
> types, POD classes (Clause 9), arrays of such types and cv-qualified
> versions of these types (3.9.3) are collectively called POD types. Scalar
> types, trivially copyable class types (Clause 9), arrays of such types, and
> cv-qualified versions of these types (3.9.3) are collectively called
> trivially copyable types. Scalar types, trivial class types (Clause 9),
> arrays of such types and cv-qualified versions of these types (3.9.3) are
> collectively called trivial types. Scalar types, standard-layout class types
> (Clause 9), arrays of such types and cv-qualified
> versions of these types (3.9.3) are collectively called standard layout
> types.
>
> The referenced Clause 9 says (n3376 9 [class]/6):
>
> A trivial class is a class that has a trivial default constructor (12.1) and
> is trivially copyable.
> [ Note: In particular, a trivially copyable or trivial class does not have
> virtual functions or virtual base
>
> Since NotTrivial has no default constructor it seems it can't meet this
> definition.

Clang is behaving correctly. NotTrivial has a default constructor,
which is deleted, and thus not user-provided. It meets the other
constraints for triviality, so it is a trivial default constructor.

(Note that deleted functions still exist, and can still be trivial.)

> The second issue (this one I am less sure about) is in this code (this also
> fires in Clang trunk):
>
> struct NotTriviallyCopyable {
>   NotTriviallyCopyable(const NotTriviallyCopyable&) = delete;
>   NotTriviallyCopyable& operator=(const NotTriviallyCopyable&) = delete;
> };
>
> int main(int,char**)
> {
>     static_assert(!__is_trivially_copyable(NotTriviallyCopyable), "A class
> with no copy constructor or copy assignment operator is not trivially
> copyable");
>     return 0;
> }
>
> This one hinges on the definition of trivially-copyable, which seems like it
> can be read two ways:
>
> n3376 9 [class]/6:
>
> A trivially copyable class is a class that:
>   — has no non-trivial copy constructors (12.8),
>   — has no non-trivial move constructors (12.8),
>   — has no non-trivial copy assignment operators (13.5.3, 12.8),
>   — has no non-trivial move assignment operators (13.5.3, 12.8), and
>   — has a trivial destructor (12.4).
>
> It seems since this class has NO copy constructors or copy assignment
> operators that it shouldn't be considered trivially copyable.

Clang is correct here too. This class has a trivial (deleted) copy
constructor and a trivial (deleted) copy assignment. It has no move
constructor and no move assignment. It also has a trivial destructor.
Therefore it is trivially copyable.




More information about the cfe-dev mailing list