Available on GitHub

Modern is now available for download from GitHub. This is the first public preview of the Modern project and I look forward to your feedback!

Here it is: https://github.com/kennykerr/modern


I would like to thank the developers who tested private builds or contributed in one way or another including James Clarke, Ales Holecek, James McNellis, Jeremiah Morrill, Larry Osterman, Raffaele Rialdi, John Sheehan, Kirk Shoop, and Charles Torre. Your feedback helped to shape my understanding of the Windows Runtime and the modern C++ language projection.

What is Modern?

Modern is a Standard C++ language projection for the Windows Runtime. The Modern compiler produces a header-only library designed to provide Standard C++ developers with first-class access to the Windows API. As I’ve previously shown, Modern provides a classy type system to target the Windows platform with standard C++.

Need a simple example? The Windows.Foundation namespace provides the Uri class with its constructor accepting a string argument. The C++ developer can call this in the most natural way:

using namespace Windows::Foundation;

Uri first(L"http://kennykerr.ca/");

The Uri class also provides the CombineUri method, which returns another Uri object:

Uri combined = first.CombineUri(L"articles");

And it provides a way to get the canonical representation as a string:

String string = combined.ToString();

That’s all there is to it. No pointers or hats, no reference counting or error codes, nothing that isn’t straightforward and natural to the casual C++ developer.

But I need more power!

Sure thing. Modern provides a library-based language projection. That means you can drill down as far as you want to go. Creating a Windows Runtime class involves the use of an activation factory.

auto factory = GetActivationFactory<Uri, IUriRuntimeClassFactory>();

If you’ve ever tried calling the operating system’s RoGetActivationFactory function you’ll know what a saving this is. With the factory in hand, I can call the logical construction method to create the Uri object:

Uri uri = factory.CreateUri(L"http://kennykerr.ca/");

Not satisfied with the Uri class? You can just ask for Uri’s default interface:

IUriRuntimeClass default = uri;

But if you do that, you’ll notice that IUriRuntimeClass doesn’t provide the ToString method. This comes courtesy of the IStringable interface also provided by the Uri class. No problem, we can just query for it:

IStringable stringable = default.As<IStringable>();	
String string = stringable.ToString();

The Windows Runtime is built on the essentials of COM. That means IUnknown** and lots of HRESULTs, right? Wrong. Modern takes advantage of C++11 and beyond to provide a truly modern language projection for the Windows Runtime. So while it is still COM under the hood, a C++ developer should think in terms of references rather than pointers. Practically nothing is off limits to the developer hungry for power, but you don’t need to sacrifice productivity or safety along the way. About the only thing that Modern prohibits is explicit reference counting. It uses C++11’s move semantics to handle reference counting reliably and sparingly. So, given an IUnknown reference:

IUnknown unknown = uri;

I can call the modern equivalent of IUnknown’s QueryInterface:

IUriRuntimeClass uri = unknown.As<IUriRuntimeClass>();	

But there’s no AddRef or Release methods. You can even retrieve the underlying interface pointer and call QueryInterface directly:

IUriRuntimeClass uri;
HRESULT hr = unknown->QueryInterface(set(uri));

But even here the reference counting is hidden away. The uri object receiving the new reference takes care of its own reference counting and the AddRef and Release virtual functions are still inaccessible. So while all of the underlying ABI virtual functions are just a -> away, the reference counting is safely and efficiently taken care of by the library and the compiler.

What if you still desperately need to shoot yourself in the foot? No problem, just get the naked COM interface pointer:

ABI::Windows::Foundation::IUriRuntimeClass * danger = get(uri);

The rabbit hole goes deeper still but I’ll leave it there for the moment.

What’s ready?

The GitHub repository includes library sets for developing apps for Windows 8.1 and Windows 10. It includes full projections containing everything you might need to build anything you can imagine, but it also contains smaller library sets for scenarios where you might not need XAML or just want to use the Windows Runtime from a desktop app, console, or service.

You can use this public preview to build XAML apps or apps directly with CoreWindow. You can write console and desktop apps that just happen to use Windows Runtime components but don’t rely on an app container or core dispatcher. It’s up to you.

What’s next?

I am not releasing the Modern compiler at this time. The compiler is required for component development, to produce updated library sets, as well as project templates.

Support for binary composition, required by XAML, is currently experimental. This is likely where I’ll be spending a lot more time improving the language projection. You can however write a simple XAML app and take advantage of the existing support for binary composition. An example is provided on GitHub.

