Is there a support for C ++ 17 in VisualGDB?

[centimo]

I tried to install VisualGDB and to use it for my project. Everything is excellent, but at least some features of C++17 are not supported by IntelliSense. For example, it is possible to work with std::optional therefore that it undertakes from the libraries loaded from Linux-machine, but “init statement for if” is underlined as an error.
At the same time I cannot set (or I do not know how) a flag “/std:c ++ latest” as would make it for msvc. It is not convenient to use CLang.

[support]

Hi,

Thanks for your feedback. We are planning to upgrade our IntelliSense engine to the latest Clang version as a part of the v5.4 release cycle (expect this to be available in the next 1-2 months). Feel free to follow us on twitter to get notified once the build with the new Clang is ready.

[centimo]

Hello. Thanks for the answer.

Possibly, there was some misunderstanding. I do not want to use Clang-based IntelliSense because it too slow (on big project). Native Visual Studio IntelliSense is interesting to me.

[support]

Hi,

Sorry, the native Visual Studio IntelliSense is outside our control. Please contact Microsoft regarding their plans for C++17 support/gcc compatibility.

That said, the recent versions of the Clang IntelliSense engine contain optimizations that improve the performance for huge projects (e.g. the IntelliSense-only PCH files), so you should be able to get reasonable performance out of it. Feel free to let us know if any specific scenarios are slow and we will help you set it up.

[centimo]

Eventually I found the solution: it was necessary to set a flag “/std:c ++ latest” in project properties -> NMake -> IntelliSense -> Additional options.

[support]

 

Hi,

Yes, that might work, although due to differences between the VC++ and the gcc compiler, some features might still not be supported properly.

[Ophidian14]

I see the Intellisense setting on the project properties page.  But how exactly do I use it?  I tried pointing it to a .h file containing some #includes but it didn’t seem to make any difference.  Can you give an example of how to set it up and then how to understand if it’s working/having an effect?

Attachments:

You must be logged in to view attached files.

[support]

 

Hi,

Normally just pointing it to a header file with multiple #include-s should do the trick. You can double-check if it’s being included by defining a macro inside the file (e.g. #define TEST_PCH) and then checking for it in your code:

#ifdef TEST_PCH
#error test
#endif

The IntelliSense should then highlight the “test “error (it won’t affect compilation). If the macro gets propagated properly, but the IntelliSense is still slow, please let us know what exact operation is slow, attach a quote from the Clang IntelliSense Diagnostics console and a screenshot of the timing report (timer icon at the top right corner of the navigation bar) and we can help you optimize your IntelliSense experience.

[Ophidian14]

Thanks for following up.  I confirmed the PCH is working with the #error test.  Here’s the improvement I saw (this is after clearing out everything in .vs, CodeDB, VisualGDBCache, etc.):

[+0:23:49.120] Operation completed: Reparsing \\10.10.161.129\build\cfa\xxx\yyy\[....].cpp [14451 msec]
versus
[+0:25:28.180] Operation completed: Reparsing \\10.10.161.129\build\cfa\xxx\yyy\[....].cpp [11712 msec]

My machine is i7-7700HQ, 2.80GHz, 16GB RAM.

How do these times stack up?  Is this inline with the team’s expectations?

[support]

Hi,

Thanks, this makes sense. Most likely the delay comes from accessing the source code over network. Any remotely located include files that are not a part of the precompiled header would add considerable delays to the parsing due to network latencies. Please try storing the files on the Windows machine and see if this improves performance.

Another way to diagnose this would be commenting out different parts of the main .cpp file and checking how this affects reparse time (e.g. first comment out everything except the #include<> directives at the top, then comment out the lower half of the source file, etc). Please note that each time you modify the preamble (#include<> statements at the beginning of the file), VisualGDB will rebuilt it, showing a greater increase in the reparse time. The next reparse will be much faster.

[Ophidian14]

I captured a .gif of the Intellisense process (attached to this post).  I’m starting from a blank environment with clean CodeDB etc. folders.  In the .gif, you can see CppEngineHost64.exe in Task Manager as I double click on my source file in Solution Explorer.  It opens, and then CppEngineHost64.exe immediately goes to 100% of one core (12.5%, so 12-13% in task manager…. eight logical core CPU).  This continues for the ~11 seconds from my prior post (this is -with- the PCH feature), and then you can see that VS “reacts” and the syntax coloring, etc. is applied as it finishes.  My point being, I don’t see any evidence here that it’s I/O bound.  There are actually very few solution files in the #includes that are being loaded over the network.  Any idea how I can diagnose further?

Attachments:

You must be logged in to view attached files.

[support]

Hi,

OK, thanks for clarifying this. This indeed looks like the parsing itself is taking a lot of time. If you are opening the project for the first time, this is to be expected – VisualGDB will build various caches and the subsequent operations should take much less time. If anything else is slow beyond the initial delay, please let us know and we can help you pinpoint it.

[Ophidian14]

Say I wait until the parsing is complete, and then I type one extra character which causes a syntax error (i.e. referring to a variable as “var2”, which doesn’t exist, instead of “var”).  I don’t click Save or anything, just type the “2”.  That line of code isn’t parsed immediately.  I get this in the diagnostic output:

[+0:17:41.039] Starting operation: Parse - HighlightBraces
[+0:17:41.039] Operation completed: Parse - HighlightBraces [0 msec]
[+0:17:41.722] Starting operation: Parse - Check
[+0:17:41.722] Starting operation: Reparsing xxxx.cpp
[+0:17:41.871] Post-PSF state of is outdated. The file will be reparsed
[+0:17:41.885] xxxx.cpp has changed since last build. Doing full analysis..
[+0:17:42.035] No changed PSFs found, but xxxx.cpp is outdated due to itself. Doing a quick PSF-based rebuild with 2 PSFs
[+0:17:42.035] Starting fpsParsingFileBody on xxxx.cpp
[+0:17:43.476] Starting fpsAnalyzingReferences on xxxx.cpp
[+0:17:47.969] Completed fpsAnalyzingReferences on xxxx.cpp
[+0:17:48.090] Completed fpsParsingFileBody on xxxx.cpp
[+0:17:48.090] Starting operation: Exporting parse results
[+0:17:48.090] Checking xxxx.cpp for missing headers..
[+0:17:48.090] No missing headers for xxxx.cpp
[+0:17:48.333] Operation completed: Exporting parse results [242 msec]
[+0:17:48.333] Checked xxxx.cpp: 3 error records
[+0:17:48.433] Operation completed: Reparsing xxxx.cpp [6710 msec]
[+0:17:48.437] Operation completed: Parse - Check [6714 msec]

The munged line is then highlighted as having an error.  Is this consistent with what you’d expect?

 

 

[support]

Hi,

Thanks, this looks like a known issue. Please try clicking on the timer icon in the upper right corner of the document and click “enable lightweight references” (or enable it via VisualGDB Project Properties -> IntelliSense). This should significantly reduce the parse time.

 

[Ophidian14]

Excellent.  This brought the reparse time in this scenario down to ~1000ms, which is a huge improvement.

[Author]

Posts