VOLE 0.6.1 broken by bad STLSoft 1.9.53 - 1.9.54 now released

A VOLE user reported problems with compiling VOLE 0.6.1, which are a result of (i) my having released an incomplete STLSoft 1.9.53, and (ii) when using GCC, which does not define UDATE, some of WinSTL's conversion shims - specifically to_FILETIME(DATE const&) and to_SYSTEMTIME(DATE const&) - were not available.

Both issues are now fixed, with the recently released STLSoft 1.9.54.

VOLE 0.6.1 released

VOLE version 0.6.1 is released.

It now supports time return values, of types DATE (via the VOLE type date_t), FILETIME, and SYSTEMTIME, as in:

vole::object obj = ...
SYSTEMTIME updated = obj.get_property<SYSTEMTIME>(L"Updated");

VOLE 0.5.1 released

Version 0.5.1 of VOLE released.

Changes:

• renamed coercion level nonDestructiveTruncation to nonDestructiveCoercion
• added com_return_traits<float>
• added com_return_traits<double>
• changed behaviour for com_return_traits<bool>, com_return_traits<short>, com_return_traits<int>, com_return_traits<long>, com_return_traits<std::string> and com_return_traits<std::wstring>
• added test.unit.return_traits.builtins
• added test.unit.return_traits.std_types

The language that never ends ...

It has been said (alas, a reference escapes me at this time) that nobody can know all of C++.

Well, today I've just had another proof of it (not that I ever thought I knew all the language). Question: what's wrong with the following code?

  bool fn()
  {
    void* p = 0;

    return p;
  }

Answer: absolutely nothing. Yes, that's right, you can convert an "rvalue of arithmetic, enumeration, pointer, or pointer-to-member type" to an rvalue of type bool(C++ Standard: 4.12.)

Who'd a thought it?!

I found upon this because I'm changing the way some of the type conversions work in VOLE as part of the new functionality of version 0.5. As well as adding specialisations of vole::com_return_traits<> for float and double, I'm adding comprehensive (i.e. a cartesian product of from-type, to-type and coercion level) unit-tests for the builtins' specialisations. I thought that com_return_traits<bool> was too permissive, in allowing any of the basic integral types to be converted when the coercion level is naturalPromotion. Turns out I was wrong!