XAML also requires a limited form of reflection. This is mostly working but it needs a bit more time to mature and I need to figure out how XAML designer support can be integrated.

Support for creating collections is in the process of being rewritten and I’ll be including that in an upcoming drop. You can of course consume collections produced by the Windows API, but you cannot create your own collections very easily. Expect this in the next update.

Windows Runtime structures are currently projected quite sparsely. In particular, better support for Numerics is coming.

Clang support is experimental. The current Clang build for Windows doesn’t work too well with the RTM build of Visual Studio 2015. Debugging is not integrated and there is a mismatch between the Clang and CL compiler options.

Visual Studio and the IntelliSense engine still struggles a bit with the large headers and a lot of the metaprogramming, but the compiler is satisfied and that’s what counts. This is the reason why the Modern library is spread out across a number of headers rather than just shipping in a single header file. I’ve done a lot of work to simplify the code. Earlier builds of the language projection took a few minutes to precompile. The code was beautiful with elegant templates but compile time was a killer. I’m actively working on reducing precompile time, but it is already quite reasonable.

Finally, I was hoping to secure some kind of corporate sponsorship for the Modern project but that has not materialized. This means that I’ll be updating Modern as I have free time to commit to the project.


Clang and the Windows Runtime

A compiler developer recently challenged me to see whether Modern produces code that Clang can compile. The Modern compiler produces a C++ library that is effectively a standard C++ language projection for the Windows Runtime. Given that it is standard C++, surely the Clang compiler will be able to handle it. As you can imagine, a compile-time language projection is going to rely quite heavily on generic programming so it took about an hour this morning to tweak the base library to support the particular way that Clang interprets the C++ standard. It was mostly a bunch of warnings about missing typename keywords in template type parameters. A short while later I built the first app targeting the Windows Runtime with Modern C++ and the Clang compiler.


Universal Windows Apps with Standard C++

This demo shows you how Modern C++ for the Windows Runtime makes it easy to write apps for the new Universal Windows Platform with Standard C++.

It features a framework-less app using the new Windows Composition API. This API is still evolving and I plan to have a course available once it has been finalized. This is just a quick tour of what you can expect.

Now isn’t this the way you’d like to write apps for Windows?

By the way, in the demo I included “windows.applicationmodel.core windows.ui.composition” on the command line and yet I was able to reference Windows::Graphics in my app. How is that possible?

The Modern compiler automatically works out dependencies and includes them in the resulting library to ensure that all references are present. If you include the –depends option it will actually trace this out for you. Here’s what that looks like. Thanks to John Sheehan for raising this question.

C:\temp>modern library -include windows.applicationmodel.core windows.ui.composition -depends

Modern v1.22 - http://moderncpp.com
Modern C++ for the Windows Runtime
Copyright (c) 2015 Kenny Kerr


When Standard C++ Isn’t Enough

Last time I showed how Standard C++ lets you go beyond the compiler. Modern C++ offers the productivity of C# and performance that beats even C++/CX. Well if Standard C++ is so great, why isn’t anyone using it to write Windows apps with the Windows Runtime? Because Standard C++ is not enough.

Think about this. The Windows SDK for Windows 8.1 – counting only the Windows Runtime – includes about 2,450 interfaces amounting to around 10,880 methods. Windows 10 – as of build 10069 – is over 3,930 interfaces and 17,748 methods. It is naïve to think that C++ developers are going to use the ABI interfaces directly since they are tedious to use and were never intended to be used directly. It is further unrealistic to think that C++ developers are going to “wrap” those native interfaces with modern C++ classes to create useful libraries. All of the supposed productivity is lost when you have to spend countless hours first writing a library. I tried that before. Here’s another C# example:

CurrencyFormatter currency = new CurrencyFormatter("USD");

String result = currency.Format(123.456);
Debug.Assert(result == "$123.45");

I’ve created a currency formatter, set the rounding algorithm, and formatted a value. What about Standard C++? A lot of developers seem to think that C# is the most popular language on the Windows platform today because it is so much better than C++. It’s not, instead it’s all about the tooling. One of the main arguments for .NET was that it avoided the reference counting hell that C++ apparently produced. Proponents of this position would like to show you the example above written in Standard C++:

HSTRING_HEADER header = {};
HSTRING string = nullptr;
WindowsCreateStringReference(L"Windows.Globalization.NumberFormatting.CurrencyFormatter", 56, &header, &string);
ICurrencyFormatterFactory * factory = nullptr;
RoGetActivationFactory(string, __uuidof(factory), reinterpret_cast<void **>(&factory));

