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

81–90 of 100 posts

Re: Dropping support for old C++ standards

#81

Post by gpderetta »

humanrebar wrote: post #76
jamesfinlayson wrote: post #12

Earlier quoted context omitted.

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

EDIT: I'm not sure the below answers the question as asked, but it does clarify why A and B probably want to use the same version of boost. In practice A and B would each have their own namespaces in C++ codebases, but that wouldn't resolve the tension if each wanted a different version of boost. One approach to resolve that tension is to figure out how to have two versions of boost in the same dependency tree. The b…

The only sane solution is, for libraries that need wide backward and forward compat, is to only expose abi/api stable types in your interface, but it doesn't. You can use still use boost internally, but make the symbols private and/or in a private namespace.

At the limit a stale interface is a C interface, but it doesn't have to be. GCC std types are fairly stable, and Qt manages a rich interface while maintaining robust ABI compatibility. It is hard work, and not always worth it of course.

Re: Dropping support for old C++ standards

#82

Post by humanrebar »

gpderetta wrote: post #81
humanrebar wrote: post #76

Earlier quoted context omitted.

EDIT: I'm not sure the below answers the question as asked, but it does clarify why A and B probably want to use the same version of boost. In practice A and B would each have their own namespaces in C++ codebases, but that wouldn't resolve the tension if each wanted a different version of boost. One approach to resolve that tension is to figure out how to have two versions of boost in the same dependency tree. The b…

The only sane solution is, for libraries that need wide backward and forward compat, is to only expose abi/api stable types in your interface, but it doesn't. You can use still use boost internally, but make the symbols private and/or in a private namespace. At the limit a stale interface is a C interface, but it doesn't have to be. GCC std types are fairly stable, and Qt manages a rich interface while maintaining ro…

Narrowing the interface helps, but the other "interface" is how the linker resolves names to specific addresses to code or data. The example I mention involving mutexes does not require those mutexes show up in public interfaces or necessarily "break" ABI guarantees. The mutexes don't even have to be used by the same source files! I guess you could consider it a library design flaw, but it's basically never mentioned as a design antipattern if it is one.

Note that it's not just mutexes. The same can happen with other kinds of "one per process" resources: memory pools, thread pools, connection pools, caches, registry objects, etc.

Re: Dropping support for old C++ standards

#83

Post by UncleMeat »

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…

You don’t just say “okay C++20 is released, swap the compiler flags and break everyone.”

But you do say “okay, C++20 is released, let’s fix all the build errors and deploy it company-wide.”

Re: Dropping support for old C++ standards

#84

Post by cardinalfang »

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?

We have used two boost versions built in different namespaces. Most of it works but there can be Fun if two now-independent versions of the same funtion use the same resource.

Re: Dropping support for old C++ standards

#85

Post by UncleMeat »

mastax wrote: post #30
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?

Or you just checkout the version that does what you need and leave it alone.

google3 has a one version rule. You can’t just check out the version of a dependency that does what you want.

Re: Dropping support for old C++ standards

#86

Post by [deleted] »

humanrebar wrote: post #82
gpderetta wrote: post #81

Earlier quoted context omitted.

The only sane solution is, for libraries that need wide backward and forward compat, is to only expose abi/api stable types in your interface, but it doesn't. You can use still use boost internally, but make the symbols private and/or in a private namespace. At the limit a stale interface is a C interface, but it doesn't have to be. GCC std types are fairly stable, and Qt manages a rich interface while maintaining ro…

Narrowing the interface helps, but the other "interface" is how the linker resolves names to specific addresses to code or data. The example I mention involving mutexes does not require those mutexes show up in public interfaces or necessarily "break" ABI guarantees. The mutexes don't even have to be used by the same source files! I guess you could consider it a library design flaw, but it's basically never mentioned…

[deleted]

Re: Dropping support for old C++ standards

#87

Post by jcelerier »

dataflow wrote: post #17
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.

It's not just the language standard, they build and deploy the latest clang HEAD every week or so

Re: Dropping support for old C++ standards

#88

Post by jcelerier »

doodlesdev wrote: post #48
pjmlp wrote: post #43

Earlier quoted context omitted.

As you can see by those tables, there are other compilers in the world, and those tables don't even include embedded platforms.

I don't think embedded platform code uses Boost though, right?

Modern embedded platforms like ESP stuff can run pretty much a full c++20 standard library and thus most of boost without issues

Re: Dropping support for old C++ standards

#89

Post by account42 »

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.

One big use case for Boost is to provide alternative implementation for standard containers and sometimes even language features that whatever toolchain you need to use doesn't have yet. Being bound to an ancient Boost version as well kind of limits the use you can get out of that.

Re: Dropping support for old C++ standards

#90

Post by vamega »

peapicker wrote: post #46
xvilka wrote: post #9

Should drop anything below C++14. Everyone who is not happy could always stay on older versions.

I’m living in a world that has to support a product which has many parts in C++ on Solaris, HP-UX, and OS/400 (in addition to Linux, AIX, and Windows). We can’t drop support yet for the AIX release that only support up to C++ 11 although they have a newer clang based compiler. HP-UX and Solaris native compilers only go to C++14. Those platforms have at least 5 years of enterprise support yet, but no new chipsets mean…

This reminds me of my time at Bloomberg. The C++ support from IBM and Oracle/Sun wasn’t nearly up to date, and without a large customer willing to foot the bill to improve the toolchains IBM and Oracle/Sun weren’t going to do the work.

There was a Linux migration project to move the company to Linux. I haven’t heard anything from people inside, but I’m willing to bet that there are still some stragglers that haven’t moved yet.

Post reply on HN