Visual C++ Announcements in Barcelona: TR1 and MFC

Note: Many of you who read this blog aren’t Windows developers. I think you might still be interested in skimming this announcement, because I think it matters to the cross-platform and global C++ community when major vendors are clearly still investing heavily in C++ and C++-based technologies, despite what some naysayers proclaim.

How much does Microsoft care about C++ and non-.NET code? In August, I already blogged about

Now I’m happy to elaborate beyond just hinting, in the wake of announcements made yesterday by our Developer Division VP Soma and by our Visual C++ team. Here’s the scoop.

This month: Visual Studio 2008 ("Orcas") ships

First the comparatively minor news: We have a ship date. By the end of this month, we will ship Visual Studio 2008 ("Orcas"), including Visual C++ 2008 in particular which includes a number of cool features I’ve blogged about before, such as /MP for parallel builds on multicore machines.

But VC++ isn’t stopping there. Instead of waiting another year or two between releases, we’re immediately doing another one, gratis to VC++ 2008 customers:

First half of 2008: VS2008 Update ships

In the first half of 2008, VC++ is additionally going to ship an "expansion pack"-like update that will be available to all owners of Visual Studio 2008 Standard and above. This includes two major pieces that I know will be welcome in two major developer communities.


"TR1" is the first set of library extensions published by the C++ committee, nearly all of which have also been adopted into the next C++ standard, C++0x. Now that we know what parts seem to be sealed for inclusion in the next C++ standard and stable, we can start shipping them.

The VC++ 2008 update will include a complete implementation of all parts of TR1 that were voted into C++0x, except only for the section on functions added for compatibility with the C99 standard. The update will include features like:

  • smart pointers (e.g., shared_ptr<T>, weak_ptr<T>)
  • regular expression parsing
  • new containers (e.g., tuple, the fixed-size array<T,N>, hash-based containers like unordered_set<T>)
  • sophisticated random number generators
  • polymorphic function wrappers (e.g., function<bool(int)> and bind)
  • type traits

and a bunch more of all that good stuff lurking inside ISO C++ Library TR1. C++0x may tweak some of the interfaces, and we’ll track that as they do. In the meantime, here they are right in VC++.

A huge update to MFC

I hinted about a "huge update to MFC" back in August. Here’s the scoop…

Using this update to MFC, developers will be able to create applications with the “look and feel” of Microsoft’s own UIs:

  • Vista theme support, allowing your application to dynamically switch between themes.
  • The Office 2007 UI, including the Ribbon bar look in all its glory, with the ribbon itself, the pearl, quick access toolbar, status bar, and more.
  • The Office 2003 and XP UI, including Outlook-style shortcut bar, Office-style toolbars and menus, print preview, live font picker, color picker, etc.
  • The Internet Explorer UI, including rebars and task panes in all their glory.
  • The Visual Studio UI, with sophisticated docking functionality, auto hide windows, property grids, MDI tabs, tab groups, and more.

All in native C++ code. In MFC.

Oh, and there are also more things… for example, you can also enable your users to customize your application "on the fly" through live drag and drop of menu items and toolbar buttons; use the new Windows shell management classes to enumerate folders, drives and items, browse for folders, and more; and take advantage of many more new controls you can use right out of the box.

Want a quick tour? Get your quick overview with lots of screen shots in our own Pat Brenner’s VCblog entry, and also check out this handy Channel 9 video interview with Pat.

Implementation notes

Where did we get the code? This time, we decided to buy rather than build. The code for Office 2007 look-and-feel and other items were based on code we got from BCGSoft rather than code we developed internally.

Some people wondered about this, but it’s just an implementation detail. In particular, here are two questions I’ve seen people ask, and my personal answers (I am not speaking for Microsoft):

Q: Does it matter that this is code originally written by another company (BCGSoft)?

A: No. This update is a Microsoft Visual Studio product, full stop. With the full level of testing and support that implies, today and tomorrow.

Like most software companies, Microsoft routinely both builds its own code and integrates licensed software. We’ve long done the latter for the C++ standard library implementation (from Dinkumware), the Office proofing tools and spelling/grammar/thesaurus/hyphenation/etc. dictionaries, and mapping data for Live, to name just a few off the top.

Q: Does it matter that this isn’t the code the Office team used to implement their own look-and-feel? Why didn’t Microsoft ship Office’s own internal code?

A: No, and because we usually don’t because internal code isn’t at the level required of a product, respectively. I wonder if people realize this is the norm, not the exception, so let me explain a little.

Think of Office as the biggest Windows ISV (independent software vendor) that operates mostly as a separate company, even though it happens to be a sister division. Office has always driven the development of their own UI advances separately from Windows and Visual Studio. Windows and Visual Studio, in turn, have always tried to follow quickly in adding support for Office’s advances so that the Windows shell and other third-party applications could present the same look-and-feel wherever they wanted to, and those implementations have usually been:

  1. Later, because Office drove the innovation and the platform and tools followed.
  2. Different from Office’s own internal home-brewed versions, because there’s a huge difference between "solid for internal use" and "productized" with all the additional level of documentation and testing and external usability that requires.

