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

51–60 of 100 posts

Re: Dropping support for old C++ standards

#51

Post by joeld42 »

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?

Yeah i've had to do this with other dependencies (which we didn't have source for) including an old or broken version of the same library we needed. It's a bit of a pain to get everything in a namespace, and of course the bloat for the executable.

Even more fun when two dependencies both use different versions of the same lib.

I much prefer bringing everything into our source tree up front and doing the build ourselves rather than just linking a prebuilt lib but sometimes you don't have that option.

Re: Dropping support for old C++ standards

#52

Post by pjmlp »

Gigachad wrote: post #49
pjmlp wrote: post #45

Earlier quoted context omitted.

Last time I read about it, PlayStation SDK was on C++14, and they aren't the only platform in such state.

Unless Sony is financially contributing, I don’t see why a 3rd party would care that the PlayStation sdk is running legacy software.

Right, same can be said regarding current state of ISO support on free beer compilers, now limping behind VC++.

So taken to extreme, some Boost libraries might become VC++ only, for authors that decide to go fully on ISO C++ 20 and 23.

Re: Dropping support for old C++ standards

#53

Post by pjmlp »

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?

Who knows, there are many definitions of embedded.

Re: Dropping support for old C++ standards

#54

Post by lanstin »

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?

Run your CI in an allow listed only network and only allow access to either your private, security scanned, mirror or else keep well trusted things. Even if a bitcoin miner gets into the stack it can’t send the results to the source so it is less dangerous.

Re: Dropping support for old C++ standards

#55

Post by jamesfinlayson »

olliej wrote: post #28
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?

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?

I've never tried it but I read that a use for namespaces was talking a library and wrapping all the #include statements in namespace library {} or whatever to avoid one stepping on another. Depending on how the library is written (and if it's all in source form rather than .lib files) I guess it should work?

Re: Dropping support for old C++ standards

#56

Post by pjmlp »

pclmulqdq wrote: post #34
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.

C++ doesn't have the same kind of head as you are thinking. The standard gets pretty well-tested before being standardized as the most recent ("head") version. C++'s head gets more testing than most libraries ever get for any version.

Anyone with proper experience on C++ ecosystem knows this isn't the case.

Not only is ISO full of DR and things that probably shouldn't have been standardized in first place (thankfully some of them were latter removed), there is plethora of compilers to chose from.

Re: Dropping support for old C++ standards

#57

Post by pjmlp »

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…

In a similar vein, here it is mostly .NET Framework, and now we finally moved into Java 11.

With .NET 8 and Java 21 around the corner,....

It feels like living the Python 2 / 3 transition.

The wonderfull enterprise land.

Re: Dropping support for old C++ standards

#58

Post by gpderetta »

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?

That can be made to work. It is not pleasant or easy but it is technically possible to compile different parts of the code with different compilers and library versions and link them together.

The vast majority of the time it is just not worth it.

Re: Dropping support for old C++ standards

#59

Post by friendzis »

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…

This somehow reminds me of the argument around git-flow. It's a decent reasoning, however, the whole idea is based on having a single, bleeding edge version. Basically a SaaS.

A lot of companies/products do not work that way. Some have physical products out there that have to be updated, some have on-premises deployments, some sell user software of which there are multiple versions under support. Each of these live versions have to have their own source branches and dependency trees. A single `:latest` can render future bugfixes unbuildable.

Re: Dropping support for old C++ standards

#60

Post by gpderetta »

dataflow wrote: post #19
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?

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

You can expose a C++ interface, as long as all the types used are ABI stable (i.e std library types bit not boost types).

I have used many libraries that use boost internally (often in a custom namespace) but do not expose it on the API

Post reply on HN