locked
fake C++ for Windows 8 ?

    General discussion

  • Just looked at the first C++ examples for windows 8 metro and noticed it was

    used keywords like ref ? and namespace?  and this ^ means XOR  but its not being used that

    way. Hmm..OH this is not C++ its MS's C++. Compiled with the cli option. BUMMER.

    I was so excited when I read that C++ would be included in windows 8 and

    the new WinRT would magically work. Now I am not so excited and the slide showing

    that metro apps can be written in C++ is a false statement. It works with the non ISO MS version of C++.

    So my question is why bother saying Windows 8 works with C++?

    Neat marketing but VERY misleading. Why bother. Just say Windows 8 C# or code your own interface.

    Frustrating and disappointing, when will MS learn we dont code in C++ because its safe or

    simple but because it delivers the best performance and flexibility of any language with the

    lowest level possible overhead. 

    Anyway thumbs down on the Windows 8 slide.


    bfxtech.com
    Friday, September 16, 2011 2:25 AM

All replies

  • btasa wrote:
    >
    >Just looked at the first C++ examples for windows 8 metro and noticed it
    >was used keywords like ref ? and namespace?  and this ^ means XOR  but its
    >not being used that way. Hmm..OH this is not C++ its MS's C++. Compiled
    >with the cli option. BUMMER.
    >
    >I was so excited when I read that C++ would be included in windows 8 and
    >the new WinRT would magically work. Now I am not so excited and the slide
    >showing that metro apps can be written in C++ is a false statement. It
    >works with the non ISO MS version of C++.
     
    Actually, the situation is much more complicated than that.  This is NOT
    C++ with the /cli option.  Instead, Microsoft has added the CLI syntax
    extensions to the native compiler.
     
    >So my question is why bother saying Windows 8 works with C++?
     
    Well, you're talking about Metro and WinRT.  Windows 8, under the hood, is
    still Windows NT.  All the native apps that used to work, will still work.
    This new stuff is all to interface with Metro and WinRT.  Those modules
    are, apparently, managed code.  There has to be magic to transition from
    native code to managed code.  Rather than force you to write a /cli module
    to do that transition, the compiler now generates that for you
    automatically.
     
    I haven't decided yet whether I love this or hate this.
     
    >Frustrating and disappointing, when will MS learn we dont code in C++
    >because its safe or simple but because it delivers the best performance
    >and flexibility of any language with the lowest level possible overhead. 
     
    Well, if you want the lowest possible overhead, you won't be writing Metro
    applications.  If you want to write Metro applications, now you can do that
    from a native C++ app, without worrying about manually partitioning your
    code into a native part and a CLR part.
     
    If you want to be disappointed that Metro is a managed technology, then I
    think you haven't been paying attention.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.
     

    Tim Roberts, DDK MVP Providenza & Boekelheide, Inc.
    Friday, September 16, 2011 4:40 AM
  • Actually if you follow the developer forum for native/WinRT you will see that it is really native COM with C++/CLI like syntax (instead of CLI references, the ^s are actually COM smart pointers).   As to why they did that, I have no idea. 

    Personally I loathe programming COM, I was hoping for a REAL C++ programming library, not COM rehashed yet again.  (I suppose, it might be tolerable if it actually throws exceptions, but I will scream if I ever have to write "if (FAILED(hr))" one more time.


    • Edited by SimonRev Friday, September 16, 2011 1:56 PM
    Friday, September 16, 2011 1:53 PM
  • Maybe a simpler question could be answered.

    In the managed code world if I have 6 YUV HD DirectX surfaces and multiple DirectShow callbacks
    which feed my assembly language interpreters before I display them in realtime how would it fair when compared
    to C++?  

    These surfaces also interact with hardware callbacks for outputing.
    The display of these surfaces need to be realtime as well.


    The interface, buttons/bars/combo boxes etc., does not need to be high performance.

    It would fantastic to get ease of creating a WPF front end with all the glitz and glamor to work with this kind of 
    C++ high performance multi-threaded back half without effecting the realtime performance of the C++ code wouldn't it?

    In PDC 2009 the Microsoft DirectShow persenter said that managed code is more than 2x as slow as C++.
    So you can only conclude that WinRT and all its glamour will be not be for high performance bits and there is
    not a good way of making stylish front ends without rolling your own. (which I think is sad)

    Bob
    Ahh well maybe windows 9?


    bfxtech.com

    • Edited by btasa Friday, September 16, 2011 2:57 PM
    Friday, September 16, 2011 2:55 PM
  • This is all still new stuff, of course, but I think the use of similar syntax to C++/CLI for WinrRT makes it easier to use ultimately.  Obviously, writing code for WinRT will make it non-standard anyway so why invent another syntax?  It also makes it really apparent what the functions are being used for.  I don't think of it as "fake" C++, but more like an extension of C++ since all the core language stuff is still there.

    The fact that will have so much functionality in C++ for Windows 8 is really exciting imo.

    Tom

    Friday, September 16, 2011 4:24 PM
  • As to why they did that, I have no idea. 

    Well maybe because:

    I loathe programming COM

    Maybe they have done that to try to please you (and me also). ;)

    Not sure they SUCCEEDED(hr);


    Saturday, September 17, 2011 2:42 PM
  • btasa wrote:
    >
    >In the managed code world if I have 6 YUV HD DirectX surfaces and multiple DirectShow
    >callbacks which feed my assembly language interpreters before I display them in
    >realtime how would it fair when compared to C++?  
     
    If C# is just doing the plumbing -- gluing the parts together -- then the
    performance impact is negligible.  What you have up there appears to be a
    graph doing all native code.  The performance of that part will not change
    just because the graph happened to be created by a managed module.
     
    >In PDC 2009 the Microsoft DirectShow persenter said that managed code is
    >more than 2x as slow as C++.
     
    That's one person's opinion, but that's not what most people have found.
    Please remember that "managed code" is STILL compiled to machine code
    before it runs.  People I trust tell me that the performance is pretty
    close to native code.  Transitions between managed and unmanaged can be
    expensive, because you have to take extra care to marshal parameters back
    and forth.
     
    >So you can only conclude that WinRT and all its glamour will be not be
    >for high performance bits...
     
    Absoutely true.
     
    >...and there is not a good way of making stylish front ends without
    >rolling your own. (which I think is sad)
     
    Absolutely false.  You can use the fancy stuff for your front ends, and
    transition to native code for the hard work.  Just the way Windows has
    always worked.  People scoffed at the Windows API in the early days because
    it was a C interface.  "Real programmers do their work in assembler!"
    You're singing the same song.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.
     

    Tim Roberts, DDK MVP Providenza & Boekelheide, Inc.
    Saturday, September 17, 2011 7:43 PM
  • Hello,

     

    I think your issue should be raised in the Windows Developer Preview: General OS questions. I believe they will know more information of this issue than us, and I will move this one to that forum.

     

    Thanks for your understanding,

     

    Best regards,

    Jesse


    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, September 19, 2011 6:00 AM
  • I am a C# developer at heart but i'm real excited to see what you can do with C++/WinRT.  Like what was mentioned earlier, The WinRT apis does get compiled to native code. 

    Also, it IS possible to write a metro application without the c++ extensions (see here).  Just know that you will be writing 10x more code (if not more).

    Herb has a great video here that explains what the extensions do 'behind the scenes'. 

    For example, the Hat(^) is nothing more than a shared_ptr and the exceptions are nothing more than wrappers around HRESULT's.

    Monday, September 19, 2011 4:19 PM
  • After watching some of the channel9 videos made of the build conference, thanks MS, I am trying very hard to get my head around all of this. At first I was certain this was managed C++. Now after reviewing the video again it looks like it might not be.. Here is where the confusion starts.

    The new MS C++ takes some C++ 11. adds in new keywords like  ref ,namespace delegates and events and partial classes but its COM and ??  err umm some compiler twist ??

    This is what I got so far. Things I dont know.

    I dont know how char arrays can work with these string objects.

    I dont know how assembly intergrates.

    How can I convert information recieved from the Metro interface via delegates and events to

    array of strcuts and use pointers etc with it.

    There is so much I dont know and feel so lost on.

    I hope they do one day learning tours where we can ask questions with videos to watch before we go.

    With all the languages of the day MS has pushed (WPF, SilverLight, ASP.NET, C#, VB.NET,HTML 5 - JavaScript) and multiple XAML implementations, its near impossible to understand anything very well anymore.

    Is that the point?


    bfxtech.com
    Wednesday, September 21, 2011 4:30 PM
  • The language extensions for C++ are syntactic sugar that makes dealing with WinRT easier. However it isn't necessary to use those and you can write 100% standards compliant code that deals with the COM interfaces directly if you so choose.
    Wednesday, September 21, 2011 4:47 PM
  • I want to see more about that. Like how do I deal with a string object? Or those delegates? How about those Events? There is a lot more going on that just calling some funtions.

     


    bfxtech.com
    Wednesday, September 21, 2011 7:09 PM
  • I want to see more about that. Like how do I deal with a string object? Or those delegates? How about those Events? There is a lot more going on that just calling some funtions.

     


    bfxtech.com


    There is very little documentation available right now but watch Deon Brewis' session from Build where he goes into some behind-the-covers detail on C++/WinRT.

     

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


    http://blog.voidnish.com
    Wednesday, September 21, 2011 7:12 PM
  • C++/CX is just syntactic sugar. (Think about C# and how LINQ query expressions are just syntactic sugar for LINQ query operators.) It helps you write less code, but more readable code and be more productive. Isn't that we all expect from a programming language? Compiled C++/CX code translates to 100% C++ code. But the beauty is you don't have to care about all that verbatim code you'd have to write if you were targeting WinRT from C++, with COM wrapper, etc. So why is it so bad for you?

     


    Microsoft MVP VC++ | www.mariusbancila.ro/blog | www.codexpert.ro
    Wednesday, September 21, 2011 9:13 PM
  • @bfxtech,

    using namespace Platform;
    #include <string>
    // initializing a String^
    String^ str1 = "Test";// no need for L
    String^ str2("Test");
    String^ str3 = L"Test";
    String^ str4(L"Test");
    String^ str5 = ref new String(L"Test");
    String^ str6(str1);
    String^ str7 = str2;
    wchar_t msg[] = L"Test";
    String^ str8 = ref new String(msg);
    std::wstring wstr1(L"Test");
    String^ str9 = ref new String(wstr1.c_str());
    String^ str10 = ref new String(wstr1.c_str(), wstr1.length());

    // accessing chars into String^
    auto it = str1->Begin();
    wchar_t ch = it[0];

    // String^ is null terminated (but can contain L'/0', just like wstring)
    assert(it[str1->Length()] == L'/0');

    // String^ is immutable
    it[1] = L'A';// yields compile error C3892

    // initializing a std::wstring from String^
    std::wstring wstr2(str1->Data());
    std::wstring wstr3(str1->Data(), str1->Length());

     FROM:

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

    • Edited by Andrew7Webb Wednesday, September 21, 2011 10:05 PM
    Wednesday, September 21, 2011 10:04 PM
  • I am not saying WinRT is bad but trying to see how it all fits together and how existing complex applications can leverage or utilize it.

    Like I mentioned if I have an application that has 800MB/sec uncompressed YUV data and want to display it on a WinRT screen is it possible?

    Whats the limits? Is it easy to try? Where are the gottcha's. Its a natural question with anything new.

    If I already programmed and tested all the business logic and tokenizing using strings stored in char arrays (STL vectors or whatever)

    with a new interface can I keep my logic without a huge penalty? I noticed that all strings have to allocated with 

    "WindowsCreateString" (not sure this is the call) or some thing like that. Will that be real expensive with performance?

    In windows 8 how is the task switching improved? Is it? I think they spent a lot of time to make a new language extensions to

    make some cooler interface widgets that could have easily been placed in a library.


    bfxtech.com
    Thursday, September 22, 2011 5:25 PM
  • Can I do this?

    char * temp;

    temp = (char *)malloc(25);

    strcpy(temp,"Test");

    String^ str1 = temp; ??


    bfxtech.com
    Thursday, September 22, 2011 5:27 PM
  • Can I do this?

    char * temp;

    temp = (char *)malloc(25);

    strcpy(temp,"Test");

    String^ str1 = temp; ??


    bfxtech.com

    If you use wchar_t it would work just like that. But since you used char, you'd probably have to convert to wchar_t before passing to a String^ constructor.
    http://blog.voidnish.com
    Thursday, September 22, 2011 5:32 PM
  • Why would they not have an overload for something as basic as conversions?

    I mean GEEZ look at the number of strings and types.  

    char *, wchar_t*, _bstr_t, CComBSTR, CString, basic_string, and System.String.

     

    A suggestion to you Windows 8 folk.  You need a one stop covert class

    for C++ C# etc . In comes one thing and ToXXX. They always talk about

    reducing the messy code but simple string conversion still looks like this.

        char *orig = "Hello, World!";
        cout << orig << " (char *)" << endl;

        // Convert to a wchar_t*
        size_t origsize = strlen(orig) + 1;
        const size_t newsize = 100;
        size_t convertedChars = 0;
        wchar_t wcstring[newsize];
        mbstowcs_s(&convertedChars, wcstring, origsize, orig, _TRUNCATE);
        wcscat_s(wcstring, L" (wchar_t *)");
        wcout << wcstring << endl;


    bfxtech.com
    Thursday, September 22, 2011 7:13 PM
  • But the beauty is you don't have to care about all that verbatim code you'd have to write if you were targeting WinRT from C++, with COM wrapper, etc.


    Microsoft MVP VC++ | www.mariusbancila.ro/blog | www.codexpert.ro

    C++ is often used when you need performance.

    You don't generaly get performance if you "don't care about all that code".

    Thursday, September 22, 2011 9:18 PM
  • But the beauty is you don't have to care about all that verbatim code you'd have to write if you were targeting WinRT from C++, with COM wrapper, etc.


    Microsoft MVP VC++ | www.mariusbancila.ro/blog | www.codexpert.ro

    C++ is often used when you need performance.

    You don't generaly get performance if you "don't care about all that code".


    So far no one's profiled performance differences between C++/CX generated assembly code vs direct-COM generated assembly code. I'd be very surprised if the C++ team haven't made sure that there won't be any performance loss in using the C++/CX syntax. And a pre-beta is probably too early to be making such comparisons anyway.

    And if you are that concerned you can just use WRL (although at the moment there is zero documentation on that).


    http://blog.voidnish.com
    Friday, September 23, 2011 12:27 PM
  • As to why they did that, they investigated several options when building the C++ projection - they were either extremely confusing (using "*" instead of "^" to represent references for example) or they violated low level language constraints (using "." for example).  The "^" syntax was the best compromise that didn't break the language.

    Having written metro style apps using the C++ projection, it take a bit of time (an hour or so) to get used to "ref new" and "^" but then it seems really natural.

     

    Saturday, September 24, 2011 4:32 PM