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

91–100 of 100 posts

Re: Dropping support for old C++ standards

#91

Post by dataflow »

jcelerier wrote: post #87
dataflow wrote: post #17

Earlier quoted context omitted.

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

Yes I realize. I didn't claim otherwise. The original post was about dropping support for older C++ standards. I was pointing out that Abseil's proposition is quite a bit more heavy handed than Boost's.

Re: Dropping support for old C++ standards

#92

Post by JohnFen »

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…

This. Years of experience has taught me to avoid "living at HEAD". HEAD has undiscovered problems. Better be be just a bit behind that.

Re: Dropping support for old C++ standards

#93

Post by mzs »

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…

this? https://youtu.be/ELeZAKCN4tY

Re: Dropping support for old C++ standards

#94

Post by maldev »

So I mainly do Kernel or super low level systems code. And i've never had an issue targeting the latest C++ standard. Given I don't use the C++ STL and only use the language features. The backwards compatability is amazing and i've never had a single issue in my career with swapping forward. So good on them. I also do Windows work though, so maybe it's different on Linux.

Re: Dropping support for old C++ standards

#95

Post by doodlesdev »

pjmlp wrote: post #52
Gigachad wrote: post #49

Earlier quoted context omitted.

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.

What do you mean free beer compilers are limping behind VC++? The situation (as always) seems exactly the contrary. [0]

[0]: https://en.cppreference.com/w/cpp/compiler_support/23

Re: Dropping support for old C++ standards

#96

Post by pjmlp »

doodlesdev wrote: post #95
pjmlp wrote: post #52

Earlier quoted context omitted.

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.

What do you mean free beer compilers are limping behind VC++? The situation (as always) seems exactly the contrary. [0] [0]: https://en.cppreference.com/w/cpp/compiler_support/23

They would do better to finalise their ongoing issues with C++20 features support, instead of spending valuable resources on C++23.

See their C++20 support versus VC++.

Re: Dropping support for old C++ standards

#97

Post by jokoon »

mzs wrote: post #93
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…

this? https://youtu.be/ELeZAKCN4tY

yes

Re: Dropping support for old C++ standards

#99

Post by nlewycky »

fooker wrote: post #67
nlewycky wrote: post #40

Earlier quoted context omitted.

It does. Google mirrors every commit to LLVM in their monorepo, builds and tests the whole monorepo with a fresh Clang nightly, and (ideally) one of those Clang nightlies is released as the new stable compiler for all users of the monorepo every week. This helps keep Google at HEAD and helps keeps LLVM upstream stable.

I thought llvm lived in /third_party, and internal projects usually target specific LLVM versions, not the current open source trunk.

As far as I know, there was only ever one version of LLVM at a time in the monorepo. It's possible things changed after I left (either the compiler team or Google).

Each upstream commit didn't land directly into the monorepo, instead there was a long lived branch, and on the compiler team there was a buildcop rotation responsible for doing an integrate from that branch into //third_party/llvm. This included running the tests (and fixing any problems) for any other software that depends on LLVM as well as building an unstable crosstool and doing some basic smoke tests on that. Taking that crosstool through testing and to stable crosstool was the responsibility of a different buildcop rotation, using a special compiler team tool for testing the testing crosstool nightly, then to release to stable we used the ordinary presubmits, but for all projects at once, making its testing as similar as possible to any normal code change.

Re: Dropping support for old C++ standards

#100

Post by pabs3 »

nlewycky wrote: post #99
fooker wrote: post #67

Earlier quoted context omitted.

I thought llvm lived in /third_party, and internal projects usually target specific LLVM versions, not the current open source trunk.

As far as I know, there was only ever one version of LLVM at a time in the monorepo. It's possible things changed after I left (either the compiler team or Google). Each upstream commit didn't land directly into the monorepo, instead there was a long lived branch, and on the compiler team there was a buildcop rotation responsible for doing an integrate from that branch into //third_party/llvm. This included running t…

How does Google deal with other projects' embedded code copies? ie some other project embeds a random old snapshot of LLVM, when you import that project into the monorepo do you end up with two copies of LLVM, or do you strip the old copy and port the codebase to the current LLVM in the monorepo?
Post reply on HN