Partial classes are finally available to C++. Sort of. It’s not part of the new C++11 standard, it’s part of the C++/CX language developed by Microsoft for targeting WinRT on Windows 8.
Partial classes mean that you can define a class spanned across several files. Why is this great? Because it allows developers and automatic code generator tools (such as designers) to edit parts of the same class without interfering one with another. WinRT allows C++ developers to write UI in XAML. This could not have been possible without the support for partial classes.
Partial classes:
- are available only for ref classes; native classes are not supported
- are introduced with the partial keyword in all definitions but one
Here is an example:
// foo.private.h
#pragma once
partial ref class foo // <- here the partial keyword is used
{
private:
int _id;
Platform::String^ _name;
};
// foo.public.h
#pragma once
#include "foo.private.h"
ref class foo // <- partial keyword is not used here
{
public:
int GetId();
Platform::String^ GetName();
};
// foo.cpp
#include "pch.h"
#include "foo.public.h"
int foo::GetId() {return _id;}
Platform::String^ foo::GetName {return _name;}
What happens when you add a new page to a C++ Metro style application? The wizard generates three files: a XAML file and a header and cpp file as the code behind. Let's say the page is called MainPage. In this case the three files are MainPage.xaml (code below is a dummy example), MainPage.xaml.h and MainPage.xaml.cpp.
<UserControl x:Class="DemoApp.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
d:DesignHeight="768" d:DesignWidth="1366">
<StackPanel Name="firstPanel">
<Button Name="firstButon" />
</StackPanel>
</UserControl>
//
// MainPage.xaml.h
// Declaration of the MainPage.xaml class.
//
#pragma once
#include "pch.h"
#include "MainPage.g.h"
namespace DemoApp
{
public ref class MainPage
{
public:
MainPage();
~MainPage();
};
}
//
// MainPage.xaml.cpp
// Implementation of the MainPage.xaml class.
//
#include "pch.h"
#include "MainPage.xaml.h"
using namespace Windows::UI::Xaml;
using namespace Windows::UI::Xaml::Controls;
using namespace Windows::UI::Xaml::Data;
using namespace DemoApp;
MainPage::MainPage()
{
InitializeComponent();
}
MainPage::~MainPage()
{
}
You can notice that the objects firstPanel and firstButton are not defined in the header for MainPage and second, MainPage.xaml.h includes MainPage.g.h. So what is this? This is a designer generated file, which together with MainPage.g.cpp completes the definition of the MainPage ref class. These files are not generated until you start a build. After you do that you can find them in the output folder (Debug or Release for instance). This is how they look:
#pragma once
//------------------------------------------------------------------------------
// This code was generated by a tool.
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
//------------------------------------------------------------------------------
namespace Windows {
namespace UI {
namespace Xaml {
namespace Controls {
ref class StackPanel;
ref class Button;
}
}
}
}
namespace DemoApp
{
partial ref class MainPage : public Windows::UI::Xaml::Controls::UserControl,
public Windows::UI::Xaml::Markup::IComponentConnector
{
public:
void InitializeComponent();
void Connect(int connectionId, Platform::Object^ pTarget);
private:
Windows::UI::Xaml::Controls::StackPanel^ firstPanel;
Windows::UI::Xaml::Controls::Button^ firstButon;
};
}
//------------------------------------------------------------------------------
// This code was generated by a tool.
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
//------------------------------------------------------------------------------
#include "pch.h"
#include "MainPage.xaml.h"
using namespace Windows::Foundation;
using namespace Windows::UI::Xaml;
using namespace Windows::UI::Xaml::Controls;
using namespace Windows::UI::Xaml::Markup;
using namespace MyDemoApplication1;
void MainPage::InitializeComponent()
{
// Call LoadComponent on ms-resource://DemoApp/Files/MainPage.xaml
Windows::UI::Xaml::Application::LoadComponent(this, ref new Windows::Foundation::Uri("ms-resource://DemoApp/Files/MainPage.xaml"));
// Get the StackPanel named 'firstPanel'
firstPanel = safe_cast<Windows::UI::Xaml::Controls::StackPanel^>(static_cast<IFrameworkElement^>(this)->FindName("firstPanel"));
// Get the Button named 'firstButon'
firstButon = safe_cast<Windows::UI::Xaml::Controls::Button^>(static_cast<IFrameworkElement^>(this)->FindName("firstButon"));
}
void MainPage::Connect(int connectionId, Platform::Object^ pTarget)
{
}
The following image illustrates the grouping of these files:
MainPage.xaml is a XAML files, which can be edited both by the designer or manually by the developer (basically with the designer is still the developer that models the UI). The other files are C++/CX files. MainPage.xaml.h and MainPage.xaml.cpp are the files the developer writes, while MainPage.g.h and MainPage.g.cpp are edited by the designer. Do not modify the code in these files, because you could either mess up the designer, or all your changes would get lost when the file is regenerated.
C++, C++/CX, partial classes, VisualStudio, VS11, winrt, XAML Hits for this post: 10090 .
