A second dark age for C++

The first beta of the .NET Framework arrived in 2000. As I look back at the decade following its unveiling, I cannot help but think of it as the first dark age of C++. Following on the success of Java, Microsoft likewise chose to distance itself from its strong roots in C and C++. The mighty developer division embraced managed code and worked tirelessly to build incredible tooling for C#. For a time the Visual C++ team tried to play catch-up with not one but two different language extensions for the Common Language Runtime (CLR), but they quickly realized that they were the unwelcome guest at the party. Thankfully, they returned to their roots in native code and so began the C++ renaissance championed by the likes of Charles Torre and others. This eventually culminated in amazing achievements such as the Concurrency Runtime, C++11 and dramatic improvements to the Visual C++ C Runtime (CRT) and Standard Template Library.

Just over ten years following the arrival of .NET, Microsoft announced Windows 8 and the new Windows Runtime. While .NET had arguably succeeded splendidly on the server, it always had an uneasy relationship to the Windows client mainly due to poor performance and the lack of a universal UI framework. With the advent of smaller devices, the operating system group decided to remedy the client problem by returning to the proven performance of C++ and the essentials of COM. The Windows Runtime would become the universal platform for not only the ultimate XAML implementation but also the entire Windows API.

At this point, any optimistic C++ programmer would be forgiven for thinking that the dark ages have passed and good times are ahead. Unfortunately, while the operating system group has embraced C++, the developer division remains largely unchanged. The CLR was retrofitted with support for the Windows Runtime. This is beyond ironic since .NET was specifically designed as a departure from COM with an incompatible vtable model. Performance isn’t great despite the fact that the Windows Runtime does make a number of concessions for the CLR, but at least most of the heavy lifting is now done by the operating system so C# code gets a pass.

While the operating system group has embraced C++, the developer division continues to champion C# as the tool of choice and the Visual C++ team continues to focus on standards compliance and more recently cross-platform development. Little has been done to support the Windows Runtime, certainly nothing that has captured the hearts and minds of C++ developers. C++/CLI was dusted off – a language extension designed for a garbage-collected runtime – and now offers an unnecessarily complex way to work with the Windows Runtime that makes no sense for COM. C++ is a language for library developers. The library developer’s job may not be a simple one, but you certainly have the tools at your disposal to do some amazing things. So when you hit some feature that isn’t directly supported by the language, then you write a library – you don’t go and invent a new language or write a set of language extensions. Prior to C++11 you could be forgiven for thinking in that way, but not now.

Microsoft desperately needs an infusion of modern C++ for Windows. The Universal Windows Platform built on the Windows Runtime is the ideal environment for C++ to thrive. What is missing is the determination to make it happen. Modern C++ for the Windows Runtime is the jumpstart that the Windows platform needs but it cannot happen without the support of both the operating system group and the developer division.

Jim Radigan has done some incredible work bringing code written for Android and iOS apps to Windows. Now we need to bring modern C++ to Windows as well. The C++ community is stronger than ever and forging ahead with incredible innovations to the C++ language and standard libraries. Will Windows be part of this new C++ renaissance or will this be another dark age for C++ programmers on the Windows platform?