WindowsCreateStringReference(L"USD", 3, &header, &string);
ICurrencyFormatter * currency = nullptr;
factory->CreateCurrencyFormatterCode(string, &currency);

ICurrencyFormatter2 * currency2 = nullptr;

INumberFormatter * formatter = nullptr;

HSTRING result = nullptr;
formatter->FormatDouble(123.456, &result);

assert(wcscmp(WindowsGetStringRawBuffer(result, nullptr), L"$123.45") == 0);

But no C++ developer in his right mind would ever write code like this (and I haven’t even included error handling). Instead the C++ developer would naturally write something like this:

CurrencyFormatter currency(L"USD");

String result = currency.Format(123.456);
assert(result == L"$123.45");

There are no pointers and no reference counting that you can see. The compiler takes care of these details and in fact does so more reliably and more efficiently than the C# compiler is able to do since this code is inherently deterministic. While Microsoft claims that C++ has always been supported this is not entirely truthful. You can read more about C++ vs C++/CX here.

The problem is that Standard C++ is not enough. Good tooling is required. C# developers don’t use the C# compiler in isolation but download the 4GB Visual Studio tools. C++ developers need better tools in order to write apps and components for the Windows platform. Modern C++ for the Windows Runtime provides that tool. Modern works in conjunction with Visual C++ to provide a first-class developer experience for C++.


Why shouldn’t C++ developers get a classy type system with all the same productivity and unparalleled performance? Here’s how it works: the Modern compiler generates a complete language projection for Standard C++.


I can simply run “modern.exe library” and it will produce a language projection for the latest version of the Windows SDK that is locally installed. There are options to use an alternative SDK, only include certain namespaces (to produce a smaller library), and so on.


The result is a header-only library that I can include with a single line of code:

#include <modern.h>

This header is backed by a small set of headers mainly because the Visual Studio editor would choke on one large file.


The base.h header is the language projection itself. This contains all of the generic or metaprogramming that describes the bindings between modern C++ and the underlying ABI in such a way that the C++ compiler can chew on it at compile time. The sdk.* headers are essentially the metadata describing the various Windows API classes and other types that form the public surface area for the Windows API. While base.h is handcrafted, the sdk.* headers are entirely generated based on the Windows SDK.

The Modern library is also not simply a class library. It provides all of the building blocks you might need to drill in or tweak the performance of your app. You might normally be satisfied with the productivity of creating a CurrencyFormatter object as follows:

CurrencyFormatter currency(L"USD");

At other times you might want to create the activation factory yourself. The Modern library has got you covered:

auto factory = GetActivationFactory<CurrencyFormatter, ICurrencyFormatterFactory>();

You can then create a CurrencyFormatter object at your convenience:

CurrencyFormatter currency = factory.CreateCurrencyFormatterCode(L"USD");

This is obviously still far more convenient and reliable than using the ABI provided by the Windows SDK for C++ developers. There’s no reference counting, string handles, or pointers.

And then there’s formatting a currency value:

String result = currency.Format(123.456);

You might want to avoid an exception here perhaps to deal with any failures directly. No problem, Format is actually a method called FormatDouble on the INumberFormatter interface:

INumberFormatter formatter = currency;

String result;
HRESULT hr = formatter->abi_FormatDouble(123.456, set(result));

assert(hr == S_OK);
assert(result == L"$123.45");

As you can see you have all the control you might need, all of the productivity and safety you would expect, and all from your favorite C++ compiler thanks to Modern C++ for the Windows Runtime. Now what about C++? (19m3s) :)

Modern C++ as a Better Compiler

Last week I made the case that Standard C++ offers both productivity and performance and showed how C++ can be just as concise and elegant as C# and indeed more so. But I didn’t really address performance so let’s do so now. It’s trendy today to refer to your platform or framework of choice as being native. Everyone’s native these days. Even managed code is native. It wasn’t long ago that such a statement would have been greeted with incredulity but today it seems as if the marketing folks have hijacked the word and we’re all a happy native family. But performance doesn’t lie and when it comes to native code there’s nothing quite like Standard C++.

Here’s a question for you. Can a library outperform a compiler? With all of the talk about native code generation it’s helpful to remember that modern C++ is in many ways a code generator. The C++ community is literally bursting with impressive examples where smart C++ developers are coming up with ways of programming C++ at compile time in what is often called metaprogramming or generic programming.

But how can a library outperform a compiler? Standard C++ attempts to be the best possible language in which to write very efficient libraries. While parts of the language may be complex, libraries written in C++ should be easy to use. Modern C++ for the Windows Runtime is just such a library.

