Your thoughts on VC++ product strategy

The Visual C++ product unit is currently in the process of refining its strategy for the post-Orcas timeframe.  We'll definitely share this strategy as soon as we're able to do so, but meanwhile I'd love to get your thoughts on how you'd like to see Visual C++ evolve.  Would you like better productivity features (Intellisense, refactoring, etc.)? More features for native code developers? More features for managed code? Better native-managed interop technology? Language features for concurrent programming? Better compiler throughput? Improved debugging? More MFC classes? TR1 support? Are there entire scenarios of development you think could be better covered? Something else?

Because it's easy to say "everything" when there's no cost associated, I'm going to make it a little more difficult: pick the top 4 things (either the things above or stuff you come up with yourself) you feel should be components of the Visual C++ strategy.  After picking those 4 things, pretend you have $100 total to invest in these 4 items and that investment must be divided among them.  You can invest $25 in each or weight your investments based on your opinion of an item's importantance.  So, for example, your investment mix might look like this:

Scenario / Feature area A: $50
Scenario / Feature area B: $25
Scenario / Feature area C: $15
Scenario / Feature area D: $10

Your opinions really do have the ability to influence the direction of the Visual C++ product, so I appreciate any input you have.

Comments

• Anonymous
  August 29, 2006
  Definitely native enhancements here. C++/CLI is essentially another language and efforts in porting existing code to it (IMO) would more wisely be spent porting to c# if the CLR is your destination.
• Anonymous
  August 29, 2006
  Full Intellisense and code documentation support for native developers; some sort of plugin scenario for different doc tag models (e.g. Doxygen, QT and the MS triple-slash).
  
  Having an "more than 1 hat" suite would be very useful for small shops. All VS features could then ship on the one CD with the license key determining which ones can be installed or activated. The other features could be installed but are inactive (e.g. readonly) until a new license is installed. The license could be user-specific so if the architect logs in the architect features are available, but if the QA guy logs in they are disabled.
• Anonymous
  August 29, 2006
  Improvements to native code, please.
  
  I do a lot of managed and unmanaged development. However, the two worlds never meet. Managed development is done entirely in C#, while unmanaged is done entirely in native C++. When work wants a legacy native application ported to .Net, they ask me to rewrite it from scratch in C#; we do not use managed C++ or the interop features. VC++ only exists to me for native development.
  
  Prefacing it with that, the best that you could do to help me is to make improvements to native C++.
  
  One thing that would help is working Intellisense. Intellisense dies on me at least once an hour, and often faster than that. I often close VS, delete the Intellisense database, and restart. Or, more often, I just put up without it.
  
  I am quite happy with the improvements made to supporting standard C++. I hope to see more improvements and conformance in the future. There are still issues with templates that I am sure you are aware of.
  
  No thanks on more MFC.
  
  TR1? Sure.
  However, how about implementing the export keyword? It's been part of the standard for a long time now. It would help with working with templates. Lets get the old standard implemented first before starting on the new stuff.
  
  I'd also like to see some more work done to optimizations. Looking at the assembly generated often shows areas where further improvements could have been made.
  
  One major area of pain is debugging linking errors.
  /verbose is a start, but I would welcome a LOT more help.
  
  To put the above into dollars...
  
  $90 Conformance improvements to C++ standard
  $5 Debugging linking errors
  $3 Working Intellisense
  $1 Optimizations
  $1 TR1
  
• Anonymous
  August 29, 2006
  There is a reason to say everything.
  
  This year I've pretty much been working on one project, for which it would be easy to answer, put everything on C++/CLI for Windows CE.  If you have any reason to like C++/CLI and if you have any reason to like your Q then you might feel this way too.
  
  But other years things have varied from month to month and the answer is pretty much everything.
  
  Fortunately Microsoft isn't quite as monopolistic in either the compiler industry or the embedded industry as it is in the ordinary PC industry, but it still has some of the same effects.  No one else seems to be building a compiler for C++/CLI for Windows CE because as soon as they do it Microsoft will eat their lunch.  For ordinary PCs maybe I should look to see if Eiffel/CLI and Delphi/CLI exist yet, but even if they do, I'm never going to have time to play with them until after I retire.  For practical purposes we're still pretty much under your thumb, so I wish your thumb were broader instead of just heavier.
• Anonymous
  August 29, 2006
  > Your opinions really do have the ability to influence
  > the direction of the Visual C++ product, so I
  >  appreciate any input you have.
  
  Would Connect not be a better forum to generate feedback?
  I know that I have posted feedback, and have voted on other's feedback.
  
  At the moment, there are...
  16,656 registered users
  26,626 total bugs
  11,356 total suggestions
  
  Unfortunately I can not filter those numbers specifically for VC++, but I imagine Microsoft can process the data appropriately.
  
  There are many suggestions and bugs that have been postponed or marked won't fix. How about re-evaluating some of the more popular ones?
  
  Connect:
  https://connect.microsoft.com/VisualStudio/Feedback
  (Oh what I would do if I could just get the old Ladybug system back...)
  
• Anonymous
  August 29, 2006
  The comment has been removed
• Anonymous
  August 29, 2006
  TR1 support 20 %
  Language features for concurrent programming 80%
