C++ Ecosystem: Compilers, IDEs, Tools, Testing

I had similar issues when I included the standard library with templated data structures and googletest. The IDE would consume my entire MacBook Pro 2016. The UI froze, input would be delayed on the orders of 10s of seconds, and I can go on...

I really really hope they can fix this because at my work I'm trying to get CLion working. The Codebase is quite large and I have to turn inspections off or else input freezes and won't be responsive for up to 30 seconds. It's at times unusable.

When it works it's amazing but it still has some ways to go.

> It's slow and freezes even on tiny projects.

This statement is false. It's way too broad a claim to hold up. With all due respect I'd consider it harmfully incorrect.

Counterexample: I use CLion to work on Cataclysm: Dark Days Ahead. It's ~360,000 lines of pretty hairy C++. It's fine.

There may be conditions that make a stricter definition of the claim true. I don't know what those conditions would be. A link to Jetbrains' definition of the issue would be good.

Here I am surprised, I've started paying for IntelliJ because I couldn't open huge project in Eclipse.

Yes it's a massive project. I've attempted all sorts of GC tuning. I'm not convinced it's all GC issues; I think whatever data structures or algorithms they are using for their semantic tree must not scale well to extremely large data sets. It also doesn't seem to be terribly friendly to high concurrency. Having lots of cores doesn't really help.

CLion seems to struggle in particular with the presence of the out / generated source directories in Chromium. Even when asked not to index (exclude), the mere presence of the directory seems to bog it down.

The tool also needs to have a more flexible notion of source roots/include roots. I should be able to notify it that a directory is an #include root without having it try to index every .c file etc. underneath there. I should be able to select a group of directories and say "these have headers, but they're relative to path X, rather than themselves" etc.

Is this even including all the stuff that gets pulled in as a 3rd party dep? Some significant portions of the code live there such as angle, blink etc.

I use Emacs + Eclim. Other coworkers use Vim + you complete me. Or just raw vim, because they're far more patient than me. Others us VSCode + clangd, etc.

You can generate a compiler_commands.json from ninja for these tools. I don't have the command handy -- but you can google for it.

They all perform quite admirably when compared to CLion, unfortunately.

I have been using it. No real improvement. Freezes all over. And I gave the GC something like 20gb.

It's even worse when adding in our internal repositories on top.

Also having a back and forth on a ticket about their support for compiler_commands.json; the one generated by ninja for Chromium simply doesn't work for me. Their person says it works for them, though. I don't know how. Right now I manually create a CMakeLists.txt with the directories I need.

But one thing that is discouraging about CLion is that even directories that you explicitly tell it not to index as source seem to still be looked at and indexed in some fashion, so a huge number of files just drags it down to a halt. My coworker was able to get decent performance by creating an empty directory and symlinking in only the directories he is working on. Simply having directories with large quantities of files is enough to drag it down.

It's very disappointing, as its my tool of choice. I feel handicapped without it.

Agreed that Java tooling is amazing. The only reason I said "even Java" here was the fact that you have to choose a build system from a handful of fairly popular options, which adds some up-front cognitive overhead to your project vs. Go or Rust.

Ive spent a good part of my 20+ year career wrangling c++ dependencies, and it's hard. MS has introduced vcpkg, which should make things better, closer to a pip or npm style package manner, but I haven't used it, so I have no idea how well it works.

Rust does support binary libraries. You just have to interoperate with them via the system/C ABI. It doesn't support binary crates, but a crate is just a compilation unit, like a file in C/C++. Do people commonly use binary .o files in C/C++ across compiler versions? That would be the equivalent of what you call "binary libraries".

> (or Meson)

C++ in a nutshell :D

Not 100% alike, because it depends on QML/JavaScript and lacks the eco-system of third party components.

Thanks for the wxFormBuilder and wxWidgets reference, I always saw them as a MFC wannabe and don't have any experience with them.

No. Qt and C++ Builder are very different. Qt with Qt Designer is much closer to wxWidgets with wxFormBuilder than C++ Builder, but from my experience so far (i am working with Qt+Qt Designer at day job and worked with wxWidgets and wxFormBuilder at previous job) Qt Designer feels like an alpha product at best when compared to wxFormBuilder.

