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.

https://connect.microsoft.com/VisualStudio/feedback/details/1612970/c-unity-build-intellisense-bug

https://connect.microsoft.com/VisualStudio/feedback/details/1579948/red-wiggly-lines-for-include-files-comes-up-incorrectly

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.
https://stackoverflow.com/questions/19547091/including-cpp-files

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.

Just:

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.

2 Likes

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:

8 Likes

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

(I did not yet test)

Awesome!

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.

3 Likes