`com_ptr::addressof` method?

[tom-huntington]

Most D3D APIs take a T *const *ppT parameter (i.e. an array of pointers). With WRL::ComPtr you could use GetAddressOf to get the argument to parse. C++/WinRT's com_ptr::put releases its reference before passing you a pointer to what it owns.

Which is safe, but this means you have to do the following dance when parsing only one pointer

auto pSrv = m_srv.get();
context.VSSetShaderResources(0, 1, &pSrv);

which is unnecessarily verbose, as you could provide

template <typename T>
struct com_ptr
{
    type* const* put_const() const noexcept
    {
        WINRT_ASSERT(m_ptr);
        return &m_ptr;
    }
}

context.VSSetShaderResources(0, 1, m_srv.put_const());

[sylveon]

I would argue against this because:

• put const doesn't make it obvious to the reader what is happening here. The code is not actually putting anything.
• it is inconsistent that all put methods releases the pointer, but this one doesn't

I'm not opposed to the idea, but it would need a different name.

[tom-huntington]

Since every variable is a length one array maybe as_const_c_array. This might be a bit inconsistent with the existing as/try_as methods. view_as_const, const_view?

Feel free to close if this is more bikeshedding than it is worth.

1-1 functionality with WRL::ComPtr would be nice though.

[sylveon]

Something like addressof() would work better - and it's also the name used by wil. Have you considered using wil for your com_ptr?

Also I will point out that WRL::ComPtr's operator& does release the held object as well, according to docs.

[kennykerr]

I believe the WIL version has a lot more bells and whistles.