C++ is a great language for writing applications that will run on a number of platforms. There are compilers for many different platforms, and some powerful libraries you can use. Still, in the end your code needs to talk to the operating system, and that means that most cross platform applications have at least a few little corners where platform-specific code lives. The challenge is how to ensure that your Windows code runs on Windows, your Linux code runs on Linux, etc, without maintaining a number of different branches or hand-merging and splitting every time you deploy.

Being C++, an unspoken requirement in solving this problem is "be as fast as possible". Putting everything through a library and paying for extra indirection, looking up something that cannot change once the program has started executing, is not as fast as possible. You also want developer convenience and productivity. If you support five platforms, and something is the same on four and different on one, copying that code around for the four that are the same is not a productive way to behave. You would like a default behaviour, and then special code for special cases.

Michael Tedder has an intriguing approach using templates. As he says:

Instead of declaring a base interface class with virtual functions then deriving each platform with a different implementation, we declare a class with one template parameter — a platform ID — then specialize it to provide a different implementation for each platform.  The template class is then typedef‘d to expose the specialization for the platform ID being compiled to the application, allowing the implementation to be used without any virtual functions and also allow for inlining of functions as well.

He has some pretty convincing armwaving about using this not for just Windows/Linux/Android but for any hardware differences even on the same operating system - like what kind of graphics architecture you have or anything else that can't change at runtime. It's a good example of how the power of templates makes things possible that would always incur a runtime cost in any other language, or a significant burden on a developer to move code around building custom versions of an application. Worth a read!

Kate

Here's an interesting project I came across:

The game is Mastermind, which many people already know. What caught my attention is that it's done in C++ and XAML. To quote Tyler Whitney's blog post,

The Mastermind code sample demonstrates how to create a simple Silverlight storyboard in Expression Blend 3, and then provide the code for the state transitions in Microsoft Visual Studio 2008. You can also see how to create brushes programmatically and how to add a title bar to a Silverlight-based app.

The code is on the Microsoft Code Gallery (only Microsoft Employees can publish there) and Tyler has been updating the article over the summer. Nice way to see how to combine two technologies some people would never thought have combining.

Kate

