Hacker News new | past | comments | ask | show | jobs | submit login
C++ Ecosystem: Compilers, IDEs, Tools, Testing (bfilipek.com)
193 points by joebaf 6 days ago | hide | past | web | favorite | 145 comments

CLion is an amazing tool -- I've purchased licenses for my personal self in the past, but my employer pays for it these days.

My problem is they've done a terrible job of making it scale up to large code bases. I work on the chromium tree -- CLion is completely useless on it. I have a dual 24-core xeon with 128GB of RAM and SSD and I've given it a wackload of memory, and it becomes completely inoperable, freezing all over the place.

Awful because I have such muscle memory for the JetBrains tools, and such a fondness for them.

I've gone back to using Emacs, but now with Eclim. I just couldn't get into VSCode.

Java-Based and Chromium-based IDE suck a lot on large code bases.

The same IntelliJ can't compete with Eclipse on handling large scale projects.

CLion gets all the bad from IntelliJ .

On this point of view, Visual Studio 2019 has improved much more on a performance perspective and can still handle large scale projects.

So far, I prefer VS and QtCreator, which have also a free license too. I don't understand why CLion hasn't a Community Edition just like IntelliJ

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

On a multi-artifacts maven JavaEE project (not submodules, just a lot of independent modules), it has serious difficulties. Support for Java12+ is far better than Eclipse, but working on IntelliJ and using auto-formatting tools (Checkstyle and Save-Actions) makes it suffer enormously. I've never had those problems on Eclipse. I had to assign over 4GB RAM to handle more files (by default it is set to 2GB max)

Second this. I've found IntelliJ to be much faster on large codebases.

Interesting. Chromium seems to be huge indeed. I googled statistics: 3+ million lines of code? Is that about right? (Not that LOC is a great universal metric of everything, but it's something.)

For comparison: I work on something a magnitude smaller: https://github.com/CleverRaven/Cataclysm-DDA/ ... about ~360,000 LOC. CLion is pretty great for that.

I'm curious, have the VM garbage collection and allocation settings been adjusted? In other words, not just the memory limits but also switching to a different garbage collector and the GC control mechanisms adjusted? I've been reading up on the collectors. As far as I can tell the G1 collector is strongly indicated when you go above a 4 or 8GB heap. It then has a number of settings to adjust. I got really good and smooth performance out of it - few and short enough pauses that I was at peace with CLion - but seemingly I set the garbage collection to be "too continuous" which caused constant CPU usage when I used that profile in Pycharm on a Python project. Had to switch Pycharm back to a more, uh, classical GC setup. (I didn't reconfigure to rein it back in as it was unnecessary in that context. I'm sure it's possible.) The JVM and the GC are a rather interesting beast.

Just curious :)

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.

Many thanks! I assumed that GC tuning had indeed been attempted.

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.

You may want to give the CLion 2019.3 EAP build a try. I was having the same issues as you with a very large (~1 million SLOC) C++ code base. To my surprise, the EAP build has seemingly removed almost all hesitation/hanging. They did rename the keymaps for some odd reason, which I worked around by extracting from a previous version's resources.jar file and placing in my preferences directory.

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.

20GB what? Xmx? That high is going to cause you really massive GC pauses... Maybe try winding that down a bit?

I've tried everything inbetween, so.

It's slow and freezes even on tiny projects. They're aware of the issue and apparently the next release will be focused entirely on trying to address those.

At the moment that's my number one issue with CLion.

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.

I don't think I'm making an extraordinary statement. If you look in their bug tracker, there are 500+ tickets with the term "freeze" in it. The reason is actually known: being a Java IDE, the design takes for granted that many operations that are almost instant in the Java world can takes many seconds in the C++ world (meaning they'd need to put that in the background instead of blocking the GUI).

Obviously there are (many) reasons for that. What you think is hairy might not be that hairy, in terms of parsing, to a compiler or static analyzer. If you're like most game developers, you use a simple subset of C++ that's C-like, which might explain why you're lucky.

Maybe the word 'tiny' was excessive. It might not affect someone's homework, but in my case it definitely does have performance issues for my relatively small one-man projects. I'm not bashing the tool; I'm a paying user too. But no one can deny the many performance issues, and indeed the focus of the next major release is precisely to start addressing those.

My statement was inadvertently aggressive. I was attempting to be clear and logical but came out wrong. I am sorry :)

It's a question of for-all-x vs. there-exists-x. I acknowledge that there exist x'es that are small projects that make CLion hang.

I just wanted to make sure it was known that it's not all x'es. And that there exist y's that are large projects that don't hang. Cataclysm DDA is not a simple codebase :)

