1. 6
  1. 3

    The GCC usage numbers really surprise me. Clang and GCC are both great, but Clang seems to steal the spotlight.

    1. 2

      56% use CMake but only 9% use Ninja. Either 47% of people really, really hate themselves or there’s something dubious in the survey methodology.

      I suspect most C++ developers that use clang also test with gcc so tick both boxes, but folks that really like GCC are happy using it exclusively. I test on gcc and suffer through all of the pain (such as warnings that gcc can’t inline always_inline functions if they’re recursive templates, or __has_include<linux/futex.h> return false on gcc 9 even though #include <linux/futex.h> happily works because there are bugs in the interaction between __has_include and gcc’s fixincludes exciting logic).

    2. 1

      Honestly surprised to see 30% don’t write unit tests for C++.

      Also disappointed by the 30% who don’t use any “quality tools”.

      Things to ask about during job interviews, I guess.

      1. 1

        Surprising to me that VS Code is the most popular IDE. I haven’t used it much, but assumed it’s in the Sublime / TextMate camp, i.e. a power editor with some language support, not a full IDE. Anyone here using it for C++?

        1. 4

          I wouldn’t say that VS Code is in “plain text editor” camp.

          On the technical side of things, the APIs Code exposes speak directly about high-level IDE features: https://code.visualstudio.com/api/references/vscode-api#languages. For example, there’s “call hierarchy”, where the extension provides just the data, and the presentation is done by the editors core. This is in contrast to “plain text editors” APIs, which typically expose just the low-level “drawing” API, an extension could do something like “call hierarchy” for ST, but it would have to implement both data collection and presentation.

          On the social and systems-design side of things, Code created LSP, and that’s huge. IMO, technically the language server protocol is obvious, non-innovative, and has some rather annoying defects. But the genius is not the technical protocol, but the industry effect it had: now every language vendor tries to make a compiler that can also work as an IDE backend. This is a hard task, but not having LSP is frowned upon, so people do it anyway. Before LSP, only a couple of languages did that properly (C# and Dart), and the status quo was “we are shipping a batch compiler, clearly adding completion on top of it is easy, so we won’t bother”.

          There’s nothing which makes VS Code a fundamentally better target for LSP than any other editor out there. However today, in practice, VS Code extension API/ecosystem are much better suited for consuming LSP. LSP provides data, and code extensions consume data, so you just plug LSP’s “call hierarchy” into Code’s “call hierarchy”. For other editors, you also need to write the extension code to display it.

          1. 1

            Thanks! I shall reinstall it and give it a try with my C++ stuff. I’m super comfortable with Xcode, but its C++ support is increasingly buggy … probably because it’s a third priority for Apple behind Swift and Obj-C. So I’m willing to try an alternative.