I have talked about plenty of C++0x (soon to be known as C++11 or just plain C++) features over the last little while. Here's a nice summary by Danny Kalev of the top features and why they matter. He covers lambdas, auto, the new ways to initialize instances (which hasn't been covered much elsewhere and contribute a lot to readability), suppressing default versions of functions (like constructors for example) or specifically requesting them (how cool is that?), nullptr (which I love because it eliminates a late night drinking argument about "what if someone #defined NULL to 3, would your code still work?", and rvalue references -- and those are just the language changes! His library coverage is super terse, but there are links in it if something (*cough* shared pointer *cough*) catches your attention.

There's no reason for a C++ developer to ignore C++11. This is big stuff, and reading these "what's new" lists from a variety of different people is essential for getting perspective on the changes. So read Danny's list!

Kate

Everyone knows that C++ is the language to use when speed matters. That's just a known fact. So here's a question: if you solved the same problem in both C++ and C#, using the generally available languages (the Standard Library for C++, the .NET Base Class Libraries for C#) and you didn't happen to know which parts of those libraries weren't implemented very efficiently, just wrote your apps -- which would come out faster and by how much?

Think you know? Of course, the answer is "it depends". Debug or Release builds? Laptop or handheld device? Whose implementation of the .NET Framework are you going to use - Microsoft or Mono? What chip are you running on? Oh, and to what extent are you deliberately setting C++ options that emphasize runtime speed? Also, did you choose an algorithm with a lot of generics or templates? C++ has a huge perf advantage there, but lots of benchmarks don't use generics or templates since they are solving one specific problem.

An article on CodeProject leapt into all of this feet-first and did some measuring. Along the way, "Qwertie" proved a universal rule of the internet: nothing will get you the answers you seek faster than posting the wrong answer. Want to know the exact date Bewitched switched Darrens? Find a place that discusses old TV shows and post your belief that there was only one, or that there were seven, or whatever, and people will correct you while the ads are still loading on their copies of the page. When Qwertie posted the first version of the benchmarking article, commenters were quick to say "but you made this mistake, and that mistake, and forgot this other thing" all of which led to a much better article.

Definitely worth a read. It gets you thinking about the things that truly affect performance. Absent-mindedly deploying a Debug build is going to cost you far more performance than your language choice ever will. Using a library in a performance-sensitive situation without understanding whether the library is high-performing or not will too. It's chock full of graphs like this one:

Don't read it to find out the answer to "is C++ faster than C#?" - we already know that. Read it to find out how to make your applications faster.

Kate

Months ago, I tweeted "Once you have a hammer, everything looks like a nail" with a link to an interesting article about the times you shouldn't use System.DateTime.Now - sure, you know how to use it, but it's not always the right tool for the job. Keyvan Nayyeri provides a number of alternatives for .NET developers who want to know when something happened, or how long something took. Definitely worth a read.

Then just weeks after that, Susan Ibach gave the SQL side of the story with a blog post about avoiding the DATETIME type if you're using SQL 2008. I saw the headline and thought "what? what else would I keep a date or a time in?". The answer is, either something smaller or something with more precision. Makes sense.

Goes to show, just because you've heard of System.DateTime in .NET or DATETIME in SQL doesn't mean there's no other way to solve your problem. Keep learning!

Kate

When I provide links from this blog, I don't shorten them. When I get a link in an email, I always hover over it to see where it leads, in case it's a phishing email. But when someone emails you a shortened link, or tweets a shortened link, how do you know where it leads? It might be a phishing link. Or it might just be that cat video you've seen too many times already.

Years ago, Joshua Long wrote up a summary of how to see where a shortened link goes before you click it, and he's been updating it pretty regularly. He covers TinyURL, bit.ly and its relatives like on.fb.me, goo.gl, is.gd, and many I've never heard of. There's even a site you can paste a shortened link and get back what it redirects to. Not all links will be worth this treatment, but many will. It's nice to have a summary of how to check them before you follow them.

Kate

I'm pleased to see that Kenny Kerr is writing his C++ column for MSDN again. He's also blogging again and in a recent entry, he provides some really plain-spoken advice to people looking for guidance:

• "You can of course still use MFC but I do not recommend it as modern C++ can do a better job of supporting the Windows developer."
• "You should never again use auto_ptr for anything."

So there! I agree with these, especially the auto_ptr one. It was an attempt at a smart pointer that just wasn't smart enough. We have shared_ptr and unique_ptr now and they work in collections and are truly smart pointers. Use them and stop typing delete in your code entirely.

As for MFC, it does fill a need and I certainly wouldn't scrap a working MFC app just because the library is getting old (the facelift a few releases ago helped) but if I was starting a brand new application from File, New Project I would need a good reason to use MFC as my UI framework.

Kate

People often ask me what Visual Studio Ultimate offers that other versions do not. There's a handy chart on the Microsoft site:

The only problem is, if you don't know what "Architecture and Modeling" includes, it's easy to think there's probably nothing useful in there. So I was pleased to see a blog post by Susan Ibach from Microsoft Canada showing how easy it is to generate a sequence diagram from code, and how that can help you understand code you've inherited from a predecessor. That's one of the diagramming tools included in Visual Studio Ultimate.

Right click in some code, select Generate Sequence Diagram, set some options (does getting a property count? What about calls to methods of String or other .NET Framework classes?) and presto, you have a sequence diagram.

This sort of thing can save you a tremendous amount of time, and that means it can save your organization money. That's why some people buy Visual Studio Ultimate, after all. Having access to a tool like this is one of the ways I can "hit the ground running" when I join a project. If you need to do the same, make sure you're not ignoring a capability you already have.

Kate