locked
Portability to C++/CLI

    Question

  • Hello,

    I'm developing a WinRT component using C++ that makes use of DirectX. The code doesn't know anything about specific window types, that is done at a higher level. As much as possible, I'd like the code to be portable to C++/CLI for use in a corresponding .net component. One issue that immediately arises is that Metro style apps use ComPtr to wrap DirectX interfaces. Is it possible to use ComPtr in a .net assembly, or, is there a portable alternative to ComPtr that could be used in both C++/CX and C++/CLI?

    My second concern is about public interfaces. The .net version would expose standard .net interfaces from C++/CLI for use by any .net language. It would be nice to design things such that the C++/CX and C++/CLI public interfaces have the same signatures. Is this a feasible goal?

    Are there any other issues related to portability between WinRT/C++/CX and .net/C++/CLI that I should be concerned about?

    Any advice appreciated,

    RobertF


    • Edited by RobertHF Saturday, June 30, 2012 11:16 AM
    Saturday, June 30, 2012 10:13 AM

Answers

  • RobertHF wrote:

    Is it not possible to use the ATL library in a Metro app, if all I use is the CComPtr? That would give portability in the handling of DirectX interfaces.

    It may be possible to make atl work in a Metro app, but it's strongly discouraged because of WinRT is different.
    There is a video on Channel9 about WRL library where the speaker say that it may work.


    My original statement that I'd like the interface signatures to be the same was a desire rather than a strict requirement. I accept there would be two different code bases.  Rather, I'm looking to keep the differences to a minimum so that any new developments in one could be incorporated efficiently into the other.

    This is why I believe that the base C++11 dll is the best solution.
    You can specialize your code for WinRT and Desktop worlds using C++/CX and C++/CLI.

    I've got the beginnings of the component (around 20 classes) written for WinRT. Before I go much further with that, I think I'll port that to .net to get an idea of what's involved.

    There is absolutely no reason to write a ref class in WinRT if this is not exposed to the WinRT world.
    If you have a complex algorithm that use DirectX, you can write it by using C++ standard language (standard C++ classes).


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    • Marked as answer by RobertHF Saturday, June 30, 2012 8:19 PM
    Saturday, June 30, 2012 7:57 PM

