Re: Report from MVP Summit
In addition to Joe's comments, much can be gleaned from the public video
"Steve Teixeira and Bill Dunlap: Visual C++ Today and Tomorrow"
at http://channel9.msdn.com/ShowPost.aspx?PostID=281987
This was the same video I posted about a little over a week ago. The same
presenters met with the MVP's last week and said much the same thing, but in
more depth. We also saw some pretty cool demos. In order to not divulge
NDA information, I just watched the above video again and took notes.
The video said:
Why is C++ still relevant?
* Native apps with large C++ codebases, which are still being innovated on
(code not "dead")
* Performance counts - e.g. virus scanner is better suited to native code
than managed code.
* Multi-platform support, if app needs to run on other OS's besides
Windows. Standards conformance is important to these people.
What is the mindset of C++ developers regarding new languages?
* C++ developers understand the machine at a fundamental level; they are
the ones who can "can write the garbage collector".
* C++ developers love their language, BUT
* C++ developers can learn other languages easily, because C++ is one of
the hardest languages to learn.
* C++ developers don't hesitate to go to C#, Perl, or another "easier"
language which is better suited to the task.
* C++ developers are want to "extend" their C++ apps to use, e.g. WPF
(Windows Presentation Foundation aka Avalon).
But they don't necessarily want to program WPF in C++. They are
comfortable using C#.
What is the new Microsoft C++ strategy to cater to these developers?
* Strategy: Focus on straight native C++ development + interop into
managed code. Don't try to match C# feature-for-feature
in Unmanaged development.
* First steps, already shipping -- It Just Works and C++/CLI language
enhancements.
* MFC and IE were "sick" for 4-5 years, but no longer. Microsoft message
"could have been done better." Now message is, "Both
native and managed code are great and can exist simultaneously."
* Aero/shell extensions are examples of modern native C++ development.
Big investment in MFC, will "love what we're doing with
native libraries".
* Tighter communication with Windows team. "Walk hand in hand with them"
to match API's with wrappers, etc. 7,000 new Windows
API's in Vista that are all native.
* Will not match C# feature for feature. e.g. Linq will not be
programmable in C++/CLI.
May be some opportunities for some interop with C++ in the future.
New Features in Orcas (aka Visual Studio 2007, now in CTP on MSDN)
* "Marshalling library". Convert, e.g. System::String <--> CString/STL
string. "One little template-based call". Supports a bunch of different
types.
* STL-CLR. Bring STL container library and use it for .NET development.
* Fully support native Vista deployment, e.g. wrappers around Vista + XP
controls, new Spy++, etc.
* DevXpress refactoring engine - partnership with DevXpress for Orcas
release.
Features in Orcas+1 (next version of Visual Studio after Orcas)
* Modernize dev environment. Modernize Compiler front-end, which is 30
year old code written with resource-scarce mentality to conserve memory,
decrease
build times. Result is, front-end can't support what C#/VB type dev
experience. Also, C++ problem is harder because native environment is more
complex,
C++ is more complex than managed equivilents. New front-end is
essential.
* There are lots of huge (millions of lines of code) legacy codebases that
needs Intellisense/Refactoring, but even more. These problems haven't beeen
solved
in other C++ environments either. Need to catch up with advanced in
C#/VB, plus "blaze new trails" in giving tools to grok huge legacy C++
codebases.
Compiler front-end being revamped to support this, as well as multi-core
CPU development, as well as "type safety/memory safety". Go beyond /GS and
safe
string libraries. "Fat pointers", etc. looked at by Herb Sutter which
allows type casting but in a safer way.
* TR-1: Next C++ language standard, may be Orcas+1 or later.
* Multi-core: need to make languages more "functional" to ease multi-core
development. Linq is one of first attempts at doing this.
MY VIEWPOINT
The MVP Summit was a terrific experience, especially the 1.5 days we spent
in the VC++ building with many of the developers and product Managers. In
addition to Bill and Steve (both of whom had Borland roots with me), I was
pleased to chat with Ronald Laermans who is now the PUM of Visual Studio. I
got to meet David W., Mihai, Nish, Carl D., and Joe, along with Mike Dunn
(who wrote a terrific WTL tutorial on CodeProject), and a bunch of others.
The whole environment was very encouraging but forthright (we didn't hold
back both our praise and our criticisms), and I was pleased there was no
trace of ego by anyone.
Given that the headline was "MFC and native code is making a comeback" I
wondered how this would jive with my new focus on learning .NET. As many of
you know, I am still selling myself as a native C++/MFC expert but am
"quietly" learning .NET so I can further add these skills to my toolset.
Would I be persauded that MFC is still where it will be at 5 years from now?
To my surprise, I walked away with a new rededication to learning .NET.
The reason is, I am an ISV and consultant that writes small to medium sized
programs. I don't have huge legacy codebases, nor am I concerned with
multi-platform. All the innovations in my space are in the managed
environment, and have been for the past several years. I will be a great
fan of the new interop and IDE stuff going into Orcas and Orcas+1, but
mostly I think I will be better served in the Managed world, especially
since the Performance and library requirements are slowly going away. If
not now, than in the next 2 years.
But still, unmanaged/MFC remains by bread and butter for awhile longer.
-- David
http://www.dcsoft.com