42 thoughts on “A second dark age for C++

  1. jponsager

    I hope your post is noted by those driving the planning sessions. I suspect you are making more of an impact than you may think. I am looking forward to the buzz that will be created when moderncpp gets some traction.

    Reply
  2. petke

    Have you got any feedback from Microsoft on your moderncpp library? I think people might be a bit vary of using an unofficial windows library. In the best of worlds, Microsoft would officially endorse it and make it part of their sdk. Is there any chance of this happening?

    Reply
  3. Tim Dawson

    I think you’re barking up the wrong tree. You can’t make people suddenly think that C++ is a credible language for modern line of business or productivity apps. People just plain LIKE C# better. I read your blog, have done for years (met you once in the UK) but I just feel sorry for you these days as it seems a bit like you’re one of the last ones standing.

    Reply
    1. ami

      wow hahaha so blind Tim. That’s why we all today live with so many bad things. Yeah sure keep taking shortcuts and when time comes to pay the price for it then run in some other random direction=language.

      Reply
  4. DBJ

    Modern data center is limitless. But it depends on Energy. This is why .NET is NOT in favor on the server side, or is quickly replaced with C/C++. Deal with it.

    All kudos to Kenny. I agree 99%.

    Reply
    1. Jake

      There is no such thing as C/C++. They are two completely different languages with different idioms, patterns and style. This is even more true in the “modern c++” age. You would also learn the languages in a completely different way. Being an awesome C programmer does not make you a good C++ programmer at all, and vice versa.

      Reply
      1. DBJ

        @Jake by “C/C++” I mean C and C++. Two different languages. Are you OK now with my comment?

  5. Tim Dawson

    “Everyone else is wrong!”
    I honestly wonder how many times, or for how many years, you’d have to be proved wrong by the market before you might just give in and accept what was happening.

    Reply
      1. Turulo Manco

        My company bought that piece of “engineering” for a project. Would I be that guy, I would change my name, and delete the site. ASAP. And start cooking show or something.

  6. Fallon

    This is a classic chicken & egg. The developer wants to be compensated by someone before the product has been proven, but no one wants to do this without some proof.

    Singing praises isn’t proof, widespread use is proof, but there are so few users that whatever is wrong may never get exposed, and who wants to pay for the privilege to test code from a non-giant corp like MS 🙂

    Maybe someone from MS will take a chance on this, if so, we’re off to the races. If not, either give it away for free and see if it gets wide use and the bugs get worked out, and MS is more likely to give someone the payday!

    Failing that… it’s likely a road going nowhere.

    Reply
  7. jeremiahmorrill

    “You can’t make people suddenly think that C++ is a credible language for modern line of business or productivity apps. People just plain LIKE C# better.”

    Regardless of what ‘people’ like, C++ is something that some ‘people’ NEED, even you, if only indirectly. Certainly folks can get pretty far with JavaScript as anyone can see with node.js, but what enables it’s environment and it’s rich ecosystem of extensions? C++. The same with WinRT. It’s the heavy lifting of C++ code that allows developers to enjoy their preferred language in this environment. Don’t you think it’s worth it to better enable C++ developers with better tools?

    Tim, its fine to like your Duplo Blocks, just realize you can’t manufacture them with more Duplo Blocks.

    Reply
  8. Lex Lavnikov

    C++ for libraries make less sense due to cross-platform issues. A good example of this issue is SQLite – writing ARM/x64/x32 code is just PITA. Having performance advantages, bringing deployment nightmare. Add here different app stores (Xamarin) and the hell breaks loose.

    Reply
      1. Lex Lavnikov

        As far as I understand, the only advantage of C++ compiler over C# is the platform optimizing compiler. That means your library compiled for x86 CPU cannot be linked with your ARM application. Unlike .NET AnyCPU libraries.

  9. danielflam

    There are many reasons C++ will never catch up off the top of my head:

    1) The “finally” exception handler is missing. Yes I know “You don’t understand the paradigm”. It’s a huge missing feature and hole.
    2) properties. Yes they are needed, and would cut a lot of useless drudge coding.
    3) class of class (metaclass) – class factories built into the language.

    One could make the language more friendly for programmers, without sacrificing usability.
    The reason I think so is because if anyone ever used Delphi/Object pascal and seen the code it produces (which is as fast as C++) would know what I am taking about.

    Reply
    1. Miguel

      You’re so right!!!!, I’am a delphi developer for almost 15 years, and your comment ring the bell so loud… 🙂

      Reply
      1. jeremiahmorrill

        Exactly. Much like IDisposable, the “finally” keyword is added to deal with non-deterministic resources. C++ already has this, so finally would be redundant.

      2. spectecjr

        Hmmm… RAII is just one way of skinning that cat. RAII is not the be-all and end-all though. For a start, it has a semantic load. (You now need to track another class in your head, and/or write one for each circumstance). It’s relatively bullet-proof, but you could also say that RAII developed out of the need to have a finally-like mechanism. The two could co-exist happily.

        There’s also a big difference between “can” and “can do cleanly and easily for the common case”. Properties are an example of this. (You can implement everything you can do in C++ in assembly, but I don’t do that often any more, because it’s onerous).

    2. Mark

      FWIW, I use Remobject’s Oxygene. Pascal/Delphi language, but able to make .Net, iOS, and Java apps.

      Reply
    3. David

      Do you really think a programming language could fail just because it doesn’t contain that particular set of features? C++ gives you powerful abstraction tools and low-level access to hardware/cpu/memory, both at the same time. There is no garbage collected language that could catch up C++.

      Reply
  10. Jasmine

    That “renaissance” seems to happened only at one group at Microsoft, so it doesn’t really counts as a global trend. In any case, the language will cover effectively some things that no other language can do, at least for now and the foreseeable future. But do not expect that LOB software or productivity software will start being written in C++, sorry. And Microsoft should have invested in better tooling for C++ very long ago. But they did not and now it is just too late.

    About WinRT: Microsoft has long lost the consumer space and only the Enterprise one is relevant to them, i.e., the companies that are built on their technologies. But companies, are still running on Windows XP (!) and Windows 7. Some do have Windows 8, yes, but most of them have disabled Store apps downloading for their employees. In other words, no one really cares about the Store and thus, technologies around it are irrelevant. And companies like/prefer to buy software from vendors or web sites that they know and maybe can verify, not from an unknown source like the Store. Stores are compelling to a consumer but not to a company. But hey, Microsoft copies everything from Apple these days, even the bad stuff!

    WinRT maybe a very fine API but Microsoft do not make anything to promote that. Instead, they hamper our productivity with crap things like “side loading” and the like. I understand that they want to make a pc a safer place for the use but i am not sure this is the correct way to go. Maybe there is no “correct” way to do so.

    In any case, if things around WinRT do not get changed, some great works, like Kenny’s here, will never gain any traction…

    Reply
  11. Dan

    I’m with the author 100%. I maintain products in both c# and native c++. I enjoy using c# more because of all the effort Microsoft has thrown into the gui and other support libraries. However, one of our products simply cannot be moved to c# for performance reasons. Even the gui of this product still must use the older common controls and mfc. If I attempt to make it a mixed mode application it weighs it down and becomes slow. The customers do not want this at all. There are thousands of apps that still fall in to this category. c#/.net is 10 times easier to get something done in, but it is also 10 times more sluggish. c# was built on the premise that CPU individual cores would keep getting infinitely faster, but we have sort of leveled out…

    Reply
  12. smallmountain

    What is having a renaissance is native code, versus managed code. Managed code in full trust scenarios does not make sense. It just slows everything down. C# has a great developer productivity story, but a poor optimization story.
    Microsoft also completely abandoned desktop application developers. WPF was never all that was promised. But what Microsoft did for the Windows Runtime was to combine XAML and native code. Why can’t desktop developers have this? Is it just over for us? The application development framework that Microsoft offers for native code desktop application development is MFC, which is older than the Internet. That is a massive, epic, failure.
    So, I agree with Kenny. C++ is a portable language. Microsoft needs to offer a modern native code application development framework that supports multiple overlapping windows.

    Reply
    1. Mike

      So true. The story of UI frameworks for native desktop apps on Windows is simply embarassing. In my day to day job I still have to work with “right on the metal” ATL/WTL. While these two are still better than MFC they are lightyears behind the stuff that my OSX colleagues use for their native UI. Composing a UI is so much work by hand, there is nothing like XAML or MVVM. Dialog resources, localized strings are still managed in archaic RC files and the list goes on and on.

      The big promise about 10 years ago was that .NET will completely replace native development on the desktop. This failed completely from my point of view because they have the same weakness as Java had with Swing: .NET-Apps don’t feel native, they load quite slowly and also run slowly. I only can imagine how the different product groups within MS bake their own UI framework on top of Win32 or really rely on ancient MFC or WTL. But we as outside native developers are left alone with tools/toolkits that are from the pre-Internet era.

      Some will say: use Qt, or WxWidgets or whatever toolkit you like but first this is only a workaround for this debacle and second sometimes it’s simply not possible to include a big 3rd party toolkit in your product so your left with the available MS-Stuff.

      Reply
      1. Timothy

        “…they load quite slowly and also run slowly.” Are you using a computer from 2002? .Net desktop apps are incredibly fast. I’m not going to take a side on managed vs unmanaged being better, because i think both have strengths suited to different scenarios, but .Net on the desktop is fast. if a particular .Net app is not fast for you, it likely wouldn’t be any faster in native code because whoever wrote it didn’t know what they were doing.

  13. k. montgomery

    Why can’t we all just get along?

    Maybe you can communicate this up the chain to your managers….

    I started my career with C and C++. I spent an enjoyable decade doing C++ with MFC, before ATL came along and spoiled everything. I moved on to C# because it is a better fit for what I want and need to do. But I recognize that C and C++ are still necessary for systems work. I just don’t want to use C++ for my GUI work anymore.

    This is a call out to both DevDiv and WinDiv. Get your collective acts together! Cooperate or you will both begin seriously bleeding developer interest; perhaps it has already started.

    I want to program in C#. I want the best performance possible out of my programs. That may mean compiling C# to native. It definitely means a core .NET in C++, built for reliability and performance (in that order).

    I DO NOT want to have any COM++ (or whatever it’s called) bleed-through into .NET or my applications. I’ve been there before, I do not want to return. Maybe others do, but not me.

    Reply
  14. Kees Koets

    Yep, quite a renaissance indeed. I guess that’s why Microsoft still trails e.g. CLANG and GCC in terms of supporting the c++11 & c++14 standards, by some distance.

    Reply
  15. brutally frank

    it would be nice if microsoft would embrace C/C++ and keep pace with the C/C++ ISO/IEEE organizations, and not try to deviate to be different. sooner or later intel will be giving away it’s tool suite for free.

    Reply
  16. Jeff Lewis

    I’m sorry – but this entire article suffers from the classic ‘I’m right – why don’t you see it?’ mindset.

    First, for the VAST majority of applications, .Net is simply more than fast enough. The performance argument simply doesn’t apply. Games, no – not fast enough – and guess what? In games, they use C++. Well, some games – actually, for a lot of lighter weight games, .Net is actually good enough.

    On the other hand, C# and .Net offers such a huge range of support, simplicity and completeness that it simply blows C++ away for ease of coding and maintenance. With the advent of Xamarin and Mono, the ‘crossplatform’ argument also mostly goes away.

    Finally, we’ve invested 15 years into .Net as developers. It does what we want and does it well. Why would we switch *back* to C++ without a really compelling reason? Modern C++ is still Old C++ with some improvements. It’s still clumsy compared to Java or C#,

    It has a place, it isn’t going anywhere – there are still many things for which C++ is really the best choice – but the idea that it’s coming back is silly. The concessions the Windows RT team has had to make to the .Net community shows that.

    Reply
  17. Bret Kuhns (@bretkuhns)

    It seems evident to me that this post and others you’ve made on the internet (Modern’s website, CppCast, Twitter) imply that you’ve approached Microsoft about adopting this library and they’ve turned you down. You’ve become very doom and gloom about C++ on Windows as a result.

    But, you’ve not yet provided a compelling reason why your Modern library would benefit from adoption by Microsoft. Nor do I see how Microsoft directly benefits. They inherit yet another way to write against WinRT with C++, meanwhile the two existing options (WRT and C++/CX) were designed to satisfy the needs of their teams internally (let’s face it, that’s who these options were designed for).

    I’d suggest the only obvious direction that Modern should take is to become open source and let the community show Microsoft that C++ is worth paying attention to. Modern’s website (on its licensing page) has been updated to suggest the only remaining option is to offer a subscription paid license in order to support the development of the library. If embraced by the community, however, your personal cost of development aught to go down significantly. Form a skeleton foundation (which can act as a steering committee), rally people behind the cause, get people involved. That’s how this thing succeeds. You don’t need Microsoft to push this for you.

    If you want to be compensated for Modern, then make the open source license reasonably restrictive (eg, consider LGPL, like Qt does). This should compel commercial users to pay, while simultaneously supporting a larger community of individual developers who want to do new and creative things with the help of a library like Modern.

    Reply
  18. Blade

    I don’t even know C# in the slightest bit, I had to briefly debug something in it once, and write a quick patch, but other than that, I’ve never touched it.

    But, in any case, fanboyism for languages is just.. weird.

    Reply
  19. amitygames

    C++ rules!!!

    C# was an attempt to compete with Java and create a captive audience of Windows developers. It can be argued it has been successful at that, but it’s really NOT a step forward from a developer standpoint. It’s just a business weapon.

    Just stick to C++. Good developers do not need managed languages anyway. The non-good developers can always go write Javascript code in their browsers.

    Reply
  20. Jesse Good

    > Modern C++ is still Old C++ with some improvements.
    @Jeff Lewis: That is a huge understatement. You could go as far as to say it is a completely new language.

    Concerning the main article:
    >So when you hit some feature that isn’t directly supported by the language, then you >write a library – you don’t go and invent a new language or write a set of language >extensions.

    While I fully agree that C++ library support is one of its biggest problems, inventing a new language allows you to think at a completely different level of abstraction (although these abstractions leak sometimes…). C++ compiler errors and compilation method would both be good examples of this I think, a new language allows you to overcome both these problems while a C++ library cannot. Having said that, higher level abstractions are not always a good thing and I think C++ has much more potential (better library support, tooling, etc) than the current situation.

    Reply
  21. wiktorwandachowicz

    I have to add something maybe controversial, but for me a portable C++ library is Qt. Writing applications using Qt is intuitive, and the Meta-Object Compiler (moc) handles Qt’s C++ extensions. I like to say that working with Qt is like programming in C++ on steroids.

    Actually I find that QString is the best C++ string class I have ever worked with (std::string and std::wstring just don’t cut it). It handles Unicode in a very friendly way, and it’s on par with Java, C#, and Delphi strings.
    Of course there’s more to Qt than only QString (it helps with a lot of modern problems, like GUI, data containers, event handling, networking, XML, concurrency, databases, OpenGL – the list goes on). But for open-source cross-platform programming in C++, Qt is the way to go.

    The only one contender that in my opinion may lead with regard to cross-platform native code is Embarcadero’s RAD Studio with FireMonkey framework (and they have C++Builder IDE too, with C++11 compiler based on LLVM). So there are at least two good options for C++ developers, even now.

    (and that’s from a developer that used C++, TurboPascal, MFC, Delphi, Java, C#, JavaScript and PHP on Windows and Linux platforms for over two decades already…)

    Reply
    1. Kenton Wilson

      Qt has a number of issues which make it very undesirable:

      1) The requirement to process code with the meta object compiler (moc) in order to achieve signal / slot binding is an abomination and completely unnecessary.

      2) Qt wants most everything heap allocated which flies in the face of modern C++ practices..

      3) Qt has made ridiculous and unnecessary pseudo C++ language extensions.

      4) The addition of container types which duplicated existing standard C++ library types or new types whose purpose is questionable.

      5) Ditto item four for algorithms.

      Lastly… Instead of addressing the above deficiencies and aligning Qt with modern C++ practice, someone at Qt thought it would be a good idea to make it even less C++ like by adding Java style iterators. Yeah, that’s the ticket!

      Reply
  22. William

    The problem with this article is it assumes Microsoft development which is not optimized to run as fast as possible in Windows with C++ is a “Dark Age.” And “The Universal Windows Platform built on the Windows Runtime” c’mon, really??? The future of e-commerce lies in cross-platform development, where a single code base can run on multiple operating systems. Unless you’re writing a video game that must maintain a certain frame rate, absolute efficiency is not as important as cross-platform compatibility & reusability.

    C++ / CLI has the feature of being able to provide a bridge between C++ & C#. I wish people were trying to write cross platform C++ / CLI compilers that would connect C# & C++ on multiple platforms, but that gets into platform specific headaches & not many people seem interested, sadly.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s