I have a non usual Vim configuration to develop in C++. It’s mostly made of plugins I’ve been maintaining for more than a decade.

There are several aspects to it:

• Project management
  I’ve been using (and maintaining) one of the local_vimrc plugins to define projects. Unlike other tools, I don’t explicitly register files belonging to a project. Instead, any file under a directory is considered to belong to the project. From there, it’ll inherit certain properties: How should it be compiled, the coding style (from indenting policy to naming policy), or other plugin options specialized for this project. From the early version until now, I’ve been trying to simplify the task as much as possible. I’ve recently added ways to auto-detect project root for simple tasks (code indexation and code compilation).
  Note that this is independent of Make/CMake/… project management. I still have to maintain these files, and I don’t use them to automatically deduce which file belong to which project — however I use `CMakeCache.txt` (the one generated with `cmake {dir}`) to deduce things like the current C++ flavour (from C++98 to C++1z), information that I use to adapt my snippets (how to make a class non copiable?, `std::size(array)` VS `std::extent<decltype(array)>::value`?, etc).
• C++ Code editing
  That’s where all the helper tools are. There is snippet insertion (from the simplest control-statement to the more elaborated non-trivially copyable class), function doxygenation (which tries to recognize whether parameters are going in or out, whether there be may trivial preconditions…), jump-to-or-generate-function-definition, override virtual functions, etc.
  This is mostly done in lh-cpp which also offers an undocumented API to extract information from C++ code.
• Style
  Vim can already be configured regarding how code is formatted. editorconfig-vim plugin is able to interpret editor independent settings to tune vim native settings.
  There is a plugin that runs clang-format on demand — and I’m trying to use its setting to directly adapt the snippets I produce with my plugins.
• C++ code completion
  Here I either rely on the tag database I generate for my C++ code, or the astonishing YouCompleteMe.
  I suspect we need to watch plugins that use Language Server Protocol to communicate with clangd (LLVM/clang V5+) on this topic.
• C++ indexation
  Historically we have been using either cscope (which is a bad C++ code indexer), or exhuberant ctags which isn’t that good either. As ex-ctags maintenance has stalled, check instead universal-tags. It has greatly improved C++ code indexation over ex-tags.
  How do I maintain my tags database? Some use gutentag. I’ve been maintaining lh-tags which offers the same services and a couple more (like adding tags to the spell ignore list). lh-tags also permits to list the tags matching a pattern in a scratch window (we could also use `:ltags` + vim-qf to do the same). This `:pselect` on steroids feature comes from the need to jump to the right overload. Alas at this time we cannot do more than that (i.e. recognize automatically the right overload). We need a smarter tool.
  We need clang to assist us. There are a few plugins. I’ve been trying to maintain clang_indexer for some time. Other tools and plugins have emerged since then like clang-tags for instance and a few more.
  BTW, tagbar seems interesting to present the symbols in the current project.
  I suspect we need to watch plugins that use Language Server Protocol to communicate with clangd (LLVM/clang V5+), or other back-ends like cquery, on this topic.
• C++ code compilation
  While many compile in the console, or use vim-dispatch, again I’ve been maintaining my own solution for a long time: Build-Tools-Wrapper. As other plugins, it permits to compile multi-files projects and mono-file projects relying on gnu-make. It has two unique features: we can register compilation modes (compilation directories actually) and switch from one to the other ; and we can pipe filters (compiler plugins on steroids).
  NB: Since Vim8, it has a better support for background compilation.
  Note that I’ve an related, and autonomous, plugin that displays signs and balloons from compilation results available in the quickfix-window: compil-hints.
• Linting
  syntastic is the tool many use. I must admit that I don’t. I’d rather compile explicitly rather than fighting on how to feed the compilation options associated to the current mode (release, address-sanitization, release with debug info…) I’m compiling for (/in?).
• Code refactoring
  In vim-refactor I provide simplistic extract variable and extract type refactorings. I also provide setters and getters const-correct generation. And a buggy extract function — So far I extract information from a (c)tags database, and the result is still far from perfection. I’m waiting for a clang-based tool to which I could feed my coding style, how I wish to receive or return parameters (out parameters by reference, or struct/tuple/… returned by value, etc).
  I suspect we need to watch plugins that use Language Server Protocol to communicate with clangd (LLVM/clang V5+) on this topic.
• Debugging
  There are a few plugins. I remember mostly pyclewn (that’s meant to replace the previous *clewn plugins), a gdb wrapper. There is also vim-lldb that wraps lldb. I never use them as I can never remember how they work. I use gdb in the console instead.
  Edit (Sept 2017): Recently Vim (v 8.0.xxx) has been enhanced to embed terminals natively without any plugin assistance. Bram has started a new package (termdebug) that integrates gdb 7.12+ at the moment.
• SCM
  It’s not C++ strictly speaking. However, I highly recommend fugitive, gitv and splice when working with git.
• Folding
  I don’t really like how the `syntax` and `indent` folding methods display C and C++ code. Again, I’ve cooked my own plugin on the subject: VimFold4C.
  There is a big catch, in order to have a good response time, it caches some computations internally, and unfortunately, they have a tendency to go out of sync.
• Other resources.
  I certainly have forgotten many things (that I use, or that other use). See for instance this entry on vim.wikia.

Edits made in Sept 2017: add notes about LSP+clangd, termdebug, and style. In May 2018: add a note about folding. In July 2018: add note about compil-hints