My first advice for anyone who wants to use Vim for C++ development would be - don't. I've used exclusively Vim for over 10 years and it's too comfortable to switch to anything else, so I'm losing out on a lot of productivity, or at least that's what my colleagues, who have never used Vim, claim.
Pithy claims aside, it has been an interesting journey actually using Vim for producing C++ code for large projects. There's a strong DIY element and you end up with a setup that's much more customised than a vanilla IDE - on the one hand giving you a certain degree of comfort in your work, but on the other a lot of what you do is unportable to other people. The language server protocol has been a pretty good development, I'm keeping an eye on what comes out of those efforts, though I'm not using one personally right now.
My current setup consists mainly of exuberant-ctags for static indexing, YouCompleteMe for intellisense and simple navigation, rtags for rich search and light refactoring and fzf for searching. As to why I ended up settling on these plugins:
- ctags:
Absolutely essential. Yes, a full semantic index straight from the compiler is better, but ctags is more than good enough for just telling you "where is this defined". When paired with fzf, you can type part of the tag, space, part of the directory and you'll get all tags in that directory. That's due to fzf doing super simple substring matching in the TAGS file's lines based on your query, there's nothing smart going on here. This tool is also very good when you are developing multiplatform software, because the compiler cannot see all places where a function or class is defined, since you have one definition per platform. Technically being able to query a plethora of language servers, one for each configuration, would be ideal, but we're not there yet, and such a setup sounds way too fragile for my taste.
- YouCompleteMe:
Aside from C++, it provides amazing completion support for many other languages. It can even deal with java project files, if the readme is to be believed. Other than for C++, I mainly use it for python. It's also good in plaintext files for completing words and file paths. I really love its substring matcher, just type gTFBT to get "getTheFooBarThing". Downsides: 1. if your build system cannot produce a compile_commands.json file, you will need to write some python code to specify compilation flags; 2. compiles each file individually, so if some of your headers aren't freestanding, you'll get spurious errors when editing them.
- rtags:
Basically a language server from before the LSP protocol existed. Mainly developed for Emacs, but the Vim integration is good enough. Continuously indexes your source based on a compile_commands.json file. It can show you who calls a function or uses a variable, class hierarchies, virtual method overloads and more. I've seen it get confused if you jump branches and require you to delete and recreate the index, but I haven't experienced that lately.
Apart from those I use a bunch of standard productivity plugins like unimpaired, surround, nerdtree, etc. etc. Vim 8's gdb integration has been very welcome, too. I struggled to find a good interface to gdb previously, as everything seems to want to be Visual Studio and give you a restricted clicky interface, whereas I just wanted the current vim buffer to be synchronised with the instruction pointer and to write gdb commands directly.
I don't feel like I'm substantially slower in Vim than my colleagues in other editors and IDEs. Colleagues across the company use Vim, Emacs, VSCode, QtCreator, and Code::Blocks. The Windows developers are all on Visual Studio naturally. I haven't noticed being slower than any of them. The above plugins are enough for the odd rename-refactor I have to do, and anything more substantial is so infrequent, that doing it manually doesn't really have an impact. Also, developing on Linux, I always feel like any graphical application will just disintegrate or cause an unrecoverable freeze in the graphics driver at any random keystroke.
Back in the day I had to make do with just ctags, cscope and debugging straight from the commandline, lol. I do believe that Stallman's refusal to allow easily plugging into GCC's AST, like one can just use clang for indexing, held back C++ development tools on the Linux platform significantly. Eclipse's CDT, KDevelop, Anjuta, Code::Blocks, NetBeans, etc. - they all suffered from having to write their own C++ indexers that were always inferior to getting semantic information straight from the compiler. I'm extremely grateful to the open-source community for the continuing work on development tools, and try to donate where I can. Watching the development tools landscape change over the years has been interesting - things don't so much improve, as they evolve chaotically with an overall trend towards improvement. Like anything else on this platform. So far many IDEs have come and gone, but Vim is eternal.
I will say that using Vim is entirely up to your taste, it doesn't seem to be substantially faster or slower than an IDE, so use what you like. It is much cheaper than Qt Creator or CLion (AFAIK for both you need a license to develop commercial software), so that might be a factor for you. Companies tend to have a big Windows development team, with a few Linux developers, so they buy bulk Visual Studio licenses and individual Linux IDE licenses, making the latter end up costing more per developer.
Ah, I see. I last looked into using Qt Creator around 2015 and it seems this license change is from 2016. The company I worked for at that time said from their reading of the license we need a commercial license and asked if I could please pick something else. If I had just checked it out a year later, hah.
I use vim8 plus an assortment of plugins and it works quite well. I use rtags, vim-rtags, vim-clang, vim-fugitive, vim-polygot, vim-cpp-modern on a large project. I'm also looking into vim-lsp instead of rtags+vim-rtags now. If you are a vim enthusiast then it can work, but it can take some time to
go through a few different IDE-like methods and also to setup/config/map things. Onivim2 is also something to look at.
Pithy claims aside, it has been an interesting journey actually using Vim for producing C++ code for large projects. There's a strong DIY element and you end up with a setup that's much more customised than a vanilla IDE - on the one hand giving you a certain degree of comfort in your work, but on the other a lot of what you do is unportable to other people. The language server protocol has been a pretty good development, I'm keeping an eye on what comes out of those efforts, though I'm not using one personally right now.
My current setup consists mainly of exuberant-ctags for static indexing, YouCompleteMe for intellisense and simple navigation, rtags for rich search and light refactoring and fzf for searching. As to why I ended up settling on these plugins:
- ctags:
Absolutely essential. Yes, a full semantic index straight from the compiler is better, but ctags is more than good enough for just telling you "where is this defined". When paired with fzf, you can type part of the tag, space, part of the directory and you'll get all tags in that directory. That's due to fzf doing super simple substring matching in the TAGS file's lines based on your query, there's nothing smart going on here. This tool is also very good when you are developing multiplatform software, because the compiler cannot see all places where a function or class is defined, since you have one definition per platform. Technically being able to query a plethora of language servers, one for each configuration, would be ideal, but we're not there yet, and such a setup sounds way too fragile for my taste.
- YouCompleteMe:
Aside from C++, it provides amazing completion support for many other languages. It can even deal with java project files, if the readme is to be believed. Other than for C++, I mainly use it for python. It's also good in plaintext files for completing words and file paths. I really love its substring matcher, just type gTFBT to get "getTheFooBarThing". Downsides: 1. if your build system cannot produce a compile_commands.json file, you will need to write some python code to specify compilation flags; 2. compiles each file individually, so if some of your headers aren't freestanding, you'll get spurious errors when editing them.
- rtags:
Basically a language server from before the LSP protocol existed. Mainly developed for Emacs, but the Vim integration is good enough. Continuously indexes your source based on a compile_commands.json file. It can show you who calls a function or uses a variable, class hierarchies, virtual method overloads and more. I've seen it get confused if you jump branches and require you to delete and recreate the index, but I haven't experienced that lately.
Apart from those I use a bunch of standard productivity plugins like unimpaired, surround, nerdtree, etc. etc. Vim 8's gdb integration has been very welcome, too. I struggled to find a good interface to gdb previously, as everything seems to want to be Visual Studio and give you a restricted clicky interface, whereas I just wanted the current vim buffer to be synchronised with the instruction pointer and to write gdb commands directly.
I don't feel like I'm substantially slower in Vim than my colleagues in other editors and IDEs. Colleagues across the company use Vim, Emacs, VSCode, QtCreator, and Code::Blocks. The Windows developers are all on Visual Studio naturally. I haven't noticed being slower than any of them. The above plugins are enough for the odd rename-refactor I have to do, and anything more substantial is so infrequent, that doing it manually doesn't really have an impact. Also, developing on Linux, I always feel like any graphical application will just disintegrate or cause an unrecoverable freeze in the graphics driver at any random keystroke.
Back in the day I had to make do with just ctags, cscope and debugging straight from the commandline, lol. I do believe that Stallman's refusal to allow easily plugging into GCC's AST, like one can just use clang for indexing, held back C++ development tools on the Linux platform significantly. Eclipse's CDT, KDevelop, Anjuta, Code::Blocks, NetBeans, etc. - they all suffered from having to write their own C++ indexers that were always inferior to getting semantic information straight from the compiler. I'm extremely grateful to the open-source community for the continuing work on development tools, and try to donate where I can. Watching the development tools landscape change over the years has been interesting - things don't so much improve, as they evolve chaotically with an overall trend towards improvement. Like anything else on this platform. So far many IDEs have come and gone, but Vim is eternal.
I will say that using Vim is entirely up to your taste, it doesn't seem to be substantially faster or slower than an IDE, so use what you like. It is much cheaper than Qt Creator or CLion (AFAIK for both you need a license to develop commercial software), so that might be a factor for you. Companies tend to have a big Windows development team, with a few Linux developers, so they buy bulk Visual Studio licenses and individual Linux IDE licenses, making the latter end up costing more per developer.