C++/CLI IntelliSense in Visual Studio vNext

C++/CLI IntelliSense in Visual Studio vNext

  • Comments 48

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.


Why We Didn’t Include C++/CLI IntelliSense in Visual Studio 2010

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?


A Brief Evolution of IntelliSense in C++ Languages

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:

  • Accuracy: all suggestions must fall within the context you are in, still encompassing the latest version of the complete related projects (i.e. a change in a header file).
  • Speed: as fast as your fingertips. Thus the implementation must be based on a time-critical approach.

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.


The 2010 Dilemma

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:

  • An improved IntelliSense error reporting.
  • Faster compilation and more optimized code generation.
  • #include auto-completion.
  • The ability to target specific compilers and libraries.
  • New MFC features like the class wizard or the restart manager.
  • A build platform that provides better diagnostics, extensibility and integration.
  • Improved C++ standards adherence.
  • Support for parallel programming from both libraries and tooling (debugging, etc.)
  • Standard Library improvements.
  • Availability of Windows 7 technologies (like Direct3D 11, etc.)

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.


C++/CLI IntelliSense in Visual Studio v.Next

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.



  • who gives a poop and who has time to read all history evolution about intellisense?

    just say you f-up and we are stuck to typing every damn class member that is 28 char long..yeah, case sensitive too.

  • One question: IFF you are concerned with speed with which the application is responding to user, why on bloody earth did you "write" VS2010 in your version of Java instead of C++? I've asked a question here: programmers.stackexchange.com/.../whats-more-important-to-write-programs-fast-or-to-write-fast-programs

    which deals with productivity (writing fast programs slower and using them) vs false productivity (writing slow programs fast and using them). Results are more than interesting.

  • Hi @Knowing,

      I'm to ask about the very reason why VS UI was recoded in managed code (by when I joined the team, VS10 had been released more than 6 months before). But let's not mix people/teams in this story. This story is about the reasons why the Visual C++ team failed in shipping C++/CLI IntelliSense in VS10. So there is a comment about performance concerns. The UI build in managed code is nothing the Visual C++ team decided (we don't build the UI either). The decision was taken at a Visual Studio level and I'm to ask them for the reason.

  • @Diegum, ok, so maybe someone from Microsoft (maybe even you) could enlight us and explain why having at hand super fast, tested by millions by over 3 decades, incredibly flexible etc etc etc. language in which the most famous, popular applications in the world are written, instead of this they choose to do it in MJ (Microsoft's Java)? When I run VS2010 and compare its perfomance with VS2008 I literally want to cry.

    But I tell you why I think "THEY" did that (recoding VS in MJ) - they wanted to show/proove that "their" language is as good as C++ and can be used to such massive task as to write IDE for C++ developers. And you know what? The only thing "they" proved is that MJ is uncapable of doing it. Working with VS2010 compared to VS2008 is like driving ford fiesta and Porche 911 respectively. I used to love VS before 2010 now I literally hate it. I'm using more and more (at home for now, but my boss asked me quite recently about it too) code::blocks - the more I use it the more attractive I find it (code::blocks) and I hope that we (the company I work for) will start use it as well.

    I'm sure you're familiar with code::blocks. It's Porche 911. And you (microsoft) created equivalent of ford fiesta and you're surprise that people (C++ developers) are furious and dissapointed?

    If I wanted to write C++ apps in managed IDE I could use NetBeans - has everything what developer needs and it's free...

  • Hi @Knowing, I'm totally respectful about your opinions.

    I contacted Paul Harrington (Visual Studio Pro team), who delivered in PDC 2009 a session explaining the reasons that -by then- motivated an UI switch to manage code. The session is posted here www.microsoftpdc.com/.../CL09

    About performance, Paul told me that he deals with IDE performance directly and that arguments against “managed code” or “WPF” for Visual Studio 2010’s performance problems are usually too general without any supporting evidence to support them. I must -knowing about some performance issues that my team (Visual C++) fixed for SP1 without touching the IDE- that Paul’s comment sounds reasonable. This C++/CLI IntelliSense is yet another example that VS2010 performance issues are not necessarily related with the UI.

    I like the point you rise about faster coding vs. faster execution. I don't believe -this is my personal opinion based in my, both, MS and non-MS experience- that there's an absolute answer for that question. I prefer C++ and native development in general but I’m willing to participate in coding projects using alternative languages as long as the final result is fair enough and maintenance is affordable for the entire team (that is to say, beyond my personal favoritism for C++).

    Yet in our own community, native development, you find people arguing that there’s an ocean of difference between C++ performance and C-Language one. If you review comments in these posts, you’ll find those two contender audiences quarreling sometimes. What can I (personally) say? I try to avoid C-language development but I found a specific case of a routine whose execution speed is highly critical and makes the difference between acceptable and unacceptable, I’d give a try to C-language or even Assembler.

    That said without invalidating your opinions. I’m just trying to mean that there’s not absolute answer to the trade-off “faster to code” than “faster to run.”

    What we, the Visual C++ team are procuring is to make C++ development as easy and productive as managed code. We started sharing a few details and we’ll keep disclosing more info in the next weeks.

  • Hi Diegum,

    Thank you for your reply.

    I (in the beginning of this comment) want to say that I'm not trying to be either harsh nor argumentative etc etc.

    But I have to raise few points:

    1. From your last comment: "Paul told me that he deals with IDE performance directly and that arguments against “managed code” or “WPF” for Visual Studio 2010’s performance problems are usually too general without any supporting evidence to support them"

    This is bit like in 1950-70 Russia. And let me tell you why. In this period in Russia every possible raport, meeting, plan etc. always stated that there are only good results, nothing but good results and that people are happy and the "bad things" are a work of evil traitors.

    What is he talking about? What is too general? If he wants supporting evidence then the only thing he should do, is to run VS2008 and compare it's performance (by eye only) with VS2010.

    I've watched the video. Again, empty, pointless, boring for most of the time, neither instructive nor informative (too long to be classified as a briefing to short to teach anything really) like one of hundreds of this type of presentations. The only thing that was interesting from this material was that he said that they did it in WPF because they wanted to, and (as I've rightly guessed) they wanted to prove that this can be done outside of C++. And as I've also said in my previous post the only thing they proved is that it is impossible to beat C++ in this kind of tasks.

    You see, we don't need performance test results to see if one app performs slower than other. It is enough to run it and work for a while with it. I don't need anyone to show me that in tests VS2010 performes if not better then at least as good as VS2008. This are methods from communist Russia where every raport stated that things are improving from month to month.

    You are also saying:

    "I’m willing to participate in coding projects using alternative languages as long as the final result is fair enough and maintenance is affordable for the entire team "

    Would it be fair to say that this is typical dumming down practice? Instead of bring up professional level of staff you lower expected level of quality and what the results are saying? Surprise, surprise: Every one performed better or at least the same as year ago, so there is nothing wrong and our decision was right. Bit like from communist Russia, don't you think?

    I know my single voice won't change anything and I also know (suspect really) that this is an internal Microsoft's policy to promote MJ (as it was for over a decade now) and get as many users to write in managed code (and by doing this slowing whole worlds evolution) but I'm also sure that there are people like me who will never ever ever leave C++ for Java, MJ or any other managed environment.

    And please don't get me wrong, I'm not some fanatic who see C++ and only C++. I'm also willing to learn/try new languages (as I did with Java and MJ) but shortly after using them I was just totally dissatisfied with performance, constraints etc etc. I'm the first in line to learn something usefull but neither Java nor MJ deserve my attention.

    As Bjarne Stroustrup once said:

    "C++ is for a programmers whose capabilities are above average."

    And that summarises and explaines why some people are C++ devs and others aren't.

    Thank you.

  • @Diegum, Sorry for that, but this part of my post is missing from previous comment (it must have happened when I was pasting it from notepad):

    You are also saying:

    "I like the point you rise about faster coding vs. faster execution. I don't believe -this is my personal opinion based in my, both, MS and non-MS experience- that there's an absolute answer for that question."

    You may not believe mathematics but I don't think it's a wise choice.


  • As a daily user of your product, I really appreciate blog posts like this, thanks for sharing this info! :)

  • Thanks for replying, @Knowing. I understand that I failed in being more specific when endorsing Paul's thought. It was not to imitate the old USSR :-)

    I failed in clarifying that such conclusion came out after profiling here, in our labs, Visual C++ in particular and Visual Studio in general. I'm sorry I said it in a way that looked like I was saying that the community speaks without knowing about. In that sense, I must say that Paul agreed with you and the community in general that when comparing VS2008 and VS2010 the obvious change is the UI what is perceived as an indicator of the root cause. We all would have come to the same conclusion if we had no profiling studies. Yes, a managed UI is slower than a native one but what Paul meant in the bottom line is that several performance pains with VS10 today -studies endorsing here- are provoked outside the UI. The WPF team guarantees that their technology is permanently tuned up for the optimal performance.

    I've also failed (sorry about that!!) in being more specific that the part of the video that goes straight to the point is in the first 5-7 minutes. Sorry about that, honestly.

    About that (conspiracy?) theory that MS wants to promote Microsoft's Oracle's SmallTalk -I'm sorry but I was self-containing that joke for days now :-P I can tell you that most of our products, including VS below its UI, are built in native code (the list includes .NET and our C++ compiler). I'm getting old as a softie and can tell you that whatever I did in this company, I heard about secret plans to foster something in detriment of something else: .NET to disallow C++, C# to cloud VB future, SilverLight to eclipse HTML usage, HTML5 to eclipse SilverLight...) Now the last one I heard out there, you won't believe me, happened after we published the C++ Renaissance interview blogs.msdn.com/.../10126533.aspx : I was told by a guy that MS is reviving C++ to get rid of .NET.

  • Thank you very much for your reply.

    As I've said before, I'm not in any way a fanatic who wants to see every possible piece of software built in C++ - far from that, I just want things to be improved from release to release not deteriorate as is the case with VS2010.

    And as for: "The WPF team guarantees that their technology is permanently tuned up for the optimal performance." - the same kind of things for decades were saying (and still are but I think at this point no one try to fools any one any more) by guys from java team, and I'm affraid that this same will happen with the whole "managed" world. After every release there will be promises that next one will be much more "optimized" that those what we are experiencing are just temporary "bumps" and after next release everything will come back to the normal.

    But you know perfectly well, as I know that:

    And as long as there will be managed vs native, it if phisically impossible (yes, impossible because of the nature) to outperform native with managed, and apps written in native will perform much better than apps written in managed.

    Having said that, I wish you and all guys from VS team all the best, and I hope that things will get improved (especially now when new C++ std is approved, yey!!!!).

    All the best,



  • "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"

    No, the intellisense experience is NOT better in VS2010 as far as I'm concerned - at least as far as native C++ goes.  It actually worked ok in VS2008.  In VS2010, the editor doesn't not even display the text I'd typed for up to a minute and intellisense would often take longer.  Clicking on 'goto definition' was also usually a grave error and actually worse than accidentally pressing F1  in 2008, locking up the entire UI.   The memory used by each individual intellisense process is unbelievable.

    I have been following VS2010 to see if any of the major things that stop me from using it are fixed,  Any of the things on my list that other people have provided feedback on end up getting dismissive, carefree responses and being closed.

    Particular items like, for example, Batch Build, which is completely broken and is a feature I can't live without in a production environment - some of my projects have several release build configurations that need to be built.  Feedback on this item resulted in Microsoft coming back with "This is a rarely used feature so we aren't going to fix it".  Unbelievable - to many people this is a blocker.  

    When it comes to simple stuff like ctrl-dragging text in the editor to copy it, such issues are passed of as "theres another way of doing it, so we won't fix it.  Ticket closed.  No more feedback possible".

    What is the point of Microsoft asking for feedback?!  Do you just want people to stroke your beards an say what a fantasic job you've done or are you actually serious about creating a worthwhile product that serious developers can use?

    To be honest its not the problems themselves but the way in which they are handled that mean I've completely lost confidence in Visual Studio.  I can't use 2010 because the experience is so infuriatingly slow and clunky.

    Its sad because I was initially really excited about VS2010.  Its more disappointing than Windows Vista was - which to be fair was redeemed by windows7.  Can you do this with VS2010?

  • @pete I have very similiar (unpleasant) to yours experiencess with VS and Microsoft's Connect (that's why I'm more and more into alternatives like code::blocks for example).

    I think it is fair to say that:  "VS2010 IS A ONE BIG FAILURE."

    As for IntelliSense? Oh my God what a disaster... To one of my feedbacks concerned the way IntelliSense works they replied, (you won't believe it) something like this:

    "In order to make IntelliSense work as you suggested we would have to add new feature..."

    And I'm saying: Duhhh... In order to make IntelliSense work as it should it needs to be DRAMATICALLY REDESIGN if it is supposed to cope with C++ syntax and semantics. It's not a MJ (Microsoft's Java) nor Java you know. This is a serious language and much more work needs to be put into it.

    As for feedback from Microsoft? God almighty, couldn't agree more with you. This particular thread contains response to my feedback that I'm finding insulting, arogant and ignorant to the boot (fourth comment counting from the bottom):


    But this isn't separated example of how guys from VS threat their costumers. If you would care to take time and browse my feedback (although I don't blame you if you won't - the way Connect works is appaling in it's own way) for them you would find good few more of similiar (dismissive, rude and arrogant) approach.

    But I tell you something pete, let them plow in their "improved, optimized" managed world and they will undoubtedly share Java's world of "increased number of users" etc etc.

    Good luck to you pete and I hope you will find right IDE for your needs.

  • @pete and as for speed of VS2010 which I like to call Very Slow 2010? IIIIIIIIIIIIIIIII dooooooooooonnnnnnnnt eeeeeeevvvveeeeeennnnnnnn waaaaaaaannnnnnnaaaa staaaaaaart oooooooooooonnnnnn iiiiiiiiiiiiiiiiiiiiiiiiiiitttttttttttttttttttttttttttttt. Noooooooowwww IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII'mmmmmmmmmmmmmmmm gooooooooooooooooiiiiiiiiiiiiiiiiiinnnnnnnnnnnnng baaaaaaaaaaaaaaaaaaaack toooooooooooooooooo Cccccccccccccccccc++++++++++++++++++++ and I talk like this again.

  • C++/CLI IntelliSense is very important!!!

    But C++ for Windows Phone 7 and later is much more important!!!

    Does Visual C++ support Windows 8 for ARM?

  • Someone kicked off my crutch.

    Please bring back intellisense as soon as possible.



Page 3 of 4 (48 items) 1234