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.

WinReg v5.0.0 Header-only Stable Release

Added more convenient methods of the form TryXxx, that return an error status or a std::optional instead of throwing exceptions on error.
Also refined and improved the public interface of some existing methods like QueryInfoKey.

WinReg v4.1.2 Header-only Stable Release

Just removed a Visual Studio .user file from the repository.