Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Under the covers with C++ for Metro style apps

Download

Right click “Save as…”

Slides (view online)
In this talk, you'll go deep into the new C++ for Windows Runtime, meet with some of the developers on the compiler teams that designed the language extension for C++, and open the lid to see the wiring the compiler provides. We’ll discuss the new C++ for Metro style apps, including the syntax, the performance characteristics, the compilation model, and more. If you're a C++ programmer, don't miss this talk!

Follow the Discussion

  • 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. 

     

  • C64C64

    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.

     

  • Deon BrewisDeon Brewis

    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.

  • C64C64

    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.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.