Since Herb is new to the Microsoft fold I grabbed a few minutes (well, hours) of his time so we could get aquainted with who he is, what he does, and what, exactly, is happening with our beloved Visual C++.
Well, I've been doing mainly a lot of C++ writing, teaching, and consulting, and the C++ community is very important to me. By the way, I'm going to continue doing those things; that community contact is why Microsoft saw a good fit to hire me, and they want me to keep doing it.
So what is that today? Well, right now I'm secretary of the ISO/ANSI C++ standards committee, and I've participated actively in that committee since 1997. I'm also writing four columns about C++, mostly in C/C++ Users Journal where I'm also half of the magazine's editorial board, reviewing and editing other authors' articles and recommending what should be published and what needs work. I've got two C++ books out with Addison Wesley, Exceptional C++ and More Exceptional C++, and I'm working on two more, one with Andrei Alexandrescu. Everything I write, except for the final versions of material in the books, gets posted free for public reading on my website, www.gotw.ca. I've also been a moderator of the primary Internet newsgroup for the C++ language, comp.lang.c++.moderated, since its inception in 1995.
Again, all of that's going to continue. What's new is that I'm now also going to be Microsoft's liaison with the C++ community on all platforms, not just Windows, to keep the Visual Studio .NET team in touch with the community and make sure that what the community needs gets into the product.
I'll admit that it would have been a lot less tempting two years ago, back when Microsoft didn't seem all that interested in Standard C++. But in the past 12 to 18 months I've noticed a real change in priorities at Microsoft, as they've resumed joining us at the committee meetings and as they've started contributing to the community and started making noticeable progress with their product's standards conformance. I discovered, to our mutual pleasure, that now not only is conformance to the existing 1998 C++ standard as important to them as it is to me, but that they want to keep tracking the next-generation C++ standard whose development is just underway.
My job is to be Microsoft's liaison with the C++ community. "The community" includes the standards committee, C++ conferences, and developers on all platforms. After all, Microsoft is naturally interested in making their tools appealing to everyone, even those who aren't using them yet, and conformance is an important part of making migration possible. There are many reasons, plus my own pre-existing personal ones, to be committed to fulfilling today's C++ standard and assisting the future development of the standard. A rising tide floats all boats, and standards conformance is good for everyone.
I hope to make a noticeable mark in the product. So now I need to give you a heads-up about something that I want to be very clear about, and namely "why" and "when" I will be pushing for language extensions in Microsoft's C++ even before the product is fully compliant to today's standard. Let me put it in perspective and then lay out my personal agenda:
Microsoft intends to conform 100% to Standard C++ as soon as possible. Period, no question. It won't all be in the next release, although many conformance improvements will be. Admittedly there's some catching up to do and it can't all happen in a week or a month or a dot release. But it will happen, and as soon as possible.
Having said that, let me tell you the two groups of conformance-related features that are the most important to me, because they're what the C++ community consistently tell me they need: My one "must-have" feature group consists of everything needed to conform 100% to current Standard C++ (a.ka. C++98). My other "must-have" feature group is key extensions that we as a community know perfectly well we need, but which are missing in C++98, usually due to just oversights or mistakes - yes, we standards guys are just humans, and we sometimes miss stuff too. Some of these are just obvious omissions that will certainly appear in some form in the next version of the standard (a.k.a. C++0x).
Here's the punchline: To me, those are not two lists, where you do everything on the first list (C++98 conformance) before you start working on the second (key necessary extensions). To me, those things all make up one list, that then gets prioritized so we can put as many of the most important things as possible into each release. That means that you can bet I will be pushing hard to get some key extensions beyond C++98 into the product even before we finish all the things to conform to C++98, because frankly some of the extensions are more important to the Standard C++ community than some missing C++98 features. We're definitely going to do all of C++98, no question. But if I have my way we're going to do it in the order that will benefit the global C++ community the most quickly - that's my assigned vested interest to promote within Microsoft, that we deliver what the global community needs as quickly as we can.
Let me give you a concrete example: Visual Studio .NET (Visual C++ version 7.0) doesn't yet have support for the "export" keyword which is in the C++98 standard, nor does it have typedef templates which are not in the C++98 standard. (As I'll point out in a second, nobody else has either of those features yet, either.) I will be pounding on the table during every design meeting you'll find me in to put typedef templates into the product before support for "export" simply because typedef templates are a lot more important. Even though typedef templates aren't in C++98, that's just a bad oversight; I don't know of an expert in the world who doesn't agree that typedef templates are obviously needed, and needed more than "export". On the other hand, as of our interview today, there's not a single released C++ compiler in the world that supports "export" (Microsoft is not alone here!) and the community is hardly clamoring for it. Edison Design Group and their licensee Comeau have an "export"-capable compiler in beta and will be shipping sometime soon, which I think is great, but if you sit me down at a table and put "export" beside typedef templates in front of me, I'll choose typedef templates every time, even though they're not officially in C++98, because key community libraries like Boost and Loki would really benefit from them; hey, the standard itself had to do that funky alloator::rebind hack just because we didn't have typedef templates, and the standard even says so! Here's a direct quote: "The template class member rebind … is effectively a template typedef"! That's just way more important. We'll do "export" too, of course, but first things first.
Don't get me wrong, I'm certainly not pushing for a lot of extensions, and certainly not anything where there isn't already a clear need and some community agreement. And when I propose those features within Microsoft, it will be after I've already talked with the world's top experts about how important they are and how they should be specified; I hate half-baked homebrew misfeatures and that's certainly not what I'm after here. I'm pushing for a handful of carefully chosen and carefully implemented extensions that the community is clamoring for, and which are not proprietary but rather the opposite: things we already know are certain or likely to come in C++0x and which we hope all compiler vendors will provide too. A standards committee can sometimes be inventive, but mostly it's supposed to standardize existing practice; I want to help Microsoft help the standard by providing just that "existing practice in the field" for these key upcoming features. Indeed, by trying to carefully wield Microsoft's product as a leader in this way I personally hope to help move the whole community forward on all compilers and platforms, as other products are encouraged to implement them too, which will benefit everybody no matter whose tools they're using.
Bluntly, if I have my way, then people are going to ask, "how come Microsoft put Extension X into the next version of VS.NET, when they haven't even finished conforming to C++98 yet?", and I hope they ask that because if they do then I've done my job. No worries, full C++98 compliance with "export" and the kitchen sink is coming on apace, and will get done, no question. But if I have my way we'll do that whole unified wish-list of C++98 and pre-C++0x standard features in the order that best serves the community, because that community priority is what I'm being paid to push inside the company.
Yes, lots, yes, no oh please no, and not even if you say pretty please, respectively. Ahem. Seriously, though some questions are okay, but at least get people to read the C++ FAQ (www.parashift.com/c++-faq-lite) and my website (www.gotw.ca) first to see if there's already a well-known answer.
It's my job to know what the community wants. That's why I'm going to continue speaking and listening to attendees at conferences, in my private independent consulting, on the public newsgroups, in email conversations with readers of my columns and books, over coffees and dinners at standards meetings with the top gurus and with the other vendors, and everything else I'm already doing.
That may have been more true until recently. I've seen some changes already in the past six months, and I'm looking forward to seeing more. There's no question that Microsoft is investing in C++, internally and externally. Look for further Microsoft community participation by contributing to platform-neutral community libraries and in other ways.
C++ is still by far the most powerful language in the .NET universe, and the one that more commercial Windows apps are written in. That's not likely to change anytime soon.
C++ continues to be relevant, dominant, and in widespread and still-growing use. The C++ standard and standardization process also continues to be relevant - committee membership and participation has increased since the first standard was published in 1998, and lately we've had more countries represented at our ISO meetings than ever before. Usually the opposite happens when a standard is completed and the committee goes into maintenance mode for a while - companies stop sending people, because they all have their own work to do after all. But not here: even while we were in maintenance mode for several years, ISO/ANSI membership has pretty much never been stronger, and all the vendors, including Microsoft, are there together actively working on the next-generation C++0x standard whose work is now getting underway.
For one thing, MC++ has to support more of Standard C++. There is (how can I say this politely) room for more overlap. There, I think that was subtle enough. The team is hard at work on these kinds of issues. I think that .NET is good for C++.
I do. I'm hopeful that it can contribute something valuable, perhaps even beyond Windows-based platforms.
Here's a for-instance: Within the standards committee and the standards process, I've seen several key recurring questions and wishes since C++98 was passed. Three of them are: a) "what about standardizing thread support?"; b) "what about compiling C++ to the JVM?"; and c) "what about a portable GUI library, something basic that will help with teaching?" I think it's very interesting that .NET provides all three, and more, and that it makes those things available to C++ programs. In particular, well before I had any idea I would come to Microsoft, I'd thought that .NET was "a better JVM" (plus a lot more of course). If we could get better convergence between "Managed C++" and "Standard C++," which is something that the team as a whole and Stan Lippman in particular are working on right now, this whole thing could get really interesting and there might be some useful standard technology to offer here someday if the C++ committee wants any parts of it. I'm saying that with my "committee-member" hat on, not my "Microsoftie" hat on. After all, this very possibility is one of the cool ideas that hooked me into wanting to participate with Microsoft and see what I could be part of contributing to the committee and the community, because like everyone else I've been looking for answers to those same three questions, and here's a technology that's already being standardized (in ECMA and soon ISO), and look, it works with C++! Well, with a lot of C++, anyway. We'll have to see how it goes, though. I don't think it's any shape yet to submit it; we'd pretty much have to be able to run nearly all of Standard C++ on .NET just to have a proof-of-concept starting point that the committee would be interested in. It's a goal. We want to contribute where we can.
But C++ developers on all platforms wants these kinds of things - threads, running on a VM, a managed GUI library. Windows-based developers have a lot of it today, and I know that the Visual Studio .NET team are working hard to make it better so that you don't have to give up so much of Standard C++ to get those benefits.
Besides the .NET stuff I just talked about, which I think has potential to help C++ as a language, Microsoft is also interested in contributing more, and more often, to the C++ community. Part of my job is to make sure that stuff that Microsoft has been developing in Research can start more regularly getting submitted openly to community libraries like Boost, so that developers on all platforms can benefit from them. We're working hard on that. Pardon me, I've got to go beat on some lawyers' heads about that; back in a sec.
Depends how you count, but the best numbers I keep seeing put the global developer community at something like 9.5 million people, and those using C++ at about 3 million of that. That's well ahead of Java in nearly all studies I've seen, by the way, usually by a factor of 1.5-to-1 or 2-to-1. And showing C++ still modestly growing, also by the way. All without aggressive marketing, yet again by the way. The reports of C++'s demise have been, well, "exaggerated."
C++ developers need power and know how to use it. I've always said you should use the best language for the job, and I've used dozens of languages professionally. Depending on how you count languages, I've probably used a dozen professionally in the past year. People who want to write efficient, tight, fast code often tend to choose C++ because it lets you get the job done with powerful code but without sacrificing efficiency.
People who want mature, stable compilers and tools often tend to use C++ because it's been around a while and the tools and libraries are plentiful and solid. Commercial client-side application development with more than a few screens, most kinds of server-based software, and most kinds of libraries are all done more often with C++ than with other languages, according to the best numbers I've seen and according to my own experience as a developer and as a consultant who shows up at other developers' shops.
The coming C++0x standard will heavily emphasize additions to the library, not to the core language. Expect to see a few well-chosen core language extensions, such as typedef templates, but not any huge fundamental changes like templates and exceptions were in their day. In the standard library, on the other hand, do expect many extensions, from obvious low-hanging fruit like hash-based containers and threading support to possibly things as big as a VM model or a basic GUI library, and lots of useful stuff in between. To get some idea of what kinds of things you might see, check out Boost (www.boost.org), although I hasten to add that we on the committee are looking for input from the whole community, don't think Boost has some inside slam-dunk track.
Along with the other C++ vendors and experts, Microsoft will continue as an active participant in the ISO/ANSI C++ committee, contributing its people's expertise to help formulate and refine proposals that will improve the coming C++0x standard. It also wants to contribute technologies or research of its own, if the committee thinks that those facilities will help the C++ language's evolution. Microsoft is now committed to supporting the community and being an active participant and contributor.
C++0x, man! It's a whole new standard out there! Or, at least, it will be once we're done. Give us a few years, it's just getting underway now. At the most recent standards meeting, held in October 2001, we already started considering the first batch of potential additions to the C++ standard library. There were seven proposals, from threading support to hash-based containers, all of them fairly self-contained and smallish ones to start with (well, okay, the threading one isn't that small). There's a lot more exciting stuff on the way; that's just the beginning. I've recently started writing a new column for C/C++ Users Journal called "The New C++" that will cover these topics, and in fact already has detailed many of the above - see the links on my Publications page, www.gotw.ca/publications, that are tagged "TNC++" (the acronymized column name).
I recently read an interview with some C++ guy, and when he was asked about the size of the C++ community, he said something like: 'Depends how you count, but the best numbers I keep seeing put the global developer community at something like 8.5 million people, and those using C++ at about 3 million of that. That's well ahead of Java in nearly all studies I've seen, by the way, usually by a factor of 1.5-to-1 or 2-to-1. And showing C++ still modestly growing, also by the way. All without aggressive marketing, yet again by the way. The reports of C++'s demise have been, well, "exaggerated." '
I think he's got a point.
