Is it C++ or C++/CLI

Question

Hi

I walkt a little bit in the samples and i saw

void HelloWorld::MainPage::HelloButton_Click(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)

{

    DisplayText->Text = "Hello World";



}

But what I remember the ^ means that the object is managed by the Gargabe Collection.  That brings me to 2 Questions:

* is it C++/CLI ?

* When all WinRT objects are managed how does the core WinRT work ?

Answer 1

Hi

I guess i found the answer

http://msdn.microsoft.com/en-us/library/windows/apps/hh454076

Answer 2

I too am wondering this. All the example I see use some language that's clearly based on c++ but isn't c++.
Can you actually use c++ for any of this?

Answer 3

Hi -

The syntax for these extensions is very similar to the C++/CLI syntax but when built against WinRT it generates 100% native code.  It *is* C++ under the covers - it just provides a comfortable syntax for talking to the Windows Runtime.  Herb Sutter is giving a talk (TOOL-532T) that discusses the language syntax, which will be available online 24 hours after it airs at //build.

Core WinRT is NOT managed - it is native and COM-based.  Our language provides a fully-native projection of that in a high-level syntax, but you aren't tied to that syntax - you will be able to target the Windows Runtime using low-level COM or WRL (an ATL-like template library) as well.  (The C#/VB projection is a different story, they generate runtime-callable wrapper objects which marshal between .NET and WinRT.)

And - if you're like most C++ developers, you have a huge catalog of existing code which represents your core business logic.  Because this language is an extension to C++, your existing code will work (note that not all native Win32 APIs are available, however).  As an example, you may have seen in the keynote given by Ales, they were able to include the Boost library directly into their Metro style application and use it.

Thanks,

Andy Rich
Windows C++ QA

 

Answer 4

@swo1: yep, you found it: the key passage from the link you pasted below is this:

If you are familiar with C++/CLI, you will notice that the Component Extensions look very similar to C++/CLI syntax. However, in a Metro style app or Windows Runtime component, all the C++ code is native.

Basically, we re-used the C++/CLI "syntax" in the C++ Compiler FrontEnd, but all the generated code is now native.

Herb's session today (Using the Windows Runtime from C++) is the right session to attend to get a bunch of questions answered. :-)

 

@Johnb1122: yep, you are still using C++. You use the "extension" to interact with WinRT, but for everything else, do use your normal C++ code. For example, you can create a std::vector<Platform::Object^>. It's all native code: All the way until the end.

 

HTH,

Ale Contenti
Visual C++ Dev Manager

 

 

Answer 5

Andy,

Just to clarify what two things you said,  WinRT is callable via COM interface only, native (aka, something like LoadLibrary, I assume) or both ?  

Second clarify, language projection, is this when C++ compiles, its taking the WinRT datatypes and replacing the "c++ datatypes"?

Regards,

Paul

 

 

Answer 6

Would it be possible to use pure standard C++ syntax with WinRT? I don't want to use the "C++/CLI like" syntax, I want to use pure standard C++ syntax without any kind of extensions.

Answer 7

Ok that's better than I thought then.

To be clear though is it possible to use WinRT with *standard* c++ without any of the extensions? I don't know that I'd want to, I'd just feel *much* happier that it was possible. I see classes in the class reference that take for example "Platform::Object^ sender" as a parameter. Is it possible to make use of those functions without using the non standard "^" extension if I wanted to?

I would feel much happier if I could build a small application the hard way without using any extensions to get a real understanding of how it all works. And then probably use the extensions in real code :)

Answer 8

I was wondering how can I transfer this

   std::wstring w= "Hello World";

into the TextBlock?

 DisplayText->Text =  w;     // Won't work

 But

DisplayText->Text =  ref new String( w.c_str() );   // should

See

http://msdn.microsoft.com/en-us/library/windows/apps/hh441549(v=VS.85).aspx

and

http://msdn.microsoft.com/en-us/library/windows/apps/br229567(v=VS.85).aspx

 

 

Answer 9

Yes, as Andy mentioned you can call into WinRT using an ATL-like library known as WRL or even maintaining it at the lowest level without the help of WRL. You will have to write more code than you would if you used the C++ projection but it is certainly possible.

Answer 10

Here are a few points that may help clear up some confusion:

• WinRT is a platform of libraries that is callable from C#, C++ (both from the C++ Language Projection using "^" as well as C++ with no extensions), Visual Basic and JavaScript.
• WinRT's core is based off of COM.
• Language projections are extensions to each of the languages mentioned above that allow you to call into the Windows Runtime in a way which is native to that language.
• The C++ Language Projection generates code behind the scenes to do all the necessary low level WinRT/COM calls. In essence, the C++ Language Projection is managing your references and resources for you, resulting in shorter and more concise code.

Does this clear up some of your questions?

Answer 11

