Very very interesting insights, thanks! Wish there was more podcasts like this one.
So, COM is alive, and COM is love.
It's a pity WTL is not supported anymore by Microsoft. I have used it once a few years ago, and then forgot about it. How about updating WTL? Lots of Windows 7 features are available as COM objects (Ribbon, Direct2D, ...), does it make sense to update ATL/WTL? Or will WRL take care of this?
Here are a few quotes I like, from the last messages:
Charles: The VC team is well aware that much better WRL documentation is needed and more samples that clearly demonstrate what they mean by C++/CX "boundary" layer programming with most of your code being ISO C++.
Charles: I for one (and I speak for myself only - myself only) think it's unfortunate that of all languages that can be used to program WinRT apps, C++ was the only one that was extended.
I couldn't agree more on this one.
Garfield: WinRT isn't really suitable to be exposed to C++; the model is too foreign to C++ even in CX garb. WinRT and C# are twins, which will never happen to C++, because it would require C++ to become C# with different syntax (C++/CX), but that will simply move the tension to the boundary with C++ uncomfortable with what is one side and WinRT (C#,CX) uncomfortable with the other.
WinRT is COM
Garfield: But I'm very concerned with foreign types and hats that will bleed outside and I don't see other alternative than a fence of native types to stop it. I'm assuming everybody agrees that WinRT types and hats have no sense in C++ applications and must be stopped at the boundary.
AFAIK, this is really not easy to do, and to do it right. It is very easy to misuse WinRT types and, for example, call IVector::GetAt(), which issues a COM call.
Jim Springfield: We believe C++/CX provides value and we are committed to it, but customers can always choose not to use it. We want to make it the best we can, but at some point the marketplace is the true decider.
Thanks for providing insight on the story of C++/CX.
This isn't really about you using multiple languages yourself in a single project - though it certainly could be the case that you would want to, say, build a UI layer in HTML5 (HTML + CSS + JS) and write the core application logic/algorithms in C++ or use XAML for the UI layer, etc... It's certainly possible, though somewhat far-fetched, that you would want to write an app that uses C#, JS and C++, but, implicitly, you probably will be doing just this: You will be consuming components across language boundaries (they could have been authored in C++, JS or C#...), many of which are not written by you... That's a key point.
I am talking about what I know, that is, creating consumer apps (in C++, although I've tried in C#, but I failed).
You are talking about 2 different scenarios where using multiple languages might be usefull:
- using a 3rd party library built in C# or C++ or JS. Well if I write C++ native code, I will certainly not hamper my app performance by using a 3rd party C# or JS library. The C# library would have to initialize a CLR, and that would consume a lot of resources. It doesn't make sense. And If I use a C++ 3rd party library, I would better use a ISO C or C++ API than a C++/CX API. I bet the 3rd party vendor has published his C++ library as a native C or C++ interface before he adds a C++/CX layer.
- building a user interface in HTML5 or XAML/C#. Well, I can use XAML interface in C++/CX right? Also, we've been trying for 4-5 years to create hybrid applications with WPF UI and C++ code. It has been proven it is not possible. The only hybrid app I know is Visual Studio 10, but Microsoft had to modify WPF to make it work, and invested a lot of energy in this project. Why would hybrid apps make sense now?
Really, I'm not interested in being able to use other language components.
I think C# or JS devs are interested in using C++ library. This makes sense. This also requires the vendor to write a C++/CX layer on top of his library. But C# programmers can already use C/C++ lib without C++/CX. Of course a C++/CX interface is more C# friendly than a native ISO C/C++ interface.
Your point is OK with C#.
Do an experiment, if you will. Take an existing physics library or math library or image processing library writtten in C++. Create a Windows 8 Metro C++ app. Create a shared module out of it. Do this with C++/CX at the boundary (so, the insides are written in C++, the skin on the outside is written in C++/CX). Now, do this same thing (the boundary, the shareable skin) in WRL. You tell us which is harder, which is more insane, which is too complex.
I've already done this kind of thing. I do agree with you: C++/CX is far more usable than WRL. But ... (you know)
I don't know how to create a Win8 app with "C++/CX at its boundary". In all C++ code for Win8 I've seen/written yet, there is no such thing as "C++/CX at its boundary" as the "boundary" tends to be 50-90% of the code. But, as I already said, I have not seen a real Win8-Metro C++ app source code, it may be different.
Once again, things are really different in C#.
This hybrid application environment that WinRT supports seems to me to be the most compelling thing about it. As you learned in the BUILD sessions on Windows 8 Metro Style Applications and WinRT, there are compelling user-centric features provided by the underlying system that your application can take advantage of for free, but only if you play by WinRT's rules (again... WinRT defines the model, not the languages used to program WinRT apps...).
Hybrid application environment sounds terrible for me... I've spent so much time trying to write managed interfaces to native programs... I don't want to do that again.
OK we need to play WinRT rules if we want to write Metro apps. Make sense. WinRT defines the model not the language, but this model is close to (designed for?) C#, not C++ (yet).
I guess many small apps will be written in C# for WinRT. The kind of app you see on iPhone or Android. They are not expensive to develop. I wouldn't write this kind of app for WinRT in C++.
For larger customer apps, C# is too weak. I don't know about C++ and WinRT. Not sure I want to spend a lot of time on this.
It seems to me that my comment on the developer productivity gains and ease of consuming and authoring WinRT objects originating or targetting different WinRT-compatible languages that C++/CX affords is simply being ignored. Why is that, exactly?
About productivity gains using WinRT, well I'm not sure. When I use WinRT, I always have to care if I am using a WinRT type or a C++ type, and write code to convert from one to another. Am I using a wstring here? Oh but I need a Platform String. Same for containers. You can see this problem in Marian Luparu's demo in the video. Most of his code is about type conversion. And you can also note that there is no "thin boundary" at all. All his code is using WinRT types. OK it is just a small sample, but still.
About the ease of merging different languages in the same application, well you are right, it is easy to author a C++/CX module and use it from a C# object. But why would I use two or more languages if I can use one? Using 2 languages makes the project maintenance at least twice as hard. You need maintain the compatibility with two languages instead of one. You also need dual competence developers, etc. Why would I do that if I can avoid it?
I've just discovered this very interesting thread, and spent quite a while to read it. I would like to thank Herb, Charles, et al. because they want to hear what we have to say. I'm not sure the Windows guys are listening to what we say.
Here is what I think about C++/CX, for what it's worth. I totally agree with what other C++ devs say here.
I have written a few C++/CX lines of code, and the feeling I have is, a C++ app which uses WinRT is not a C++ App. It is not using C++, it is something else.
I haven't written a full featured app in C++/CX with a data layer, presentation layer, etc, Only a few code samples. But in all the code samples I wrote, there was no "thin boundary" to WinRT. All the code had to use C++/CX in some way: an API call, a callback or a system type (I hate Platform::String). WinRT is using async calls, this is great, but it is WinRT C++/CX parallelism. Of course I could have created some layers, but the WinRT interface layer and the layer boundaries would have been far bigger than ISO C++ code itself. This is really worrying me.
This is worrying me because Microsoft already said that 10 years ago with .Net. Problem is, there is only one model, and the languages (except C#) have to be distorted to fit WinRT concepts.
In June 2011, when I heard rumors that Microsoft would go native, I thought Windows guys would build some native framework we could use in C++, and build a CLR layer on top of it so it could be used in C#. But Windows team did not do this. They built a native framework with a CLR-compatible interface (WinRT). And we are trying to use this interface in C++, although it is designed for C#. How disappointed I was two months ago!
This is the first point. OK it has nothing to do with C++ team, it is Windows team.
The second point is C++/CX itself. IMO, it is designed to look like C#. Marketing point. In fact it is really easy to translate C++/CX code into C# or VB and vice versa but do we care? WinRT is really pleasant to use in C#, it has been designed for that. Then the C++ team had to find something to make WinRT work with C++. You did it the C# way, not the C++ way. C++/CX is C++ distorted to fit C# design. So where is the point using C++/CX instead of C#?
As other guys here, I do beleive there is another fast and fluid way to use WinRT in C++. But maybe this other way of using WinRT in C++ is too far from WinRT concepts. Why creating a new design with WinRT if you don't use it in C++?
Agreed - gdiplus is nice. [..] But it can't be deleted using a C++ syntax directly, without wrapping it and calling flat functions. I think Gdiplus is an example of what I meant: "would be the least common denominator of all languages". It's basically a C++ wrapper around flat functions, passing object pointers as handles.
No, you are wrong.
You delete gdiplus objects with C++ delete keyword. You call methods with "->" or ".". You can allocate objects on the heap or on the stack, and objects are automatically deleted on function return, etc. Gdiplus also supports inheritance: Bitmap derives from Image for example. Gdi+ seems very much like a C++ class!
Gdi+ is not "passing object pointers as handles" at all.
Hence my question again, why not using this kind of interface?
But how can such an object directly be allocated in a different language and then passed to C++, where the C++ application calls "delete b"?
Well, you can't C++ delete a GDI+ object allocated in C#, but how often do you need to do that? Once or twice in a lifetime?
I haven't needed that yet, although I use C#, C++ and C++/CLI, and have used GDI+ quite a lot.
Thank you very much for the detailed clarifications. This answers my concerns.
I especially like this paragraph:
>there are real conveniences (cleaner code) and efficiencies >(performance gains) from using compiler-understood extensions >like C++/CX, which is why we went to the trouble of baking >a CComPtr<T> into the language as T^... so my only >recommendation/request would be that you give each a >try and then use whichever you like best. Who knows, >some people who hate extensions might just find after >trying them side by side that they kinda prefer the >language extensions after all