Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dropping support for old C++ standards

lists.boost.org

Post reply on HN
Print view View original

21–30 of 100 posts

Re: Dropping support for old C++ standards

#21

Post by lbrandy »

bb88 wrote: post #13
VHRanger wrote: post #2

Titus Winters leading the google abseil library eventually came to the conclusion that the only sane way to manage a large scale C++ system is to "live at head" [1] -- that is, libraries should live at the head production version of their dependencies. This is patchworked around in more easygoing languages with dependency management systems, docker containers, etc. etc. but if you can enforce living at head from the…

That's fine as long as HEAD doesn't break things. I can no longer count the number of times we had an issue with a "supposedly" minor release that ended up breaking major things in our stack. Most of them were things that could have been detected using unit tests or some kind of basic regression testing. If you have a 1000 dependency packages, and at any point in time 0.1% of them are broken, then odds are you will a…

We should be clear... in these large organizations... HEAD is always broken. But it has the advantage of being broken for everyone, tested by everyone, fixed by everyone, and thus fixed for everyone. And this usually makes it far better than the alternatives.

Having 1000 dependencies with versions pinned means you are living alone and will run into fewer issues, but when they do come, they will be absolute nightmares that no one else is dealing with and no one can help with. And one day you'll have to do the game of begging someone else to upgrade their version of a downstream thing to fix the issue, and they won't, so you'll try to get the other group to backport the fix in their thing to the version you can't upgrade off. And they won't. etc. etc.

Full versioning is the worst of all approaches, IMO, for large complex interconnected codebases (especially ones that are many-to-many from libraries to output binaries) but it absolutely is sometimes the only viable one (for example, the entire open-source-ecosystem is a giant(er) version of this problem, and in that space, versioning is the only thing that I can imagine working).

Re: Dropping support for old C++ standards

#22

Post by TillE »

pornel wrote: post #15
AnthonyMouse wrote: post #4

Earlier quoted context omitted.

You can often have multiple dependencies. Library A uses Boost and requires an older version of GCC. Library B uses Boost and requires the newer version of Boost. You want to use libraries A and B in the same project, what now?

If you've chosen to use an ancient OS, with an obsolete compiler, you should not expect to be able to use anything new with it. Just keep the mothballed code as-is. Maybe find an equally old version of the library B if you must. Or pay RedHat to backport the library B to the old Boost for you :)

Also you can almost certainly use a newer compiler to target old OSes.

The real problem is when you have a big pile of ancient, unmaintained code that uses long-deprecated stuff. At that point, no, you really can't expect to seamlessly interoperate with new code.

Re: Dropping support for old C++ standards

#23

Post by galangalalgol »

lbrandy wrote: post #21
bb88 wrote: post #13

Earlier quoted context omitted.

That's fine as long as HEAD doesn't break things. I can no longer count the number of times we had an issue with a "supposedly" minor release that ended up breaking major things in our stack. Most of them were things that could have been detected using unit tests or some kind of basic regression testing. If you have a 1000 dependency packages, and at any point in time 0.1% of them are broken, then odds are you will a…

We should be clear... in these large organizations... HEAD is always broken. But it has the advantage of being broken for everyone, tested by everyone, fixed by everyone, and thus fixed for everyone. And this usually makes it far better than the alternatives. Having 1000 dependencies with versions pinned means you are living alone and will run into fewer issues, but when they do come, they will be absolute nightmares…

Supply chain attacks are worsened if everyone lives at the head. Staying far enough behind that some brave (and hopefully small) project discovers the compromise of a repo for some dependency five layers deep before you re-pin to a new version is probably the best mitigation short of some permissions based model like Austral is working on.

Re: Dropping support for old C++ standards

#24

Post by VHRanger »

galangalalgol wrote: post #23
lbrandy wrote: post #21

Earlier quoted context omitted.

We should be clear... in these large organizations... HEAD is always broken. But it has the advantage of being broken for everyone, tested by everyone, fixed by everyone, and thus fixed for everyone. And this usually makes it far better than the alternatives. Having 1000 dependencies with versions pinned means you are living alone and will run into fewer issues, but when they do come, they will be absolute nightmares…

Supply chain attacks are worsened if everyone lives at the head. Staying far enough behind that some brave (and hopefully small) project discovers the compromise of a repo for some dependency five layers deep before you re-pin to a new version is probably the best mitigation short of some permissions based model like Austral is working on.

