posted by pierremf

posted by pierremf

I hope C++16 will have a great library

BTW: was the C++7 package SD or HD diskettes? Did DVD-Rom edition already available?

posted by pierremf

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?

posted by pierremf

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

Yes please...

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.

posted by pierremf

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.

posted by pierremf

Charles wrote

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?

C

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?

posted by pierremf

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.

At some point I was trying to figure out how to use one particular WinRT object. I found a Javascript sample, nothing in C++ or C#. The Javascript sample let me understand how it works. I was able to translate the code from Javascript to C++/CX and C# on a line by line basis. That was straitforward. Same WinRT types, same instructions, the syntax differs. So with C++/CX we can share our code base with C# and Javascript developers, isn't that wonderful?

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.

The other thing that is worrying me is, you can translate C++/CX code into C# and Javascript on a line by line basis. I haven't tried VB though. I don't like this "one size fits all" idea. 10+ years ago there was Visual C++ on one side, and Visual Basic on another. 2 different languages for different purposes. Then .Net guys thought one pattern would fit all. They even tried to build Windows in C#/.Net, but they failed. Then they had this great idea of writing .Net framework in native code, and now they can build Windows using .Net, well WinRT. And this great marketing phrase: you can use fast and fluid C#, Javascript, VB, C++, whichever you like, to build Windows Applications! 

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++?

posted by pierremf

C++ has really changed in the last years, I didn't notice how deeply, although I use it very often: I couldn't see the forest for the trees. Thanks for pointing this out.

posted by pierremf

Andre wrote:

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.

posted by pierremf

> If all Windows developers would be C++ developers
> it would be fairly simple - WinRT would be something
> like QT - but come on - it's not the case

I'm thinking about Gdiplus API, which is pure C++ API in native code:

using namespace Gdiplus;
Bitmap *b = new Bitmap("a.jpg");

and is also part of the .Net framework, can be used in C# or VB:

using System.Drawing
Dim b As New Bitmap("a.jpb")

This is the kind of API what I would have liked for WinRT.

This is not COM ABI.

Impossible because of concurrency/process/thread safety?

posted by pierremf

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

posted by pierremf

Do you MS-guys use these extensions in Windows 8 code?

If yes, then we will certainly have to reconsider our bad 1st impression about C++/CX, and admit we are wrong.

If no, then this C++/CX stuff will certainly join WPF (amongst others) in the trash can very soon.

posted by pierremf

+1

WE DO NOT WANT TO USE THESE EXTENSIONS

posted by pierremf

We don't need delegates, partial classes, generics, or ^ pointers since C++ already knows how to do that. Why would we do it the CX/C# way?

C++ references a COM object with a * pointer or a smart pointer.

Hopefully there seems to be a new WRL C++ template library somewhere. Is there any documentation about it? Can we use it instead of CX?

posted by pierremf

I've been working for different ISVs for several years on large C++ projects (tax paying software, Image editing, Financial, programming tools...)

One problem with existing C++ apps now is the UI, which is outdated. They share that problem with Delphi apps . You know that battleship gray. I've spent lots of time trying to move (parts of) projects to Winform or WPF. This generally ends up with an awfull mix of C++, C++/CLI and C#. You know what I mean since you guys have ported Visual Studio UI to WPF ! This surely has been a huge amount of work.

If there would have been a modern UI C++ library, thing would have been far simpler. I've heard about DirectUI, and I can't wait to know more about what seems to be a native UI library.

Also I have participated to brand new WPF projects, in C#. For example an image editing app. One year after it started, the project is thrown away (10 men-year). WPF is too heavy, .Net has poor memory management, and the software was not compatible enough with previous versions of this project. Customers don't want a new app, they just want a better app which is able to reuse their old files/data.

What are all the C++ app developpers doing ? They have built their own UI framework and libraries years ago, sometimes based on MFC, or other libraries. (AFAIK MFC is not that bad, it is still used in many C++ apps, it is just old) They try to update the framework over the years. That's not easy, and requires a lot of resources. In the same time they have to update the applications. I bet the Office team at Microsoft has its own C++ framework. You can ask them what to do.

Since I've discovered .Net framework, I wonder why it is not also written in C++ native code. Maybe not the whole framework, but at least some core libraries, a powerfull UI layer, a fast database engine (I sometimes use SQLite in C++ client app)

Well, you know, just ask the guys who have ported Visual Studio to WPF, they will tell you what you need to do

Oh, and an important point: all developers have coding guidelines (or at least they should!). Many C++ ISVs ask their developers to write SIMPLE code. That means, avoid functors, use templates sparingly, etc. Don't use advanced C++ features if you can write simple code. Because simple code contains less bugs, and can easily been maintained. C++ is a powerfull language, and not all C++ developers can handle that power correctly.

I don't expect C++ language improvements, C++ is fine. But please, give us the equivalent of a light .Net framework, written in native code. That would be heaven.

posted by pierremf

For example, about the taskbar interaction, all I have found is CWinApp::EnableTaskbarInteraction(BOOL bEnable), which actually only sets a BOOL flag... which is not used anuwhere else in the MFC code. Or I am missing something ?

Also, I can't open the class wizard now

Anyway the Ribbon designer is really great ! .NET programmers will really be jalous.

www.blogmfc.com (in French)

http://www.microsofttranslator.com/BV.aspx?ref=Internal&a=http%3a%2f%2fwww.blogmfc.com (automatic translation in English)

posted by pierremf