Same thing, but strongly enforces the type of the array. This also
allows removing the <type_traits> include, since we can just query the
size of the array.
Alphabetizes includes and resolves quite a few instances of indirect
inclusions, making the requirements of several interfaces explicit. This
also trims out includes that aren't actually necessary (likely due to
changes in the API over time).
Now that decrement() doesn't lock a mutex every time its executed, we
can mark it as noexcept. This allows us to make most of the interface
noexcept. In particular, the move constructor and move assignment
operator can now be noexcept. This allows all Boo objects to play nicely
with interfaces that may make use of std::move_if_noexcept, like some of
the standard library facilities, without always taking the copy
constructor/copy assignment.
Now that we have the fencing and atomic operations in place to ensure
access to data on other threads will always occur before the use of
delete, we can remove the destructor lock. This will be useful for
making ObjToken's move assignment operator noexcept.
Increasing a reference count is able to always be relaxed. New
references to an object can only be formed from an existing reference.
The passing of an existing reference from one thread to another will
already necessitate the use of synchronization primitives, so this is a
safe change to make. Regardless, nothing other than the object itself
directly relies on the reference count, so this will always be a
suitably atomic operation, even in the face of no synchronization
primitives.
In the case of decrementing the reference count, it's sufficient to
treat it with release semantics and follow it up with an atomic thread
fence. This ensures that all accesses to the object in one thread will
occur before the delete occurs in another thread (if the situation ever
occurs).
This should make for a slightly more efficient increment and decrement.
The default move constructor isn't const qualified. The copy assignment
operator wasn't deleted either which is somewhat dangerous. We can also
opt for simply defaulting the move constructor and assignment operators
instead of defining the move constructor like a copy constructor.
Lioncash
Phillip Stephens
Jack Andersen