Visual C++ Futures

The more that you focus your efforts on native code, the better.

Managed code is great, but 100% of my managed code development is done in C#. When transitioning to managed code, customers ask me to rewrite the code in C#. They do not want native / managed interop.

Each release of VC++ has improved compliance with the standard. However, there are a much of issues still remaining. I think these should be a high priority. The older standard should be fully implemented before implementing the currently proposed update. For starters, export is still missing. (Like it or not, it is part of the standard and it is not being removed.)

I can not speak for everyone, but in my experience, any work done to further interop will be useless to me. The more done to improve native code the better. Make the most compliant compiler on the market.

IDE Pain Points

Each version of VS

- loads more slowly

- compiles more slowly

- the IDE is more unstable

- library searches produce more irrelevant hits

- introduces more on screen clutter

Dynamic help isn't and probably never was.

Closing a file opens the branch in solution explorer. Never found the collapse all.

Would be nice if the current IDE could drive the older compiler chains.

Debugger sometimes looses selected stack frame wrt watch variables.

Remote debugging setup stupidly manual.

CRT deprecation system is broken for legacy and cross platform code.

Platform Pain Points

Concurrency/Throughput

- some interesting technologies and APIs (e.g. IOCP), but...

Portability

- the great debacle for server type apps

- older Windows and Unix platforms have severe API differences

- least common denominator or multiple implementation?

- mixed results with common open source libraries

Standards

- kudos for improvements, keep it up

- IMO, forget export, it was DOA

Top 3 requests:

- C++ 0x support - really like to this get into future VC++

- IDE Performance (browsing, opening, editing, ...) - can save a lot of time and electricity :-p

- Stardard compliance - VC++ is too tolerant for bad (old) C++ code

Larry,

We hear your concerns, especially regarding code bloat in VS and the impact it has on performance (such as load time and compile time).  We've worked hard in VS2008 to hold the line on performance and to improve it in many areas, and we'll continue to do so in the future.

In the mean time, if you have any specific performance concerns (especially for the VS2008 Beta) you're welcome to e-mail us: DevPerf@Microsoft.com.

Best Regards,

David Berg

Developer Division Performance Engineering Team

David, my post ended up more negative than I had intended. I do like the VS editor and debugger very much. But I spend quite a bit of time with it and a fewe things just end up driving you crazy.

I tried beta 1 only briefly but did run into an  issue. VS will refuse to (directly) open solution files if the previously open solution file's directory is removed. I haven't had a chance to install beta 2 yet. Is there a reason you need to register to submit bug reports?

Larry,

Thanks for the input, I'll forward it to the appropriate team.  Registration for Bug Reports is primarilly so we can follow up with the individual submitting the bug if we need more information or need help in verifying a fix.

Regards,

Dave

Larry,

Can you e-mail me details on how to reproduce the open solution issue you mentioned: David.Berg@Microsoft.com?

Thanks,

Dave

I was waiting for Orcas for one little C++ thing: a valid TR1 implementation.

It seems that I will have to wait for the release of C++0x in order to get all these nifty classes (other solution: DIY or buy a separate implementation... Well, DIY is quite fun (especially since compiler support hurts a bit), and there is not much available solutions out there).

Other than that, the C++ compiler is roughly similar to VC++ 2005 (it still accepts the same bogus code, especially wrt double phase lookup), so is there a specific reason to update?

Thanks everyone for the comments.  We definitely hear you with regard to improved C++ conformance (both compiler and library) as well as IDE performance and scalability.  There are things that we are actively working to address for Orcas+1.  

Bill Dunlap

Visual C++ Development Team

I really would like to see more convinience libraries like the .NET classes over in C++. There are many similar looking things but they drive you crazy if you try to use them in the same way like in C#.

The ATL CPath class is very cool but CAtlFile is a nightmare to use.

CAtlFile OpenFile(const CString &file)

...

CAtlFile openedFile = OpenFile("C:\\foo.txt");

If I try to use it as simple as this I get compiler warnings that I use a non standard compiler feature (conversion of a value to a reference).