So far I'm convinced that I don't want to mess with the C++/CLI syntax. You mentioned that there are two alternative ways; by using WRL or maintaining it at the lowest level. Where can I find the WRL library and info for those approaches?

Answer 12

Thanks Zac.

Is this WRL template library available somewhere? Will it be available at some time? Note that in C++ we always write more code than in C# ;)

I would like to ask you MS-guys a question: are you using C++/CX?

Answer 13

Hi -

The syntax for these extensions is very similar to the C++/CLI syntax but when built against WinRT it generates 100% native code.  It *is* C++ under the covers

Why would you claim that, when it's obviously not true? What you mean is "it is native code", or "it is link-compatible with our C++ compiler", but it is not C++. For someone writing portable, standard C++ code, it is no different than C++/CLI was. The problem with C++/CLI wasn't so much that it generated different code (managed vs native), but that it wasn't ISO C++, and it locked our code into only working on your compiler. That hasn't changed. As far as a C++ developer is concerned, it might as well be C++/CLI.

Answer 14

<blockquote>yep, you are still using C++.</blockquote>

As above, no we're not.

std::vector<Platform::Object^>

is not, and will never be, C++. It is no more C++ than C++/CLI was.

 

Please tell me that the VC++ team knows the difference between "native code" and C++. The latter is language. It describes the source code. The former merely describes the output format, whether it generates x86 machine code or .NET's intermediate code.

Answer 15

Here are a few points that may help clear up some confusion:

• WinRT is a platform of libraries that is callable from C#, C++ (both from the C++ Language Projection using "^" as well as C++ with no extensions), Visual Basic and JavaScript.
• WinRT's core is based off of COM.
• Language projections are extensions to each of the languages mentioned above that allow you to call into the Windows Runtime in a way which is native to that language.
• The C++ Language Projection generates code behind the scenes to do all the necessary low level WinRT/COM calls. In essence, the C++ Language Projection is managing your references and resources for you, resulting in shorter and more concise code.

Does this clear up some of your questions?

It prompts a question, rather:

C++ has had ways to "manage your references and resources" for 15 years. It's been one of the strong points of the language, even compared to C# and Java, which have *no* way to manage resources robustly. So why do we need these language extensions?

Yes, a custom smart pointer (coupled with a `winrt_new<T>()` function, and a few other bits and pieces) would've been a bit more typing, *but it would have been a true "projection into C++". Why wasn't that good enough?

why did the WinRT team choose instead to project into their own proprietary language, which C++ code can interop with?

Where does this leave cross-platform code bases? Where does it leave compilers other than VC11 (whether ICC, MingW or even VC10 or older)? Microsoft *could* have written a "projection" into ISO C++, and these questions would have been void.

Why didn't they?

Answer 16

why did the WinRT team choose instead to project into their own proprietary language, which C++ code can interop with?

Where does this leave cross-platform code bases?

 

WinRT is not cross-platform so your point is moot.  You can always write your "pretty UI" using the new C++ extensions and write all your cross-platform code in C++.

Answer 17

WinRT is not cross-platform so your point is moot. You can always write your "pretty UI" using the new C++ extensions and write all your cross-platform code in C++.

Yes, and so much easier than wrapping your C++ in C++/CLI so it can be consumed by a C# UI.
 

---

David Wilkinson | Visual C++ MVP

Answer 18

why did the WinRT team choose instead to project into their own proprietary language, which C++ code can interop with?

Where does this leave cross-platform code bases?

 

WinRT is not cross-platform so your point is moot.  You can always write your "pretty UI" using the new C++ extensions and write all your cross-platform code in C++.

I think you missed my point. No, WinRT isn't cross-platform, and I wouldn't expect it to be.

But cross-platform code bases will need to interact with WinRT when built for Windows.

My point is that these language extensions are going to make "ordinary" compilers choke. And I have a hunch that the whole "but you only need to write a bit of boundary code in this proprietary dialect" is easier said than done. In practice, won't WinRT types "bleed" into the main code base rather easily?

Consider how hard it is to keep your code clean from dependencies on Windows.h

Consider people who use GCC to generate both their Linux and Windows builds: how do they access WinRT?

Consider people who use a build system such as CMake to handle builds for multiple platforms. How many custom build scripts are required for it to cope with these almost-but-not-quite C++ files?

I don't know. All these issues might turn out to be trivial in practice, but I'm not convinced yet.

Answer 19

My point is that these language extensions are going to make "ordinary" compilers choke. And I have a hunch that the whole "but you only need to write a bit of boundary code in this proprietary dialect" is easier said than done. In practice, won't WinRT types "bleed" into the main code base rather easily?
 
Consider how hard it is to keep your code clean from dependencies on Windows.h

Yes, but if you are in the business of writing cross-platform code then presumamably you have solved the windows.h problem, and you can use your clean code with a WinRT UI, or any UI.
 
