VisualGdb vs VS2017

Sysprogs forums Forums VisualGDB VisualGdb vs VS2017

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #20553
    twdi
    Participant

    Visual studio 2017 can directly develop remotely on Linux with C++

    VisualGDB can offer the same as plugin for VS2017.

    Which advantage would it be to start using VisualGDB?

    #20556
    support
    Keymaster

    Hi,

    VisualGDB offers a much more streamlined experience than the regular VS2017 Linux integration. First of all, it uses a highly optimized build backend that works much faster for large projects with complex structure, and is generally more reliable.

    Second of all, VisualGDB provides known workarounds for common issues on the underlying Linux tools. Inaccurate path mappings, missing LD_LIBRARY_PATH entries, mismatching interactive/non-interactive environments and many other scenarios. VisualGDB can automatically discover and fix many issues that would normally take hours to diagnose.

    Our debug engine is also designed to recover from known gdb bugs and provides deep diagnostic tools (e.g. a tool for analyzing timings of specific underlying commands that help reduce latency on slow connections).

    On top of that VisualGDB offers a Clang-based IntelliSense engine that is specifically designed to handle Linux-specific code and provides many C#-like features: detailed code map, create-from-use, etc.

    VisualGDB also includes very deep integration with Make, CMake and Qmake that let you use convenient GUI to quickly edit various project settings without the need to understand the specifics of the project file formats. Our Advanced CMake project subsystem brings this even further – it lets you use the regular Solution Explorer GUI to view and edit CMake targets, automatically editing CMakeLists.txt files in response.

    Beyond the regular editing and debugging functionality, VisualGDB includes advanced valgrind-based profiler optimized for huge projects, support for running unit tests on Linux machines (with code coverage), static and dynamic code analysis tools and a convenient set of custom actions that lets you easily transfer files between machines as a part of build or while preparing for debugging.

    There are also numerous customization options (like using a custom command for sending the ‘break in’ signal to your app if your Linux distro is configured to ignore the regular SIGINT mechanism) that come in handy when dealing with highly customized target environments and features like Team Settings that help you share common settings to other team members instead of painstakingly setting them up on each machine manually.

    You can get a quick overview of the Linux-related highlights here or browse through our Linux tutorials here.

    Hope this explains. If you have any further questions, feel free to share them and we will be happy to answer them.

    #20593
    twdi
    Participant

    Ok sounds nice. I will give it a try for the trial periode.

    My major doubt is how to deal with specific Linux libraries like librt for shared memory etc when developing in VS2017. I don’t have time to spend a lot of time to get that to work due to deadlines for my study.

    🙂

     

     

    #20601
    support
    Keymaster

    Hi,

    No problem. If you are planning to debug some Linux-specific issues that involve custom gdb commands, you can use the GDB Session window in VisualGDB – it will let you run custom gdb commands as if you were using the regular command-line debugging experience and will automatically translate common commands (e.g. for setting breakpoints) to corresponding VisualGDB actions, so you can easily follow Linux-specific tutorials for those libraries with the full convenience of Visual Studio.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.