Steve Teixeira

ZippyV wrote:

Charles, did you forget to white balance your camera? Everyone is wearing a pink shirt.

I thought the same thing, as Kate's shirt is actually gray.  If you're interested in the VH1 Behind the Music aspects here, there were actually some bright lights behind and above us that were affecting the camera's light pick-up. 

shortcutz wrote:



For those not planning to move to VS08 anytime soon, how can we have access to these cool libraries?

Would be nice to c the lib. or a small version of them out there!!!

Our plan is to provide this new version of MFC for VS2008 and higher.  If you're unable to upgrade and need support for VS2005 or lower, you might consider licensing BCGSoft's libraries.

Hope that helps,

Steve Teixeira, Group Program Manager, VC++

DCMonkey: The BCGSoft angle is discussed in the length thread on this topic on the VC++ team blog.

In short, partnering with BCGSoft to deliver this functionality dramatically reduces our time to market and frees up time for the VC++ libraries team to also invest in several other cool projects in the VS10 timeframe.

Thanks!

Steve Teixeira
Group Program Manager, VC++

mwirth, schroedl, wkempf, and the other C++ C9ers:

Indeed, it's hard to disagree with you that C++ doesn't get the same air time as some of the shiny new stuff, but really it's because we know that C++ developers are secure and self-confident in their own coolness and don't need all of that public relations stuff to tell them they're cool. 

On a more serious note, we've discussed all of the major new C++ stuff coming in Orcas on C9 in the recent past, including:

Marshaling library and new MFC features
STL/CLR
Safe C++ Libraries

Also, Bill Dunlap and I did a C9 video a couple of months back that talked more generally about the future of VC++.

Regarding some of the other topics you guys brought up, let me talk about those briefly as well:

Refactoring: Great C++ refactoring support is absolutely something that is in our long terms plans for Visual Studio.  However, it's not something we can deliver in the box today because of legacy architectural issues.  Two bits of good news on this front, though: 1. One of our major investments for the Orcas+1 product is to completely overhaul the C++ plumbing within the Visual Studio IDE, with the goals of improving the performance and scalability of existing features (e.g., Intellisense) and unlocking new scenarios for us in the future (e.g., Refactoring).  2. Meanwhile, we have partnered with Developer Express to deliver C++ support in their Refactor! for Visual Studio product.  You can get Refactor! today to add C++ refactoring support to your VS2005 experience.

Unit testing: VS2005 supports unit testing of C++ code today, albeit with the limitations that the test harnesses and test generation must be C++/CLI code.  We've been talking a lot with the Visual Studio Test team about adding first-class native C++ support to the mix as well, but I don't have any news to report on this front as of yet.  Meanwhile, there are also viable third party alternatives such as cppunit you might wish to investigate.

MSBuild: MSBuild support for VC++ is actually something we're working on right now.  Unfortunately, we weren't able to complete this work in time for Orcas, but we are looking at creative ways we might be able to deliver some of this work to customers, perhaps in CTP format, well before the Orcas+1 release.

I hope this helps, and - by the way - I always love to see you C++ fans telling Soma and Charles that we need to get more VC++ and native code content out there! 

Steve Teixeira
Group Program Manager, VC++

gsuing wrote:

I haven't installed the CTP, but I'm wondering if the performance of the C++ compiler has improved.  The C++ compiler in VC++2005 is quite slow compared to the VC++6.0 compiler.

The reduced build throughput between VC6 and VC2005 is primarly a result of vastly increased correctness and standards conformance.  In Orcas, we have increased throughput by supporting compilation of multiple translation units in parallel.  We have also done some work to optimize dependency checking for managed/mixed projects.  We blogged about this recently on the VC++ team blog: http://blogs.msdn.com/vcblog/archive/2007/03/12/multi-processor-builds-in-orcas.aspx.

dcsoft wrote:

Huh?  When I see names like the "Visual 2005 Service Pack 1 for Vista" that is different than "Visual 2005 Service Pack 1", and other mile long product names (e.g. Windows Presentation Foundation, and not Avalon), etc.,  the person in charge of naming things at Microsoft definitely needs to be put out to pasture.

I'm afraid the VC++ team can't take, uh.... credit for those things.  We're happy when we call things like our marshaling library the "Marshaling Library." I supposed we could also have called it the the "Microsoft Super Fancy Data Converter Template Classes Foundation," but that's just more typing.

But I hear you... we can often come up with some pretty head-scratching names as a company.  Although we do also get it right sometimes (Windows, xbox, and C# come to mind as good names).

Indeed, there will be no direct LINQ support in VC++ for Orcas, as least as far as new language enhancements go.  There are some LINQ APIs that are accessible from .NET languages without the LINQ-specific language features, and these kinds of things are accessible from C++/CLI, although I wouldn't be so bold as to call this "LINQ support."

However, we intend to get better and better about our level of interop with C#, so that it becomes increasingly easy to take advantage of C# as well as C++ innovations from VC++ applications.

What I mentioned in the video is that some of the language enhancements planned for C++0x (automatic type inference, for example) dovetail well with features need by LINQ, so it's possible we could chose to directly support LINQ from C++/CLI sometime in the future.

Framework deployment is certainly an issue for some folks, such as those that require fast, minimal dependency binaries (e.g., for deployment as a small web download).  I would say, however, that the group of customers in this category shrinks a little everyday as the frameworks become ever-more pervasive and developers continue to find value in managed code.

Hi Gary,

Re: MFC and WPF...

"Thanks, but I am looking for a way to do this in unmanaged C++. I would love to throw the CLR switch in my MFC apps, but the performance hit is too dramatic. Even the UI performance. Building the code is also much slower."

WPF itself is managed code, so you're going to be in managed-land no matter what.  You might try only throwing the /clr switch on those .cpp modules that require access to managed types.  Throwing /clr on an entire project that was originally designed to be native code (e.g., an MFC project) will definitely cause a bad hair day.  VC++ also allows you to delay load the CLR by placing your managed code in a separate DLL for which you would LoadLibrary() on demand.

I might also mention that we're working hard to improve the runtime as well as the build performance of mixed native/managed apps.  You should see the fruits of some of this labor in the Orcas release.

All the best,

Steve Teixeira
Group Program Manager, VC++
http://blogs.msdn.com/texblog

"About native C++ support, do you plan on putting WPF support into MFC? If not, is this exposed through COM or standard C calls?"

Gary,

For the Visual Studio Orcas release, we are not planning to build new MFC plumbing to connect MFC and WPF.  However, WPF is built with HWND-interop in mind, so adding WPF pizzaz to your MFC UI isn't too difficult to do.  As an example, check out this demo build a while back by Nick Kramer: http://blogs.msdn.com/nickkramer/archive/2006/06/08/622695.aspx

Thanks!

Steve Teixeira
Group Program Manager, VC++