The thing is that I've been using IntelliJ since version 3something, 15 years ago or so. It's _always_ had freezing problems. Over the years they made incremental progress on the Java front such that it became less common; or else workstations just caught up with the software. Or both.

I also used AppCode extensively, that one actually behaved pretty well, overall.

So I am not really surprised by CLion's performance/stability issues. I have a long love/hate type thing around this with Jetbrains.

I hope they can get these things sorted out.

I often wonder if they wouldn't be better rewriting in a non-GC'd language. Rust or something.

> This statement is false.

I've run into this issue, also. It's not Visual Studio levels of constant freezing, but it definitely pauses once in a while. Seems to mostly occur when I'm developing on Windows, though.

EDIT: Wanted to add that it's definitely a regression. I've been using CLion without the pauses for years.

To clarify: I believe that it can happen even with tiny projects, under certain circumstances.

It works fine only if inspections are turned off.

So it's an amazing tool but actually not so amazing?

That being said, having worked on chromium myself I can attest to the size of the code base being such that pretty much every tool shits itself.

Have you tried pinning the IDE to one NUMA node? Text editors are pretty random access and will not have a fun time across numa nodes.

Also, what range of CPUs is your xeon on? Buying a current-gen consumer chip could yield a huge performance uplift if it's not from this gen.

SlickEdit isn't cheap, but I feel like I've gotten my money's worth over the years. It can handle tagging yuge codebases and still stays responsive.

Did you try other setups? Maybe you could share what your teammates use? (Also working on the chromium tree, in search for a better environment)

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.

Sorry, I meant to say Eglot, not Eclim. Too many E in my Emacs.

Thanks for clarifying, but neither Emacs nor Vim is my cup of tea :)

Sorry, I meant to say Eglot, not Eclim. Too many E in my Emacs.

Microsoft Visual Studio has the best c++ debugger. You get spoiled by it. Highly recommend it. If you are a beginner start with Visual Studio; it will make lots of things easier for you. Once Microsoft ports it to Linux the competition is fucked.

Microsoft still hasn't ported Visual Studio to 64 bit, so I don't expect Linux support is coming any time soon.

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.

This is a bad excuse for too much (internal) complexity. 64bit is over 10 years old at this point and there's no reason NOT to update programs.

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


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

The blog post is 10 years old, the reasoning was poor then and has not aged well. No mention of the performance benefits of extra registers, new instructions, security benefits, etc.

The only advantage I can see to staying 32-bit is that Windows on ARM64 only has an x86 emulator, not x86_64.

I think there’s a 0% chance of a Linux port: VS Code is the cross-platform/future dev environment for Microsoft. But I wouldn’t be surprised to hear that a 64-bit Visual Studio is coming soon to Windows.

The new instructions are generally special-purpose, Visual Studio doesn't sound like an obvious target for vectorisation. Security is meaningless - VS is not on a security boundary. The memory size cost disadvantage is real, though.

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.

Managed language tooling is written in their respective languages, so I doubt about the process still being 32-bit.

It is very nice .. but I suspect that even Microsoft have realised it has serious maintainability issues within itself, so it will probably never be ported. Expect VSCode to acquire a comparable debugging plugin instead.

"The best" compared to what exactly?

Have you tried "rr" for instance?

Once Microsoft ports Visual Studio to Linux the Windows is fucked.

That's the only reason why they don't do it.

It will definitely mean a significant increase in Linux developers.

I had to use Qt as the UI lib for a project, it made me discover that QtCreator was actually not a Qt-only tool but a very good lightweight and generic C++ IDE.

