VC++.NET产品经理回答有关MFC/ATL的问题

Introduction

Nick Hodapp is the Visual C++ Product Manager. He´s also damn nice guy whom I unfairly and continually give a hard time. I caught up with Nick at VSLive! 2002 in San Francisco and passed on a bunch of questions that I see continually being asked by MFC and ATL developers so that we could get the set of definitive ´What´s the deal with MFC´ answers.

1. What are the future plans for MFC, ATL in the .NET world? Are MFC and ATL´s days numbered?

This is a very popular question. I’m sure you’re aware that there are literally millions of Visual C++ developers who use, extend, and incorporate both MFC and ATL into their applications. In fact, as many as 75% of all Visual C++ developers use MFC. Microsoft considers these libraries to be extremely robust and mature - they’ve been around for a long time, have been used as the infrastructure for hundreds of thousands of applications, and have grown over the years with countless updates and extensions. They have been very suclearcase/" target="_blank" >ccessful. Our focus is starting to shift to .NET, but MFC and ATL will each be continually updated in order to maintain sync with operating system features, and will be maintained into the foreseeable future. Backwards compatibility is always an issue with libraries like these, and as computing environments and requirements change it becomes more and more difficult to extend an older technology and still retain robustness. The time has come for us to introduce a newer technology with a renewed lifespan, and the C++ team is committed to making the transition as easy and comfortable as possible for MFC developers. With Visual C++ .NET you can continue to use MFC and ATL where it makes sense, and begin the transition to the .NET Framework at a pace you set.

2. Where do these libraries fit into the .NET vision?

Today MFC and ATL fill roles that aren’t yet fully realized in .NET. .NET, with all of its thousands of classes in the framework library, doesn’t provide application framework functionality similar to that provided by MFC. Developers need to be aware of their options - both managed and unmanaged, and choose carefully the technology most suited for the task. Visual C++ developers are typically very advanced, and have for years been accustomed to choosing appropriate technologies for their applications -- so this should be nothing new. With .NET, VC++ developers have the distinct advantage of being able to seamlessly integrate existing unmanaged code with newer managed code and data without the headaches of losing backwards compatibility or learning a new language. Managed extensions for C++ make sense for progressing applications forward, and they’re easy to use.

3. How long will these libraries be supported?

We have no plans to stop supporting any library shipping with Visual C++. All of the VC++ libraries have extremely high usage in real-world code, and Microsoft isn’t about to ignore this fact. We’ll continue to refine existing libraries, and have plans to introduce new libraries as technology evolves.

4. What are the new version numbers and DLL names for MFC and ATL?

MFC version 7.0 - MFC70.DLL
ATL version 7.0 - ATL70.DLL

Note the changes from the DLL names in 6.0 - we broke binary compatibility in order to make some key refinements to the libraries themselves. But your code will recompile against the new versions just fine.

5. Once .NET becomes established on every PC running Windows, will there be any reason at all to write C++ or MFC apps?

Assuming feature parity between .NET and MFC, a developer might choose MFC if there were a compelling need to write purely unmanaged code. Developers may choose to use C++ to target .NET because of the powerful C++ language features not found elsewhere, like templates, and the quality of code generated by the compiler. Visual C++ .NET is the only .NET compiler that generates highly optimized MSIL, and it is the only compiler that can generate an assembly image containing both managed and unmanaged code. Developers should choose C++ when they need unbounded flexibility and control.

6. Why would a developer wish to use MFC instead of Windows Forms, and why Windows Forms instead of MFC?

Windows Forms are a technology that do not yet provide the command-routing and document-view infrastructure found in MFC. Today, choosing Windows Forms is similar to choosing Visual Basic 6.0 in place of MFC. Each offer distinct advantages - the developer or architect must determine what priorities are relevant. The really sweet thing about C++ is that you can choose MFC and at the same time incorporate .NET technology where it makes sense. One reason we did this was so it would be dead-simple to extend existing applications without requiring them to be rewritten. A second reason is to enable the C++ developer to self-pace their adoption of .NET technology. We knew the C++ developer wouldn’t be interested in a technology that forced abandonment of their existing skills or code.

7. Will MS be writing any of their apps in MFC or will they start moving to C# and Windows Forms?

A majority of Microsoft applications are already incorporating .NET technology, using not only C#, but also C++ and Visual Basic .NET. There may well be less MFC development done at Microsoft going forward, but because MFC is integral to so many existing applications - our own and 3rd party -- it will continue to be a viable and supported framework for some time to come.

8. What is the future of WTL? Will it be made an official framework?

We don’t have specific plans for WTL. However, we are rather stunned by its growing popularity and are keeping a close watch. It is not a topic we’re ignoring internally.

