Under the covers with C++ for Metro style apps

Thanks for an informative low key lecture which helped me understand better how things work in WinRT.   One typo is that your title should be Principal Architect. 

Excellent lecture.

BTW: At about minute 57th, you showed that all C++ exceptions (caught by "catch(...)") are mapped to COM generic failure E_FAIL HRESULT. Why don't catch std::bad_alloc separately and map it to the more meaningful E_OUTOFMEMORY?

Thanks.

Thanks!

Definitely considered catching std::bad_alloc, but the main problem with that is that if we change it to E_OUTOFMEMORY on the boundary, and you have a C++ client on the other side - do we throw E_OUTOFMEMORY as OutOfMemoryException^ (that can be easily caught by the base 'Exception^' and you can get ->HResult on that), or throw is as std::bad_alloc again? (Which will then be an orthogonal exception that have to be caught separately).

We've considered ideas like deriving std::bad_alloc from OutOfMemoryException, but that's also a fairly unnatural act.

Either way, thanks - this is valuable feedback - we'll continue to evaluate options surrounding this.

4 hours ago

Thanks!

Definitely considered catching std::bad_alloc, but the main problem with that is that if we change it to E_OUTOFMEMORY on the boundary, and you have a C++ client on the other side - do we throw E_OUTOFMEMORY as OutOfMemoryException^ (that can be easily caught by the base 'Exception^' and you can get ->HResult on that), or throw is as std::bad_alloc again? (Which will then be an orthogonal exception that have to be caught separately).

We've considered ideas like deriving std::bad_alloc from OutOfMemoryException, but that's also a fairly unnatural act.

Either way, thanks - this is valuable feedback - we'll continue to evaluate options surrounding this.

Considering that C++ exceptions (in the "classical" meaning, i.e. simple C++ classes, like those in std::exception hierarchy) can't cross module boundaries (or at least it's not safe to throw C++ exceptions out of module boundaries), I'd do it as follow:

- catch std::bad_alloc separately from the generic catch(...) and map it to E_OUTOFMEMORY HRESULT on the boundary

- to the C++ client on the other side: throw E_OUTOFMEMORY as OutOfMemoryException^.

The client can catch it by both base Exception^ and get a more meaningful HRESULT (E_OUTOFMEMORY instead of less-meaningful E_FAIL), or can directly catch OutOfMemoryException^.

I think if you swallow std::bad_alloc in generic catch(...) and map it to E_FAIL you are "killing" some important information (i.e. an allocation failed).

My 0.02€.

Thanks.