fake C++ for Windows 8 ?

Question

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

Answer 1

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, [e-mail]

Providenza & Boekelheide, Inc.

 

---

Tim Roberts, DDK MVP Providenza & Boekelheide, Inc.

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

> 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);

Answer 6

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, [e-mail]

Providenza & Boekelheide, Inc.

 

---

Tim Roberts, DDK MVP Providenza & Boekelheide, Inc.

Answer 7

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.

Answer 8

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.

Answer 9

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

Answer 10

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.

Answer 11

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

Answer 12

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

Answer 13

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

Answer 14

@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

Answer 15

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

Answer 16

Can I do this?

char * temp;

temp = (char *)malloc(25);

strcpy(temp,"Test");

String^ str1 = temp; ??

---

bfxtech.com

Answer 17

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

Answer 18

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

Answer 19

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

Answer 20

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

Answer 21

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.