The fact that we have an internal and an external "real" implementation for the same thing doesn’t matter. We’ve always done it that way, and the "real" implementation is equal and fully supported. (I think it’s funny that some worry that they’re not getting Office’s original internal ‘real’ implementation; the real "real" implementation is the one that’s not just for internal use, almost by definition!) Once a UI innovation gets into the Windows UI and/or especially the Visual Studio toolset, it’s first-class and here to stay.

Finally, I said this a huge update. What does "huge" mean? This update nearly doubles the size of MFC. Now, "nearly do
ubles the size of X" can be a bad thing. In this case, though, it’s a Good Thing… in my opinion, at least.

Beta and release availability

The update is expected to be available in beta form in January 2008, and to ship in the first half of 2008. Enjoy!

Wrapping up

Finally, let me express some well-deserved appreciation for a HUGE amount of hard work invested by the Visual C++ team, and our libraries team in particular, to make this happen and bring it to customers. Those of us who spend a good fraction of our lives on the second floor of Building 41 saw it firsthand, and know how hard everyone on the team has worked to make this happen at high quality. Thanks for that; it’s been quite a year of PM design work, coding and QA milestones, bug bars, and shiprooms.

For those who’ve asked what Visual C++ is planning beyond this month’s release, the above is an additional part of the answer. Far from the last part, however, because as Ale Contenti said in his announcement on VCblog about our plans beyond VC++ 2008:

"This is just the first step in our drive to improve the native development experience.  There’s a lot more that we’re working on, but we hope you enjoy this first milestone."

Stay tuned.

12 thoughts on “Visual C++ Announcements in Barcelona: TR1 and MFC

  1. Great news for all native developers! I’m really glad to see that MS is keeping up with the language.

    Now, I hate to be the first one to whine but I have to ask: is there planned support later on for TR1 in the Express edition?
    The fact that the TR1 expansion pack is restricted to Standard edition and above means that open-source projects will essentially be unable to use the TR1 library for their MSVC compatible configuration because they will want to guarantee portability with free tools for all platforms. As a consequence adoption of TR1 in both commercial and non-commercial open-source projects will likely be delayed.

    For most commercial developers this won’t be a problem and I understand it also makes financial sense for MS to provide additional features for paying customers. I’m a student and a C++ enthusiast (that takes a special kind of crazy, huh?) and not being able to afford to buy/upgrade commercial dev tools often, I’m mostly reliant on free tools. I’m really excited about the new library features in TR1 and language features in C++0x but I can’t help but feel slightly disappointed that TR1 won’t be available for me if I want to write code for VC++.

  2. That’s wonderful.
    Are there any plans to upgrade some other parts of MFC, maybe moving away from all those macros.
    I can’t help but thinking it would make sense to do it now.

  3. Well if they are allowing the Ribbon in MFC. Will it be supported in ATL 9.0 also? And since they are using a "sister" code of the Ribbon. Why can’t they use the "sister" code of Visual Assist X for intellisense in it also? Thats what makes the C++ platform faulter in my own opinion. And its night to see them starting to put C++0x in VS2k8 even though its only updates at a time. Will they continue doing it after each one is standardized? Or will it all be shipped with a Service Pack? And when will ATL get Aero implentation.
  4. No support for ASP .NET projects. C# and VB.Net are supported.
    No Support for WPF projects. C# and VB .Net are supported.
    No support for WCF projects. C# and VB .Net are supported.
    No support for LINQ. C# and VB .Net are supported.
    ATL Server has been dropped so no support for any web application framework in C++ and Visual Studio.

    I am so sorry if I am not overly enthused by the latest C++ offering in VS Studio. The so-called C++ development team at Microsoft can go back to sleep for another 3 years, since they have largely slept through the last 3. STL/CLR is nice but is so little when so much has been expected. Oh golly, MFC updates. Is that why C++/CLI was created so that C++ programmers can continue to use that old, kludgy framework ? If you created C++/CLI for a purpose, please tell me what that purpose was Herb, considering that Microsoft is intent on promoting their other two languages for .Net programming and clearly is not intent on promoting C++/CLI.

  5. I just wanted to give my name as the maker of the previous comment of disappointment in the work of the VC++ team vis-a-vis C++/CLI and .Net. Evidently "Use profile information" does not have my name and I will correct that but I did not want to duck identification.

  6. I understand what was explained about the Office implementation and the Visual Studio implementation of Ribbons and such are different, but I don’t know if I completely agree with the idea. By definition the two implementations will not be the same and in the end will have different behaviors. I guess the choice was stability over compatibility, but I just wonder if there wasn’t a "better" solution that allowed for both.

  7. Hi, I’d like to want to know whether VS2008 incorporates a UML to C++ code UI/translator that generates C++ skeleton codes from UML class diagrams and also does it the other way around, C++ -> UML (say i modify an object property in the code, that should be reflected in my UML). I read somewhere that this is possible for C# but not C++. Thanks, Tasha.

Comments are closed.