Remove workaround for GCC 4.x

[julianbrost]

Just noticed some small room for improvement while looking over another diff in that file:

The fallback implementation was added for GCC 4.x as that didn't yet implement std::is_trivially_copyable. However, by now we're using C++17 as our language standard and that wasn't even implemented in GCC 4.x yet¹:

Some C++17 features are available since GCC 5, but support was experimental and the ABI of C++17 features was not stable until GCC 9.

Hence, this became more or less dead code and can be removed.

While at it, I also made use of std::conditional_t and std::is_trivially_copyable_v available in newer C++ versions, doing the same but more compactly (if you look at their documentation, they are defined as just what we did before).

Footnotes

1. https://gcc.gnu.org/projects/cxx-status.html#cxx17 ↩

[jschmidt-icinga]

This might not actually matter since we don't currently use AtomicOrLocked<T> with types like that, but std::atomic actually puts more constraints on its use than just std::is_trivially_copyable, it also wants the type to be copy/move constructable/assignable and not be a reference (see here).

From what I can see, Locked<T> only implements value semantics, so unlike std::atomic it could live with a deleted move-constructor and assignment operator. So maybe the conditional should additionally reflect that and allow for trivially constructible types with deleted move constructors.

(Also it seems that counter-intuitively, unlike std::atomic<T> and our own Atomic<T>, Locked does not support value-construction, which would have made AtomicOrLocked<T> usable with references, but that would be an easy fix if we ever needed it.)

[julianbrost]

My idea with this PR was to only remove dead code, not change any functionality.

This might not actually matter since we don't currently use AtomicOrLocked<T> with types like that, but std::atomic actually puts more constraints on its use than just std::is_trivially_copyable, it also wants the type to be copy/move constructable/assignable and not be a reference (see here).

The main use-case for AtomicOrLocked is to automatically pick the best choice allowing safe concurrent access to class members generated from *.ti files:

icinga2/tools/mkclass/classcompiler.cpp

Line 1071 in cfff82b

m_Header << "\tAtomicOrLocked<" << field.Type.GetRealType() << "> m_" << field.GetFriendlyName() << ";" << std::endl;

So if possible, it should pick std::atomic and being trivially copyable is only an approximation for that. However, the good thing here is that (according to cppreference which you've linked), the programm is ill-formed otherwise (instead of being undefined behavior), so we should notice if this was ever used with a type that doesn't fit that pattern, we should notice it.

In the end, this boils down to the question: is that just good enough (it seems to be so far) or do we want the more complex condition (which will be technically more correct but also more code).