TexBlog

Steve Teixeira's Blog -- Thoughts on parallel computing, Microsoft, the industry, and life

Your thoughts on VC++ product strategy

Your thoughts on VC++ product strategy

  • Comments 21

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.

  • 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.
  • 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.
  • 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
  • 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.
  • > 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...)
  • I'm doing mainly C# development. Every now and then, I dive into C++ because I want to interop with C++ components that come from other sources.

    To do so, I always write - whenever possible - a C++/CLI wrapper. So C++/CLI is important for me, but not because I'm a C++ developer, but because I'm a C# developer.
  • TR1 support 20 %
    Language features for concurrent programming 80%
  • 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.

  • 1) IDE : "browse info + stack callers" not just across all projects of the solution, include external projects and solutions
    2) IDE : fix that freaking random intellisense hang. It's about time.
    3) C++ and IDE, plus analysis tool : OS-specific configs. If I build for XP SP2, I expect the compiler to tell me, based on the what's available or not from the Platform SDK, what I can't use that would be Windows Server 2003 only for example. Think of it as FxCop rules based on the target config.
    4) C++ and IDE, plus analysis tool : more control over optimizations in regards to multi-threading : volatile, ...
    5) make it more easy to port a piece of code to Linux. i.e. include Linux headers of a popular distribution as part of the platform SDK.
  • 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.
  • For all MS's hype about how .NET is language-neutral, the reality is that MS makes it clear that C# is **the** language for .NET, so the main purpose of C++/CLI is in fact just to wrap unmanaged code rather than the development of .NET apps.  So, let's spend $30 on making the .NET / ANSI C++ interop seamless.  Then, let's spend another $30 on making the wrapping itself easier, by having a complete set of WPF and WCF bindings in C++/CLI so that the C++ wrappers can operate as effectively within the .NET Framework 3 as can an interface to a C# app.  Finally, let's spend the remaining $40 on concurrent programming.  Make C++ under Windows server be a genuine High-Performance Computing language for clusters and grids etc.  Number-crunching is C++'s domain, not C#'s, so put the money where you will get the biggest bang for the buck.
  • -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 :-).
  • 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.
  • 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.
  • 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
Page 1 of 2 (21 items) 12