CODEWITHSUNDEEP
c++type-traitsstdallocator
Daniel
Daniel

Reputation: 406

Why is std::allocator not trivially copyable?

According to cppreference, std::allocator is stateless. I would except that most stateless type be trivially copyable, since they have no state to copy! Perhaps the only exception I can think of would be a stateless type that writes to some global variable whenever it is copied, thus leaving a side effect. I do not expect std::allocator to do anything like this.

However, the following static assert fails on both Clang and GCC

static_assert(std::is_trivially_copyable_v<std::allocator<int>>);

This is annoying because code that relies on detecting trivially copyable types to improve their performance (for example, by substituting memcpys for actual copies) can not work in the presence of std::allocator. Why does this happen?

Upvotes: 3

Views: 144

Answers (1)

Sneftel
Sneftel

Reputation: 41522

std::allocator is not trivially copyable because it has a user-provided, and therefore nontrivial, copy constructor. The copy constructor is presumably user-provided in order to specify it as throw()/noexcept. It's not generally going to be an issue because an allocator will ordinarily be held by a container class, which is definitely nontrivial.

Incidentally, "code that relies on detecting trivially copyable types to improve their performance" sounds like you're trying to outsmart the optimizer. I guarantee you that your compiler is capable of recognizing that std::allocator can be bitwise-copied without a function call, and that in general it's going to do a better job of recognizing and exploiting optimization opportunities like that than your templatey stuff is.

Upvotes: 1

Related Questions