SQLite with Modern C++

My latest course, SQLite with Modern C++, is free for a limited time on Pluralsight. If you don’t yet have a Pluralsight subscription then be sure to check it out right now.

SQLite370_svg

If you do have a Pluralsight subscription, be sure to check out my growing collection of courses. My next course, Windows Runtime Internals, will also be available to subscribers within a few weeks.

Modern C++ and the Universal Windows Platform

I have started publishing information about the Modern C++ project at moderncpp.com and I hope that you’ll go and take a look to see what I’ve been up to. Subscribe here for updates or follow me on Twitter:

I recently made the case that Modern C++ for the Windows Runtime offers the productivity of C# and performance that beats even C++/CX. Surely this would be tremendously valuable to the Universal Windows Platform. And I topped it off with my biggest video demo yet of the Modern library.

1. A Classy Type System for Modern C++

2. Modern C++ as a Better Compiler

3. When Standard C++ Isn’t Enough

Video: Universal Windows Apps with Standard C++

I’m off to work on my next course for Pluralsight entitled Windows Runtime Internals, but I’ll be back to continue the work of bringing modern ISO C++ to the Windows platform.

Adding Compile-Time Type Checking to Printf

Here’s my article in the May 2015 issue of MSDN Magazine. This is the special edition of the magazine that was available at Build 2015.

Adding Compile-Time Type Checking to Printf

I explored some techniques for making printf more convenient to use with modern C++ in my March 2015 column. I showed how to transform arguments using a variadic template in order to bridge the gap between the official C++ string class and the antiquated printf function. Why bother? Well, printf is very fast, and a solution for formatted output that can take advantage of that while allowing developers to write safer, higher-level code is certainly desirable.

While this is a convenient bridge between modern C++ and the traditional printf function, it does nothing to resolve the difficulties of writing correct code using printf. printf is still printf and I’m relying on the not entirely omniscient compiler and library to sniff out any inconsistencies between conversion specifiers and the actual arguments provided by the caller.

Surely modern C++ can do better.

Enjoy!

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>
{
public:
    
    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:

A
AB
ABC
ABCD
ABCDE
ABCDEF
ABCDEFG
...

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;
timer.Start();

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

timer.Stop();
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!

perf

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.

Visual C++ 2015 Brings Modern C++ to Legacy Code

Here’s my article in the April 2015 issue of MSDN Magazine:

Visual C++ 2015 Brings Modern C++ to Legacy Code

Systems programming with Windows relies heavily on opaque handles that represent objects hidden behind C-style APIs. Unless you’re programming at a fairly high level, chances are you’ll be in the business of managing handles of various kinds. The concept of a handle exists in many libraries and platforms and is certainly not unique to the Windows OS. I first wrote about a smart handle class template back in 2011 when Visual C++ started introducing some initial C++11 language features. Visual C++ 2010 made it possible to write convenient and semantically correct handle wrappers, but its support for C++11 was minimal and a lot of effort was still required to write such a class correctly. With the introduction of Visual C++ 2015 this year, I thought I’d revisit this topic and share some more ideas about how to use modern C++ to liven up some old C-style libraries.

Enjoy!

Using Printf with Modern C++

Here’s my article in the March 2015 issue of MSDN Magazine:

Using Printf with Modern C++

What would it take to modernize printf? That might seem like an odd question to many developers who believe that C++ already provides a modern replacement for printf. While the claim to fame of the C++ Standard Library is undoubtedly the excellent Standard Template Library (STL), it also includes a stream-based input/­output library that bears no resemblance to STL and embodies none of its principles related to efficiency.

This is partly in response to a brief defense of printf that I published late last year. Enjoy!