All replies

  • RobertHF wrote:

    Hello,

    I'm developing a WinRT component using C++ that makes use of DirectX. As much as possible, I'd like the code to be portable to C++/CLI for use in a corresponding .net component. One issue that immediately arises is that Metro style apps use ComPtr to wrap DirectX interfaces. Is it possible to use ComPtr in a .net assembly, or, is there a portable alternative to ComPtr that could be used in both C++/CX and C++/CLI?

    My second concern is about public interfaces. The .net version would expose standard .net interfaces from C++/CLI for use by any .net language. It would be nice to design things such that the C++/CX and C++/CLI public interfaces have the same signatures. Is this a feasible goal?

    Are there any other issues related to portability between WinRT/C++/CX and .net/C++/CLI that I should be concerned about?

    Any advice appreciated,

    IMO, this is not the best approach.
    Even if the two syntax are very similar C++/CX and C++/CLI are totally different as the first target pure native code while the second target managed code (CLR).
    Remember that C++/CX ref classes are WinRT (super-powered COM) objects so they are subject to reference counting instead of CLR GC mechanism of the reference classes in C++/CLI.

    My suggestion is:
    - design a standard C++11 portable code that wraps DirectX library. This means using shared_ptr, unique_ptr, etc. as smart pointers and other STL goodies
    - create a Metro specific wrapper for this library using C++/CX dialect
    - create a .NET specific wrapper by using C++/CLI dialect
     At this point your target should be to keep the C++/CLI and C++/CX wrappers as smaller as possible.

    Another point arise now.
    DirectX and Xaml can be mixed now. I understand that you want to control the swapchain totally. In this case, consider to use Xaml for standard UI controls like buttons.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    Saturday, June 30, 2012 1:49 PM
  • Thanks Raffaele,

    Do I really need the extra layer of DirectX wrappers? I don't want to expose any DirectX functionality from my component. Any use of DirectX will be made internally. The interfaces that the component provides won't refer to any COM types, but to standard types such as int, double, etc., plus ref types that the component itself publicly exposes.

    All I want to do is use DirectX internally within the component in as portable a way as possible.

    Robert

    Saturday, June 30, 2012 3:10 PM
  • Hi Raffaele,

    After reading your post again, I think we're in agreement. It was your comment that my approach wasn't the correct one that threw me. Your suggestion to use STL smart pointers helps me. There will be a distinct metro and .net component, each with its own code base. I'd just like to keep the code as common as possible, and using STL smart pointers helps with that. However, I don't think I need to factor out any DirectX functionality into yet another component.

    My other question related to public interfaces and whether the Metro interfaces could be made to have as similar as possible syntax to the .net interfaces.

    The DirectX functionality I'll be using will be to create "islands of DirectX" within a standard C++ XAML application, rather than a full-screen DirectX app.

    Robert

    Saturday, June 30, 2012 3:33 PM
  • RobertHF wrote:

    Hi Raffaele,

    After reading your post again, I think we're in agreement. It was your comment that my approach wasn't the correct one that threw me. Your suggestion to use STL smart pointers helps me. There will be a distinct metro and .net component, each with its own code base. I'd just like to keep the code as common as possible, and using STL smart pointers helps with that. However, I don't think I need to factor out any DirectX functionality into yet another component.

    Agree. I do not intended to wrap DirectX as-is, but wrapping specific tasks of your app that you want to expose to both Metro and desktop worlds.

    Be aware that STL smart pointers are used for managing compile-time instances of classes AKA objects that are built with C++; while C++/CX implicit smart pointers (ComPtr) are used to manage WinRT objects, that are totally different beasts as they are most of the time only available as binary components.
     > My other question related to public interfaces and whether the Metro

    interfaces could be made to have as similar as possible syntax to the .net interfaces.

    When you talk about .net, you are talking about standard .net desktop applications or .net Metro applications?

    The DirectX functionality I'll be using will be to create "islands of DirectX" within a standard C++ XAML application, rather than a full-screen DirectX app.

    In this case you can simply create a WinRT component (dll) that can be referenced inside a Metro project (either .net or C++).
    When you create a WinRT component, this is immediately available to both the C++ and C#/VB Metro projects.

    Microsoft stated that they do not support the scenario where a WinRT custom component is used in a desktop application.
    Please note that many WinRT Microsoft component can be used in desktop applications so it should work also with your custom component but, I repeat, this scenario is explicitly not supported.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    Saturday, June 30, 2012 5:28 PM
  • On the issue of smart pointers, they would need to accommodate COM, so would it be possible to use ATL::CComPtr for portability?

    Re the interfaces, the .net functionality would be for desktop applications.

    Robert

    Saturday, June 30, 2012 5:47 PM
  • RobertHF wrote:

    On the issue of smart pointers, they would need to accommodate COM, so would it be possible to use ATL::CComPtr for portability?

    In the WinRT world, you would use WRL library, not ATL.
    Also, WinRT has a different type system, so you need to take this in account too.


    Re the interfaces, the .net functionality would be for desktop applications.

    In this case, I believe the most appropriate and clean solution would be the one I wrote in my first answer.
    As WinRT and .Net interfaces are shaped differently, there will be no way to have a single component that can be compiled for both worlds (unless those crappy macros that make the code unreadable ;) )


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    Saturday, June 30, 2012 6:15 PM
  • Is it not possible to use the ATL library in a Metro app, if all I use is the CComPtr? That would give portability in the handling of DirectX interfaces.

    My original statement that I'd like the interface signatures to be the same was a desire rather than a strict requirement. I accept there would be two different code bases.  Rather, I'm looking to keep the differences to a minimum so that any new developments in one could be incorporated efficiently into the other.

    I've got the beginnings of the component (around 20 classes) written for WinRT. Before I go much further with that, I think I'll port that to .net to get an idea of what's involved.

    Robert

    Saturday, June 30, 2012 7:26 PM
  • RobertHF wrote:

    Is it not possible to use the ATL library in a Metro app, if all I use is the CComPtr? That would give portability in the handling of DirectX interfaces.

    It may be possible to make atl work in a Metro app, but it's strongly discouraged because of WinRT is different.
    There is a video on Channel9 about WRL library where the speaker say that it may work.


    My original statement that I'd like the interface signatures to be the same was a desire rather than a strict requirement. I accept there would be two different code bases.  Rather, I'm looking to keep the differences to a minimum so that any new developments in one could be incorporated efficiently into the other.

    This is why I believe that the base C++11 dll is the best solution.
    You can specialize your code for WinRT and Desktop worlds using C++/CX and C++/CLI.

    I've got the beginnings of the component (around 20 classes) written for WinRT. Before I go much further with that, I think I'll port that to .net to get an idea of what's involved.

    There is absolutely no reason to write a ref class in WinRT if this is not exposed to the WinRT world.
    If you have a complex algorithm that use DirectX, you can write it by using C++ standard language (standard C++ classes).


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    • Marked as answer by RobertHF Saturday, June 30, 2012 8:19 PM
    Saturday, June 30, 2012 7:57 PM
  • Thanks Raffaele, you've given me some things to think about.

    Saturday, June 30, 2012 8:19 PM
  • RobertHF wrote:

    Thanks Raffaele, you've given me some things to think about.

    you're welcome!


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    Saturday, June 30, 2012 8:33 PM