Asked by:
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- Moved by Jesse Jiang Monday, September 19, 2011 6:00 AM (From:Visual C++ Language)
- Moved by Steven - Support EngineerMicrosoft Support Wednesday, September 21, 2011 5:16 PM (From:Windows Developer Preview: General OS questions )
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 NOTC++ with the /cli option. Instead, Microsoft has added the CLI syntaxextensions 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, isstill 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 modulesare, apparently, managed code. There has to be magic to transition fromnative code to managed code. Rather than force you to write a /cli moduleto do that transition, the compiler now generates that for youautomatically.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 Metroapplications. If you want to write Metro applications, now you can do thatfrom a native C++ app, without worrying about manually partitioning yourcode into a native part and a CLR part.If you want to be disappointed that Metro is a managed technology, then Ithink you haven't been paying attention.--Tim Roberts, timr@probo.comProvidenza & 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 theperformance impact is negligible. What you have up there appears to be agraph doing all native code. The performance of that part will not changejust 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 codebefore it runs. People I trust tell me that the performance is prettyclose to native code. Transitions between managed and unmanaged can beexpensive, because you have to take extra care to marshal parameters backand 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, andtransition to native code for the hard work. Just the way Windows hasalways worked. People scoffed at the Windows API in the early days becauseit was a C interface. "Real programmers do their work in assembler!"You're singing the same song.--Tim Roberts, timr@probo.comProvidenza & 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.comWednesday, 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.comWednesday, 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.comWednesday, 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.roWednesday, 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.comThursday, September 22, 2011 5:25 PM -
Can I do this?
char * temp;
temp = (char *)malloc(25);
strcpy(temp,"Test");
String^ str1 = temp; ??
bfxtech.comThursday, 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.comThursday, 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.comThursday, 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.roC++ 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.roC++ 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- Edited by Nishant Sivakumar Friday, September 23, 2011 12:27 PM
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