Enough gossip. What I want to share with you today is a small change that was made to lambdas in the C++ compiler to allow them to be implicitly converted to function pointers. I can just hear you say, who cares?! Well again, if you forget for a moment that Windows 8 was also released you may recall this vast library called the Windows API that, by the way, Windows 8 was written in and you may also recall that a great many of these libraries were extensible by means of function pointers.
What this means is that you can now use lambdas to write these callbacks rather than having to define them elsewhere. This can introduce significant savings in complexity. Consider the TrySubmitThreadpoolCallback function from the Windows thread pool. Prior to Visual C++ 2012 if you wanted to allow a lambda to be submitted to the thread pool you would have to first create some concurrent queue and then have at least two functions. The first would queue the lambda-turned-function object before calling TrySubmitThreadpoolCallback. The second function being the actual callback function that would dequeue the function object from the concurrent queue and call it. That represents quite a lot of coding and run-time overhead just for the convenience of using lambdas.
Now thanks to the Visual C++ 2012 compiler you can use lambdas with the Windows API with no overhead whatsoever. No concurrent queue. No function objects. Just the thread pool.
TrySubmitThreadpoolCallback((PTP_CALLBACK_INSTANCE, void *)
printf("hello from the thread pool\n");
Clearly this only works for stateless lambdas as they are binary-compatible with function pointers whereas lambdas that capture variables are not. Still this represents a nice improvement for the C++ programmer on Windows. Enjoy!
My latest column for MSDN Magazine is now available online as well as in print.
If you work for a company that has one of those coding standards documents that would annihilate an entire rainforest were it ever to be printed, you’d better stop reading now. Chances are, what I’m about to show you will violate many of the sacred cows in the aforementioned epic. I’m going to tell you about a particular technique I originally developed to allow me to write completely asynchronous code efficiently and without the need for complex state machines.
I hope you enjoy it. This is the first of three articles where I explore alternative techniques for achieving concurrency in C++. Thanks to Artur Laksberg from the Visual C++ team for reviewing the drafts and providing valuable feedback.
You can find links to more of my articles here.
Microsoft has a long history of churning out technology, then confusing everyone with weird and wonderful marketing names for it, then encouraging otherwise smart people to write complete nonsense about it. I am confronted by this every few years when the next big wave of technology arrives from Microsoft. I could write endlessly about this but since I have a pile of work, I need to keep this brief.
I am not knocking the technology as much of it was good for its day and served a purpose, but the stream of API names can leave developers confused. To access some data, should I use ADO or ADO.NET or DAO or RDO or MDAC or ODBC or OLEDB or MSDASQL or System.Data.SqlClient or System.Data.OleDb or System.Data.Odbc and so on? I could tell you the answer but I do not think anyone cares anymore.
It can also get confusing when the hardware changes. For years, “Win32” represented the world of Windows application programming – to contrast it with the former 16-bit APIs. Then AMD and Intel introduced 64-bit microprocessors and Win32 became the “Windows API” even though the API stayed the same. Then Windows 8 happened and there were “Metro-style” apps and “desktop” apps. Now Metro is no longer in vogue and the Metro apps will presumably be called “Windows apps” and the desktops apps … well let us just pretend that desktop/Windows/Win32 apps never happened shall we.
So branding is a problem for Microsoft. That is ok. I am sure it keeps many people happily employed.
Then there is the complete nonsense that inevitably flows from ignorant sources and is then propagated around the web. When the .NET Framework was “it”, there were popular rumors that “Win32” was dead and that .NET – obviously written directly on the kernel – would take over the world. Oh, and by the way your .NET code would be much faster than native C or C++. As I said back then, this is nonsense and much of the .NET Framework was written and continues to be written with the native Windows API.
Now we have Metro and the same thing is happening. Apparently, it was written directly on the kernel – whatever that means – and so the Windows API is dead and somehow .NET is also a casualty. Again, this is not true. Metro was written using the existing windows APIs. As time goes on more of it may be written specifically for WinRT but the legacy will remain for a long time to come. But do not take my word for it. If you are a programmer, get your favorite debugging tools and look for yourself. If you do not know how then pick up a copy of Windows Internals by Russinovich.
Enjoy the ride. Do not be fooled. Remember that this is still Cutler’s Windows.