If the open fails and I do check the file handle now for NULL or INVALID_HANDLE_VALUE?

After fumbling around I did go back to good old HANDLE values I can much easier check for correctness.

A new library with a consistent error handling approach would be very cool to make silly coding errors where you check for the wrong return code occur less often. Yes exceptions can help but any new library should work as seamless as possible with the Windows APIs for interop.

Yours,

  Alois Kraus

I'd like to put in a vote for continuing to address interoperability smoothly. I am working on a very large legacy C++ project, so native code is critical. But as we build more data interoperability the XML and webby friendliness of the CLR libraries are too much to resist. And large pieces of the new interface ought to be built using managed code, but will clearly need to call back and forth with the unmanaged components -- including unmanaged interfaces in libraries like Qt. In short, managed code should represent a practical way to augment existing C++ code without having to flip a switch and recompile the whole thing.

I really like VS 2005.  I develop mostly C++ native apps.  The performance of C++ Intellisense is the number one pain for me.  I have 100,000 lines of code spread out over 10 projects, and normally keep them all in the same solution.  I use boost and stl quite a bit.  I have had to turn off Intellisense (via renaming feacp.dll) because my CPU goes nuts every time I change a header file.  I have a dual core machine, not sure if that makes it worse or not.

In constrast to many of the folks who have posted comments, managed/native interop is EXTREMELY IMPORTANT to my group and to others who are developing high-performance critical applications.  My application is medical imaging, and our front-end is .NET but Managed C++ for performance reasons.  (We heavily utilize OpenMP and there is no way we can get the same performance using C# - believe us, we've tried).

Forms support in VS C++ 2005 basically sucks.  Half the time the designer can't load the form and how come it takes 10 minutes for a form to load while in C# it takes a couple of seconds?  Sometimes we've had to resort to manually editing the header file to move buttons around!

Also, the designer generates atrocious looking header files.  Why not borrow from C# 2.0 and use "partial class" definitions.

More OpenMP/multi-core enhancements would be appreciated, fix the forms support, I personally don't care about export but do care about C++ TR01.  My group is also very interested in STL/CLR.

As an ISV working in Visual Studio extensibility we work with every version of the Visual Studio family from VC6 and eVC4 through to VS2008. You wouldn't believe some of the howlers we've seen in the IDE interfaces - the Visual C++ automation interfaces (VCProjectEngine) in particular.

We still develop mostly in VS2003. Why? Simply because developing add-ins in VS2005 is a royal pain - the environment is sluggish (especially when the IDE is loaded under a debugger, which we of course do regularly) frequently locks files it shouldn't (especially Satellite DLLs) and can't even successfully toggle the load settings of add-ins loaded through HKLM (this bug, incidentally was reported to MS in VS2005 Beta 2 and closed as "won't fix").

As such we are stuck using earlier versions of the Windows SDK and with a real problem on dev machines running Vista.

We'd love to believe that VS2008 will be the platform that will allow us to move to the latest Visual C++ libraries, but the fact is that unless VS2008 addresses these issues *and* makes the runtime library easier to install (hint: provide a way to circumvent those SxS manifest requirements where appropriate) it just won't happen.

+1 for the vote about allowing VS to open and work with previous versions of solution/project files too. We maintain dual VS2003 and VS2005 (the latter primarily for occasional work on Vista) solution and project files, and keeping the settings in sync is a royal pain. How about providing a tool for automated conversion in both directions?

Oh and if you are serious about really getting VC++ up to speed please do something about getting the toolset in sync with other Visual Studio supported languages. Tools like Sandcastle need to be able to handle native code too.

I'd love to see some tighter integration between VS debugger and virtualization technologies. Actually, that applies not only to VC++ but the whole VS in general. With the vastly improved performance of Virtual PC, I tend to do development & testing on a virtual machine more and more. The way I debug my applications in virtual machine is using Remote Debugger (or WinDbg). Well, it works, though I am absolutely positive that you guys can achieve some more seamless experience.

I presume improvements in this direction will be welcome even more when employing virtualization for development needs will become mainstream (if it hasn't become such already).