locked
Is there a way to avoid the C++/CLI-like syntax?

    Question

  • Ok, I really love that WinRT is native and may replace the need to use the Win32 functions. However...

    I can't get past the fact that we are using this ugly hack that is the C++/CLI syntax that's inbound with the Component Extensions. When I code in C++ I want to code in C++, not some dialect of it.

    Why can't Microsoft just give a plain C++ library, with headers encapsulating the com classes? Why not return a std::smart_ptr<System::String> insted of forcing us to use System::String^?

    That's why I want to know. Is there a way to avoid this C++/CLI-like syntax and develop Metro and WinRT apps in plain standard C++ syntax?


    Homero Cardoso de Almeida
    Thursday, September 15, 2011 9:41 PM

Answers

  • Herb says it should be possible using WRL:

    http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-532T#c634517976543836549

    Friday, September 16, 2011 8:05 PM

All replies

  • Removing the /ZW option should disable the syntax.  There is an item for it in the C/C++ property page..."Enable Windows Runtime Extensions"
    Friday, September 16, 2011 2:29 AM
  • /ZW may disable it, but how would I write metro-style apps then?

     

    Someone mentioned WRL and low level COM calls, but we cannot find any examples of either in the MSDN documentation about metro released so far.

     

    If I do not use /ZW, what will my program be? Win32? Will it have to have a winmain or a regular main?


    Homero Cardoso de Almeida
    Friday, September 16, 2011 10:41 AM
  •  When I code in C++ I want to code in C++, not some dialect of it.

     


    Homero Cardoso de Almeida
    I think so!
    Friday, September 16, 2011 12:29 PM
  • "What the ^ have they done !?" was my initial reaction, however after getting more information, I'm starting to understand.

    Lets think this through:

    Why do we want to use WinRT ?

    1) Access to Metro and XAML GUI

    2) Ability to interact with other WinRT modules not written in C++.

     

    Why do we want to use standardized C++?

    1) Quality design through the standardization process.

    2) Portability from OS to OS.

    3) Performance.

    4) A known syntax.

     

    Now consider if those benefits would apply to using syntax only in C++11 for the WinRT interface?

    1) Maybe

    2) No, only Windows will support this interface.

    3) Same

    4) Yes, there is a new syntax to be learned.

    The Visual C++ reference for Windows Runtime documentation is preliminary, and available

    http://msdn.microsoft.com/en-us/library/windows/apps/br229567(v=VS.85).aspx

    I'm sure it would have been much easier for Microsoft to avoid having to change the C++ compiler to support this syntax.  Until I see what the interface would look like in C++, I have to give them the benefit of the doubt that this syntax is better for interfacing with WinRT.  I can still use just C++11 away from the GUI level.


    • Edited by Andrew7Webb Friday, September 16, 2011 1:13 PM
    Friday, September 16, 2011 1:10 PM
  • I'm sure it would have been much easier for Microsoft to avoid having to change the C++ compiler to support this syntax.  Until I see what the interface would look like in C++, I have to give them the benefit of the doubt that this syntax is better for interfacing with WinRT.  I can still use just C++11 away from the GUI level.

    Your #2 is misleading too.

    Yes, of course the WinRT code won't work on other platforms than Windows. But in cross-platform code, I typically want to minimize the amount of non-portable code. My Linux-only code can, for the most part, compile on Windows. I have to avoid including a few headers, sure, and I'll need to throw in a few #ifdefs, but it's C++, so I can share nearly all of it across all platforms.

    Can I do the same with these language extensions?

    And you're missing one or two reasons for sticking with ISO C++:

    5): I can use other compilers.

    What if I want to write a Metro application using MingW or Clang? Or, for that matter, Visual C++ 2008?

    Microsoft *could* have supported this very well. They didn't.

    6) Microsoft is making a big fuss of how WinRT integrates cleanly into *any* language. And yet they didn't integrate it into C++ *at all*. They could have designed their product to actually live up to the marketing hype. they chose not to.

    Why not?

    Friday, September 16, 2011 2:46 PM
  • Ian Griffiths has just written an introductory post about how to call WinRT objects using pure native code - i.e. without the C++ WinRT projection. 
    Friday, September 16, 2011 2:49 PM
  • Herb says it should be possible using WRL:

    http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-532T#c634517976543836549

    Friday, September 16, 2011 8:05 PM
  • Herb answerd my questions. However, I still don't understand why go to the length of giving us this ugly extension instead of a simple wrapper library to the WinRT COM-based objects.

    Sigh... Oh, well.


    Homero Cardoso de Almeida
    Friday, September 16, 2011 8:34 PM
  • Good points Jalf,

    I'm going to give WinRT a try, gather some more information, and keep an open mind.

    Of course Microsoft Developer Dev does not have much of an incentive to help other compilers.

     


    http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-690C

    Under the covers with C++ for Metro style apps

    • Date: September 15, 2011 from 9:00AM to 10:00AM
    • Day 3
    • TOOL-690C
    • Speakers: Deon Brewis

    Describes how to skip the new syntax if you really want to.

     

    • Edited by Andrew7Webb Saturday, September 17, 2011 11:59 PM
    • Proposed as answer by vxsery Wednesday, February 29, 2012 6:46 PM
    Saturday, September 17, 2011 5:20 PM
  • Hi guys. Let me see if I can clear this up a bit more.  As a developer you have basically 4 options for interacting with the Windows Runtime:

    1) The JavaScript projection.
    2) The .NET projection.
    3) The C++ "high level" projection, which makes use of WinRT language extensions.
    4) No projection at all, what we call "the ABI." No language extensions are needed.

    Option #3 will make a lot of sense for a great many C++ developers. You get to take advantage of the performance and control of native code, without having to learn COM, and with the ability to write much more succinct code. If you're a C++ developer I highly recommend you at least give this a shot. I was skeptical when I first saw it (what's the crazy hat thing?!?) but after playing with it for even just a few minutes, the advantages became pretty obvious. If you're a cross-platform dev, I expect you'll be asking for this on other platforms, versus wanting to get rid of it from ours.

    However, Option #3 is in the end syntactic sugar over #4. Writing directly to the ABI will feel most natural to seasoned COM developers. There's also a new template library (WRL) which someone mentioned earlier in this thread, which provides a lightweight set of utilities similar to what you may have used in ATL before (for example, ComPtr<>). It also includes several new helpers for things like async callbacks. And they're all template based (and very friendly to C++ 0x features like lambdas), so no language extensions are required.

    The "high level" C++ projection and the associated set of language extensions do exactly the same thing as the raw ABI plus the WRL templates. But the template solution can feel kludgey, especially to developers coming from the C# or Java world. By extending the language to be aware of concepts like refcounting and partial classes, you end up with something much more inviting to those developers, not to mention toolable.

    Oh, and one more difference between #3 and #4... the raw ABI is all HRESULT based. The projections (including the C++ projection) are exception based. This often means the projection is better suited for use with other exception-based libraries (like STL).  But if you're an exception-free shop, then the ABI + WRL is probably just the thing for you.

    Hope that helps. For more details, the various talks from //BUILD are the place to look. Also the DirectX sample on the dev center demonstrates usage of WRL and the raw ABI (actually, it seems to mix both, but still provides an example of using WRL). Also I just found a forum post by Herb Sutter which addresses this same question.

    Brandon

    Saturday, September 17, 2011 10:02 PM
  • I also don't like to use C++/CX syntax for the same reasons explained above. I saw some msdn directx examples where they mix WRL with CX extensions - see http://code.msdn.microsoft.com/windowsapps/DirectX-Marble-Maze-Game-e4806345/sourcecode?fileId=43833&pathId=1814339653.

    It seems like the WRL library allows one to write metro app in pure native C++. However its use brings another negative considerations:

    - HRESULT based api is not nice. Ideally I would like to use compiler generated wrappers which transform retval to return value and throw exception if FAILED(hr). Same as when using /CX. However this seems not to be possible. I would even accept properties to do that because they are already implemented in VS for a long time (through __declspec so no new extension is required here).

    - as Herb explains there is some minor performance problem when using ComPtr as a function parameter. Ref counter has to be both incremented and decremented and this can be avoided when using /CX extensions.

    - I am afraid that if I choose to use WRL instead of /CX I cannot use XAML designer and other MS tools because they will keep poisoning my WRL code with ref sealed ^ nonsenses. Or can they actually generate WRL compatible code?

     

    So although we have 2 options how to write C++ metro apps neither of them seems attractive to me as a C++ developer. Can somebody from MS comment on this?

     

    Monday, September 19, 2011 4:44 PM
  • Well outside of directly using COM code, the two choices would have been syntactic extensions or a wrapper-library. Neither of them would have felt as smooth as straight C++/COM. So between the two choices they picked a syntactic solution, and to me that seems like a better choice specially since the syntax they chose is already popular (loosely using the word) because of its similarity (nearly identical except or 1-2 keywords) with C++/CLI.
    http://blog.voidnish.com
    Monday, September 19, 2011 5:22 PM
  • why its not 'as smooth as straight C++/COM' ???

    I mean, even WRL is not necessary, you can always use the lowest level RoAPI, just like COM.
    WRL for WinRT is like ATL for COM. so what's the difference here ?


    http://msdn.microsoft.com/en-us/library/br205774%28v=VS.85%29.aspx

    http://msdn.microsoft.com/en-us/library/hh438466%28v=VS.110%29.aspx
    • Edited by TheCat666 Monday, September 19, 2011 7:08 PM
    Monday, September 19, 2011 7:04 PM
  • Jobs must be feeling happy now because MS has created a huge complicated non-human readable language/languages which will surely prevent developers from helping MS to compete with Apple. 

    shenzy

    Monday, November 19, 2012 4:53 PM
  • It is possible but frankly rather painful to completely avoid all use of C++/CX when consuming WinRT APIs. As noted above WRL is an option, so is writing everything by hand.

    You can isolate your WinRT usage from the rest of the application. You can even write shared code that potentially has 'dual-use' applicability. See <http://blogs.msdn.com/b/chuckw/archive/2012/09/17/dual-use-coding-techniques-for-games.aspx>

    Tuesday, November 20, 2012 10:00 PM