It is interesting that Qt as an API feels more polished, but the designer is barebones whereas wxWidgets as an API is a bit more clunky but the designer is much more polished (wxFormBuilder is the most common one, though there is also wxSmith which is a commercial designer that is supposedly better - though i never used it myself). In comparison at least, wxFormBuilder does have its own warts.

Though you use both in essentially the same way you'd use MFC with Dialog Resource Editor in Windows 3.0 - just with a bit more features and an easier API. But the core ideas behind the workflow remains the same.

In C++ Builder, even the original version from 1996, is much easier to work with because you design the UI and assign the handlers in a visual way. You are also working with live objects instead of stand-ins (when you create a control or other -nonvisual- component, you compile it into a DLL and the IDE loads and creates an instance of that DLL that you are editing through the rich RTTI it has - this relies on extensions to Delphi/C#-like C++ language). Your form is serialized as a resource inside the executable and deserialized when it is instantiated.

The IDE uses RTTI (remember that this is richer than C++'s regular RTTI) to manipulate the objects, create event handlers (just double click a button or click on a menu and the IDE will create the methods for you - update the header file, write the method body, associate the handler with the event, etc). When you drop a component in a form, it will automatically add any necessary header file #include's at your code (later versions of C++ Builder will also automatically add any necessary includes if you use any function the IDE knows of - like a stdlib function or a function from another file).

In general the IDE will do most of the work for you, you focus on the "meat" of your applications and any busywork/pumbling/boilerplate is handled by the IDE.

I have heard that QtCreator does provide something similar, but from the very little i've used it, it looks that these "whispers" come from people who haven't really used (or understood) C++ Builder as it feels more like how Visual Studio integrated the Resource Editor that back in the day used to be a standalone application inside its UI but still acts as if it was a separate application, than a really interwoven integration like VCL (C++ Builder/Delphi's framework) and C++ Builder have. But truth be told, i have used QtCreator very little to judge properly - i'll need to do a more in-depth experiment (though again, i never had to do that with C++ Builder or Delphi).

(as a sidenote, in general i have a bias against anyone that only focuses on the form designer aspect of C++ Builder/Delphi when comparing it to some other supposedly similar tool as the form builder is only the tip of the iceberg that only works as well because of the rest of the iceberg beneath it)

Now if modern C++ Builder wasn't such an overpriced DRM-infested PITA it'd be nice. Though like with Delphi, if $whoeverownsittoday decided to release a cheap (similar to their mid-90s prices) DRM-free version (especially on a box, though i'm ok with an installer or ISO i can keep on my own media) i'd (most likely) buy it instantly.

Though their community editions are free (but with a bad license that says you can use it only if you make up $5k annually and still needs activation that can go away at any time they feel like) so if you just want to play around they're fine.

I like to think that its spirit lives on on .NET.

Valgrind's memcheck is still useful: it doesn't require recompiling, can handle external (binary-only) libraries, handles inline asm or jitted code, and provides uninitialized memory read instrumentation (yes, memsan does this, but it's tricky to set up). For me personally, I've required memcheck for applications using CUDA because CUDA and sanitizers don't play well together (for example, see https://github.com/google/sanitizers/issues/629). but indeed, the sanitizers are soooo much faster :)

Is there a mem issue that can be caught by Valgrind but not by a compile time sanitizer?

Use it to profile my code, especially if you want to count cache misses, etc.

Due to the memory unsafety of C++, memory debuggers are absolutely used, including valgrind's memcheck and the Google sanitizers. Memory leaks and double frees are easier to avoid in C++ than C even without tooling, but use-after-free (for example) is absolutely a problem. And "modern" C++ won't necessarily help you here: even heard of string_view, span, or ranges? Memory debuggers are also often used in conjunction with fuzzing to track down bugs that the compiler may not tell you about.

Can you say the same about the third party libraries or other in-house modules?

Standard containers/algorithms/iterators have some caveats like messing up the erase-remove idiom by forgetting to pass the end iterator.

clangd is really good these days (clangd-9), I suggest you give it a try. It's incredibly easy to set up if your distribution packages it. I'm using it with Emacs' lsp-mode, it's great.

I only hear about PVS-Studio from their adticles that they agressively post to programming-related communities.

Note that https://clang-analyzer.llvm.org/scan-build.html is another llvm-based static analyzer.

It does a more deep analysis into the control flow, whereas clang-tidy does (mostly?) comparatively simpler checks on the AST.

direct link to cppcheck releases: https://github.com/danmar/cppcheck/releases

Clang has support for cross-compiling [1] without needing separate builds for each target so you should be able to use clang-analyzer and clang-tidy whit the right -target flag for your ARM platform.

https://clang.llvm.org/docs/CrossCompilation.html

Besides that, most bugs found by static analysis are platform independent so you should be able to use any static analyzer you get your hands on as long as your code is cross-platform.

You can also get run-time checks in libstdc++ and libc++ with -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC and -D_LIBCPP_DEBUG=1.

If your company makes a million bucks in revenue it can afford a few Visual Studio subscriptions. $45/month.

I'm more looking for a debugger rather than a compiler. Like GDB. I wouldn't call cmake or make debuggers.

I have seen a few gdb plugins but at least my experience is that they are extremely wanting.

I'm fine with GDB. But I would like it in vim. You know how in GDB you can get the line by line representation? Just that but with my colorschemes and so I can set breakpoints while in vim. GDB isn't an issue, it is that GDB is old, doesn't support colors, and doesn't integrate with my editor.

Alternatively, running "M-x gdb"[1] within Emacs configured with Evil[1] for Vim keybindings[2]. Running a separate program is a pain, and it won't have config from your .vimrc, but the tight integration between GDB and Emacs is really nice.

[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/GD...

[2] https://github.com/emacs-evil/evil

I use tui (well I just hit `<C-x>a`) but there's more I want, like color (because we aren't living in 1970!). Maybe this vi more does the other part I want, which is code exploration and allow me to select lines for break points instead of typing as much. But I'm not sure what `M-C-j` is (I'm sure this is a dumb question). Both of these things are pretty standard in modern gui debuggers. The other thing I kinda want but isn't necessary is my display variables to be in a different pane and to have a nerdtree like file structure.

Frankly a lot of times I know where I need to investigate my in my code. But it is annoying to switch to vim, find the file and line number, go back to gdb then do `b my/file/structure/is/long:1825`. That gets hectic in large projects.

edit: My current setup I used vim+zsh+tmux. So I don't mind having gdb in a new pane that isn't a vim pane, but I just want colors and some of the basic features. I don't need everything that the IDEs do, just the basics.

I agree. Vim with ctags and gdb is a pretty performant workflow. I just turned 40. So maybe it is context. I do like vscode though. Its pretty snappy and has good keyboard shortcuts so I don't have to touch the rodent.

... I use Conan in projects with dependencies on OpenSSL on Linux and I don’t have any issues. I use the Makefile generator (because our build system is plain make + Conan). The name of the package shouldn’t impact you at all, unless I’m misunderstanding what you mean?

Another example is a dependency on a package called ‘jsonformoderncpp’, which I use by ‘#include “nlohmann/blah.h”’ - the package name is arbitrary, even if you have to refer to the dependence using the package name in your build system rather than the canonical name I don’t see how that would be an issue (even with FindPackage or whatever you use in CMake)?

Per a StackOverflow post, the reasons for this are detailed here:

https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-stu...

Is there some reason you would expect a 64-bit Visual Studio port before a Linux port?

MS has explicitly stated they dont intend or expect to make VS 64-bit in any near timeframe. They say they dont need to because the components that would benefit from 64 bit are already out of process and communicate to the main UI over IPC.

That said, nothing stops a 32 bit VS building/debugging a 64 bit process. I was doing this 10+ years ago.

MS doesn't support running VS at all on Linux/Mac, and probably won't ever, or for a very long time out. Use VS Code, instead. Yes, you can target Linux/Mac from Windows running VS, but VS wont run on the same OS.

All of the underlying tools are native 64-bit, but it's hidden behind a project property that you need to turn on to use them.

I think it's just the C# code editor process that's still only 32-bit.

It will definitely mean a significant increase in Linux developers.