Archive for the ‘C++/CX’ Category

In VC++ 2013, you can have a boxed object as a member of a value type. Example code below.

value class Member sealed
    String^ name;
    IBox<int>^ age;

Here’s some code showing how the type can be used.

Member member;
member.name = "Nish";
member.age = 80;
int age = member.age->Value;
member.age = nullptr;

Even in normal boxing/unboxing, when you use a safe_cast on a boxed object, eventually what happens is that a safe_cast to IBox<T> is performed and then the Value property accessed. Example, the following two snippets are semantically identical.

int y = 11;

// snippet 1
Object^ obj = y;
int y3 = safe_cast<int>(obj);

// snippet 2
IBox<int>^ boxedY = safe_cast<IBox<int>^>(obj);
int y2 = boxedY->Value;

Read Full Post »

Object::ToString was not virtual in VS 2012 and thus could not be overridden, and this was a bit of an inconvenience when databinding with XAML. Tarek Madkour’s Build 2013 talk on what’s new in VS 2013 for C++ Developers had a slide about overriding ToString. While that was exciting to see, I was a tad disappointed when I could not get it to compile under the VS 2013 preview build. The following code fails to compile.

ref class Person sealed
    virtual String^ ToString() override
        return "Test override";

The error thrown is : Error 1 error C3668: ‘Person::ToString’ : method with override specifier ‘override’ did not override any base class methods

I am hoping that it just never made it to the preview release and that the RTM version will have it, as it can be quite handy to be able to override ToString, and not just in XAML scenarios.

Read Full Post »

C# projects Windows::Foundation::DateTime as System.DateTimeOffset, whereas C++ just exposes the raw structure. This can be rather unnerving if you are trying to port some C# code to C++/CX. All you have to work with is the UniversalTime property which is a long long that MSDN defines as the number of 100-nanosecond intervals prior to or after midnight on January 1, 1601. Even a simple task as displaying a formatted date/time string is difficult as ToString merely returns the fully qualified name of the type.

Fortunately enough, Windows::Globalization::DateTimeFormatting includes the DateTimeFormatter class that can be used to get readable date/time display strings from a DateTime structure. Here’s some sample code that shows how you can use this.

auto dateFormatter = DateTimeFormatter::LongDate;
auto timeFormatter = DateTimeFormatter::LongTime;

for(auto item : feed->Items)
    dateFormatter->Format(item->PublishedDate) + " " +
    timeFormatter->Format(item->PublishedDate) + " - " +  

Obviously, it’d have been heaps better if the compiler gave us easier to use projections, but it’s still not that bad. A common practice is to convert this to standard C++ or ATL/Win32 date structures and formats if you want to do additional date/time processing on the object.

Read Full Post »

It’s been a long break for me from blogging, but I intend to make up for that over the next few months. I’ll primarily be blogging on topics mostly related to using Visual C++ to develop Windows Store applications. So if that’s the sort of thing that interests you, do check back once in a while.

Putting the BindableAttribute on a C++ ref class makes the class available for databinding. Unfortunately, if you add a very simple ref class and then mark it as [Bindable], you’ll get some weird compiler error messages. Example – consider this simple bindable class defined in Restaurant.h.

namespace ViewModels
  public ref class Restaurant sealed

Assume there’s a Restaurant.cpp that includes this file. You’ll get these compiler errors (or something close to it).

Error 1 error C3083: 'ViewModels': the symbol to the left 
    of a '::' must be a type ...\xamltypeinfo.g.cpp 
Error 2 error C2039: 'Restaurant' : is not a member 
    of 'ViewModels' ...\xamltypeinfo.g.cpp 
Error 3 error C2061: syntax error : identifier 
    'Restaurant' ...\xamltypeinfo.g.cpp

The not so obvious fix for these errors is to include Restaurant.h in any of your xxx.xaml.h files (right after the include to the xxx.g.h file would be a good place). This seems to be due to how the XAML compiler ties into the whole build process. Not a major hassle, but more something to be aware of.

Read Full Post »

When migrating apps or libraries that use sockets to WinRT, the absence of Winsock is often one of the first hurdles for many C++ devs. The suggested alternative to Winsock is to use the Windows.Networking.Sockets namespace. For a full list of alternate APIs that replace existing ones, see:

Be aware that you will most likely not get a one-to-one mapping for various API functions and structures. So you should fully expect to re-design and workaround that and use alternate approaches to achieving the same functionality/usability.

Read Full Post »

This is slightly related to the previous FAQ on connecting to localhost. While Metro apps can use contracts to communicate at some level with other apps, that is not equivalent to the traditional concept of inter-process communication. A metro app cannot communicate with a desktop app or even with another metro application on the same machine.

With desktop apps, the metro app cannot take for granted that it’s running or available, and thus it makes sense to not allow that. But you may be wondering why IPC is blocked between two metro apps. Well, metro apps can be in a suspended state at any given time, and there’s no sure way to predict its state. So even if there are two apps running at the same time, neither app can be sure if the other app’s ready to accept data or a command. This is quite likely why they decided to design it so that metro apps cannot talk to each other.

So, what’s the workaround? Again, the only reliable way an app can talk to another app on the same machine is to use a a 3rd service that’s running on the network, or to use a cliched phrase, use the cloud.

Read Full Post »

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.

Read Full Post »

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
        voidFoo1(Native n) { } // <--This is fine

        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)

Read Full Post »

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.

Read Full Post »

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.

Read Full Post »

Older Posts »


Get every new post delivered to your Inbox.