7

The Folly library requires that std::atomic<hazptr_obj*> should be a trivial type. This works with gcc and clang, but failing for Visual C++ even for std::atomic<int>. Why does std::is_trivial return false?

#include <type_traits>
#include <atomic>

static_assert(
    std::is_trivial<std::atomic<int>>::value,
    "std::atomic<int> not trivial");
KindDragon
  • 6,558
  • 4
  • 47
  • 75
  • Related: [trivial vs. standard layout vs. POD](https://stackoverflow.com/q/6496545/712526) – jpaugh Feb 14 '18 at 19:00
  • I was under the impression that a trivial type had to be trivially copyable, while `std::atomic` types are not copyable. – François Andrieux Feb 14 '18 at 19:02
  • I'm curious -- did you put in the `static_assert`, or did the library authors do this? If it's the authors, then they must have had some knowledge that `std::atomic` is not guaranteed to pass the `std::is_trivial` test. – PaulMcKenzie Feb 14 '18 at 19:03
  • 8
    `std::atomic` used to be trivial, but isn't anymore. See https://stackoverflow.com/a/29759556/3002139 for a great and detailed explanation. – Baum mit Augen Feb 14 '18 at 19:04
  • @PaulMcKenzie https://github.com/facebook/folly/blob/8635022f0c4005dc218dd74cdee768126c954763/folly/experimental/hazptr/hazptr-impl.h#L316-L318 – KindDragon Feb 14 '18 at 19:05
  • @BaummitAugen Thanks. You can post it as answer. Good enough for me – KindDragon Feb 14 '18 at 19:06

2 Answers2

12

std::atomic used to be trivial (which requires Trivially Copyable), but isn't anymore. See this answer for a great and detailed explanation for how and why that changed.

This makes VC compliant and gcc and clang non-compliant at least in C++17. As this was considered a defect by the committee, VC shows the desired behavior for C++11 and C++14, too.

For future reference, the relevant defect is DR #1734, you can see the implementation status for clang here. I'm not aware of an equivalent status page for gcc.

Baum mit Augen
  • 49,044
  • 25
  • 144
  • 182
1

The assert in folly was disabled for MSVC in https://github.com/facebook/folly/commit/a47a5531edcb95a27f987e810272ba94a9b51162

Andrew Steven Krieger
  • 21
  • 1
  • 2
    I know absolutely nothing about the Folly library, but having the assertion for some compilers but not all seems obviously wrong. Either the library depends on triviality, in which case the assertion should stay and prevent building on corrected toolchains until the library is changed to work right with the new behavior (although it should move so it doesn't affect users who merely include the file), or the library doesn't require triviality, in which case the assertion is wrong on all compilers. Am I missing something? – Ben Voigt Feb 18 '18 at 21:24