That's my choice now. I need something that can navigate easily in a code base, I don't really like learning all the oddities around emacs and vim (even though I am a bit competent at vim) and I don't see what is so bad in using a mouse.

At first I thought annoying to have to manually edit the .includes and .config to add the includes and the macro I needed in our complex, hard-to-parse CMake based project, but now I really enjoy the freedom it gives.

The worst thing about C++ is the endless sequences of choices you need to make about tooling before you even write a line of code. This is actually what made me switch to Go for personal projects - I'm a professional C++ programmer, but setting up a development environment required so many choices and so much futzing with various tools that I would spend all my energy getting set up and never make progress on the projects themselves.

Go, Rust, and even Java are all way better in this department - the tools are standard enough that you only have to make a choice if you are doing something less common. I would love a Dropwizard-like bundle that just gives me a pre-set-up config with everything I need to write a C++ CLI app or daemon.

If you standardize on CMake, lots of up-front choices go away, and will be converted to options which can be changed on per-developer basis. CMake can generate the whole project part for lots of different developers, allowing the devs to use practically any IDE they wish.

Plus, you'll get a properly configured project with automatic dependency tracking.

I don't understand why CMake isn't used by default. (or Meson)

> (or Meson)

C++ in a nutshell :D

I think I see what you're trying to point out ;), but both meson and cmake will allow you to use different tools to do development ;)

> The worst thing about C++ is the endless sequences of choices you need to make about tooling before you even write a line of code.

I don't know about endless. CMake is supported in almost every IDE toolchain these days, so there's your build generator. Compiler choice may as well be down to the platform you're developing on.

> I'm a professional C++ programmer, but setting up a development environment required so many choices

Me too, and it's about as complicated as Java or any other language I've worked in.

> I would love a Dropwizard-like bundle that just gives me a pre-set-up config with everything I need to write a C++ CLI app or daemon.

Visual Studio, CLion, QtCreator all do this. They'll even add your main.cpp to your CMakeLists.txt for you.

Now, if we're talking dependency management on Windows, I'm all about griping there. vcpkg is not quite the drop-in solution Microsoft makes it out to be.

Yet I never wait for C++ builds like I do with Rust ones, due to lack of support for binary libraries.

That is currently my number one grievance, 2nd is lack of tooling that matches C++ for Windows/.NET developers.

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".

Naturally I was speaking about binary crates.

Yes we do, all the time on Windows, as .lib, .dll or plain COM (now UWP).

Dynamic libraries and COM are an OS ABI, as such compiler agnostic.

And for compiler specific versions, well known libraries do bundle pre-compiled libraries to latest three versions of e.g. VC++, ICC and C++ Builder.

Watching the same crates being compiled over and over across projects isnt' fun. And the workaround with a common workspace only kind of helps.

Right. I would say that any large C++ project, especially one with multiple binary targets, will naturally split the code base in dynamic or static libraries.

Yep and in large organisations the compiler version is anyway managed by IT, thus all teams can get to share common binary libraries.

Even Java? Java's tooling is top notch.

IDE is awesome. Debugging tools are rawsome. Build tools can be... Well you've got choices. Workspace setup is easy

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.

> ...wrangling c++ dependencies

Yep, I think this is my main gripe with C++ on Windows right now. vcpkg is meant to work with CMake or Visual Studio, but you still have to manually tell it where your toolchain file is - which means it's additional work for the rest of your team. In Visual Studio, it's seamless.

On Windows, it's gotten to the point where I try to build dependencies as part of the build chain and hope the tooling is smart enough to not rebuild them a million times. Would be really nice if Windows 10X (or whatever) could come with a package manager or integrate vcpkg.

I stick to Debian/Ubuntu Linux. Its package manager is essentially the package manager for C++ from the beginning.

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.

> I need to write a C++ CLI app

At first I thought you meant this obscure little language: https://en.wikipedia.org/wiki/C%2B%2B/CLI

C++ Builder + VCL keeps being the only development environment where RAD and C++ really go hand-in-hand.

Sadly thanks to their management mistakes and the trend of wanting everything for free, only a select few know how it actually feels in practice.

C++/CX + XAML came close to it, but got replaced by C++/WinRT, which is still catching up to C++/CX tooling.

