Add _bst user-defined literal for BSTR-shaped wide strings

[jonwis]

Reduce global initializers and intermediate allocations with a BSTR-compatible string literal.

// Unnecessary globals - 
const wil::unique_bstr g_bst(SysAllocString(L"kittens"));
const auto g_bst2 { wil::make_bstr_failfast(L"puppies"); };

HRESULT UseBstr(BSTR bst);
void call_bstr_function() {
    UseBstr(g_bst.get());

    // Unnecessary local allocation
    auto propName = wil::make_bstr_failfast(L"waffleCount");
    UseBstr(propName.get());

    // !!super mega ultra danger!! - not passing a real bstr...
    UseBstr(L"kablooie");
}

Instead, literals:

const auto g_bst = L"kittens"_bst;
const auto g_bst2 = L"puppies"_bst;

void call_bstr_function() {
    UseBstr(g_bst);
    UseBstr(L"waffleCount"_bst);
}

(Thanks Copilot!)

[dmachaj]

Do you need to guard against N=0? In that case this is getting the address of a zero-size buffer.

[dunhor]

Zero sized arrays are not valid in C++

[dunhor]

Add something like:

static constexpr const std::size_t size = N;

or a (constexpr) size() method to wchar_literal_storage so you don't need the manual length calculation

[dunhor]

Should also include a constexpr validation

[dunhor]

Consider: something like static_assert(offsetof(m_data) == 4)

[dunhor]

My personal expectation is that this would be _bstr, but I don't use BSTRs enough to know how common of an "abbreviation" this is.

[dunhor]

One thing worth mentioning is that "bst" could stand for "binary search tree" (not that that would make much sense for a user defined literal)

[dunhor]

Given that the typical usage will be something like using namespace wil::literals, it's probably best to keep these types outside of the literals namespace. (You probably also don't want to drop them in a wil::literals::details namespace, because that may then interfere with a consumer's details namespace).

I gave it a try and it seems as though there's no "gotchas" for moving the type definitions out: https://godbolt.org/z/enaKvGs4M. Note that I've kept bstr_literal_t "public" so that its name can be uttered without acknowledging the details namespace.

[dunhor]

Right now this has a minor foot-gun. E.g. the following will compile, but has UB since it refers to a buffer that is outside its lifetime:

BSTR foo = L"foo"_bstr;

One could argue this usage is unlikely - and I'd tend to agree - however I could see someone unknowingly running into this when assigning to member variables, fields of a struct, etc.

I can't think of any good standard ways to fix this without also breaking legitimate uses of r-values, however the non-standard lifetimebound attribute should at least be able to trigger a warning. E.g. somewhere near WI_NODISCARD and other definitions:

#if defined(__has_cpp_attribute)
#  if __has_cpp_attribute(msvc::lifetimebound)
#    define WI_LIFETIMEBOUND [[msvc::lifetimebound]]
#  elif __has_cpp_attribute(clang::lifetimebound)
#    define WI_LIFETIMEBOUND [[clang::lifetimebound]]
#  elif __has_cpp_attribute(gnu::lifetimebound)
#    define WI_LIFETIMEBOUND [[gnu::lifetimebound]]
#  endif
#endif
#ifndef WI_LIFETIMEBOUND
#  define WI_LIFETIMEBOUND
#endif

And then:

    WI_NODISCARD constexpr operator BSTR() const WI_NOEXCEPT WI_LIFETIMEBOUND
    {
        return const_cast<wchar_t*>(&m_data[0]);
    }

Example that has the warning and an ASan failure: https://godbolt.org/z/qf9qxWfzf