4 ms·

C++ with vcpkg is a bliss to work with. Depending on which triplet you configure, it can build either static or dynamic libraries. And CMake will take care of

C++ with vcpkg is a bliss to work with. Depending on which triplet you configure, it can build either static or dynamic libraries. And CMake will take care of transitive dependencies for static libraries for you. Just declare it as a PUBLIC link dependency and all downstream projects will link against it automatically. What the article fails to mention is that dynamic libraries can also be an attack vector. Users can replace a .so with a variant that does something you don't expect. For statically linked apps, it is much easier to ensure your code has not been tampered with. Also, the CMake integration in CLion is great. "How did things get this bad?" What are you talking about? It's a great time to be a C++ programmer! The tools are finally stable and powerful (and not either MSVC or ICC) and there's lots of good libraries to choose from.

klodolph 6y ago
> And CMake will take care of transitive dependencies for static libraries for you. This assumes that everything is correctly expressed as part of the CMake system. If you stick everything in one build system, of course it’s going to be fine. > Users can replace a .so with a variant that does something you don't expect. For statically linked apps, it is much easier to ensure your code has not been tampered with. If your users are able to replace libraries, it’s reasonable to assume that they can mess with the code inside your application too. It is generally hard to ensure your code hasn’t been tampered with, unless you’re in control of the hardware.
- bobthebuilders 6y ago
  I think it's more of an accidental or unintentional threat they're talking about than a malicious one.
accountofme 6y ago
Mind you it has been a few years since I have worked in C++ professionally. I understand why you might like it. But in my opinion, it is a dumpster fire. My friend who is a music producer has a saying: "You can't polish a turd." With C++ and CMake, this is apt.
DDSDev 6y ago
> "How did things get this bad?" What are you talking about? It's a great time to be a C++ programmer! I think like most things C++, the modern solutions are great, but a large number of programmers are still stuck with legacy systems that they cannot or will not change for a variety of reasons. I don't think there is a magic bullet for people experiencing these problems in legacy codebases - it's either update to a more modern build system and use libraries within that ecosystem, or learn how to work around the potential issues outlined in the original article.

klodolph 6y ago

> And CMake will take care of transitive dependencies for static libraries for you. This assumes that everything is correctly expressed as part of the CMake system. If you stick everything in one build system, of course it’s going to be fine. > Users can replace a .so with a variant that does something you don't expect. For statically linked apps, it is much easier to ensure your code has not been tampered with. If your users are able to replace libraries, it’s reasonable to assume that they can mess with the code inside your application too. It is generally hard to ensure your code hasn’t been tampered with, unless you’re in control of the hardware.

bobthebuilders 6y ago
I think it's more of an accidental or unintentional threat they're talking about than a malicious one.

accountofme 6y ago

Mind you it has been a few years since I have worked in C++ professionally. I understand why you might like it. But in my opinion, it is a dumpster fire. My friend who is a music producer has a saying: "You can't polish a turd." With C++ and CMake, this is apt.

DDSDev 6y ago

> "How did things get this bad?" What are you talking about? It's a great time to be a C++ programmer! I think like most things C++, the modern solutions are great, but a large number of programmers are still stuck with legacy systems that they cannot or will not change for a variety of reasons. I don't think there is a magic bullet for people experiencing these problems in legacy codebases - it's either update to a more modern build system and use libraries within that ecosystem, or learn how to work around the potential issues outlined in the original article.