• Anonymous
  August 30, 2006
  That's a tough question for an outsider. Is the VC++ team in charge of the MFC or is it the Platform SDK team?
  
  Will Vista still be the target OS for the post-Orcas release, or will it be Vienna? Is Win32/Win64 here to stay? Will native and managed development co-exist or is native evil and responsible for all security problems of Windows?
  
  C0x and TR1 is a must, so I'd say 30%
  XAML support for C++/CLI: 10%
  
  We've OpenMP, Visual AssistX, BoundsChecker and other tools and libraries, so you should concentrate on the compiler and platform stuff and leave stuff that others can do (better) to them.
  
  I'm not happy with C++/CLI, because it is not C++, period. What "you" did with unions is a shame.
  
  I would like to be able to compile my C++ source either to a target CPU or to IL. That's even doable today with many #defines and typedefs, but the compiler should be responsible for that. Memory management seems to be the biggest problem here. So I give another 30% to a ANSI/ISO C++ compiler for .NET.
  
  And then I would say the VC++ team has the burden to lead the C++/MFC developers to a new application framework. And I'm not talking about interop etc. but migration to a new framework. If .NET is the target then write wrappers and some classes for document/view, command routing etc. So you should spend the 30% which are left on that.
  
• Anonymous
  August 31, 2006
  The comment has been removed
• Anonymous
  September 01, 2006

1. I vote for support of /clr switch in Smart Devices projects for CE 5.0 and above. It's Number One.
   2. ALL VS dialogs must be resizeable and remember their position for each screen resolution.
   3. Project properties and project wizards - if you have Smart Device project it's hard to add Win32 configuration and vice versa. It's hard to copy all your 10-15 configuration to new project (actually it's very easy with Copy&Paste of Configurations section in *.vcproj).
   4. I hope VS 2005 SP1 will fix Intellisense.
   5. Add context menu "Open this address in Memory Window" for variables in watches/locals/autos. Or even for all objects and open the memory where the objects reside. Cool feature would be to highlight bytes in memory window when i click on the class member occupying these bytes.
   
   
   I would have added compilation speed but I expect 8-in-1 CPUs at the time of the Post-Orcas release.
   Anyway, for C++ language compilation speed is very important.
   

• Anonymous
  September 07, 2006
  The comment has been removed

• Anonymous
  September 11, 2006
  -I definitely agree with those suggesting to put the big effort on concurrent programming with priority to unmanaged C++: $40 to $50.
  -Improving native code generation $30.
  -Taking into account the many bugs we have in VC++ 2005, I suggest spending the rest on QA :-).

• Anonymous
  September 11, 2006
  Judging by the number of posts on my favorite developer forum and a recent voting C++/CLI hasn't caught on yet.
  
  While the C++/MFC forum is swamped with posts there are hardly 5 on the C++/CLI forum.
  
  But then again there are as much posts on the C# and VB.NET forum as on the C++/MFC forum, so either C++/CLI just needs some more time or people resist from using it. Judging by the recent vote only a handful of developers are using it or intend to use it.
  
  VSTO doesn't support C++/CLI, no XAML support and WinForms with C++/CLI is only for diehards.
  
  So far C++/CLI is only good if pinvoke doesn't do the job.
  
  It doesn't surprise me that most C++ developer asks for native enhancements.
  
  If you really want to push C++/CLI the following is required:
  
  - MDI support in WPF
  - More / 3rd party controls for WPF (Ribbon, Docking)
  - XAML support in C++/CLI (I know that workarounds exists)
  - MAF (I hope that 3.0 and later versions play together well)
  - .NET linker
  - More ANSI compliance syntax
  
  And of course support for mobile devices.
  

• Anonymous
  September 15, 2006
  There is also a concrete change to the MFC I'm looking for, beeing able to remove the border of the MDIClient window.
  
  MFC always resets the style on every possible occasion. The style should be restored when you restore a MDI child window and not set to the default.
  
  Also the legacy stuff that forces the "File Window Help" menu pattern should be removed. I'm using a Ribbon now and had to create a dummy resource that follows those 20 years old design guideline to avoid an assertion everytime I start the app.
  
  So please muck out MFC, that's a minor task.
  

• Anonymous
  September 29, 2006
  Implement the Standard properly: $40
  
  Make sure that there are no reasons for template-heavy systems like Boost to have to work around VC++ limitations in eg spirit: $30
  
  Compile fast on multicore systems: $30
  

• Anonymous
  October 01, 2006
  exported templates: $75
  no restrictions on where an interior_ptr can be declared or allocated: $25
  

• Anonymous
  October 01, 2006
  The comment has been removed

• Anonymous
  October 03, 2006
  Thanks to everyone who provided feedback on my last post on VC++ product strategy . While I totally appreciate

• Anonymous
  October 16, 2006
  Steve Teixeira (Current Group Program Manager for VC++) has a nice series of posts ( here , here , and

• Anonymous
  June 09, 2009
  PingBack from http://besteyecreamsite.info/story.php?id=2414

• Anonymous
  June 16, 2009
  PingBack from http://lowcostcarinsurances.info/story.php?id=7681