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

71–80 of 100 posts

Re: Dropping support for old C++ standards

#71

Post by humanrebar »

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…

> We should be clear... in these large organizations... HEAD is always broken.

I don't know about all of them, but a lot of them have CI set up such that HEAD is never broken for some definition of broken.

Practically speaking it's basically impossible to fuzz test everything, but typically builds and reasonably fast and reliable tests are run before HEAD includes new changes.

Being efficient about supporting this workflow is more or less what monorepo build systems like bazel, buck, and pants were designed for.

Re: Dropping support for old C++ standards

#72

Post by humanrebar »

saagarjha wrote: post #61
pjmlp wrote: post #56

Earlier quoted context omitted.

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.

Most people looking for modern C++ are choosing one of three compilers. Most code mostly works.

Most people are using more than one compiler at the same time. For instance, MSVC plus some combination of clang-based tooling for static analysis and/or local dev.

And folks using a full stack of MS tooling are probably using the EDG compiler as an implementation detail for IntelliSense support.

Re: Dropping support for old C++ standards

#73

Post by humanrebar »

Narann wrote: post #66
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…

I'm not sure to understand: What "living at the head" means?

There are various ways to implement this, but to simplify the explanation, assume that versioning always works via lockfiles [1]. Lockfiles record all of the versions of all of the projects that contributed to some experiment or release. They're common in various language-specific ecosystems like gem, pip, cargo, and so on.

Assuming you have these lockfiles, you have the typical option, which would be to make a lockfile for each released entity, record it for later reproduction, and update it at least every release.

The "live at head" approach would be to instead have a main shared lockfile for every project in the company in a recorded sequence. All projects pick a version of that lockfile to release from. Practically speaking, all projects probably just take the latest version (the head) of that lockfile and everyone works hard to make sure that lockfile always works for everyone.

The main advantage here is pretty straightforward combinatorial math. Maintaining and validating unique combinations of dependencies for every release in a codebase is NP-silly, whereas sharing one set of dependencies across as many applications as possible isn't easy but it has a much nicer cost curve. In theory at least, but a lot of large organizations claim practice backs the theory up as well.

[1] Versioning doesn't have to work this way. Putting all code into one big source repository (vendoring) has the same effect.

Re: Dropping support for old C++ standards

#74

Post by HelloNurse »

mihaaly wrote: post #65
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…

> it has the advantage of being broken for everyone, tested by everyone, fixed by everyone The correct word here is not advantage but risk. While making a product you rely on something, some other product/package. Thousand of them if you are unlucky. If you have 1000 packages to collaborate in the development/testing/QA of them you will do nothing else! Also try building a house on a concrete that is still maturing,…

It depends on the context: in a React Native project you are almost guaranteed to realize the hard way that you depend on abandonware that won't ever support the latest React Native version or the latest smartphone operating systems, while in a Python project you are almost guaranteed to attempt to use something that is hard to install or compile, or just doesn't work on your slightly divergent platform (e.g. Windows).

Re: Dropping support for old C++ standards

#75

Post by humanrebar »

pabs3 wrote: post #38
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…

Does that include the head of GCC/LLVM?

"Head" at Google means "head of the google3 monorepo". I gather they stay close to upstream for GCC and LLVM. Alsonote that they aren't necessarily matching upstream offerings with respect to C++ standards flags. They aren't necessarily matching upstream for various third-party libraries either. "Head" for third-party libraries means "the latest vendored in from upstream", which doesn't have to be particularly new.

In contrast, those third-party projects like boost would probably consider the latest commit on their HEADs of their git repos to be "head". So "live at head" is a statement about how each organization should version its dependencies. It doesn't really make sense in the context of boost maintainers deciding their support surfaces since they have all the "heads" to worry about, inherently -- all the organizations using boost libraries.

Re: Dropping support for old C++ standards

#76

Post by humanrebar »

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?

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 below is addressing that proposal.

---

Practically, no. You could certainly create a new namespace C++ names: functions, classes, global variables, and so on.

But there are other "names" in C++ that don't respect C++ namespaces: C symbols, included headers, preprocessor names, and library names (as in `-lfoobar` on a link line). You'd need to make up new names for all of these and possibly a few more things to make a full duplicate of a library.

Now, if you managed to do all that, there are still problems to watch out for. For instance, it's common for projects to assume that global or static names in a C++ namespace can be treated as unique process-wide values in a running program. As in, `mynamespace::important_mutex` might guard access to specific hardware, so having a `mynamespace2::important_mutex` also thinking it has the same job would be bad.

And if that wasn't a problem, you still have to think about types that show up in APIs. How will downstream code be written when you have a `boost::string_ref` and a `boost2::string_ref` in the same codebase? Which `string_ref` do you use where? Can you efficiently convert from one to the other as needed? Will that require changing a lot of downstream code?

Re: Dropping support for old C++ standards

#77

Post by skywal_l »

jokoon wrote: post #70

I really like what Herb Sutter is doing with cpp2/cppfront: it's a new language that translates to C++, by defaulting to C++ good practices and "avoiding 95% of C++ pitfalls". Please watch its presentation on it. It's designed to interact with C++. Backward compatibility is good to have, but C++ needs for alternatives that allow it to drop support for old things, because the language needs to evolve and backward comp…

Have a look at Circle from Sean Baxter [0]. It's pretty impressive.

[0]: https://github.com/seanbaxter/circle/blob/master/new-circle/...

Re: Dropping support for old C++ standards

#78

Post by LaLaLand122 »

pjmlp wrote: post #42
LaLaLand122 wrote: post #33

Earlier quoted context omitted.

Exactly! People point out RedHat provide newer compilers (and newer patched C++ standard libraries depending on the default one!) and he says "It's not us, it's our customers. And no, they won't use any compiler which isn't the system default". Either you only use the system defaults, and that includes the old Boost included with RHEL, or you don't. I guess he includes a private Boost copy as part of his project. Wel…

Customer is king, when one needs them, it is the one trying to make money that needs to accommodate. When not, others will.

The customer

- "Wants" "stable", i.e. the default gcc

- Doesn't care what Boost version is used

- Pays the developer

The developer

- Wants the latest toolchain

- Wants the latest Boost

- Makes money

The developer

- Accepts using an old compiler because Boost keeps compatibility with it

- Does not pay Boost developers for it

There is no single entity that wants old compiler (other than to satisfy others) and new Boost.

Re: Dropping support for old C++ standards

#79

Post by galangalalgol »

lanstin wrote: post #54
hamandcheese wrote: post #26

Earlier quoted context omitted.

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.

But it can insert itself in your pipeline so that anyone who depends on you is also infected. We have already seen CI worms for thevlack of a better term. One was briefly spreading in crates.io early last year as part of the "crate depression" thing.

Re: Dropping support for old C++ standards

#80

Post by galangalalgol »

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.

Yeah everyone seemed to have atarted talking about living at head in general. My concerns about living at head for c++ is primarily compiler and static analysis support. I like my pipeline to build for clang and gcc and run unit tests in both clang tidy modernize, gcov, cppcheck asan etc.

By the time all of that is supported for a language release we are on the next one, and I value that pipelene more than the changes currently being made.

Post reply on HN