Microsoft’s goal is to have a ‘competitively compliant’ compiler – meaning it won’t be 100% compliant. There are a couple of features of the ANSI/ISO standard (for instance the ‘export’ keyword as applied to template classes) that won’t be implemented because they are considered by Microsoft to be obscure and, at this stage, theoretical. Microsoft is however working to ensure that Visual C++ will compile the most popular libraries such as Boost, Blitz, Loki and a fully compliant version of STL. The emphasis is on a level of compliance that allows popular libraries to be compiled, not 100% compliance.
Nick Hodapp, Microsoft’s C++ Product Manager also added that while high compliance is definitely a very important goal Microsoft would not sacrifice code-generation quality or robustness at the cost of extreme compliance. However in recent lab tests they are still beating several popular compilers on conformance tests.
For the pending release of Visual C++ .NET (VC7) Microsoft focused on enabling interop features. VC7 has the best interop scenarios of all the managed languages and includes the ability to have both managed and unmanaged code in the same image. They also focused on enabling optimization technology on the generated MSIL - the result is that VC7 is the only compiler to generate optimized MSIL. In future releases Microsoft will focus on ANSI/ISO conformance (enabling many more features for both managed/unmanaged code), as well as features that will give Visual C++ feature parity with C# - WinForms, for example. Visual C++ will be positioned as the power-systems language for .NET.
Template support and generic programming are a must and Microsoft is very keen to implement code DOM support, both for ASP.NET and WinForms. With these added features we see Visual C++ as being the power programmers’ language of choice for the .NET framework - to compliment it is current role as the language of choice in unmanaged development. Even without the template support that is currently being pursued we see Visual C++ as the only language suitable for those who need more than C# or VB.NET can offer.
Microsoft’s approach to adding new features is whether those features are
Being used in code that other compilers can build, or
Whether those features are compelling enough that it becomes apparent that their customers want them.
Microsoft will not simply implement features because they are specified in the standard. They will implement them when people want them because they are beneficial.
The message is that Visual C++ is definitely alive and kicking and has a very bright future in the .NET world. Microsoft’s aim is to have the compiler at a point where it’s the benchmark against which all other compilers are compared – in terms of simplicity, fun factor and conformance. It should be easy to use, versatile, enjoyable, and it should be what developers think of whenever they think C++.
Continuing improvements in C++ compliance along with future support for ASP.NET and WinForms will ensure that Visual C++ be the power language for .NET and for native development.
As to the question of whether developers will move to C# instead of managed C++ Stanley thinks there will be more of a move from VB to C# than C++ to C#. C++ is the better, more versatile and the only optimized compiler available in .NET.
Jonathan Caves, developer on the Visual C++ Compiler Team, speaks about plans
His team has for the next release of Visual C++.
“After the last release of Visual C++ we took a long, hard look at the compiler source base and decided we needed to take the time to seriously invest in reworking our existing code base - some parts of which are over 20 years old. We have plans to really improve the development process for both our existing native C++ customers as well as our newer C++/CLI customers. Unfortunately these changes are going to take time to implement and we definitely can't do anything in the next release (called Orcas), which has a short development cycle.
So instead of working on the next release of Visual C++ most of the compiler development team will be full steam ahead working on the future generation compiler - we are not yet sure exactly what form this compiler will take but we do know that it will really improve and re-energize the C++ development process.
This does bring up the question of what C++ compiler enhancements will be in Orcas. Notice I said "most of the compiler development team" as we are not putting the whole team on the future generation compiler - instead we have left one developer, yours truly, to work on the current source base. We know that C++ is still one of the most widely used programming languages and that we can't just let the current Visual C++ compiler stagnate so I'll be working on keeping it ticking. This is mostly going to involve bug fixing (and I hope that most of the bugs I fix will be ones reported by our customers) though I also think that I may find time for a few small features!
One thing we did after Whidbey, as part of analyzing our source base, was to categorize the remaining bugs in the database. This analysis showed some areas of the C++ language in which the compiler support was less than what we would have wished it to be. We made an effort to address these areas and in some cases we think we can get this work into the next release of the compiler. One example is the interaction between friend functions and templates. In many other cases, however, the work became so big (like rewriting the code that handles the parsing of qualified-names) that we decided to just move it to the 'future' compiler. Going forward I know of other 'problem' areas in the compiler that I am pretty certain can be addressed without needing major reconstructive surgery.
But these small features aside, most of the work on the compiler for the next release is going to bug-fixing and I know from interacting with many of you over the last few years that you’ll be quite happy about this. I’m sure you'll welcome a compiler that doesn't introduce a lot of new features and instead focuses on improving the quality of what we have. So if you have a serious bug you feel we need to address you should definitely open an issue on the Product Feedback site but please be aware that I am only one person and so, unfortunately, I won't be able to fix each and every bug. I can assure you though that as a team we will focus on the bugs we believe have the greatest impact - like compiler crashes (especially without any error message), bad code generation, blocking issues, etc.”
Peter Michael Osera, program manager on the Visual C++ compiler front end, said that their work to update MFC to use elements of the new Vista UI, Aero. They recently finished their efforts to integrate the new Vista- style file dialogs into MFC. The customers do not need to do anything special to take advantage of this feature. As the top priority was making the transition to Vista as seamless as possible, the MFC code that uses CFileDialog must be only recompiled under Orcas.
Underneath the covers, the new file dialogs are exposed through a new set of COM interfaces collectively known as the common item dialog. As this is a large departure from the old common file dialog APIs, much of the work consisted of wedging as much of the new common item dialog functionality through the CFileDialog (MFC) API as possible. The end result is that you can use the same interface as before to control both the old and new dialogs.
Of course, because of the redesign of the underlying file dialog objects, some old functionality of the CFileDialog class is not supported when using Vista dialogs. In particular, since the new Vista dialogs no longer support hwnd template customization, your CFileDialog object will throw CNotSupportedException if SetTemplate is called on it.
Instead of using templates, it is we recommended, along with the windows team, to use the IFileDialogCustomize COM interface to add controls to your dialog objects. In the spirit of MFC, we’ve exposed getters for the entire common item dialog COM interfaces so you can get at the remaining functionality that is not exposed through CFileDialog. In general, if you customize your CFileDialog object extensively, please make sure to review the updated MSDN documentation when it is available to make sure that the methods, events, and flags you use are supported with the new dialogs.
The Visual C++ team is excited to announce the release of Visual Studio 2005 SP1!!! The Service pack launched on Friday December 15, 2006 and is available for download. This SP addresses issues that were found through a combination of customers and partner feedback, as well as internal testing.
There are over 400 Visual C++ bugs that have been fixed with issues ranging in severity from minor syntax highlighting problems to customer reported crashes across various scenarios. In some areas, more than 50% of the bugs addressed were reported by customers through the MSDN Product Feedback Center and Microsoft Connect. Overall, Service Pack 1 offers customers improvements in responsiveness, stability and performance for Visual Studio 2005.
Service Pack 1 also provides over 70 improvements for common development scenarios including:
- New processor support (e.g., Core Duo) for code generation and profiling
- Performance and scale improvements in Team Foundation Server
- Team Foundation Server integration with Excel 2007 and Project 2007
- Tool support for occasionally connected devices and SQL Server Compact Edition
- Additional support for project file based Web applications
- Windows Embedded 6.0 platform and tools support
For developers using Visual Studio 2005 on Windows Vista, Microsoft is in current development on an update to Service Pack 1 called the ‘Visual Studio 2005 SP1 Vista Refresh Beta’. This update builds on the improvements made in SP1 and delivers a first class experience for developers wanting to take advantages of the new features in Windows Vista. The Visual Studio 2005 SP1 Update for Windows Vista is expected to ship after the consumer availability of Windows Vista in Q1 of 2007 and is now available in beta.
