VS2017 Intellisense

This is also a really big issue at our company. JUCE does not work well with Visual Studio Intellisense.

Possibly it could help to put more pressure on Microsoft. I could only find the following issues reported, and there seems to be little interest around them from community.



As far as I know.

  • Microsoft are hardly responsive. I think I raised it with them via some channel and got zero response. There was an issue with resharper but we leaned on them a tiny tiny bit and they fixed it.
  • Jules uses Xcode which is why he’s never been crying about this intellisense problem?
  • My Xcode can’t even display the right line number for an error message in some projects. So it’s basically gone in the bin.
  • Resharper isn’t only available as a subscription, you just need to subscribe to keep getting new upgrades. They say at the bottom of the page “Includes perpetual fallback license right away.”
  • You need to disable intellisense to stop the red underlines once you’ve installed Resharper. Presumably the same applies to Visual Assist.
  • @jules about a quarter of OUR code is in modules so I’m not sure that “Intellisense should work fine for your own code” is actually true. It basically works fine unless you try using a module! :slight_smile:

It was include files inside namespaces that broke resharper. Maybe that’s the problem that breaks intellisense too and if JUCE moved the namesspace {} into each individual include file it’d be fixed. It’s a stab in the dark…

1 Like

The simple fact is that JUCE doesn’t follow C++ core guidelines: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-source
After a while, you can get everything. The IDEs usually follow them because people developing them are in the C++ committee and discuss with people writing these guidelines. They have a purpose. If you don’t follow them, then there are some things in the IDE that may not work as expected.

Doesn’t JUCE, and the IDE problem, rather pre-date the guidelines…?

Some of them yes, but the IDE problem is the fruit of practices that are now core guidelines and was already good practice decades ago (cpp files always including what they required).
For Intellisense, the main issue is that the team responsible for it doesn’t use the compiler itself. It’s even worse if you think that there can be several compiler backends, so there will always be discrepancies between how the compiler behaves and what the IDE can infer. I can agree with Jules about the fact that for a project, the IDE might be able to figure out the headers to add, but only might. This doesn’t cover NMakefiles for instance.
So including the relevant headers has, is and always be the best practice, no matter how smart we want IDEs to be.

Is it worth raising this scenario with MS so they can address it?

You can try, the odds of them adding this feature (for code not following the core guidelines that they are starting to support) is 0%.
Microsoft was bad at proper C++ a decade ago, with using undefined behavior for their own benefits. But since then, they are getting far closer to the C++ standard, and this is also true for the guidelines they follow.
Similar to the Open Source revolution in their projects as well.

My experience of Visual Assist did not solve the underlining, as someone else has chimed in here. @reFX sounds like you have had a better experience! Is there some magic button I am missing to persuade Visual Assist to replace Intellisense? Or are we foregoing it, in turn for the Go button and class to header navigation?

Regarding .cpp inclusion, (which issue I think we should dub “inclusals” [sic. occlusals] for all the pain they are causing, and for want of a better nomenclature :wink: ) , in an ideal world I’d prefer adopt the accepted convention, as surely the whole point is cross platform compatibility, and that is bound to mean cross-compiler compatibilty sooner or later. Prejudicing VS2017 seems like a really bad idea to me. If there is a workaround, great, but as I mentioned earlier, my world is Windows dominant, so if not I may find an alternative. Haven’t ruled out DIY at this point.

Also, I found this on the nation’s favourite dev site.

For what it is worth, I hope we do find a simple workaround. Isn’t that what forks in repos are all about?

Well, this is a bad example, as JUCE doesn’t include files that are also compiled on their own.
JUCE modules are consistent, it’s just that they are not consistent with the norm, hence the issues in any IDE. But they are not alone there, lots of software package don’t follow the “include what you need” guideline. And they will all have issues with static analyzers in IDEs.

Just in case anyone in interested … here’s a view inside a JUCE module with intellisense disabled and resharper working.

Can’t you introduce a #define MIDI_CHANNEL_STARTS_WITH_0 to let people choose? Apparently, I’m not the only one that would appreciate that…

Hi, guys, if you’re using Visual Assist in MS Visual Studio, this issue can be solved very easily.


But, the adverse side is: the red underlines will never appeared no matter you input the correct member name or not.

I think the problem is the ambiguity between juce::Component, which is the result if you parse juce_gui_basics.h, and Component, which doesn’t really exist, but which results from parsing juce_component.h, which appears to happen as soon as you open that header in the text editor. One can only speculate, but maybe Intellisense assumes it can parse that header by itself (which in almost all other software projects would be a valid assumption).

The nuclear option is to type juce::Component everywhere.

The way to fix this in Juce would be to repeat the namespace juce { … } scope in every header file, instead of once in juce_gui_basics.h. Incidentally, this is how every other C++ library out there is doing it.


This would appear to be an easy fix :slight_smile: Did you try it…

No I haven’t had a chance to actually try it. It would be a major job (you have to go through the entire Juce library) and the issue isn’t affecting me too badly.

May be of interest to the people on this thread :slight_smile:


Excellent news, this probably increases productivity for a lot of people.

(I did not yet test)


You have no idea how much this helps. Thank you. It will have cost your team a few man days but has helped thousands of developers so the time savings are HUGE.