1. 13

I’m curious about the “soft” side of development tools. What editors, debuggers, IDEs, testing tools and the like do you use?

  1. 11

    vim, perf, gdb, objdump

    1. 7

      I have a hard time breaking my dependency on gvim and rg. I usually use gdb or lldb. I have used atom occasionally, which was a fairly nice experience. But I don’t use it often for C/C++. I’ve heard good things about CLion, but I have only kicked the tires on it.

      Test tools – sanitizers are indispensable: UBSan, ASan, MSan and to some extent TSan. I use lit a lot (w/llvm) and occasionally CPPUnit or Google Test.

      1. 5
        • Build system: Meson
        • Editor: neovim with ncm2 + LanguageClient-neovim
        • LSP server: clangd (yeah yeah I should try cquery or its fork ccls I guess)
        • Debugging: lldb, Sanitizers, DTrace, truss/strace
        • Profiling: DTrace with flame graphs
        • Static analysis: clang-tidy (includes clang static analyzer), cppcheck
        • Formatting: clang-format
        1. 3

          And this is the kind of pure Lobste.rs gold I asked this question for. Thank you! I’m a big Neovim fan and use the LSP stuff for Python with Deoplete quite a lot. I love it. Kind of fun watching coworkers jaws drop when I get full IDE-like tab completion in Python without Pycharm :)

          1. 3

            Oh, nice, LanguageClient-neovim works even with VIM and cquery/ccls are way better than clangd. I didn’t stumble upon the latter while I was looking for something better than YCM. I should try these out, too.

            1. 1

              I’m trying ccls right now. Not seeing how it’s way better so far, only seeing higher RAM usage :D

            2. 2

              This is almost identical to my setup, though I use ccls instead of clangd, use ALE for running linters, and include flawfinder in my linter set. I also integrate clang-format into Neovim through Neoformat (note that both this and ALE work with Vim also).

              I’m curious - how lightweight do you find clangd? Since I started using ccls (as opposed to no language server), I’ve had a hard time editing C++ on my laptop due to the resource use (in particular, long-duration CPU spikes for reindexing on most file openings).

              1. 3

                I’ve been working on small-ish projects mostly (though with some dependencies), and clangd has been okay on my not-so-powerful laptop (i3-4010U).

                If CPU spikes interfere with actual editing, try running the language server with nice?

                1. 1

                  True, that could be a good idea. For now I’ve been able to mosh into my more powerful workstation and edit there, but nice-ing would probably help for my laptop. Thanks!

            3. 4
              • Visual Studio Code + cpptools + markdown-toc
              • clang-format (integrated with VSC)
              • clang static analyzer (integrated with VSC)
              • Instruments for profiling
              1. 4
                • Languages: C (no C++), Lua
                • Editor: joe
                • Build system: GNUMake
                • Debuggers: gdb (Linux), dbx (Solaris), ldb (Mac), valgrind (Linux)
                • Tests: manual (home) custom (work)
                1. 4

                  vim with YouCompleteMe + ctags

                  1. 4

                    Text editor: Geany. Offers some IDE-like features, but is otherwise just a plain text editor.

                    Tabs can be put at the top or the side. All bits of GUI are togglable. Customisable bliss.

                    Geany’s extension system has a few dozen options. I only really use the spell checker (for when doing non-code, html, etc). There’s also a document minimap thing (made popular by sublime).

                    When I started coding I found lots of examples and tuts showing big IDEs. I never had luck with them. Often they had changed completely (major release) since the tut was made and worked completely differently, or confused the hell out of me if they hadn’t.

                    Now I know IDEs are a horrible thing to throw beginners at too. Teach someone to drive on a car before an articulating truck, they can try the truck later and see whether they like it.

                    I’ve been across a few text editors/mini-IDEs over the years, but I’ve always come back to geany. For one the devs are not trying to change it, it’s a hammer I own rather than a hammer I rent. That and Puppy Linux includes it, which is praise enough.

                    Build: short shell script that’s similar to make, but autodetects header files being changed and recompiles the relevant sources too. No config needed when new sources and headers are added.

                    This has taken a few years of iteration. It used to be longer and more complex, but now it’s down to 77 lines inc whitespace and comments.

                    A few limitations: namely every source is compiled in the same way with the same options. This is fine for my style of projects.

                    Screen layout: I’m on a small 1366x768 at the moment. I keep geany on the left and a terminal on the right.

                    i3wm makes it quick and easy to switch windows without the mouse (I’ve rebound the stupid almost-vim directional keybinds to the actual vim ones). Often I wish I had just a tad more space however.

                    Fonts: Terminus. Only pre-bitmapped (no anti-aliased fonts) allowed.

                    I can’t stand articles I read about people’s font preferences. Modern font AA sucks to me regardless of what flavour (OS, truetype version, hinting settings) it is.

                    My ideal font rendering case is how XP did it (perfect and sharp 1-bit). My worst case is how Windows 7 does it. It gives me an actual headache, where as I can survive without a headache on default Linux/truetype setups. I suspect this is heavily influenced by what I’m used to, but I’ve also run some 3-month stints at Win7 desktops all day and I have not gotten over the problems/headaches.

                    Admittedly modern fonts are not designed with non-AA rendering in mind, so they look damn ugly if you try. Truetype/linux can be told to AA/hint things a little ‘sharper’ (more like a 1-bit non AA render) with the following export:

                    export FREETYPE_PROPERTIES=“truetype:interpreter-version=35”

                    … unfortunately some apps ignore this. Namely my web browser :(

                    This option tells truetype to use the ‘old’ algorithms for font rendering. This was the default for a very long time, then recently (a year or two ago?) they changed. I only realised when I looked back at old screenshots and realised how much clearer things used to be.

                    The new algos, based off what I have read, are designed to emulate how Windows does the rendering. To every man his own!

                    1. 4

                      Windows: cygwin, tmux, vim, trying out cdbg, Visual Studio but only for the debugger

                      Linux: tmux, vim, gdb, cgdb to make gdb usable (you have to build from master, there hasn’t been a release for ages), this thing to prompt to attach a debugger when my code crashes like on Windows

                      OSX: I gave up developing for OSX a couple years ago but tmux/vim/gdb again

                      Vim: the only C/C++ specific plugins I have are a.vim and gutentags

                      Testing: asan, relacy, cdschecker. I don’t unit test but if I did I would use my own framework, all the existing ones are insane

                      Profiling: mostly just perf and profiling macros I wrote myself. I use vtune and IACA for very high perf code, and I should really integrate something like tracy but I haven’t got around to it yet

                      Building: I static link ninja and lua and add the binaries to the repo, then have a lua script to generate the ninja file. Everything else is garbage.

                      Dependencies: I put the sources into my repo, delete their build systems, and build them with my own. If they take more than a few seconds to build or are totally dependent on cmake/autotools/etc I have a separate libs repo with build scripts which I run through CI, then copy the binaries into the main repo. With my dependencies and build system in the repo, I can pretty much pull and build immediately anywhere.

                      1. 3


                        emacs evil mode, cgdb, clang-format, r tags, occasionally some flame graphs.

                        Want to move more stuff inside emacs. About one year of dev work in emacs so far.

                        1. 3

                          Qt Creator 4.8 beta w/ clang code model, VIM with YCM–these I spend most of my time with.

                          For various debugging purposes, I launch gdbserver, strace, valgrind. Sanitizers are also nice as my colleague has shown me.

                          I’ve been using CMake for almost a decade now, I’ve even converted $work to use it.

                          There’s not much else other than that. The only thing I’m missing must be https://github.com/beacoder/call-graph for the IDE. Or some better tool than my crude script to (also recursively, following dependencies) compute the size of compiled symbols in a binary. Otherwise I’m pretty content, I must say.

                          Anything in particular you’re interested in? Something you find annoying in your own setup?

                          1. 1

                            I’m just learning the language. I’ve spent the last ~15 years of my career living exclusively in languages like Perl, Ruby and Python.

                            I use Vim (Neovim mostly) for most of my work, and am using CodeBlocks for the C++ stuff mostly because it was a ready made environment that stays out of my way to learn on. I’m sure when I start doing work in earnest I’ll figure out a good Vim setup and start using that.

                            I asked the question mostly to see if there were any stand-out tools that the vast majority of C++ used that I should invest time in learning as I ramp up with the language.

                            1. 4

                              Ah, okay. My advice would be to trash Code::Blocks immediately. I highly recommend trying out Qt Creator, even more so since you’re a VIM user, too, as it has a pretty nice FakeVIM mode and doesn’t cost anything, unlike e.g. CLion. It’s not perfect but it’s one of the best environments I’ve found, and it’s another thing I’ve been using for about 8 years already.

                              One big problem for C++ IDEs is the code model. Even though clang has made it much easier to get it in all kinds of projects, I don’t think you can get very good results there with any current VIM plugin, or even with LSP servers. And I very much enjoy things like instantaneous and always-up-to-date “find usages”, or global symbol renaming (“refactoring”).

                              All that being said, people differ, some of the best programmers I’ve met in person used nearly plain VIM or Emacs, with ctags at most, which would make me very unhappy. Expect extremely varying responses.

                              1. 1

                                That’s interesting I thought the Clang language server stuff was very well thought of.

                                Thanks for the recommendation, I’ll give Qt creator a shot!

                          2. 3

                            I run a pretty basic setup. I work with GCC and the GNU binutils for embedded devices most of the time.

                            • Emacs and cc-mode with minimal customizations. I use a combination of ansi-term and eshell, depending on what I’m doing.
                            • GNU Global and ggtags in Emacs for code navigation.
                            • Zsh for the shell, with not too many customizations. In other words, no oh-my-zsh or anything like that.
                            • Testing tool is DejaGnu since that’s what GCC uses
                            • GDB when I’m debugging the compiler itself. When debugging anything on a device, I use a variety of different things, depending on the device: MPLAB X, Atmel Studio, J-Link with GDB server, to name a few.
                            1. 3

                              Vim, shell, ctags, sanitizers. Usually clang-format. This is for open source work. At work there are other build tools.

                              I probably should expand this basic toolchain, but it works well enough when I code C and C++, which is not super often.

                              1. 3
                                • ssh + tmux, to run most of the rest on fast servers
                                • vim, to edit all the code
                                • cmake, to build
                                • ld.gold, to link a little bit faster (than default gcc linker)
                                • buildbot, for CI
                                • gtest + gmock, to write tests
                                • gdb, to debug
                                • valgrind memcheck and asan, to debug
                                • valgrind helgrind, to debug thread related issues
                                • benchmark, to make sure cpu performance is good
                                • valgrind callgrind, to measure where that cpu time is spent
                                • kcachegrid, to visualise callgrind results
                                • perf, to also measure cpu usage
                                • valgrind massif, to measure where memory is used

                                and lots of smaller and bigger internal tools.

                                1. 3

                                  I use Notepad++ for editing. As an architect I don’t do much coding anymore and the changes I do are usually trivial (at least if you look at the diff). I would prefer vim but my IT-controlled Windows environment makes it suck too much. The others mostly use VisualStudio or VisualStudioCode afaik.

                                  For unittesting we use Googletest and Cantata. The later is necessary to instrument code for coverage statistics. While gcc and other compilers can do this for you, various compilers for embedded targets don’t. Unfortunately, Cantata does not even support C++11 completely/reliably, so we are restricted to using C++11 minus some features.

                                  Debugging happens with VisualStudio, gdb, or the Lauterbach tools depending on the platform.

                                  For building, we recently switched to CMake from a homegrown system. Our CMake is heavily adapted and does not look idiomatic.

                                  For coding rules (e.g. MISRA) we primarily use QAC. This sucks because the licensing model does not allow to check pull request with Jenkins.

                                  That is all the external tooling I can think of for now. There is plenty of internal tools as well.

                                  1. 3

                                    Combining work and home into one list: ssh/putty, tmux, emacs, ctags, lua (for writing tests), gdb and GUD (Grand Unified Debugger), lint/clang-tidy/pclint/flexelint, valgrind. Sometimes I use CLING interpreter to try ideas. Since people are mentioning fonts, I’ll note that at home I use Iosevka Term Slab.

                                    1. 3

                                      It’s been awhile since I’ve done it, but Visual Studio on Windows is a fantastic C++ dev env that just works.

                                      1. 3

                                        I use neovim’s :Man command and K binding a lot, along with ctags integration.

                                        1. 3

                                          I’m developing on Windows, so…

                                          • Editor: vim (command line version)
                                          • Debugger: windbg (if you use Windows and haven’t tried it, you should)
                                          • Revision control: git
                                          • Documentation: doxygen (I don’t use the output but it validates that all my functions are commented)
                                          • Build: nmake
                                          • Installer: nsis historically, but I’m moving away from it
                                          • Shell: yori (this is circular, since I’m working on it. Having things like expr handy is nice, but it doubles as testing.)
                                          • Font: Lucida Console
                                          1. 2

                                            clang, gcc, emacs, sublime, gdb, valgrind, make