Bill Dunlap and I had the opportunity to sit down with Charles Torre on Channel9 to talk Visual C++ product strategy. We talk about the three-pronged product strategy for the product, which is:
We also talk more specifically about some of the work we're doing for Orcas, including the marshaling library and STL/CLR, post-Orcas work we're doing on compiler front-end, cryptic comments on "big things" we're planning for MFC, and early thinking on concurrency and safer C++.
We also have a number of other Channel9 videos with other team members that will come online over the coming weeks that drill into more detail on our Orcas features.
All I can say is work on CLI for UI( because win32 and MFC suck.), and every thing else is gold.
Aaron, The WinForms designer already supports C++/CLI, and we also try to make it easy to build UIs in C# and integrate them with your C++ code using C++/CLI.
steve, doesnt that add to performance degradation? MFC and Win32 UI stuff is faster and less memory consuming than the WinForms one. (Since they deal directly with the system and winforms is over a .net abstraction layer, or atleast i think so, correct me if im wrong)
Maybe a faster lowlevel UI engine kinda thing can be really good to get the performance upto the mark. i did a small research project on "why today's applications are more memory and performance eaters" and interviewed a teamlead from mentor graphics and he jus said "oh well, cuz thats the industry trend. the memory is so much cheaper now, why not just use it as much as we can". (i was asking him why we cant use the techniques used in RTOS and embedded systems memory management in our daily apps). My argument was, why should msn messenger take as much as 60mb of my 512mb ram, internet explorer should take 70!mb of my 512mb ram at times and the latest visual studio can go over 150mb.... (not to mention some antivirus, a firewall etc). a good degradation of performance.. Yes there are some really slick performance tweaks and memory management going on, (like idle or minimized programs fall back from using memory and let others use their fairshare. but then, the performance overhead of maximizing the same application is nogood).
So a UI library or architecture that emphasis on performance and let the hard-core datastructures of program take hold of majority of the allocated resource rather than the other way round. Enlighten me if im wrong:)
because end-user is more important than the developer its just a tradeoff wether to build an _easy_to_use_ library/platform or a robust one. microsoft's strategy lately has been more on the earlier one (easy for the developers: enter C# 2.0)
Its there but you guys could do a better job of it. I don't like the idea of switching languages between ui and business logic. Not to mention its far more difficult to maintain and support.
To be fair I made that comment before watching the video. After seeing it I think your moving in the right direction.
PS
I find the C# ide lacking when it comes to large projects and complicated logic.
zakimirza: easy of use and robustness don't necessarily have to be mutually exclusive, but certainly the more power and flexibility the framework exposes, the more difficult it is to make the framework simple to use. I believe our choice of investment directions for C++, though, will pay dividends for those focused on building large-scale software.
Aaron: Glad you like the direction. We've come to realize that we simply cannot do everything C# and VB do *and* do everything that needs to be done for native code developers. Brilliant interop technology has to be a key part of our strategy for bridging the gaps.
> We've come to realize that we simply cannot do everything C# and VB do *and* do everything that needs to be done for native code developers.
OK, if that's MS's policy, then we all know where we stand, and we can make our software development plans accordingly. However, shouldn't MS then stop touting .NET's supposed "language independence" as one of its great advantages over other competing platforms? I can't even begin to count how many articles and presentations make a big deal of "language neutrality" in .NET. However, the official policy, as you say, is that there are 2 first class languages (well, one language with 2 syntaxes, really) for .NET, and a language such as C++ is very much a second-class language, useful only for communicating between the .NET framework and the underlying WIN32 world. C++/CLI is not intended for use in developing code instended to run inside .NET, such as WPF and WCF apps, so isn't it about time that MS's marketing stopped handing us the "language neutrality" line on .NET every chance they get?
Anyway, thanks for letting me vent. Now it's back to writing some actual applications (in C++, not in C#)!
Wil: I believe I've addressed this issue of .NET language neutrality vis-a-vis C++ in this previous blog posting: http://blogs.msdn.com/texblog/archive/2005/07/19/440621.aspx