I recently upgraded from 2013 Pro to 2017 Community and I've been putting the IDE through its paces. After a couple of weeks, here are the top things that still confuse me. I'm wondering if there might be something I'm missing.

• like everyone else, I don't understand the sudden need for the green squigglies. I've seen MS suggest adding problematic macro declarations to hint.cpp over and over again, but that 1) didn't use to be necessary, 2) is a blatant hack and 3) doesn't work
• occasionally, when writing a new variable declaration or a function definition, I get a sporadic "Object reference not set" error in the form of a modal popup. Usually this happens when I type in a type, a variable name and then press tab (which I do often due to the way I format my code). The error persists until I press OK/Cancel (eg Enter or Escape), then briefly multitask out of the IDE and back again. I used to get this error in 2013, but only occasionally when code peek failed to display something. I can't really find information on the particular flavor of the error on the web
• despite being eligible for the free Community edition, I bought myself into the new ecosystem by renewing Visual Assist X. Initially this caused massive slowdown issues in the editor, to the point where the screen would be redrawn 2-3 times per second while scrolling quickly. I alleviated this by disabling VAX's own intellisense (which is apparently really slow and feels incomplete) and disabling most extensions I was using in 2013. I'm mentioning this, because it leads me to my next issue:
• auto-complete (eg the built-in parser) flat out fails in many cases. One most notable case happens when listing enum members, which simply does not work. Now, I don't use vanilla enum syntax, but rather have my own self-unrolling macros that recursively expand enum declarations using FOR_EACH. This, however, was not an issue in 2013
• what baffles me even more, is the fact that auto-complete no longer suggests function names and/or signatures when overloading a function in a derived class. It simply doesn't suggest anything
• build times seem comparable to 2013, but link times can be uneven and abysmal, even when changes are small and incremental

Given that the IDE has been out for a while and my whole system is as up to date as it gets, I'm left to wonder if at least some of these issues can be mitigated in some way. Considering that it took me 10+ hours just to find the right config to get the IDE to be responsive without sacrificing too many things I'm accustomed to, it's entirely possible I've missed a checkbox or somehow managed to mal-configure either the VS or VAX.

Are you having a similar user experience? Any ideas or suggestions?

Good to know I haven't screwed up my settings or something. On the flipside, too bad they've apparently opted to implementing a completely new intellisense and broken so many basic things while doing so. Here's a few further observations:

- occasionally, the IDE starts chewing up CPU like crazy, getting to 30-40% on my 4/4 core. Restarting fixes this.

- the enum auto-complete issue seems to come and go. It did work for an hour and then stopped working again. 

- rebuilding the database seems to help occasionally. It's a pain, though.

Ironically, just as I started to respond to this thread, I got a UX questionnaire when starting up VS in the background. It was surprisingly thorough, but then hard froze the IDE just as I was about to click "Done".

As for navigation (and this is not an endorsement) - I've found VAX to be well worth the money they're asking. One of the best things it has is a Ctrl+click to navigate to feature - so if you click on a function name, it lists all declarations and definitions and you can go to which ever you need. AFAIR it does need to be manually enabled though. I wish they made their custom intellisense about 2-3x faster and added a bunch of features the built-in one actually does have. Right now it just feels awkward and unnatural.

As for other IDE's - ironically MS's own free Visual Studio Code is actually a fair bit faster, although it does lack many of the features I've grown accustomed to. It's fairly good for GLSL and stuff, though.

The ironic and also kind of funny thing here is a blog post by MS a few years ago, explaining why certain C++ features were not implemented (I believe it had to do with something in the standard library). I can't find the topic right off the bat but, as customary, the reasoning was there and it did make sense if you looked at it from a certain angle. The post was inundated with backlash and negative responses along the lines of "gcc has had these for years now" and "it's a paid product", which were valid criticism. From a certain angle. The compiler team (or at least someone from there) were pretty actively trying to respond and calm people down, but you can guess how well that went. I mean, MS's STL didn't even implement emplace_back() properly back then (I'm kinda assuming it does now).

I remember reading this and trying to put myself in both shoes. I was biased, of course, because the lack of conformation to the standard was becoming increasingly frustrating and I think I was doing research to make sure it was worthwhile upgrading to 2015 (which I finally decided it wasn't). In any case, the entire "discussion" suddenly took on a completely new look, when it dawned on people that something like one single person was responsible for implementing the STL back end and he flat out couldn't figure out how to make things work.

Which is when I formed a completely new view of the VS dev team:

- C++ is secondary, if not tertiary or quaternary one their list of priorities

- the C++ compiler and likely tools development teams appear to be under-staffed and/or focused on more than one thing. I don't want to bring the word "incompetence" to the table, but some of the bugs and hacks (I'm looking at you, hint files and blatantly wrong underlining), which the team routinely dances around without flat out ignoring on the blog/forums, suggest there is some degree of, shall we say, uncoordination at play here

- as far as I'm concerned, a run of the mill text editor should consume around 1-3% CPU when implemented correctly. That's what Chrome is consuming as I type this (and it does dictionary lookups as I type). The fact that VS jumps to 20-40% while I'm typing a damn string, is a disgrace and a testament to the absolute irrelevance of hardware. I'm on a laptop and typing in the IDE drains my battery 3x faster than watching a HD video on Youtube. Let that sink in for a moment. Software was an order of magnitude faster 15 years ago - you still needed to redraw a similar number of pixels every time a key was pressed, but the computer simply didn't have the oomph it has today, so things needed to be handled differently. By writing optimized software. Just recall what it was like to write a Word/Excel document in 2003 and what a pile of broken and unoptimized bloatware 360 has turned into.