Visual C++ WinRT FAQ – connecting to localhost

This is probably one of the most frequently asked questions on WinRT in the forums. The answer is – no, you cannot communicate with localhost. You can communicate with a service running on the local network, the intranet, or the internet. But you cannot connect to the loop back address. This is by design. It’s a security measure, and also a side-effect of how a Metro app cannot take any assumptions about the machine it’s running on. And expecting a localhost service to be running is such an assumption. So what’s the alternative? Use the cloud

Note: you can connect to localhost for debugging, but your app will not be approved for publishing to the store.

Visual C++ WinRT FAQ – Non-RT types in public signature

Your public WinRT classes cannot use non-RT types in their public signature. This is something people run into very frequently when they start writing WinRT components. For example, see the code below.

class Native { };

public ref class MyRef sealed
{
private:
        voidFoo1(Native n) { } // <--This is fine

public:
        voidFoo2(Native n) { } // <--This won't compile
};

You’ll get a compiler error there:

error C3986: 'Foo2': signature of member contains native type 'Native'

Note that this is by design. (If you think about it, it’s perfectly logical, since WinRT components can be consumed by any WinRT caller including non-C++ ones)

Visual C++ WinRT FAQ – WRL vs C++/CX

As I said in my previous blog entry, WRL is a non-extension-based ISO compliant alternative to using C++/CX when targeting WinRT. They are both far easier to use than using straight COM, so what do you choose to use for your Visual C++ WinRT needs. In his talks, Herb Sutter has very strongly recommended that we use C++/CX. And it’s fairly obvious that C++/CX is far simpler to use than WRL, specially when creating components (consuming components is relatively easier).

• The big thing with WRL is that you can use ISO C++. You don’t have to learn a new syntactic extension that you cannot use outside the Microsoft-world. Most C++ devs would feel comfortable using WRL, specially if they’ve used ATL before. That said portability is a myth, since WRL code is as tied into Windows as would be C++/CX code.
• Do you want to totally avoid exceptions (perhaps to remain in sync with existing code that doesn’t use exceptions)? If so, you have to use WRL since C++/CX uses exceptions.
• Performance wise, will you see any difference? As stated above, C++/CX uses exceptions while WRL uses HRESULTs. So the performance implications of using exceptions will obviously come into play. There is also the non-trivial conversion between HRESULTs and RT exceptions. Outide of that, I don’t think there’s going to be any noticable difference in performance
• Not sure to what extent you can do this, but since WRL exposes the underlying COM architecture, you can fine-tune your code to some degree (since WinRT is built on top of COM). I haven’t read or heard about any scenarios where this has actually made a difference.
• The psycological aspect. While this is the least technical of the reasons, it might be the biggest factor here. Many C++ devs would simply hate anything that they see as foreign syntax. And C++/CX is certainly not ISO C++. Its close similarity with C++/CLI (which many C++ devs found disgusting) doesn’t help either. If your C++ dev team comprises mainly of a bunch of these guys, I reckon it’d be wise to just use WRL.

And personally speaking, I’d probably recommend that you learn to use both C++/CX and WRL. That way you can use what’s best for your specific scenario. And finally, you can mix WRL and C++/CX in the same project.

Visual C++ WinRT FAQ – Alternative to C++/CX

There are C++ developers who haven’t really been thrilled with using the C++/CX extension syntax. It’s alien to C++ in some ways and many people prefer to write code that’s as close to ISO C++ as possible. While you can avoid C++/CX and write staight C++/COM code to consume and create WinRT, it will be an unbelievably painful experience. So on one side you have C++/CX which I consider to be high-level access to WinRT and on the other side you have straight C++/COM which I consider to be low-level/raw access to WinRT.

There is a middle path though. It’s called WRL – Windows Runtime C++ Template Library. Maybe they should have called it WRCTL, but they called it WRL and I’ve heard a few folks pronounce it as “Wurl”. WRL is to WinRT what ATL was to COM. WRL allows you to avoid using the extension syntax and to use ISO C++ to write WinRT components. That said, you’d be kidding yourself if you assume WRL allows you to write portable code. The moment you use WRL, you are locked into WinRT/Metro. So it’s not as if you can take that code and reuse it in your GCC/Linux project.

Which of the two should you choose between C++/CX and WRL? Well, there are a few things to consider there and I’ll cover that in the next blog entry. But eventually it’s a subjective per-project decision that you need to make.

Visual C++ WinRT FAQ – Does C++/CX produce managed code?

A variation on this question is people asking if C++/CX generated WinRT DLLs/apps require the .NET framework. The answer is No! WinRT is a native COM based framework, and C++/CX produces 100% native binaries. The syntax is similar to C++/CLI (which produces managed code) which may be the cause of confusion. You are not allowed to mix managed code in a C++/CX project – so you cannot use C++/CLI and C++/CX in the same project, and in fact C++/CLI is not supported for WinRT. That said, if your application uses a WinRT component that was written in C#, then your deployed application will have a .NET dependency since the required DLL is managed. But C++/CX itself is a 100% native language/compiler/technology.

Announcing the Central Ohio C++ User Group

If you are a C++ developer/enthusiast who lives in or around Columbus, OH, then you may be pleased to hear that we are launching a C++ specific user group in Columbus, Ohio. The first UG session is scheduled for the 14th of March. Quick Solutions, Columbus, OH has kindly agreed to host the meeting. Details below:

• Meeting: Central Ohio C++ User Group March Meeting
• Location: Quick Solutions Training Center at 440 Polaris Pkwy, Suite 500, Westerville, OH.
• Date/Time: March 14th Wednesday, 6PM – 8PM
• Session: Using Visual C++ to write WinRT/Metro applications (Speaker: Nish Sivakumar)
• Session: Future direction of the C++ user group (Group discussion)

For a speaker bio, check out my About page here: http://www.voidnish.com/Home/About

Here’s the marketing summary:

“Nish Sivakumar is a C++ developer from Columbus, OH. He has been a Microsoft VC++ MVP since 2002 and is the author of C++/CLI in Action by Manning Publications (2006) and Extending MFC Applications with the .NET framework by Addison-Wesley (2003). He has published over 100 articles on C++, C#, WPF, WP7, WinRT, and other Microsoft technologies on The Code Project. Nish has a keen interest in photography as well as in mixology.”

Please note that we will be meeting once a month. If you live in or around Columbus, and would be interested in presenting on a C++ related topic, please get in touch with me through this blog.

March 14th Wednesday, 6PM – 8PM
440 Polaris Pkwy, Suite 500, Westerville, OH

Mark your calendars!

WinRT : Databinding with C++

Here’s my 2nd article on WinRT with C++.

• Visual C++ and WinRT/Metro – Databinding Basics

Databinding (at the moment) is easier with C# or VB than with C++ since with C#/VB, the .NET interop handles the required plumbing required to get databinding working. With C++, the required interfaces and functionality need to manually implemented (which is what the article covers). I personally hope that this will change in a future release and the compiler will generate this code for us automatically. So the article is mostly of academic interest specially if you are interested in knowing how databinding is implemented at the consuming client level (not the Xaml internals).