What about Qt? Doesn't it have something similar?

As a cross-platform C++ Builder replacement, I have been using wxFormBuilder and wxWidgets in the past. There are some manual steps, but it let's you build a GUI quickly, hook up event handlers and then write implementation code in a derived class, so that stuff generated by GUI editor doesn't rewrite your code.

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.

You can still use QWidgets, which is more similar to VCL.

There are third-party components (for example the open-source Qwt [0]), but probably fewer than you find for VCL :)

0: https://qwt.sourceforge.io/

QWidgets are stuck in desktop deployment scenarios, with QML taking front row for everthing else, something that they plan to change with Qt 6, which remains to be seen in what form it will be done.

Qwt is not the same as the commercial support from component oriented companies, including the UI/UX care of some components.

wxWidgets is worth looking at. I use it and really enjoy using it. Used it for a largish cross-platform job a few years ago which is why I think all the modern garbage like Slack and Electron-based apps is sheer laziness.

The forum can be a bit quiet sometimes but you'll likely get a response. Bug reports and stackoverflow questions also might get some help.

Much preferrable to me than the MFC stuff I had to use at work for years. wxWidgets is actually nice to use and can have bind/connect instead of macros for event handling, as well as CallAfter(...) for easy firing of events from background threads etc.

Great toolkit.

wxFormBuilder and wxWidgets is indeed "Dialog Resource Editor and MFC" wannabe, though more cross platform, with a nicer API and with more features. Also wxWidgets is actually what people think MFC was (a layer on top of Win32/native API) instead of what it really was (a C++ extension utility of Win32 that did not try to hide Win32 API).

wxFormBuilder is nicer than Qt Designer but they are both essentially based on the same core idea of designing a dialog visually and then wiring everything by hand (code).

In another comment above i go into more details, but i guess you already know most of that :-P.

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.

Oh, Delphi+VCL was the peak. It went downhill from there.

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

No mention of any LanguageServer implementation?

I highly recommend rtags (even if it's not stricly LSP)


For the C++ using ccls[1] is way better.

[1] https://github.com/MaskRay/ccls

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.

Gotta have Valgrind suite in there somewhere. Useful to find use-after-free and loads of other issues. Plus cachegrind and the rest of the suite.

These days most people moved on from Valgrind to ASan and other sanitizers, which provide much of the same functionality with lower performance penalty.

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?

Sanitizers are not compile-time: they're runtime checks (aka dynamic analysis). For some strengths of valgrind compared to sanitizers, see my other comment in this thread.

I love valgrind, but it falls on its face if you're dealing with more realtime aspects. In particular, dealing with high frequency trading systems. Valgrind, in of itself can through timings off in of itself to be unusable in some contexts.

That said, great tool.

Massif + one of the visualizers is amazing for profiling allocations too.

Do people use Valgrind much in C++? I've never had to. I feel like the only time I'd need it is if I'm writing "C++" code that is really just glorified C.

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.

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

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

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

A few more:

- compilers: Intel compiler

- IDEs: SlickEdit, GNOME Builder, KDevelop, Eclipse, Netbeans

- Build systems: Bazel, Meson

- Static analysis: Klocwork, Coverity Scan

- Fuzzer: American Fuzzy Lop

- Memory debuggers: Valgrind, AddressSanitizer

- Profilers: DTrace, VTune, Vampir

- Documentation: Doxygen

- Debugging (and more): edb, x64dbg

- Reverse engineering: Radare, Cutter, IDA, Ghidra

And rmsbolt (compiler explorer for emacs)...

Forgot rr - reverse debugger: https://rr-project.org

Also MXE - cross-compile environment: https://mxe.cc/

Didn't see any mention of any static analysis tools for C++. Any HN recommendations?

- https://clang.llvm.org/extra/clang-tidy/

- cppcheck is sometimes updated also

- clazy : https://github.com/KDE/clazy

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.

You can actually run the static analysis checks from clang-tidy.

But you won't get the detailed HTML output that tells you why Clang Analyzer things a problem exists.

yep, see all the clang-analyzer checks listed here : https://clang.llvm.org/extra/clang-tidy/checks/list.html

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

I wrote a few posts on this topic that may be helpful: http://btorpey.github.io/blog/categories/static-analysis/

I hear about PVS-Studio often.

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

I'm interested in this too! I've been looking for one that can be used with arm-gcc for cross compiling on embedded platforms. What do people use in such situations?

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.


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.

Oh cool, thanks!

I use what Visual C++ offers, which is already quite nice.

Plus VC++ debug builds do bounds checking, even for [].

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

Thanks, I guess I spend too much time on Windows. :)

