none
Is there a way for both the native C++ API and the managed C++\CLI API wrapping it to have the same names of namespaces and classes RRS feed

  • General discussion

  • Hi guys,

    Asked this over at stack overflow.

    For your consideration.

    http://stackoverflow.com/questions/25021421/is-there-a-way-for-both-the-native-c-api-and-the-managed-c-cli-api-wrapping

    Thanks in advance. Please feel free to point me at a managed C++ / CLI steering committee so I can suggest the feature if what is requested is not currently possible.

    Thanks in advance for any assistance.

    Best regards,
    Steve.
    Wednesday, July 30, 2014 10:21 AM

All replies

  • Hi Steve,

    I look through the discussion on your stackoverflow thread, in my opinion, I also don't recommend writing the same managed and native class into the same namespace.

    So I think this issue can be changed to general discussion type in order to involve more members who are intersted in this topic to join this discussion and provide their advices.

    May


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, July 31, 2014 8:00 AM
  • Thanks for your time & input, May.
    With respect, you are free to want to style your code class/namespaces your way.

    I'd like to code mine my way. In the meantime, I'll use the workaround of different namespaces.

    The language (managed C++/CLI) appears to currently have a restriction preventing me from being able to present identical interfaces across multiple languages. I think this is something that should be addressed.

    Hence, I'd appreciate the issue being raised with the managed C++/CLI steering committee (or whatever the name of the team is who consider the evolution of this interface).

    Thanks in advance.

    Best regards,
    Steve.
    Thursday, July 31, 2014 10:35 AM
  • FWIW, what I do is use the same namespace, but prefix all the managed class names with "Man"

    MyClass -> ManMyClass

    etc. Combined with a using directive this allows me to avoid namespace qualification in the C++/CLI wrapper code, and see at a glance whether a given class name is unmanaged or managed (which can get confusing when you have callbacks as I do in my case).

    Of course this imposes the "Man" prefix on the C# client, but this can be "fixed" by means of using statements:

    using MyClass = MyNamespace.ManMyClass; // C#


    David Wilkinson | Visual C++ MVP

    Thursday, July 31, 2014 11:21 AM
  • Thanks, David but I've escalated this so it can be addressed properly, even if it does take a while. Can use a workaround in the meantime, but looking forwards to a clean solution that enables identical namespace/class names in c++ and c#.

    Regards,
    Steve.
    Thursday, July 31, 2014 11:30 AM
  • "The language (managed C++/CLI) appears to currently have a restriction preventing me from being able to present identical interfaces across multiple languages"

    That's not a restriction, that's simply how the language works. It doesn't matter if a type is native or managed, it's a type and you can't have 2 types with the same name in the same namespace. It would be impossible to distinguish between them.

    "Hence, I'd appreciate the issue being raised with the managed C++/CLI steering committee (or whatever the name of the team is who consider the evolution of this interface)."

    There's no such committee. For all intents and purposes the C++/CLI language can be considered frozen, there's no chance that MS will waste time working on C++/CLI in the foreseeable feature.

    Thursday, July 31, 2014 1:46 PM
    Moderator
  • So a design restriction on windoze then. Noted.

    Clean designs are not wasting time but your company, you work on what you please.

    Sounds like you're saying the suggested syntax :

    native[MyClass] *m_native;

    Won't work because there would still be a namespace clash in the assembly or final dll.

    Ok. Is what it is. Thanks for the feedback.
    Thursday, July 31, 2014 1:49 PM
  • so a design restriction on windoze then. noted.

    will hack mono to work the way I want when I have time to look at it.

    clean designs are not wasting time but your company, you work on what you please.

    Personally I do not regard using the same name to mean different things as clean design, rather confusing design.

    In fact I cannot believe that you really want to use the same name within your C++/CLI wrapper code. I suppose it might be nice if the managed classes could be exported under aliased names (which could be the same as the unmanaged names) without conflict, e.g. rather than

    public ref class ManMyClass
    {
      //  wrap MyClass
    };

    we might write something like

    ref class ManMyClass public MyClass
    {
      // wrap MyClass
    };

    But to me it is really not that important.


    David Wilkinson | Visual C++ MVP

    Thursday, July 31, 2014 2:13 PM
  • you're right that it's really not that important. it's the icing on the cake that make you able to take a step back and say, yeah - that's done. it does everything someone might reasonably want it to.

    I am going a little OCD on this. if the namespace in C# has to be slightly different from it's  C++ equivalent, who cares ?

    Microsoft in one. microsoft in the other.

    make porting oh so very slightly more complicated, but anyone who can't get their head around such a tiny difference isn't likely to be much of a porting engineer anyhow.

    so, maybe you're right. not worth the effort.

    but would be nice for it to just work.

    native[MyClass] *m_native;

    or some such qualifier to resolve the ambiguity would work unless a namespace clash would still result in the final binary/assembly or however it works under the hood.

    you're right. I've spent to much time on this already. going to let it go. for now anyhow.



    Thursday, July 31, 2014 2:19 PM
  • I fail to see the purpose of this question. Doesn't this completely undermine the purpose of having namespaces in the first place? Namespaces, after all, are meant to establish uniqueness, and to disambiguate entry points.
    Thursday, July 31, 2014 5:34 PM
  • I fail to see the purpose of this question. Doesn't this completely undermine the purpose of having namespaces in the first place? Namespaces, after all, are meant to establish uniqueness, and to disambiguate entry points.

    The OP wants the managed C# interface (which uses the wrapper) to have the same names as the unmanaged C++ interface (which uses the native code. For example

    C++: MyNamespace::MyClass::MyFunction()

    C#: MyNamespace.MyClass.MyFunction()

    If this were easy to achieve (for example by aliasing the names of the exported managed classes in the C++/CLI managed class library, as I suggested above), I must admit I would do it.


    David Wilkinson | Visual C++ MVP

    Thursday, July 31, 2014 8:18 PM
  • So, more of a proposal than an answer.

    How about this :

    namespace MyTech
    {
       class Foo  // implicitly MyTech::native::Foo
       {
            public:
                Foo() { m_var = 1.0f; }
                float m_var;
       };
    
       public ref class Foo  // implicitly MyTech::managed::Foo because of ref.
       {
          Foo(native::Foo *native)  
          {
             m_native = native;
          }
    
          native::Foo *m_native;
       };
    }

    and could write class managed::Foo instead of ref class Foo

    .. and dump that ref from the syntax as it's confusing to have two ways to specify the same thing.

    feel free to adopt/ignore/comment.

    Friday, August 1, 2014 4:41 PM

  • feel free to adopt/ignore/comment.

    This makes no sense to me. It appears you have introduced a new keyword native. Then you use it like an object:

    m_native = native;

    IMHO this completely messes up what was a clean syntax. Thumbs down. (remember you asked for my comment)


    • Edited by Brian Muth Saturday, August 2, 2014 12:05 AM
    Saturday, August 2, 2014 12:04 AM
  • Hi Brian,
    Frankness & comment appreciated - that's the way to reach an optimal solution.

    I thought about introducing a new keyword, my original proposed syntax was :

    [proposal 1]  native[MyNamspace::MyClass] *m_native;

    then decided a namespace postfix might be cleaner :

    ie.

    [proposal 2] MyNamespace::navite::MyClass *m_native


    The fact I have also selected variable names with the same identifier as the proposed implicit namespace postfix or type qualifier could be confusing to some, I suppose, but the compiler would not have a problem with it. native is not a reserved word where the compiler is looking for a variable, only when considering namespaces or type declarations. In essence this is a compiler issue. The rest likely 'just works'.

    Saturday, August 2, 2014 10:16 AM
  • re: your coding style critique - could do something like this instead if the pepperings of native are not to your taste :

    m_my_unmanaged_instance_ptr = unmanaged_instance_ptr;

    Saturday, August 2, 2014 10:19 AM