The wheels of the standards committee, I have said more than once, do grind slowly, but exceedingly fine. Apologies to probably Longfellow, though I might be mistaken. Anyway, progress continues on the next version of the standard and there are some details still to settle. Anthony Williams has written a nice summary of the October Mailing (in preparation for a November Meeting) along with some helpful links. He points out that generating move constructors (as compilers do today for copy constructors), as required by the Final Committee Draft (FCD) could break some existing code, so discussions are planned on restricting (or dropping) this implicit generation. I  like knowing that people are putting this level of thought into language changes instead of just issuing a Breaking Changes list and expecting me to go edit my code accordingly.

He also highlights situations where people are deliberately throwing exceptions from a destructor (gasp! I know!) and their working code will break unless they change it say they intend to throw exceptions from their destructor. You would think that this was a tiny population of people, and that marking their code in this way is no big deal, but C++ philosophy is that working code with defined behaviour should continue to be working code with defined behaviour in the latest version of the language. As you can see, that can really be a challenge sometimes.

If you're a C++ person, I challenge you to read the papers Anthony links to. If you can't understand a word of them, you're missing a lot of what C++ is these days. While talk of "implicit invariants", rvalues, and a "throwing move" may take some effort to decipher, I think it's worthwhile. C++ is a language in which performance and correctness are both paramount. That's why the developers are expected to manage lifetimes themselves, explicitly state whether they want shallow or deep copies, and so on. Template libraries simplify much of this (shared_ptr and unique_ptr are the death knell for the characters d-e-l-e-t-e in my code) but understanding those lifetime issues, understanding rvalues and lvalues, understanding when temporaries are created and deleted are all fundamental to being a C++ developer. Understanding those things lets you write better C++ code than you otherwise would. I know there are other languages in which your understanding doesn't matter because it is always done the same way. I also know that the control offered by C++ enables performance gains in specific situations where the developer knows better. These things can both be true at once, and can make other languages a better fit for certain developers or for certain business problems. They are also what makes C++ a better fit for some developers and some business problems. But if you don't have those understandings, if you don't want to control your application at that level, then why are you using C++? Use something simpler that can't be controlled the way C++ can.

For those who are using C++ "on purpose", who are "unrepentant" as I say in other of my talks, knowing the language at this level is key to being good at it. Would you say that "Implicit Move Must Go" or not?

Kate

I've been pretty active lately on StackOverflow, a question-and-answer site where people ask "what does this error message mean and I how can I make it go away?" for a variety of languages, platforms, and business purposes. There are a number of brilliant features on StackOverflow including voting on both questions and answers, and closing questions that are off topic for the site. This means less junk to wade through and a bit more confidence that any particular answer is actually going to be helpful.

One of the reasons questions get closed on StackOverflow is because they don't have an answer. There's a category of nasty questions of the form "Have you stopped [bad thing] yet?" that have no answer. If you never [bad thing]'ed in your life, then you obviously haven't stopped. Yet answering "no" implies you continue to [bad thing]. Answering "yes" implies you [bad thing]'ed for some time, but have no stopped. Either way, it's bad. So I knew the question "Should LINQ be avoided because it's slow?" was going to be closed. And sure enough, it was. But not before some really excellent answers and comments accrued to it. Like these:

• I would not avoid code because it only executes 250 million cycles a second instead of around 750 million, unless that kind of throughput is an actual business case. Also, chances are that the data comes from something that is a lot slower than this code anyway (a database, disk, ...). Go for what seems most convenient and optimize where it matters.

• Slow is irrelevant to your customers, your management and your stakeholders. Not fast enough is extremely relevant. Never measure how fast something is; that tells you nothing that you can use to base a business decision on. Measure how close to being acceptable to the customer it is. If it is acceptable then stop spending money on making it faster; it's already good enough.

• So what you're saying is that the devil you know is better than the devil you don't. Which is fine, if you like making business decisions on the basis of old sayings. I think it is generally a better idea to make business decisions based on informed opinions derived from empirical measurements.

