BUILD2011

Under the covers with C++ for Metro style apps

Download this episode

Download Video

Description

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!

Day:

3

Code:

TOOL-690C

Room:

Jolt

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • bdhc73a

      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. 

       

    • C64

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

    • C64

      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.

    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.