Supply chain attacks only matter for libraries that can make their own network call, or libraries that directly touch unsanitized web input however?

Re: Dropping support for old C++ standards

#25

Post by AnthonyMouse »

jcelerier wrote: post #16
AnthonyMouse wrote: post #4

Earlier quoted context omitted.

You can often have multiple dependencies. Library A uses Boost and requires an older version of GCC. Library B uses Boost and requires the newer version of Boost. You want to use libraries A and B in the same project, what now?

> Library B uses Boost and requires the newer version of Boost. but the same question applies to Library B: if your regulations state that you can't update your compiler version past the default distro one, why can you bring in some random recent libraries that are definitely not part of the distro since they depend on a Boost version that is more recent than the one your distro provides? Of course this all very stup…

It's not a question of regulations. You either need to use the old library with the new compiler or the new library with the old compiler.

But the old one is crufty and barely maintained and nobody wants to touch it, and the new one is only using one feature of the new version of Boost, so it's a easier to blacklist the newer version of Boost than to overhaul all the old code. But is that what we wanted to cause?

Moreover, with widely used core libraries like this, that sort of thing happens repeatedly, and now the downstream users have to do work they wouldn't have had to do if compatibility was maintained. At scale probably a lot more work than it would be for the widely used thing to maintain compatibility. That seems bad.

Re: Dropping support for old C++ standards

#26

Post by hamandcheese »

VHRanger wrote: post #24
galangalalgol wrote: post #23

Earlier quoted context omitted.

Supply chain attacks are worsened if everyone lives at the head. Staying far enough behind that some brave (and hopefully small) project discovers the compromise of a repo for some dependency five layers deep before you re-pin to a new version is probably the best mitigation short of some permissions based model like Austral is working on.

Supply chain attacks only matter for libraries that can make their own network call, or libraries that directly touch unsanitized web input however?

How does one restrict network access for a library?

Re: Dropping support for old C++ standards

#27

Post by bawolff »

VHRanger wrote: post #24
galangalalgol wrote: post #23

Earlier quoted context omitted.

Supply chain attacks are worsened if everyone lives at the head. Staying far enough behind that some brave (and hopefully small) project discovers the compromise of a repo for some dependency five layers deep before you re-pin to a new version is probably the best mitigation short of some permissions based model like Austral is working on.

Supply chain attacks only matter for libraries that can make their own network call, or libraries that directly touch unsanitized web input however?

Supply chain attacks matter anytime you need to trust the code being run. Which is usually always.

Most libraries have network access, but even if they didn't, supply chain attacks could be relavent (but probably less generic)

Re: Dropping support for old C++ standards

#28

Post by olliej »

jamesfinlayson wrote: post #12
AnthonyMouse wrote: post #4

Earlier quoted context omitted.

You can often have multiple dependencies. Library A uses Boost and requires an older version of GCC. Library B uses Boost and requires the newer version of Boost. You want to use libraries A and B in the same project, what now?

I've never worked in a big C++ code base or had that issue but could you library B in a namespace?

Do you mean have library B built with its own separate copy of the new version?

e.g. You have Library A using LibDependency-1.0.0 and Library B using a separately compiled LibDependency-2.0.0? Then have MyAwesomeApp linking LibA and LibB and just accept the binary+memory overhead of two copies (albeit different versions) of LibDependency?

Re: Dropping support for old C++ standards

#29

Post by galangalalgol »

hamandcheese wrote: post #26
VHRanger wrote: post #24

Earlier quoted context omitted.

Supply chain attacks only matter for libraries that can make their own network call, or libraries that directly touch unsanitized web input however?

How does one restrict network access for a library?

That was my thinking. In Austral that is a thing, but in c++ not so much. And if you are building the dependency from source, which is pretty common, the common build systems are all Turing complete themselves so they can take over your pipeline and do bad things.

Re: Dropping support for old C++ standards

#30

Post by mastax »

fbdab103 wrote: post #7
VHRanger wrote: post #2

Titus Winters leading the google abseil library eventually came to the conclusion that the only sane way to manage a large scale C++ system is to "live at head" [1] -- that is, libraries should live at the head production version of their dependencies. This is patchworked around in more easygoing languages with dependency management systems, docker containers, etc. etc. but if you can enforce living at head from the…

Doesn't that require you have a Google sized army of engineers and tooling to stay in sync?

Or you just checkout the version that does what you need and leave it alone.
Post reply on HN