Those last two are by Eric Lippert. Yes, that Eric Lippert. He's answered almost a thousand StackOverflow questions, and he's by no means the only product team member who's answering questions there. In addition, other answers fix a different perf bug in the asker's code (an unnecessary and expensive cast) and provide a wide range of opinions about performance decisions, architecture, choosing technologies and so on.

I love StackOverflow for fixing immediate blocking problems, but don't neglect the possibility of gaining philosophical wisdom from reading an offtopic question or two.

Kate

Jeff Blankenburg has produced a great quantity of blog posts about developing for Windows Phone 7. Now he's supplementing that with an all-in-one resource page that links out to a ton of great material in addition to his own. Oh I know, you might not need to see the TV ads to learn how to develop for the thing, but I appreciate the link anyway. If you're doing phone work, or thinking about it, this list is for you.

Kate

Jennifer Marsman has built a very nice list of Windows 7 developer resources. Of course, she had me at Code Pack (the very first item she lists as a matter of fact), but she carries on, drilling into both native and managed scenarios, covering libraries, SDKs, training materials, UX guidelines, samples, blogs - even Twitter handles!

There is a LOT of material out there and it's a little bit fragmented. This is a great post to help you find your way around. Remember, if you have a Windows app, it should be a Windows 7 app!

Kate

According to Wired, C++ was born October 14th, 1985, with the publication of the first official reference guide by Bjarne Stroustrup. That's 25 years ago! I've still been "working in C++ since before Microsoft had a C++ compiler", as I like to say at the start of any C++ sessions I deliver. While that is a long time, it's not the full 25 years the language has existed - not quite, anyway.

Wired marks the anniversary with an interview with Bjarne. If you're curious about what kind of computer he uses day to day (a small Windows laptop) or what music he likes to listen to, now you can find out. Or this advice for young programmers:
I'd call that "simple but not easy", as much advice is. C++, of course, is neither simple nor easy, but it is incredibly rewarding to those who take the time to learn it and use it well, and I hope it will continue to do so for at least another 25 years.

Kate

I'm teaching OO design and UML again this term, and one of the things I emphasize to the class is the dangers of coupling. (Get your mind out of the gutter, I mean classes with dependencies on each other.) It's not about calling methods of each other necessarily; it's more about if-I-change-this-one, I'll-have-to-change-this-one-too. Changes that ripple through a system are expensive and dangerous.

When I am helping clients with interop, they are often surprised to learn how entire applications and libraries can depend on each other without ever calling each other's code. For example, App A writes a record to a database table. Service B checks the table regularly for new records (or records with a 0 in the Handled column, or whatever) and calls a web service (or whatever.) Those applications are now coupled - if a change in one necessitates a change in the format of that table (or its name, etc) then the other must be changed too. Thinking ahead and doing all you can to reduce this kind of coupling is part of the challenge of doing good application integration, even if there are no interop calls in the solution.

And then there's performance. So often left until last, it provides another consideration that you should ideally have in mind all the way along. And as Rico Mariani points out, it also couples applications and libraries you may have thought were independent:

Two subsystems that both (loosely) use 2/3 of the L2 cache are going to use 4/3 of a cache... that’s not good. There may be no lines between them in the architecture diagram but they are going to destroy each others ability to work.

Sound advice as always. Please read the post, and keep one more "don't forget" floating around as you design and architect your systems and solutions.

Kate

This is really fitting, isn't it? You have a product code named Dev10 and released as Visual Studio 2010 (with the tens not related to each other - see my history of Visual Studio and Visual C++ version numbers and release names). And today is 10/10/10 no matter what date format you prefer. So today is a great day to take a quick survey about Visual Studio 2010. Seven questions. I recommend you read them all before you start answering because they are asking about different aspects of the product and you wouldn't want to answer a question about speed with your thoughts about ui features. But it will take almost no time so go and do it.

Kate

I've gained a lot of Twitter followers in the last few days, and I'm pretty sure I know why. John Bristowe included me on a list of Canadian Developers that includes a full list of luminaries. I counted 112, and he's included blog links as well as Twitter handles. Most, but not all, are .NET developers. John follows all of them (us), which shows remarkable dedication. Why not take a look and see if there's someone there you'd like to follow too?

Kate