Recently Mohsen & Craig talked about a Renaissance within C++ development and Tony talked rebuilding our developer communication around C++, both of these videos touched on the subject of providing a more real world pragmatic discussion around why we do things and what we’re planning. This post is the first in a series of posts we’re planning on making over the coming months where we’re asking for your thoughts about what you need in a C++ development tool and about our proposals for the next version of Visual C++. To set the stage for those discussions we’ll be providing some insight into how and why we made some particular decisions regarding product features. In the case of something new we’ll share how we saw the problem space and how we’re thinking of addressing it.
We’re looking forward to hearing your thoughts regarding these features and how best we can use the developer resources we have to give you the most value in the upcoming product (ideally we’d want to deliver on 100% of your needs but, as you know, sometimes you have to make trade-offs so we’re looking for your help to make the right ones).
The first feature area we’d like to hear from you about is C++/CLI IntelliSense. Let’s provide some background explanation and then discuss what we’re doing.
As we are close to the final release of Visual Studio 2010 SP1, one of the top issues that came back is the absence of IntelliSense in C++/CLI projects. When we released the SP1 Beta last December, this issue topped the list of complaints as it was announced that it would not to be part of SP1. In this post we’ll explain a bit about the evolution of C++ IntelliSense support and one of the two questions everybody asks: why it’s not supported for C++/CLI projects in Visual Studio 2010?
Those developers who have been using Visual Studio since its earliest editions know that IntelliSense has been featured for both native and managed C++. So why is it today only available for native? IntelliSense is a powerful feature that has to meet certain goals:
Our first implementation of C++ IntelliSense appeared in Visual C++ 6.0 and we did this through the creation of a supporting file, the infamous .NCB, that contained consolidated references and definitions generated by the compiler. IntelliSense was pretty limited but still considered an outstanding feature as no other IDE at the time offered anything similar. The .NCB file contained a rich set of information including class members, global variables, etc. but we didn’t have complete information for such constructs as namespaces and exceptions. This deficiency and the fact that these files grew so large, complex and occasionally corrupted (who doesn’t remember fixing an IntelliSense problem by deleting the .NCB file and having it rebuild), that we needed to change the underlying implementation.
With projects becoming more complex, additional issues emerged such as the one known as the “multi-mod” problem. This problem occurs when a header file is included into multiple translation units with different contexts (such as difference macros). With the NCB approach, we only remembered one context for a header file and you would see incorrect results for IntelliSense when in a different context. There was also the issue where we needed to recompile many files when a shared header was changed. This could cause the IDE to freeze in some cases (this also happened if a compile option was changed, like switching from DEBUG to RELEASE). To address this we needed to not only better understand the information contained in the source code but also store that data more efficiently and reliably. We also wanted to ensure that the IDE was as responsive as possible. Initially, we used techniques such as background compilation threads, idle time detection and priority queues to achieve this but eventually we realized that a complete IntelliSense re-architecture was required. For Visual Studio 2010 we started that work and decided to use a live model for IntelliSense, while changing the store (which is still used for “browsing” features) from an .NCB file to SQL Server Compact Edition. This helped increase the performance while also decreasing memory consumption. We also wanted to address the problem of differences between how we interpreted the code for IntelliSense and how we did it for the final compilation product. This problem manifested itself in things like the language features appearing in the IntelliSense engine but not in the compiler and vice versa.
Prior to VS 2010, we used a modified version of our command-line compiler to implement IntelliSense. As we added new features to the language it was minimal work to enable them for IntelliSense. As part of our IntelliSense/IDE re-architecture in VS 2010 we decided to use a new compiler codebase for IntelliSense. This decision provided many benefits, but we simply underestimated the amount of work it would take to implement C++/CLI in this codebase, and we couldn’t change our plans by the time we realized it.
In addition to this unexpected amount of work, there were lots of new features that customers’ were asking for, such as:
Even with this constraint we really wanted to deliver IntelliSense for C++/CLI in VS 2010. We looked at several alternatives and mitigations, but nothing would fit our schedule and provide real value to our users. We considered trying to enable the old IntelliSense mechanism (i.e. NCB) for C++/CLI projects, but that would have been a huge amount of work as well. We also considered trying to hack something in, but we rejected that as well after investigation. We wouldn’t have been able to provide IntelliSense on any imported metadata, which would have made IntelliSense pretty useless for most people.
In the end it was one of those hard cuts you have to make when dealing with the real world resource and schedule constraints. It turned out that the work was also too much work to fit into SP1. As soon as we wrapped up VS 2010, we started work on C++/CLI IntelliSense, but it wasn’t ready in time for SP1. We realize this wasn’t what you wanted to happen and an explanation doesn’t help you get your work done if you are affected by this, but we want you to know the truth.
The good news, though, is that all these architectural changes made in Visual Studio 2010 have enabled us to deliver a better IntelliSense experience overall and will set us up to deliver a number of other features in the future.
Hopefully this gives you some insight into why we made the decisions we did.
The good news is that C++/CLI IntelliSense will be in the next version of Visual Studio. We’ve done a lot of work to get this in and, barring major unforeseen complications, you should expect to see it in the final product. As always, there is some risk, but we wanted to get this information out in front of you for your comments.
In our next post on this subject we’ll delve into more detail on our plans and ask you to comment on our thoughts. Stay tuned.
@ ‘small-mountain’ and ‘G’
Thanks for sharing the issues with Go To Definition. Yes, we are aware of the performance problems with this feature. We have addressed a number of these problems in the upcoming Visual Studio 2010 SP1 release. There are some fixes in SP1 that will help the general case (e.g. making IntelliSense PCH generation more fault tolerant to improve parsing speed, improving Go To Declaration performance and displaying a cancel dialog for long running Go To Definition operation etc.) and some others that improve performance in specific cases (e.g. improving the database queries when the include hierarchy is very deep and intricate). We are continuing to work on improving the performance of Go To Definition further in the next release of Visual Studio.
I am hoping that SP1 will eliminate some of the problems you are seeing. Please try SP1 (when it becomes available) and let us know if you continue to see these issues. If the problem persists I would like to work with you to investigate further. If needed, please contact me at sumit dot kumar at Microsoft dot com offline.
I am a long time C# developer and am quite familiar with the growing pains the C# team had with IntelliSense. VS2005 (my least favorite version or was that VS2003) crashed a bunch on me and I believe it had a lot to do with all the stuff IntelliSense was trying to do. VS2010 with the PowerTools extension kick major backside in C#. From Dot Net 1.0 (I think it was VS2001) up to VS2010 have seen constant improvements.
I suggest not trying to get the kitchen sink in on the first go around. Grow it as you develop the platform. It will never be instant but the utility of it will make the slight slowdown bearable.
Sorry, I was too harsh. I used VS6 for very long time (I believe till VS8 came out), and never used class viewer or any other component that needs NCB. For code refactoring browse info was ideal -- precise and very fast.
Good luck with fixing Intellisense. This time for sure...
Great to know it's coming, even if we still have >1 year to go :)
That's definitely good news, Intellisense in C++/CLI would be a productive addition. One other thing definitely on the wishlist is the same support for project and item templates that we have in C# and VB. The wizard framework is, frankly, antiquated and the documentation obscure. Is there a centralized location for feature requests?
@Andrew Marshall, you can make feature requests and file bug reports at connect.microsoft.com/VisualStudio.
small_mountain, I agree with you. I think C++/CLI is the perfect language to use for migrating to .Net. I think it's better than C#, too, especially since C# doesn't have destructors. I, too, ported a large legacy application to C++/CLI and it was relatively easy. It sure would be nice if I could stay in the C++ world and still do .Net. Sadly, I think the same Microsoft mentality that resisted putting an MDI window into VB is the same one that thinks forcing yet another underpowered language on us makes sense.
I say, C++/CLI is all we need. It's a C# and java killer. People say C#'s syntax is cleaner. Maybe so, but it's more limited - not to mention all of the extra, confusing keywords and did I mention lack of destructors? And who really thinks getting rid of header files is a good idea?
Hey Microsoft, stop treating C++/CLI like it's only an "interop" language. Treat it like the superior language that it is.
Very sad, no wonder you poorly allocated resources when most of your people dwell in the clouds dealing with abstractions. You can't build a huge castle on the poorly done foundations of a two bedroom house, this should be more than obvious to you and the fact that it is not really worries me as I have a lot riding on your ability to properly identify priorities. Instead of building three iterations of MVC, maybe you should have done a single iteration of a proper Intellisense. Just maybe? Its not like abstracted stuff can't be made by community, but stuff at the core of VS most certainly cannot be.
So basically you guys screwed up and now I get to pay for it at my place of work? If I gave this same excuse to my boss I would be fired. Visual Studio 2010 is a very expensive piece of software, for the money it costs, there should be a second service pack just to provide this feature.
One more thing could be improved for C++ in VS. It would be nice if the .h and .cpp files could have been always opened t6ogether in one window, but with two tabs: one for .h file and one for cpp file, as it is Borlan C++ Builder.
we c++ developers have been treated like 2nd class citizens ever since .net 1.0.
anyway all this is academic as i move to xcode 4 where it DOES support intellisense for obj-c and C++ in the same project file.
MS is losing touch i feel
I do both C++ and C# programming and I find C#'s "Extract Method" refactoring tool to be superb.
I would like to see the "Extract Method" refactoring tool in the next version of Visual C++.
Microsoft has been doing it's best to make C++ developers life hell since .NET 1
Guess what you've succeeded ! Eclipse is now better for C++ developers.
Hi @Micky D, @Cpp director,
Admittedly, we did way less for native C++ than for .NET in Visual Studio. We are doubling efforts to reverse that trend and some announcements are starting to be told in that sense. The comeback of the C++/CLI IntelliSense being just the first but there are going to be more.
For sure the question is "why not now?" Tony Goodhew explains that better than me: blogs.msdn.com/.../10135761.aspx
Thanks for sharing your suggestion. We also realize that "Extract Method" is a very useful feature. We'll look into this for future releases.
Thank you again for your support!
Program Manager. Visual C++ team