Allows for more flexible copying/manipulation within using code. While
we're at it, we can make the interface of SWindowRect and SScrollData
constexpr, given they only manipulate primitives.
Get/SetWindowLong is superseded on 64-bit Windows platform with
Get/SetWindowLongPtr. These are trivial to migrate over and have been
available since Windows 2000 Professional, so there's no need to worry
about breaking meaningful platform support
We can utilize the std::data and std::size utility functions to support
passthrough-ing data for any container that satisfies the
ContiguousContainer concept, which would be either std::array,
std::string, or std::vector.
This way we can utilize std::array internally without exposing the
inclusion within the header.
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.
Luke Street
Henrique Gemignani Passos Lima
Jack Andersen
Phillip Stephens
Lioncash