Kang Su Gatlin - What's the advantage to writing managed code in Visual C++?

Beer, we're not at the point where we're talking about internals of Phoenix publicly.  But keep it on Channel9, because when we do, I'll be sure that the message gets posted here. As it stands today, the PPT on the webpage you pointed to is still the best place to get info on Phoenix.

Thanks,

Kang Su Gatlin
Visual C++ Program Manager

Kang,

I have enormous appreciation for MC++.  The ability to bridge managed and unmanaged code is so powerful.  It takes a lot of smarts to allow for such seamless Interoperability and optimization work that VC++ team has made, with each product release.  Congratulations!

My wish would only be if MC++ could be possible on the .NET Compact Framework.  As on the desktop, the embedded type devices (Windows CE base) have system level features only exposed thru native API.  P/Invoke is too limiting and primitive comparing to the power and flexibility of MC++.

Is it feasible to have MC++ on Compact Framework in the near future? (I am sure that VC++ team does not shy away from a challenge)

Mike M
WinInsider.com
Microsoftonian

Hi Mike, unfortunately in the near future (Whidbey) we won't have C++ targeting the compact framework.  I view the Compact Framework as a very important target, and post-Whidbey I consider this a key scenario.  Whether or not we do it in that time frame -- I'll have to answer that question as we get a bit closer.

But thank you for the feedback.

Thanks,

Kang Su Gatlin
Visual C++ Program Manager

I am surprised that you will have templates and generics. I have used the STL because it was supported on a lot of compilers for different platforms, it performs well, however, I have always disliked the interfaces. Are you including this so that you can port existing code that uses the STL and templates?

I can't imagine writing any new managed code using STL or templates unless I had a good reason.

Actually there is a lot of reason to use templates over generics.  Have you ever heard of BOOST?  Take a look at: http://www.boost.org/.  On top of that there are cool things like Blitz for using expression templates to do cool math (and does amazing things like not generating temporary arrays and such).

Templates in general give you the great advantage of runtime efficiency, while being Turing Complete (yes, you can express any computable function with templates). 

And there still is no equivalent to the algorithms and containers in the STL -- that I've seen at least.  Remember you can have user-defined specialization, and partially specialized templates.

Let me refer you to a couple of articles:
http://www.developer.com/net/cplus/article.php/10919_3367531_1
http://weblogs.asp.net/branbray/archive/2003/11/19/51023.aspx

I think you'll never look at generics and templates the same way again. 

Kang Su Gatlin
visual C++ Program Manager

I think the point I was trying to make is that I would like to use common library type functions suchas strings, containers and iterators from the .NET framework, and these classes should be optimised for performance. To be honest, in the future, I don't really want to see multiple libraries from Microsoft with overlapping functionality. But thats just my 10 cents.

In the past the STL implementation and in fact the template implementation in Microsoft C++ was quite poor. Just resolving compile errors was a pain,intellisense was useless and debugging a nightmare. So you might understand why I am scheptical about use of templates.

Thanks for the links and insight.

Kang Su,

Question:
For C++ software targeting the x86 CPUs, what are the trade-offs for using a 64-bit or 32-bit exe?  If the answers are seperate managed and unmanaged code, that would be interesting also.  ISVs need some solid criteria to base a decision on.

Question Background:
Obviously some things, like anything to run in kernel space must be 64bit.  But if the application does not gain in features (ex: does not need more memory space) does it make sense to rebuild?  Take mspaint.exe for example.  Microsoft chose to release that as a 64-bit exe, but is anyone going to try to paint a bmp that exceeds the 32-bit limit? (I suspect there was an order from on high that everything would be 64bit in the 64-bit windows so no per-application decision was made on that).  I am seeing 20-60% increase in memory consumption between a 32-bit and 64-bit build of the same code.  Even though you can add more memory you still have to pay for it!  I work mostly in the Terminal Server area, and when we talk about 200 or more instances running on a server of a 20MB versus 30MB app it becomes important (especially because the server farm may typically be 5-10 servers - That is a lot of money for the extra memory for just one app).  Those parts are relatively obvous, but what about 32/64 performance?  Is it "close enough to not matter"?  The extra registers and all.  And anything else that Microsoft learned so far with all the porting it has done?

Thanks