WinReg v6.3.2 Header-only Stable Release

Fixed building with MinGW 32-bit (issue #73).

WinReg v6.3.1 Header-only Stable Release

Added some checks when casting from size_t (usually from STL) to DWORD (at Win32 API boundaries).
Now the code throws exceptions in case of size_t not fitting a DWORD (possible in 64-bit builds with size_t being 64-bit while DWORD being a 32-bit unsigned integer).

NOTE: Some methods that have been previously marked noexcept (e.g. RegKey::TrySetStringValue, RegKey::TrySetExpandStringValue, RegKey::TrySetBinaryValue) are now not marked noexcept, as an exception may be thrown in case of input size_t not fitting a DWORD.

WinReg v6.3.0 Header-only Stable Release

Added methods to the RegKey class to check if a registry key contains some specified values and subkeys.
These methods are: ContainsValue, ContainsSubKey, and the corresponding TryXxxx versions: TryContainsValue and TryContainsSubKey.

WinReg v6.2.0 Header-only Stable Release

Modified some library implementation code to avoid a potential race condition when reading some data from the Registry.

Detailed Explanation
Before this change, to get values of types like strings, multi-strings or binary data, two successive calls were made to the RegGetValue Windows Registry API. The first call was made to get the destination buffer size; then a buffer of that size was allocated to read the actual data; and, finally, a second call to RegGetValue was made to read the data in the previously allocated buffer.
Schematically:

1. Invoke RegGetValue the get the output buffer size
2. Allocate a buffer of that size
3. Invoke RegGetValue again to read the data from the registry in the above output buffer

The race condition that may happen (but has never happened during my use of the library) is a modification of the registry value between the two calls to RegGetValue, such that the buffer size is not large enough to store the new data. To prevent this situation, a while loop is used instead. For example, in RegKey::GetStringValue, I wrote some new code like this:

  LSTATUS retCode = ERROR_MORE_DATA;
  while (retCode == ERROR_MORE_DATA)
  {
      // Get the size of the result string
      retCode = ::RegGetValueW( ... );

      // Check for error...

      // Allocate a string of proper size
      result.resize(dataSize / sizeof(wchar_t));

      // Call RegGetValue for the second time to read the string's content
      retCode = ::RegGetValueW( ... );
  }

WinReg v6.1.1 Header-only Stable Release

This release basically implements a small (backward-compatible, and useful) fix: it uses winreg_internal for the library's internal namespace.
Using winreg_internal instead of just internal (or detail) for WinReg's private internal helper code makes the library code safer in case of client code using namespace winreg. In fact, in such case, WinReg's internal code is still protected under winreg_internal and will not conflict with potential internal/detail namespaces from other libraries.

WinReg v6.1.0 Header-only Stable Release

Small fix to make the code compile on MinGW (according to a library user; I don't use that compiler to build and test this code).
Plus added a T&& move-semantics-enabled constructor overload to RegExpected<T>.

WinReg v6.0.0 Header-only Stable Release

The main difference between the previous stable release and this one is that here non-throwing methods TryGetXxxxValue (e.g. TryGetDwordValue) return RegExpected<T> instead of std::optional<T>. In fact, in case of errors, std::optional looses the error information, while RegExpected<T> stores it.

WinReg v5.1.1 Header-only Stable Release

This bug-fix release proper handles the case of zero-length binary data in the Registry.
I also improved code quality, using std::vector::data() instead of &v[0] to get a raw C-style pointer to the underlying array (used e.g. for interop with Win32 C-interface Registry APIs).

WinReg v5.1.0 Header-only Stable Release

Added methods like TrySetDwordValue, TrySetQwordValue, etc. that, on failure, return an error status instead of throwing exceptions.
(Note that the previous exception-throwing methods are still available in this release, as well.)

WinReg v5.0.1 Header-only Stable Release

Used LSTATUS instead of LONG to represent the type of error codes returned by Windows Registry APIs.