As the title suggests I am interested in knowing if Microsoft has any plans to improve the C++ programmers experience with the next VS.
I've tried to use VS 2005 for C++ projects but I failed to do so in a productive manner so now I'm only using it just for C# applications. My main reason was that VS 2005 is difficult to use.
In a normal project I use perhaps 5-10 functions of the IDE and nothing more. This means I expect lighting speed and precise results. Yet the tool is quite slow in performing them as, I suppose, it loads a lot of unnecessary components (to me).
As it is now I find VS 2005 for C++ quite similar to what Forte was a couple of years ago for Java: a tool with a huge list of great features but at the same time a tool that was painful to use.
Making a unique IDE for C++/C#/VB might be a good marketing idea but I think that had a negative impact on the C++ side of the tool. I believe different languages require different tools and if Java/C# programmers might like a slow but rich tool I think C++ programmers expect something else. At least I do.
A big issue that was already mentioned by others is the documentation. I recently uninstalled the MSDN coming with VS 2005 and reinstalled the version coming with VS 6.0 as I was using Google to find Windows API and C++ libs docs more than I was using the local MSDN. I understand that C# needs to be promoted but I fail to understand the need to cuts parts from the C++ documentation (or making them difficult to find).
Because of all these issues, my company is still using VS 6.0. The only major downside of VS6 compared to VS 2005 consists in the compiler/library bugs. But, as we are familiar with them they can be avoided.
It's not all bad, there are some nice new features and I'm sure more will come. I want to benefit from the improved compiler and some of the neat features but I'd prefer them in a lighter packaging. So my plea is to let the programmer configure the tool to suit his needs and feel good while using it.
I do not plan to stick forever to VS 6 but when I migrate I want to do it to a better tool. Hopefully the development team will manage to make Orcas such a tool.
Last edited by PadexArt; June 21st, 2006 at 03:22 AM.
Your message here is: I'd love to use this product but the main "adoption blocker" is the IDE usability/performance/bugs. I sat down with them in October of 2003 and gave them that exact message. And for the most part VC 2005's IDE usability is a great improvement over VC 2002/2003. That's why I've started to use it over VC 6 because I believe they were and are committed to solving this adoption blocker.
However, some problems still exist:
1) Intellisense is impossibly slow (and/or loops) in large projects (hotfixes potentially can alleviate this)
2) Intellisense does not work well with multiple subprojects (a single NCB file cannot differentiate between the projects so you get mixed up syntax greying, missing symbols etc) - only workaround here is separate instances of VC for each vcproj so separate NCBs are generated - not sure how committed they are to solving this one.
3) Combined with Visual Sourcesafe, the Pending checkins window is impossibly slow (major regression since 2003) and they are not interested in looking at this (but workaround is not to show the pending checkins window at all - not happy with this but can live with it)
4) Clicking around in the project tree can be very slow (opening and closing folders etc) - can live with this - will be buying Conroe machines in a couple of months.
I think PadexArt has hit the nail on the head on this...I should also add to this...let the development community and the R&D department design the Visual Studio and not the MARKETING DEPARTMENT(who would not know a pointer form a Mutex).
ATP BE400 CE500 (C550B-SPW) CE560XL MU300 CFI CFII
"The speed of non working code is irrelevant"... Of course that is just my opinion, I could be wrong.
"Nothing in the world can take the place of persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination are omnipotent. The slogan 'press on' has solved and always will solve the problems of the human race."...Calvin Coolidge 30th President of the USA.
We are for sure taking all such feedback in consideration. I really doubt that you will see major changes in the Orcas time frame. Please at any time feel free to use the product feedback center to record your suggestions. We really look such suggestions and evaluate them.
As for the documentation issues, as I mentioned early, I agree we need to have more VC++ specific docs & samples....thanks for putting more on my plate :-)
Intellisense is impossibly slow (and/or loops) in large projects (hotfixes potentially can alleviate this)
Not only on large projects. I'm using VS 2005 and I'm working both on small projects (say 10-15 files) and larger projects (1000+ files). What I've noticed is that sometimes, when the Intellisense is updating, it takes as much time regardless the size of the project (well, I didn't do benchmarks ).
I see someone has added [RESOLVED] to the post title. I have to disagree. The concerns/issues I have expressed with regard to VS 2005 are not strictly related to the IDE or the IntelliSense. The IDE is indeed a major part of the problem but it is more an effect of the real problem and not the cause.
As I see it, Visual C++ is: C++ (the language) + Microsoft Libraries + Documentation + Community + Microsoft Commitment. The last component is the most important one and, at the same time, the one that seems to decrease with the last releases of VS.
I do not comment here the statements Microsoft has made on the topic, including this forum, but their effects. The MFC and the other libraries have not suffered a major update compared to the versions available in VS 6.0. And from other posts on this forum it seems there are no short-mid term plans to do so.
I think a lot of VC++ programmers would throw a party if even 25% of the .NET platform would become available in the form of an unmanaged library (included in MFC or not).
The Microsoft libraries (MFC, ATL etc) and a good/clean IDE are what made VC++ my #1,2,3,4,5 option when it comes to desktop applications. Working for Vista with these aging libraries is like going to war with a toy sword.
So my question is: what are the long term plans for the unmanaged VC++ as a whole? Would we be able to achieve the same results with it as we would with .NET or C++/CLI? Even if that would require considerable more effort from our side.
With the debut of the .NET, the Visual C++ team was forced to deal with three different programming models: native, managed, and mixed. This is not a situation faced by either the VB or C# teams...nor did we have to deal with this up to and including VC6. To advance the product on all of these fronts we had to make some tough feature decisions. You correctly pointed out that we focused the last several versions on trying to provide a good .NET experience for C++ developers. Since this was "the new thing" it made sense to skew this way. But due to the inherent differences between the design of the CLR and the design of the C++ language...this has been difficult work. As a result, we haven't been able to advance the product (esp around native code) as much as we would have liked to. This is not to say that there were no native code enhancements. In the past few versions we have added a variety of IDE productivity enhancements, Whole Program Optimization, Profile Guided Optimization, /GS to guard against stack buffer overflow, SafeCRT, native 64-bit targeting, etc. That said, we recognize that more work on native code development must be done. Your posts to the chat further confirm that this is something we need to address. Native code is still vitally important to Microsoft and in future versions we do plan to advance the state of the art.
As to your question about "achieving the same results" with native C++ as you can with .NET...this distills down to a productivity issue. .NET development involves a tacit trade-off of run time control for developer productivity. So while you gain productivity you must also deal with the limitations enforced by the CLR. With native C++, on the other hand, you have the complete power and performance of the platform (HW and SW) at your command. The trade-off with native is that developers must deal with greater design-time complexity. The bottom line is that .NET development will always be faster than writing native code. Yes...we need to do more to make native C++ development better, faster and cheaper. We hear you. But it is not likely that you'll ever get the same programming productivity benefits in native as you get with .NET development.
Thank you for your detailed answer Bill. I want to clarify a single idea:
Originally Posted by bdunlap
Yes...we need to do more to make native C++ development better, faster and cheaper. We hear you. But it is not likely that you'll ever get the same programming productivity benefits in native as you get with .NET development.
I am sure any C++ developer understands and accepts this tradeoff as long as he can still get the job done. With the current market, passion/pleasure for C++ cannot replace entirely the productivity issue you've mentioned. Although I would love to make everything from scratch (an MFC.NET or something ) using just the compiler and the APIs, that's just not feasible.
So it is indeed great news to know there are plans to improve VC++ as a whole, at least to a level where it can be reasonably competitive. As already mentioned I would be very happy even with 25% of what is currently available for C# and .NET.
One thing to note is that in the mean time you can still keep all your current investments in MFC yet be able to use the .NET framework selectively within your application. Using C++/CLI to call some .NET APIs is a very effective way for doing this.
Lead Program Manager
Microsoft Visual C++