But how can a library outperform a compiler?! Doesn’t a library still need to be compiled? Well let’s run a little experiment and the Windows Runtime provides a good environment in which to compare libraries and compilers. You see, the Windows Runtime defines a binary platform that’s intended to be projected into different programming languages. When you write a Windows app in C# you are using the language projection provided by the C# compiler. The same goes for JavaScript and other language projections that I’ve heard of. But when it comes to C++ it’s a different story. Standard C++ is a different kind of language. Although it offers multiple programming paradigms it has a certain bias toward systems programming. This is why it’s so popular among operating system developers. It’s also not the kind of language that can support a language projection directly via the compiler unless you go and change the C++ language itself. This is precisely what the Visual C++ compiler attempts to do with its C++/CX language extension.

But that’s not how C++ was meant to be used. If the language doesn’t provide what you need then you can write a library. There’s no need to invent a new language or change the fundamental structure of the C++ language itself. Still, because the Visual C++ compiler offers up a compiler-based implementation of a Windows Runtime language projection we can now go ahead and compare the compiler’s performance against that of a Windows Runtime language projection implemented as a library using only Standard C++.

I’ll begin with a simple Windows Runtime component that offers up a class called Sample with a single static property returning an IVectorView of strings. An IVectorView is just a read-only vector with a portable ABI that is understood by different language projections. Using Modern C++ for the Windows Runtime I’m left simply having to implement this Strings method, which represents that static Strings property within the component:

class SampleFactory : public SampleFactoryT<SampleFactory>
    IVectorView<String> Strings()
        // code goes here

Since I’m implementing this component in modern C++, I can use whatever modern or standard libraries that I’m most familiar with as a C++ developer. Let’s use a few standard containers to build a really big vector of strings:

vector<String> values;
wstring const value = L"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";

for (unsigned i = 0; i != 10000000; ++i)
    values.emplace_back(value.c_str(), i % value.size() + 1);

I’m using the standard string to act as a sort of template and then I’m filling a vector of Windows Runtime strings with a range of values that look something like this:


And this will simply repeat until the vector contains ten million strings. So I have a really big collection of strings. I now need to pass it back to the caller and I can do that by simply wrapping it inside an implementation of IVectorView as follows:

return VectorView(move(values));

So my component’s static property boils down to this:

IVectorView<String> Strings()
    vector<String> values;
    // pump full of values ...
    return VectorView(move(values));

The VectorView function will create a COM object that implements the necessary interfaces such that this standard vector of strings may be transported across ABI boundaries very efficiently.

With the component implemented I can return to app development and see what this looks like from various language projections. First let’s look at C#:

var timer = new Stopwatch();
IReadOnlyList<string> strings = Sample.Strings;
long sum = 0;

foreach (string s in strings)
    sum += s.Length;

m_sum = sum;
m_elapsed = (long)timer.Elapsed.TotalMilliseconds;

I call Sample.Strings to retrieve the collection of strings and then use a C# foreach statement to iterate over the collection. The sum is just a sanity check to confirm that each implementation walked the same collection of strings. In this case I’m using the .NET Framework’s Stopwatch class to measure how long it takes to iterate over the collection.

This is a very simple and unscientific test but it should give us a good idea of how efficiently each language projection can iterate over a collection expressed in terms of Windows Runtime collection interfaces. There’s a lot of memory involved and a lot of virtual function calls. A language projection is going to have to be very careful to manage this efficiently, but I’m sure any decent compiler can figure it out.

I ran a release build of this C# version a few times and it consistently calculated a sum of 264999712 characters in around 2619 milliseconds. Now let’s take a look at C++/CX:

IVectorView<String ^> ^ strings = Sample::Strings;
long long sum = 0;
auto start = Now();

for (String ^ s : strings)
    sum += s->Length();

m_elapsed = Elapsed(start);
m_sum = sum;

In this case I’m using a pair of functions that use the operating system’s high resolution performance counter to measure milliseconds. Other than that, the samples are equivalent, the sums match, but the elapsed time is around 628 milliseconds. And finally we come to the standard C++ approach:

IVectorView<String> strings = Sample::Strings();
long long sum = 0;
auto start = Now();

for (String const & s : strings)
    sum += s.Length();

m_elapsed = Elapsed(start);
m_sum = sum;

