We’re back with the third installment of C9::GoingNative.
At the recent //BUILD conference, we introduced a series of technologies targeting the upcoming version of the Windows platform. One of those consists in some extensions to the C++ language, intended to help developers bridge their C++ logic to the Windows Runtime (WinRT) environment.
C++/CX (the name of these extensions) is a lightweight syntax for COM creation, being COM the framework that allows components written in different languages to interoperate in Windows. In practice, it allows the user interface to be designed with ad hoc tools like MS Expression (XAML) or any HTML5 editor, while adding application behavior in C++.
The reception of C++/CX is mixed so far. It’s being appreciated for those developers who considered COM a complex technology despite its usefulness. It’s not much liked by developers who dealt with COM or the Active Template Library (ATL), an abstraction layer to make COM creation easier.
These last ones asked about an approach that doesn’t involve non-standard language extensions but an API that encapsulated COM complexities. Such API is called Windows Runtime Library (WRL) and follows the principles of ATL, re-implementing those for the Windows Runtime though.
In this episode, we interviewed Sridhar Madhugiri, one of the authors of the WRL, who answered for us questions like When would you use WRL? Why would you use WRL? How do you use WRL?
Prior to that Tarek Madkour, a leader on the VC++ team, shares some wise perspectives on modern C++ for Windows 8 (Metro style apps). Enjoy this episode!!
I heard that WRL will only be accessible to Windows Store applications.
Is this true?
WRL is a alternative technology to C++/CX for building Metro style apps, whether they are in the store or not.
Thanks,
Diegum
Diegum,
There´s any chance of more C++11 features suppport with the final build of Visual Studio ?
Can use C++/CX to replace ATL in non-WinRT application for simplified COM operation ?
Must one use script to do layout or may one use real, compiled-to-he-man-bits code to do layout?
For crying out loud.
That's not c++ it's c++/cli. Managed .net crap.
Microsoft just wants to lure more devs over to .net, and this is the transition drug. Disgusting !
Please stop this already.
You should have spent more time on the c++11 features then this but as we all know your prioritization is messed up.
@James:
It is neither. That was actually made pretty clear in this video (if you'd bothered to watch it) and quite a few other places.
It is not CLI, it does not load or use the .NET runtime *at all*.
It is a proprietary nonstandard C++ dialect which reuses C++/CLI syntax, but is used to interop with WinRT, and not .NET.
I too disagree with their prioritization, but let's stick with the facts, shall we? This is not in any way a gateway drug to .NET, because it is 100% unrelated to .NET.
@jalf If I may, I was thinking about it for a while and I think that MS will ditch .NET in near/not so near future, but they want their users to stay with them. That's why this familiar to them syntax. There is over 6 millions of C# devs at the moment. Microsoft wants them and in order to keep them and make their transition from 'will be ditched' technology to 'this is new hot stuff' there introduced this syntax. As everyone of us already knows there is no C++11. Why? Just guessing but again, those C# devs aren't bothered by not having C++11 stuff. What they need is familiar syntax so they can start using new technology. And C++11 will be implemented… who cares!!! Those losers (I'm amongst them) who program in C++ are not their (MS) problem. MS has loyal C# crowd and needs to accommodate them.
I think the primary inflammatory factor is that MS is advocating the use of the C++/CX extensions in .cpp and .h files. Herb Sutter has advocated limiting the C++/CX to a thin interoperability layer, which seems prudent to me, but when C++/CX and ISO-C++ use the same file extensions, it makes it very likely that the extensions (or at least, dependencies on them) will find their way into otherwise standard code. If MS introduced a new file extension like they did for C# (.cs), I don't think anyone would care.
@S. Colcord:
"If MS introduced a new file extension like they did for C# (.cs), I don't think anyone would care."
I think there are two distinct reasons people are up in arms:
1. Almost complete lack of progress on C++11, which is very desired.
2. Yet another extension to C++, which many (me included) don't want.
People feel betrayed due to 1, disappointed due to 2 (various reasons: many see the new language extensions as another attempt at vendor lock-in, many think that the extensions are not sufficiently justified as simply packing the relevant functionality into a clever set of C++ libraries would do the job much better, many are non-plussed by the fact that this set of extensions is no less than a third, with the previous two sets not doing very good in terms of support and adoption, etc), People also feel appalled by Microsoft's attempts to paint the combination of 1 and 2 as 'C++ renaissance' (there's very little C++ in there).
If Microsoft would introduce a new file extension and change their rhetoric for 'C++ renaissance' to 'C++/CX renaissance', that would perhaps solve the third issue (less people feeling appalled), but not the former two.
@Alex Ionescu: yesterday, Dr. Dobb's published an interview to our C++ Principal Architect Herb Sutter. He reiterates what he told last month during the //BUILD conference (that while the next release won't include variadic templates and other C++11 features, you won't have to wait for a whole release cycle to get those).
@jerry7: No. The extended syntax is restricted to Metro style apps.
@Jerimiah: XAML and HTML5 are the two core technologies for layouting components in Metro style apps.
@James: jalf is right. This is neither .NET nor an attempt to lock you in: the extended syntax helps you build WinRT components without falling into the details of the Windows component architecture (COM). C++/CX is not more proprietary than COM.
Your opinion about our prioritization (widely shared by others) is legitimate, though. Let me ask: if we announced the Metro style programming model with only .NET and JavaScript as alternatives, but not C++, would we have avoided the discomfort? I’m just curious because the Windows Phone 7 tools we released hadn’t considered native development and that wasn’t well received either. By then, our coverage of C++0x was good enough. Looks like every time we choose we’ll get people unhappy. The good news is that new C++11 won’t have to wait until VC++ v12 (check my answer to Alex).
@Knowing me: not at all. No conspiracy theories apply here. In fact, C++/CX was pretty well received by .NET developers who were glad to see that they can learn C++ (both, ISO and our extended syntax) as they feel that they could get more of their code running “on the metal” (Check these tweets: 1, 2, 3, 4). This doesn’t mean an end of .NET either; I consider important this clarification because I found people concerned in the .NET camp about whether the C++ Renaissance meant an end of managed development. That’s totally wrong as well.
@S. Colcord, @PleaseFixYourBugs: interesting thoughts both of you. Check the 2nd paragraph in my answer to James, though: if we shipped C++11 features but no way to make Metro style apps in the upcoming Windows 8, wouldn’t the community feel “betrayed” as well?
@Diego Thank you for your answer.
But just to clarify, I didn't mean that it is some conspiracy theory. What I meant is that policies are made in order to ease shift for C# programmers to native coding (which I do not see as a bad thing by the way).
No conspiracies – just politics.
@Diego: "…if we shipped C++11 features but no way to make Metro style apps in the upcoming Windows 8, wouldn’t the community feel “betrayed” as well?"
To be clear, I have no objection to the existence of the C++/CX extensions. However, I do feel that it was inappropriate to enable the extensions by default in normal C++ code. Microsoft should have used a different file extension for C++/CX header and source files to avoid the risk of confusing C++/CX code with ISO C++.
@Diego Dagum – MSFT:
"…if we shipped C++11 features but no way to make Metro style apps in the upcoming Windows 8, wouldn’t the community feel “betrayed” as well?"
If you did this, people would be unhappy too.
I am not sure what you are trying to get to: that whatever you do, someone would feel unhappy, and thus you are partly or entirely justified in ignoring the outcries? If so, I find this line of reasoning unappealing. Outcries are different. This particular outcry is very valid, you did manage to fool C++ developers into believing you are working on C++11 while you were working on something else completely (something that many of us actively *don't* want, too). People who think you have betrayed them are justified in doing so.
@Knowing me: sorry for my confusion. It may be understood like the intention was to make easier for .NET devs to build COM. In fact was not thinking on .NET devs in particular but also the many C++ devs -so devs in general- who found COM way too complicated, even with ATL (which shorten the lines of code count but doesn’t hide completely some details, so you need to learn COM anyway). .NET devs still need to learn ISO C++ for the components core (STL, by-value vs. by-reference, probably also concepts like RAII, etc.), because the /CX extensions make sense just for the interop part.
@S. Colcord: crystal clear.
@PleaseFixYourBugs: I’m not justifying the lack of much C++11 progress with that question. If possible, I’d like you to be more explicit in what you say that “you did manage to fool C++ developers into believing you are working on C++11”. I got some news from the VS Debugger team about the bugs we filed. The one that had been fixed, they are at this time investigating what failed in the process as they reconfirmed me that the fix should have been shipped in the CTP. Will keep you posted. About the other one, I’m procuring them to explain better in the proper place (the Connect bug) the reasons they decided to keep it in the backlog.
@Diego Dagum – MSFT:
"If possible, I’d like you to be more explicit in what you say that “you did manage to fool C++ developers into believing you are working on C++11”."
Sure. We had a new version of the C++ standard approved. At the same time you were talking about having 'C++ renaissance'. Naturally, me and I suspect everyone else thought part or all of that C++ renaissance was support for the new standard. This isn't rocket science.
I see. It was unfortunate that we couldn't do more C++11. Yet, the "C++ Renaissance" wasn't meaning "we promise C++11 conformance in the next version" but rather "C++ is stopping being a 2nd class citizen in Visual Studio -little or no tool support, absent in several parts of the Windows platform", etc.
I propose you to move forward on this point. I don't consider much justice that our lack of progress in one area -which we admitted and are working to resolve- invalidates the progress we are doing in several others that also make the experience of C++ development in Visual Studio.
Btw, the debugger team told me that they see the bug that had been fixed already implemented in the Developer Preview. I'm just confirming that same with the VS11 Dev Preview (I mean, the version that doesn't come included in the Windows 8 Dev Preview). Are you trying with that same?
@Diego Dagum – MSFT:
I have been able to see both problems using the Developer Preview almost immediately in my work project. I will recheck if the problem you say you fixed happens with the exact code that is in the bug report.
On a larger topic:
"I propose you to move forward on this point. I don't consider much justice that our lack of progress in one area -which we admitted and are working to resolve- invalidates the progress we are doing in several others that also make the experience of C++ development in Visual Studio."
Fine, let's move forward. What are the areas where you made progress as regards the experience of C++ development in Visual Studio?
* C++/CX? I am not interested.
* Several bells and whistles in the UI, like the merge of Solution Explorer and Class View (you can expand a file and see a list of classes in that file)? I am not interested in this either. In fact, I am more interested in whether I will be able to turn this off, since I am worried about the performance on real-world projects.
* The performance of the IDE? I don't see any improvements in the developer preview. I hope they are coming.
* The new help engine, rewritten once again? Gasp, I wish you stopped wasting time on this. You rewrite the help engine again and again and again, removing things like Index, then adding them back, removing the offline client, then adding it back, yet never solving the long-standing problems like totally useless search. Stop the rewrites already.
So, what's left, C++ AMP? Well, we already use both CUDA and OpenCL, both are far superior to C++ AMP in all respects save for integration into the language (where C++ AMP is on par with them), but I agree C++ AMP is something that could potentially be useful.
You see? You are doing stuff I and my team just aren't interested in. Now, not all C++ developers are the same, and I accept that there might be C++ developers who are glad you are doing C++/CX. I don't think there are a lot of them though. And there's nothing else apart from C++/CX and C++ AMP. Everything else is either too little and gimmicky (Find & Replace dialog is now a docked line at the top of the text editor window, big deal), or is a promise (performance, add C++11 here as well if you want).
Look, Diego, I understand that it might be tiring for you to keep reading my negative posts. Please believe that the situation is at least as tiring and frustrating for me as well.
In the year or so since I started commenting on this blog there was very little positive about VS. Me and my team continue to suffer from bugs, we had a service pack which fixed more or less nothing. Our hopes for more complete support for C++11 have been thoroughly shattered, you are rolling with extensions to the language which we don't want, you promise this will get better before VS12, but, frankly, if that ends up being just variadic templates (which you claim you have more or less done) and nothing else, half-year after the release of VS11, that's still too little and too late. The only hope that we still hold is that you will improve the performance of the IDE, and given that the developer preview doesn't seem to improve on that front at all, this hope starts fading too.
This is what it looks like from this end. :-(
@Diego/VS Team
Just (and please take this as constructive criticism) – as I've explained to Tony Goodhew some time ago, in order to stay on top of C++ game I had to stop using VS and for a while now I'm using GCC 4.6 with code::blocks as an IDE. Just before few minutes ago I've started VS11 developer preview. You know what? Before, it wasn't that obvious (although still noticeable) but now, after using code::blocks for a while, **icons in VS are terribly blurred**. Same for font on start page. Run code::blocks then your product and compare for yourself. In code::blocks everything is crystal clear. In VS on the other hand blurry. What a shame.
Ok, one last post from me in this discussion. I'll try to avoid rehashing the same old arguments, but I'd like to try to summarize the main problem as I see it:
(And one a side note, I suggest we leave complaints about the IDE or the help system out of this discussion, since those are handled by different teams. We're talking to the VC++ team, so let's discuss VC++, not Visual Studio as a whole)
It's nice to hear that your team is working to catch up on C++11 support, but we were told the same thing two years ago. And five years ago, we were told the same thing about C++03 support. So what has changed? Is the team going to hire more compiler developers? Are they going to sacrifice other things to focus more on C++11? For how long? Which features might be added before VC12? We don't know.
And when we don't know, we have to extrapolate from what we do know, which is that in the last two years, the team has found room to work on *one* new feature, and a bit of polish on existing ones. And if we include the development of VC10, we get something like 4 features in 4 years. That's a feature per year, and the table posted by STL recently shows 27 red fields. Does that man we'll have C++11 support in 27 years? Even if we say that some of the features aren't important (call it 20 important features then), and that the team will work twice as fast from now on, that still means another decade. That's what worries me.
It doesn't bother me that variadic templates turned out to be more work than you'd anticipated. That's fine, no one can predict the future. What worries me is that this feature was apparently *all* that was being worked on for the last 2 years. You'd think, if VC11 was a priority, that there would be multiple developers working on multiple features in parallel. I'm worried about all the hints and allusions we're getting to the VC++ compiler team basically being a one-man show.
And I'm worried that this one-man show is being tasked with maintaining one language after another (not just C++/CLI, C and C++, but now also C++ AMP and C++/CX), *while also implementing C++11*. Despite the C+ renaissance talk, it's easy to get the impression that where the C# team has 10 people working on the compiler for one language, the VC++ team is more like one person working on a compiler for 10 different languages.
I honestly think C++/CX and WRL together make up a pretty good strategy for WinRT interop (although the way it was communicated at /Build// was pretty lousy, and seemed custom-tailored to upset C++ developers), but it worries me that a team that was falling behind *before* is now given yet another language to maintain.
The VC++ team can't work miracles, and it seems like they're not given the chance to succeed. That's not @diegum's or any other VC++ team member's fault, but that doesn't make it any less worrying to us.
@jalf wrote: "You'd think, if VC11 was a priority, that there would be multiple developers working on multiple features in parallel. I'm worried about all the hints and allusions we're getting to the VC++ compiler team basically being a one-man show. "
To be fair, there's also STL working on the library side, but I think this concern is well-grounded. Microsoft has shown that when it considers something a strategic priority, it can focus resources on it and get it done; Internet Explorer appears to have had a genuine renaissance over the last few years. If there's really going to be a "C++ Renaissance", they'll need to do something similar for the C++ compiler.
@S. Colcord: yeah, sorry if it wasn't clear, but i was talking solely about the compiler/core language stuff.
The library side of things seems to be in much better shape. :)