Coverity is used at my company and seems to work reasonably well.

> Visual C++ is a commercial Visual Studio IDE from Microsoft

The OP failed to mention there's a freeware edition.

> It provides the Microsoft Foundation Class (MFC) library which gives access to the Win32 APIs.

Last time I used MFC was around 2003. Last time I used Win32 APIs was today. MFC doesn't give access to anything besides MFC.

The free (Community) edition is licensed for working on open source projects, individual developers, and up to 5 users in “non-enterprises” (< 250 PCs or < $1 Million US Dollars in annual revenue.)

So covers most people, but could be a pain if you’re in a big company that otherwise doesn’t do much engineering.

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

The harder task is to convince management when there are lots of free alternatives that "do the same thing".

Clangd is a must have, using clangd in vscode + the Bear tool, you can get accurate code intelligence for just about any C/C++ project.

I see no mention of various implementations of C/C++ standard libraries. It's like the second most important decision to make just after compiler vendor (or THE most important, whatever your priorities are)

I would say that in 99% of the cases, using the standard library of the compiler is the right decision. Also you should target multiple compilers, possibly on multiple platforms.

Does anyone know a good debugger plugin for vim? I've tried a few and found them not great. This is seriously the only thing I currently want more from vim. I keep an IDE around just for this purpose. (A debugger with support for C++ and python. Don't care if two plugins)

IME, if you haven't already then I'd suggest biting the bullet and learning GDB. It's not as nice to step through code but far more powerful than the features typically exposed by an IDE, or at best are only exposed by GDB's command line interface anyway. Reverse debugging and scriptability (the command interface is a DSL) are the big ones. Like vim, GDB is an incredibly powerful tools that deserves the time to learn well.

"Give me 15 minutes and I'll change your opinion on GDB" was one of the most life changing videos I've watched. It's on youtube or text version here: https://undo.io/resources/cppcon-2015-greg-law-give-me-15-mi...

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.

Personally, Ive never tried to make Vim my IDE on Linux. Just Vim as my editor, make as my "builder" and gdb as my debugger. Effectively, bash was my IDE.

I know on the older spectrum of the audience here, but that is an effective workflow for me. But, as a nearly 40 yr old, the command-line is very natural to me. I actually get irritated when I have reach for a mouse to complete an action.

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.

You know how in GDB you can see the lines you are working on? Really I just want that to have color, like I do in vim. We don't like in 1970 anymore. We have color. The other thing I want is that while editing I can add break point.

Maybe I'm too young (28), but how I read your and the parent's comment is "My workflow has been working fine, why improve it?" which sounds weird to me. There's always room for improvement.

Have you tried ConqueGDB? It lets you start the GDB from within your vim session and uses your vim buffers to show the current file. I recently started using it and didn't really get into familiarizing with it yet, but it seems to integrate the gdb quite well. I am uncertain whether or not you can set breakpoints within the code though.

I assume you're using cmake? For C/C++, cquery does completion (which I got working, but honestly didn't like and turned off. There are these two plugins for cmake:



It would be fairly quick to put something in your vimrc to pop open a small split on the side, run a build command, and show an output. You could also probably pop open a terminal (new vim has the :term command) and maybe script that? If not cmake, it shouldn't be too difficult to replace cmake with something else. I've always found I can get better results from vim that more exactly what I want, but I've got to kind of want it and be willing to write some script to do it. The results are better, but there's more up-front investment.

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.

Why not just run `:term` followed by full gdb? Doesn't seem like it's worth implementing a whole other interface.