9. MFC and ATL had some changes under the hood, but no major facelift and only a handful of new classes. What were the reasons for this?

As I’ve said, these are mature libraries that accomplish their objectives well. Our intention is to enhance them to keep pace with operating system features, to refine them where it makes sense, and maintain backwards compatibility. The updates we made for Visual C++ .NET reflect this positioning, and comprise a slew of refinements that make these libraries easier and safer to use, while adding support for Windows 2000 and XP.

10. Can you give us a brief rundown of the new features in Visual C++?

The list is actually quite long - a full enumeration of new features exists in the product documentation under “What’s New in Visual C++ .NET”. I have several favorites that I’ve been using in my own code. For the first time, it is now easy to use both MFC and ATL in a single application - the compiler will no longer complain about conflicting header definitions. Both libraries now share CString, and have in common several of the other non CObject derived classes. This feature alone factors out a lot of potential for duplicated effort in code, and can lead to a much more elegant implementation. It’s about time we did this, and it just makes sense. The STL library has been entirely overhauled - with more readable source code, a faster and standards-compliant implementation, fixes to all known major issues like threading and cross-DLL usage, and, at long last, all new documentation. And of course, the compiler itself has loads of new options and features, including whole-program optimization, code security features including support for runtime buffer-overrun checking, and managed-code generation.

11. Can we expect MFC and ATL/WTL to be extended in the near future to cover new features and controls in W2K, XP and CE 2002? Will MFC try to emulate some of the new components in .NET?

Yes, MFC and ATL will continue to enable developers to target the newest features of Windows. If you want to include new .NET features in your MFC application you can do this directly - there’s no need for MFC emulation of the feature.

12. Are there any tools to help developers move from MFC/ATL to .NET?

Beyond the /CLR switch of the C++ compiler, no. Should there be? What would you like them to do? How should they work? We’re very interested in this and are keen to have feedback about the importance of such a tool.

13. Can I still use MFC and my old MFC components in .NET?

Yes. It is easy to wrap or extend existing C++ components so they are callable from .NET - by any language. This is much simpler than it used to be with COM and ActiveX. Simply add a keyword to mark an object as a .NET reference-type, and compile with /CLR. No IDL, no reference counting, no registration code. Code it and use it - very simple.

14. Will MFC and ATL be extended to cover XML Web Services?

MFC and ATL already have the capability to consume and expose XML Web Services in Visual C++ .NET, both with managed and unmanaged code.

15. The various wizards had some annoyances, such as not handling derived classes very well, or being too restrictive. How have Microsoft addressed this in Visual Studio .NET?

One way we’ve addressed this in Visual Studio .NET is by exposing, for the first time, an extremely extensive automation interface enabling developers and third-parties to create their own add-in applications. If a wizard or feature doesn’t do what you want it to, you can write your own. With VS.NET automation, you can plug into the IDE at the same level of integration as any of Microsoft’s features. If you’re a member of the VSIP program you can even integrate new languages and compilers with the IDE.

16. Will MFC be ported to managed code to allow it to be used in Managed C++

We won’t likely port MFC to be a fully managed library. But it is entirely feasible to extend your own MFC applications with managed code - without leaving C++.

17. Will there be a MFC-like framework for .NET?

The .NET framework will continue to evolve and will likely add capabilities that are found in MFC. The C++ team is driving for this internally - we want .NET to be a compelling and comfortable place for C++ developers. We’ll achieve this is in a couple of ways. First, we’ll continue to make it easy to use the .NET Framework in C++ code. Secondly, we’ll ensure that there are compelling reasons to continue using C++ - by enabling C++ to achieve a level of flexibility and control on .NET not found in other languages.

18. What compelling reasons are there to upgrade to Visual Studio .NET if I have no intention of writing managed code?

Every aspect of the product has updates - the IDE, the debugger, the compiler, the libraries. As I mentioned before, the compiler alone offers the several new optimization and code-security features that increase the robustness of your applications. Across the board we’ve overhauled features like Intellisense, debugging scenarios, even the warning and error messages you get building code.

Bottom line: building existing code with Visual Studio .NET will result in faster, more robust software with lots of new potential to expand the capabilities of your application with emerging technology.

19. Can I use Visual C++ .NET to develop traditional MFC apps?

Of course! No one is forcing VC++ developers to swallow .NET whole - in fact, managed-extensions aside, the majority of features we’ve added this iteration are geared at unmanaged code development. MFC development is better than ever with refined IDE integration, compile-time type-checking for message maps, ATL support, and new classes to access new OS features.

20. What’s your favorite Website?

CodeProject.com. You guys rock.

原文转自：http://www.ltesting.net