It's no different from if WinRT had been implemented by some kind of smart pointer based library. You would have to keep that out of your clean code also.
 
I write MFC apps, and when I first started separating the "business logic" from the MFC parts, I did it so I could port the code to Mac or Unix/Linux (which never happened).
 
And then I thought I would use it to port the UI to .NET (which never happened either).
 
So now we have WinRT. This time I might actually do it...
 

---

David Wilkinson | Visual C++ MVP

Answer 20

Hi guys.  Let me see if I can clear this up a bit more:

First, WinRT, as mentioned, is built on an evolved version of COM.

The WinRT library included with Windows 8 is built from interfaces defined in IDL just like COM intefaces in prior versions of Windows, and the implementations of those interfaces are called Runtime Classes (think of this as the evolution of "CoClass" in COM).

Before you say "Ew, COM" (if you were going to say that), note two things:

1) This is, as they say, not your grandfather's COM.  One small example: Intead of IUnknown as the base interface for all things, we now have IInspectable.  This brings a lightweight sort of "reflection" which is used in projecting these APIs to different languages and runtime environments, and also to enable better tooling.  The IDL compiler and syntax have seen huge investments as well.

2) You don't have to know or care about how the internals work if you just want to work with the high-level projection.

As a developer you have basically 4 options for interacting with the Windows Runtime:

1) The JavaScript projection.
2) The .NET projection.
3) The C++ "high level" projection, which makes use of WinRT language extensions.
4) No projection at all, what we call "the ABI."  No language extensions are needed.

Option #3 will make a lot of sense for a great many C++ developers.  You get to take advantage of the performance and control of native code, without having to learn COM, and with the ability to write much more succinct code.  If you're a C++ developer I highly recommend you at least give this a shot.  I was skeptical when I first saw it (what's the crazy hat thing?!?) but after playing with it for even just a few minutes, the advantages became pretty obvious.  If you're a cross-platform dev, I expect you'll be asking for this on other platforms, versus wanting to get rid of it from ours.

However, Option #3 is in the end syntactic sugar over #4.  Writing directly to the ABI will feel most natural to seasoned COM developers.  There's also a new template library (WRL) which someone mentioned earlier in this thread, which provides a lightweight set of utilities similar to what you may have used in ATL before (for example, ComPtr<>).  It also includes several new helpers for things like async callbacks.  And they're all template based (and very friendly to C++ 0x features like lambdas), so no language extensions are required.

The "high level" C++ projection and the associated set of language extensions do exactly the same thing as the raw ABI plus the WRL templates.  But the template solution can feel kludgey, especially to developers coming from the C# or Java world.  By extending the language to be aware of concepts like refcounting and partial classes, you end up with something much more inviting to those developers, not to mention toolable.

Oh, and one more difference between #3 and #4... the raw ABI is all HRESULT based.  The projections (including the C++ projection) are exception based.  This often means the projection is better suited for use with other exception-based libraries (like STL).

Hope that helps.  For more details, the various talks from //BUILD are the place to look.  Also the DirectX sample on the dev center demonstrates usage of WRL and the raw ABI (actually, it seems to mix both, but still provides an example of using WRL).  Also I just found a form post by Herb Sutter which addresses this same question.

Brandon

Answer 21

Thanks for explaining the how and why.

I was expecting a C++ interface to WinRT, without extension or CComPtr ("Ew, COM"!). WinRT being written in native code is really great. Until 3 days ago, I was dreaming of simple C++ objects exposed by this new part of Windows.

Something like, for example, gdi+. This library is written in C++ native code, and has a "real", "direct" C++ interface. It is also part of the .Net framework. Gdi+ offers the best interface for both worlds.

WinRT doesn't have the same kind of interface than gdi+, it is using my grandson's COM (since I'm the grandfather.. well not quite yet.) Maybe it is not possible because of concurrency/interprocess/thread safe problem, or for some other reasons. Maybe what I was expecting is impossible, I don't know. What I know is, what I was expecting is not actual.

Also, I'm a bit surprised you talk about "developpers coming from C# or Java world" to C++. Developers generally use opposite direction. If you target C# programmers, this would explain why you created C++/CX. But as a C++ programmer having also some good knowledge of C#, I'm wondering if C#/WinRT might be a really better alternative than C++/WinRT.

Answer 22

"Under the covers with C++ for Metro style apps"

http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-690C

also helps understanding.

Deon builds a small C++ function in a class, and shows:

1) Hatless C# access

2) C access.

Answer 23

The answer we gave to people about COM and the Windows Runtime is:

There are elements of COM in the Windows Runtime, but the Windows Runtime is *NOT* COM, it's much more.  There are very few aspects of COM that are present in the windows runtime - IUnknown for lifetime management, proxy/stub DLLs for IPC and that's about it.  Everything else is new.