4 ms·

In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being inclu

In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being included into new projects sooner or later (and everyone and their dog has their own bespoke string handling libraries). Copy/pasting large chunks of code from elsewhere is also rampant. I'm not so sure C/C++ solves the actual problem. Only sweeps it under a carpet so it's much less visible.

achierius 1y ago
It definitely does solve one problem. Like it or not, you can't be hit by supply chain attacks if you don't have a supply chain.
- dgfitz 1y ago
  I mirror all deps locally and only build from the mirror. It isn’t an issue. C/C++ is my dayjob
  - procaryote 1y ago
    at some point you could mirror a supply chain attack... xz was a pretty long game and only found by accident for example
    - dgfitz 1y ago
      I’m sure I will.
  - josephg 1y ago
    This runs the risk of shipping C/C++ libraries with known vulnerabilities. How do you keep track of that? At least with npm / cargo / etc, updating dependencies is a single command away.
    - dgfitz 1y ago
      Pull, update, build?
      - josephg 1y ago
        How do you even know a dependency has an open vulnerability?
        dgfitz 1y ago
        Conversely, how do you know when a dependency doesn’t have a vulnerability?
Frieren 1y ago
> every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc You are right. But my conclusion is different. If it is a stable and people have been there for a while then developers know that code as well as the rest. So, when something fails they know how to fix it. Bringing generic libraries may create long callstacks of very generic code (usually templates) that is very difficult to debug while adding a lot of functionality that is never used. Bringing a new library into the code base need to be a though decision.
ryandrake 1y ago
> In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being included into new projects sooner or later Same here. And a lot of those homegrown functions, utilities and classes are actually already available, and better implemented, in the C++ Standard Library. Every C++ place I've worked had its own homegrown String class, and it was always, ALWAYS worse in all ways than std::string. Maddening. And you could never make a good business case to switch over to sanity. The homegrown functions had tendrils everywhere and many homegrown classes relied on each other, so your refactor would end up touching every file in the source tree. Nobody is going to approve that risky project. Once you start down the path of rolling your own standard library stuff, the cancer spreads through your whole codebase and becomes permanent.
- rileymat2 1y ago
  Although I like std::string for somethings becomes a little tricky with cross platform work that involves both linux and windows. It also can be tricky with unicode and lengths.

achierius 1y ago

It definitely does solve one problem. Like it or not, you can't be hit by supply chain attacks if you don't have a supply chain.

dgfitz 1y ago
I mirror all deps locally and only build from the mirror. It isn’t an issue. C/C++ is my dayjob
- procaryote 1y ago
  at some point you could mirror a supply chain attack... xz was a pretty long game and only found by accident for example
  - dgfitz 1y ago
    I’m sure I will.
- josephg 1y ago
  This runs the risk of shipping C/C++ libraries with known vulnerabilities. How do you keep track of that? At least with npm / cargo / etc, updating dependencies is a single command away.
  - dgfitz 1y ago
    Pull, update, build?
    - josephg 1y ago
      How do you even know a dependency has an open vulnerability?
      - dgfitz 1y ago
        Conversely, how do you know when a dependency doesn’t have a vulnerability?

Frieren 1y ago

> every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc You are right. But my conclusion is different. If it is a stable and people have been there for a while then developers know that code as well as the rest. So, when something fails they know how to fix it. Bringing generic libraries may create long callstacks of very generic code (usually templates) that is very difficult to debug while adding a lot of functionality that is never used. Bringing a new library into the code base need to be a though decision.

ryandrake 1y ago

> In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being included into new projects sooner or later Same here. And a lot of those homegrown functions, utilities and classes are actually already available, and better implemented, in the C++ Standard Library. Every C++ place I've worked had its own homegrown String class, and it was always, ALWAYS worse in all ways than std::string. Maddening. And you could never make a good business case to switch over to sanity. The homegrown functions had tendrils everywhere and many homegrown classes relied on each other, so your refactor would end up touching every file in the source tree. Nobody is going to approve that risky project. Once you start down the path of rolling your own standard library stuff, the cancer spreads through your whole codebase and becomes permanent.

rileymat2 1y ago
Although I like std::string for somethings becomes a little tricky with cross platform work that involves both linux and windows. It also can be tricky with unicode and lengths.