Here again you’ll notice that the Strings property is projected as a method and it returns a vector view of strings without any hats. From a performance perspective, the ‘const &’ in the range-based for statement is purely a matter of style and convention and the omission of which would make no difference at run time. Again the sums match, but the elapsed time is even faster at 447 milliseconds!


Can a library outperform a compiler? It’s perhaps a bit of a philosophical question but it’s clear that the C++ compiler is insanely good at optimizing Standard C++. The library developer is also in the driver’s seat and is able to optimize everything from resource management, algorithms, iterators and adapters, and so much more. Clearly C# does not provide ‘native’ performance. Although C++/CX gets you a lot closer it does so by trading productivity and you lose the essence of the C++ language. I could go on to explain why C# is so much slower but the bottom line is that only Standard C++ allows you to do anything about it. And that’s the point. If you’re using C# or C++/CX you’re at the mercy of the compiler. Only Standard C++ lets you go beyond the compiler. Modern C++ for the Windows Runtime is for those of you who love C++ but also want to create Windows apps.

A Classy Type System for Modern C++

C++11 changed the game for C++ developers. We no longer need to defend the fact that C++ is so much harder to use than those other “modern” languages like C#. Because it isn’t. We no longer need to make a choice between performance and productivity. Because they’re not mutually exclusive. Standard C++ gives you both and Modern C++ brings it to the Windows Runtime.

Consider a simple C# example to determine the capabilities of any connected mice:

MouseCapabilities caps = new MouseCapabilities();

if (0 < caps.MousePresent)
    Debug.WriteLine("Buttons " + caps.NumberOfButtons);

I need to use the C# new operator to create a MouseCapabilities object and call its constructor. I can then use the various members to figure out what I can expect for my app’s input. The MousePresent property is intended to indicate whether a mouse is present, hence its name, but it can also be used (rarely) to determine how many mice are detected. As such, it actually returns an integer rather than a Boolean value and C# won’t implicitly convert an int to a bool. How well this works in practice is another story.

So why did I start with a C# example? The Windows Runtime was first and foremost designed with the CLR in mind. So much of the Windows Runtime architecture is the way it is purely to make it easier for the CLR even at the expense of language projections that don’t rely on this managed runtime. Still, the Windows Runtime is built on the foundations of COM using native code so Standard C++ has no difficulty going head to head with C#. Here’s the same example but this time using Standard C++:

MouseCapabilities caps;

if (caps.MousePresent())
    printf("Buttons %d\n", caps.NumberOfButtons());

This is in fact simpler than the C# projection of the same code. A new-expression is not required since that has a different meaning in C++. The C++ compiler is also happy to convert from int to bool for the sake of defining the if-statement’s condition. The only obvious difference is that Standard C++ doesn’t provide properties so those are projected as methods.

What if you need a variable for some class but you want to delay its construction. I can imagine needing a member variable but wanting to actually create it at some later stage. No problem, that’s what a nullptr is for:

MouseCapabilities caps = nullptr;
// some time later ...
caps = MouseCapabilities();

if (caps.MousePresent())
    printf("Buttons %d\n", caps.NumberOfButtons());

This is in fact very similar to how it appears in C#:

MouseCapabilities caps = null;
// some time later ...
caps = new MouseCapabilities();

if (0 < caps.MousePresent)
    Debug.WriteLine("Buttons " + caps.NumberOfButtons);

The Standard C++ examples above are using Modern C++ for the Windows Runtime, a Standard C++ language projection. But this is not what Visual C++ provides. Visual C++ offers C++/CX and at first it might seem quite convenient. Here’s the example again but this time using C++/CX:

MouseCapabilities caps;

if (caps.MousePresent)
    printf("Buttons %d\n", caps.NumberOfButtons);

C++/CX is not Standard C++ and it takes the liberty to add support for properties. Other than that, it appears much the same. Of course, if I want to delay construction of the caps variable then things quickly become more complicated. I cannot simply use a nullptr:

MouseCapabilities caps = nullptr; // error C2440

The C++/CX compiler mistakenly believes that MouseCapabilities actually resides on the stack and therefore a nullptr cannot possibly be converted to a MouseCapabilities object. It demands that you stray even further away from Standard C++ and use a weird little hat:

MouseCapabilities ^ caps = nullptr;

What does the hat do? Well nothing. It’s merely there to satisfy the compiler. It doesn’t change the nature of the MouseCapabilities class or how it is constructed. But now the rest of the example doesn’t compile either:

if (caps.MousePresent) // error C2228
    printf("Buttons %d\n", caps.NumberOfButtons); // error C2228