That doesn't enable the same marking of break points and other features you typically get from IDEs. In GDB you can see multiple lines and split your screen, so I wouldn't use :term (I'll split with tmux). But other things that IDE debuggers have are like a file list (nerd tree) and display works better (off to the side). GDB technically has all these things, but it isn't formatted nicely. I use vim to be fast and efficient (and vim plugins for IDEs SUCK, plus are bloated).

Do people just not use debuggers around here?

Fair enough; I do like the visual breakpoint interface. Honestly, that's one thing MSVC does really well: the debugger. Just curious to see why that didn't work for you. I'm assuming it's viable to implement this, I guess no one yet has.

It looks like there is a debugger in the newest vim. A little playing around with it shows some nice features. Still not quite what I want, but better than nothing.

Not within Vim, but I'd recommend running "gdb --tui" in your terminal (not inside Vim), and then flipping it into "vi mode": https://sourceware.org/gdb/onlinedocs/gdb/Readline-vi-Mode.h...

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.

> But I'm not sure what `M-C-j` is


Basically hold down the 'Alt' and 'Control' keys and then press 'j'.

If you don't want to have to toggle it every time you launch gdb, then you can create a ~/.inputrc file with the following contents:

    $if gdb
      set editing-mode vi
If you want vi bindings in every program that uses GNU Readline (Bash, etc.), then you can leave off the $if/$endif part.

For colors - GDB 8.3 added source code syntax highlighting, but it was just released this year and may not be the version on your Linux distribution.

gdb has colored output since v8.3, including syntax hightlighting.

Regarding vim, have you tried the termdebug plugin that ships with vim?

    :help termdebug-starting

Vim >= 8.1 has a built-in debugger interface called termdebug: https://www.dannyadam.com/blog/2019/05/debugging-in-vim/

I haven't used it, but it might meet your needs.

If neovim is an option to you, nvim-gdb is excellent. It also supports pdb for python debugging.


These days, I found the best IDE like experience coding C to be CMake generating the compile_commands.json and a handcrafted .clang-format. Both used as input to clangd via VSCode’s vscode-clangd plug-in.

Works pretty great!

Any good recommendations for logging? (Embedded environment with SD card)

spdlog is well regarded (I use it and I like it). It's configurable enough that should be able to use it in an embedded environment; you can control the flush policy and use it in either sync or async mode. You can use method calls or macros (if you want to completely removed things like DEBUG and TRACE calls in production). You can use it as either header-only or traditional library.

Really it's a great library.

Had so much trouble trying to get a C++ project cmake setup with opencv 4 in macOS. Until I found conan.

I have been use to package managers from other languages.

+1 for Conan, my favourite feature is using the deploy generator to gather my dynamically linked libs to deploy with my binaries - so powerful, and generally breaks the coupling between the distribution (and which packages it provides) and my application.

I've tried to use Conan, but was unable to use 'openssl', because it was named 'OpenSSL'. So, then I wanted to use HarfBuzz library, but Conan was unable to find one. Later I've found out HarfBuzz exists, but it's named 'harfbuzz'.

The 'case sensitivity' bug was created in 2017, is still open. I think it's connected to a case sensitivity flag in filesystem which is used in the system. So, since 99% of Linux systems use case-sensitive fs, it's not usable on Linux.

... 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)?

Nix is the best C++ package manager at the moment, once you climb the slight learning curve.

CoC + ccls + nvim is the fastest, smoothest C++ dev experience I have had yet. (I use CLion exclusively for debugging)

No mention of the only build system worth using: Bazel. Fail. No valgrind/callgrid/cachegrind either. No google-perftools. No Linux `perf`. No mention of YouCompleteMe. This is not a comprehensive list, to say the least. I use all of these tools pretty much all the time working with C++.

On emacs use: M-x gud-gdb

"M-x gdb" gives you a more IDE-like experience with more features: https://www.gnu.org/software/emacs/manual/html_node/emacs/GD...

i bought clion then realized it is really only for cmake-based c++ projects, yes you can bend others to kind of work but it sucks, i hope clion can work with autoconf/makefile/cmake/whatever and stay neutral to build tools soon.

still looking for some online c++11 course these days, udemy had none that looking good.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact