DateTime projection in C++/CX

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)
{   
  listBox->Items->Append(
    dateFormatter->Format(item->PublishedDate) + " " +
    timeFormatter->Format(item->PublishedDate) + " - " +  
    item->Title->Text);         
}

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.

Compiler errors when using the Bindable attribute

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
{
  [Windows::UI::Xaml::Data::Bindable] 
  public ref class Restaurant sealed
  {
  public:
  };
}

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.

Visual C++ WinRT FAQ – Winsock and other APIs

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:

• Alternatives to Windows APIs in Metro style apps

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.

Difference between std::move and std::forward

In really simple terms, std::move returns an argument as an rvalue reference while std::forward returns either an lvalue reference or an rvalue reference based on how the argument was passed in to the current function. While this is fairly obvious once you get the hang of it, it can be quite tricky to grasp earlier on. The easiest way to see how they work differently is to try some code such as the following:

void Show(int&&)
{
	cout << "int&& called" << endl;
}

void Show(int&)
{
	cout << "int& called" << endl;
}

template<typename T> void Foo(T&& x)
{
	cout << "straight: ";
	Show(x);

	cout << "move: ";
	Show(move(x));
	
	cout << "forward: ";
	Show(forward<T>(x));
	
	cout << endl;
}

int _tmain(void)
{
	Foo(10);

	int x=10;
	Foo(x);
	return 0;
}

The output of the above code is:

straight: int& called
move: int&& called
forward: int&& called

straight: int& called
move: int&& called
forward: int& called

When Foo is called with an rvalue, T&& is deduced as int&&. But the variable itself is an lvalue within that function. So the straight call calls the Show(int&) overload – no surprises there. Both the move-call and the forward-call calls Show(int&&) as expected. In the 2nd case, Foo is called with an lvalue, and again the straight call will go to Show(int&) while the move-call will go to Show(int&&). Now here’s where forward comes in handy, it will go to Show(int&) because that’s what T has been deduced to in this instance of the function call (perfect forwarding). If you are wondering why, the collapsing rule for T&& collapses it to T& during template argument type deduction.

Building Metro apps without Windows 8

This is an FAQ on the forums. And unfortunately but unsurprisingly, the answer is no, you cannot build a Metro app without Windows 8. If you are running Windows 7 and don’t want to risk screwing up your OS, you could install Windows 8 on a VM or dual-boot off a VHD/2nd partition. Those options are reasonably performant, and more so if you have an SSD.

C# and the need (lack of) for move semantics

Someone recently asked me why C# does not support move semantics. Well, C# mostly deals with references, so you don’t have to to deal with copy constructors called on temporary objects. C# does support value types too but they are nearly always used for POD (plain old data) types. And when there is the need for a copy, what’s usually done is to implement an interface such as ICloneable. In the C# (and .NET) world, assignments are mostly reference copies. A reference variable takes the value of another reference variable. In summary, C# as a language does not have a need for move semantics.

Visual C++ WinRT FAQ – Inter-Process-Communication

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.