The C++/CX compiler now treats the caps variable as a pointer and helpfully suggests that I use ‘->’ instead and I lose all semblance of modernity:

MouseCapabilities ^ caps = nullptr;
// some time later ...
caps = ref new MouseCapabilities();

if (caps->MousePresent)
    printf("Buttons %d\n", caps->NumberOfButtons);

There are hats, another non-standard new expression, and the dreaded “member of a pointer” operator. It is no wonder that developers prefer to use C#.

Now let’s consider a slightly more interesting example that highlights the Windows Runtime’s classy type system. While COM and the Windows Runtime share a common foundation, COM is really about interfaces while the Windows Runtime is all about classes. Let’s turn back to Standard C++:

Uri first(L"http://kennykerr.ca/");

That’s an object representing a URI value with various properties and methods for parsing and manipulating such strings. I can combine this URI with another to produce a new Uri object:

Uri combined = first.CombineUri(L"articles");

And I can get its canonical string representation:

String string = combined.ToString();

assert(string == L"http://kennykerr.ca/articles");

I won’t bore you with more examples of C++/CX. Needless to say, this example would require more hats and more pointer semantics.

Modern C++ for the Windows Runtime preserves the classy type system that the original component author had imagined while ensuring that the representation at run time is nothing more than the underlying ABI interfaces. The author of the Uri class intended that developers should be able to call the ToString method as if it were a method of the Uri class, but under the covers it’s actually a method on a separate interface. Of course, with Standard C++ the developer is always in control. If you need to trade a bit of convenience for performance and want complete control you can simply retrieve the IStringable interface yourself:

IStringable stringable = combined; // QueryInterface

String string = stringable.ToString();

At this point I have an actual IStringable interface pointer at run time and the cost of calling ToString is precisely what you would expect and without the risk of a lazy call to QueryInterface that might throw off your performance targets.

What does C++/CX offer? A really big hammer called reinterpret_cast. You’re left scrambling for a smart pointer class and the language projection is gone entirely. By contrast Standard C++, thanks to Modern C++ for the Windows Runtime, even lets you reach down to the underlying ABI if you really want but you’re not on your own and the library will continue to support you every step of the way for things like reference counting and additional type support.

Given a Uri object, I can call modern projected methods as well as ABI methods interchangeably without needing to reinterpret_cast and I don’t have to think about reference counting:

Uri uri(L"http://kennykerr.ca/");

int port = uri.Port();

HRESULT hr = uri->get_Port(&port);

The world needs one C++. One Microsoft needs One C++. Modern C++ for the Window Runtime enables Standard C++ to be on par with C# for productivity and provides the unparalleled power and flexibility that C++ developers have come to expect.

Coming Soon

Modern is a header-only library designed to provide Standard C++ developers with first-class access to the modern Windows API. This includes complete support for the Windows Runtime as well as classic APIs such as DirectX.

In the coming weeks I’ll be sharing more about the Modern library but here’s a quick preview of what you can expect. The Modern library provides:

  • Standard C++ language projection for the Windows Runtime
  • The most natural way to use the Windows Runtime from C++
  • The simplest way to use DirectX without compromising performance
  • A single and consistent library for both DirectX and Windows Runtime APIs
  • More convenient than using C++/CX or WRL
  • No overhead compared to using the Windows API directly.

Supported APIs include everything you need to build both immediate-mode and retained-mode apps and games with the best possible performance:

  • Complete Windows API for Windows Runtime apps
  • Direct2D
  • DirectWrite
  • DirectComposition
  • DirectX Graphics Infrastructure (DXGI)
  • Windows Imaging Component
  • Windows Animation Manager

Consider an example from the Windows Runtime application model. An app must register for the Activated event in order to activate its CoreWindow object. Here’s what it looks like with the Modern library using Standard C++:

void Initialize(ICoreApplicationView const & view)
    view.Activated([](ICoreApplicationView const & sender,
                      IActivatedEventArgs  const & args)

By contrast, achieving the same thing with C++/CX requires noticeably more code:

virtual void Initialize(CoreApplicationView ^ view)
    view->Activated += 
        ref new TypedEventHandler<CoreApplicationView ^,
                                  IActivatedEventArgs ^>(
            [](CoreApplicationView ^ sender,
               IActivatedEventArgs ^ args)

Despite the use of a lambda expression in both cases, the second example using C++/CX is not nearly as concise and certainly not very convenient to type. With all of the hats (^) and -> operators it just doesn’t look like modern C++.

Modern is the library you’ve been waiting for to unleash standard C++ for Windows.