CPP, C++ Pain Points

From about 1700 results, 31.35% considered this as major pain, 40.85% as minor pain, and 27.80% as not a significant issue.

I am surprised that this topic is rated that high as a pain point.

For personal projects, GitHub or GitLab CI has brought enormous help in the last few years. If there is no problem with dependencies, which is handled in the following topics, setting up a CI/CD pipeline is a matter of minutes once you manage the basics. There is some learning curve, but the basics are relatively easy to learn. It is doable in an afternoon or two.

And for professional projects, I expect a dedicated team or person to do the CI/CD setup. I agree that dealing with that CI/CD situation, or team, can be a pain point, and often is. But that is maybe not what the question is about?

From about 1700 results, 43.34% considered this as major pain, 37.56% as minor pain, and 19.10% as not a significant issue.

Build times can indeed be an issue. There are multiple reasons. The project may be big. The lack of dependency management may lead to a huge mono repo, and caching does not work properly. Or purely configured virus scanners slow down build processes.

C++ tries to address some aspects of the problem with the instruction of modules in C++20. And some tools can help to speed up the build process, like ccache or distcc. But they also put you quickly in need of a dedicated team or person to manage them. Incremental builds solve for developers a lot, so the problem is not that bad. Except you work on the one header everyone uses 😉.

But for deliveries you want or must build from scratch, preparing third-party libraries, or building your Yocto base system, build times can be a real issue. And I guess these are the topics where the feedback comes from.

From about 1700 results, 47.37% considered this as major pain, 35.09% as minor pain, and 17.54% as not a significant issue.

Nearly 50% of the respondents consider managing dependencies as a major pain point. That is a lot.

Managing dependencies is indeed a problem. Not everyone is Google who can say, let’s don’t use OpenSSL and develop our own crypto library. Most projects will have to take what is available.

The problem starts already with build systems. There are no standard build systems for C and C++ libraries. Chances are, if you use 5 dependencies, you have to deal with 3 different build systems.

Once you have built the dependencies, you need to figure out how to make them available to the projects you want to use them. That works differently over platforms, target systems, and of course, for the build system used.

If you work on Windows and deliver for Windows, or on Linux and deliver for Linux, or an embedded Linux, you might be lucky and find a solution that works for you. That might be the case for people who consider the topic as no issue, or a minor pain.

If you have to do that for multiple platforms, you have a decent sized problem. And that does not even mention the problem of keeping track of security issues in your dependencies, and reacting to them.

And it continues, different compiler settings, debug and release builds, sanitizer builds, …​ all that needs to be managed.

Companies often do not have that on the radar. They want to see features realized, not spending time on managing dependencies. That features can often not come to life without managing dependencies is something that needs to be learned.

There are C++ dependency managers that claim to have solved the problem. And for some kinds of projects, they might be a solution. But they are not a silver bullet. They often add another layer of complexity and fall short in advanced scenarios where you build for multiple platforms with multiple compilers in multiple configurations and need to deliver to multiple teams so they can work.

Vcpkg and Conan work nicely in scenarios but have their limits. Tools like spack are not platform independent. Other approaches like CPM or FetchContent transform projects into mono repos, introducing other problems. And we have build system like meson or xmake, which come with their own dependency management solutions. On top of that, every dependency you use might have its own idea of how it deals with its dependencies and how it wants to get built. And once you solved all of that, if you need to deliver to multiple teams with different requirements, tools, and cultures, you enter another problem domain.

In short, managing dependencies has the potential to be a mess. And for some projects, it can quickly become an expensive mess.

So yes, I see managing dependencies in C++ as a major pain point. That was my answer to the survey. And it seems I am not alone in that point of view.