Dropping support for old C++ standards • Hacker News Board

Re: Dropping support for old C++ standards

#11

Post by bluGill » Wed, Mar 08, 2023, 3:10 AM UTC

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 works for google web where they can upgrade everything at will. When you work in embedded upgrades can cost millions of dollars since someone needs to go to remote locations to run the upgrade.

Re: Dropping support for old C++ standards

#12

Post by jamesfinlayson » Wed, Mar 08, 2023, 3:11 AM UTC

AnthonyMouse wrote: post #4

mappu wrote: post #3

I'm surprised to see "GCC as shipped by RHEL 7" used as an argument downthread. If you need to use an older GCC then you can equally well use an older Boost.

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?

Re: Dropping support for old C++ standards

#13

Post by bb88 » Wed, Mar 08, 2023, 3:12 AM UTC

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 always have something broken.

Re: Dropping support for old C++ standards

#14

Post by leroy-is-here » Wed, Mar 08, 2023, 3:12 AM UTC

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…

is "living at the head" constantly pulling each update or version-controlled source of every library?

Re: Dropping support for old C++ standards

#15

Post by pornel » Wed, Mar 08, 2023, 3:15 AM UTC

AnthonyMouse wrote: post #4

mappu wrote: post #3

I'm surprised to see "GCC as shipped by RHEL 7" used as an argument downthread. If you need to use an older GCC then you can equally well use an older Boost.

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 :)

Re: Dropping support for old C++ standards

#16

Post by jcelerier » Wed, Mar 08, 2023, 3:15 AM UTC

AnthonyMouse wrote: post #4

mappu wrote: post #3

I'm surprised to see "GCC as shipped by RHEL 7" used as an argument downthread. If you need to use an older GCC then you can equally well use an older Boost.

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 stupid when you can install GCC 11 and compile in C++20 mode on RH 7 with the official devtoolsets...

But the core problem is as always to tie compilers to linux distros, like a C++ compiler version is relevant in any way to your operating system's stability...

Re: Dropping support for old C++ standards

#17

Post by dataflow » Wed, Mar 08, 2023, 3:19 AM UTC

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…

Note that "large scale" is pulling a heavy weight here.

Also, living at the HEAD of your language standard is quite a bit different from living at the HEAD of other dependencies.

Re: Dropping support for old C++ standards

#18

Post by jcelerier » Wed, Mar 08, 2023, 3:21 AM UTC

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?

I do it pretty much on my own for https://ossia.io ; it takes me roughly a day every other month to update my mac, linux and windows SDKs to the new LLVM / Qt / FFMPEG / {... other large dependency I use ...}.

Definitely not the end of the world. Said SDKs & build scripts are available here: https://github.com/ossia/sdk for anyone interested (I'll be honest though: the scripts are a mess!)

Re: Dropping support for old C++ standards

#19

Post by dataflow » Wed, Mar 08, 2023, 3:24 AM UTC

AnthonyMouse wrote: post #4

mappu wrote: post #3

I'm surprised to see "GCC as shipped by RHEL 7" used as an argument downthread. If you need to use an older GCC then you can equally well use an older Boost.

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?

> what now?

Build each one as a separate shared library and wrap each one with a C interface?

Re: Dropping support for old C++ standards

#20

Post by dataflow » Wed, Mar 08, 2023, 3:33 AM UTC

jcelerier wrote: post #18

fbdab103 wrote: post #7

Earlier quoted context omitted.

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

I do it pretty much on my own for https://ossia.io ; it takes me roughly a day every other month to update my mac, linux and windows SDKs to the new LLVM / Qt / FFMPEG / {... other large dependency I use ...}. Definitely not the end of the world. Said SDKs & build scripts are available here: https://github.com/ossia/sdk for anyone interested (I'll be honest though: the scripts are a mess!)

1 day for... ~500 kLOC, it seems. Which is pretty good I think, but larger codebases would have a lot more to deal with -- not just more dependencies, but also more breakages per dependency.