I think he has this about right. The project I contribute to (and no, I'm not a massive contributor) is LibreOffice and it is a C++ codebase. It has a decent build system that is easy for anyone to run out of the box. It uses modern C++17+ code, and though it has a lot of legacy code, it is being constantly modified by people like Noel Grandin via clang plugins (along with a lot of manual effort).
This code was originally developed in the late 1980s.
A good packaging tool would have helped a lot.
I'm stoked to hear they're on C++17 now.
When I contributed to LibreOffice (GSoC 2012) they were still on C++03 !
Well, can't really blame them in 2012. Especially that C++11 did bring an ABI break. Looks like they keep it fresh, although C++17 is getting a bit dated. Migration from C++17 to 20 or even 23 is probably a breeze though compared to migrating 03 to 11.
IIRC it wasn't just the ABI break that was a problem, it was the fact that they wanted to build on systems that didn't have a C++11-compliant compiler available yet.
In 2012 that was reasonable. In 2024 that would be unreasonable, but they are not stuck on C++03 in 2024. C++17 today with serious plans to force upgrade to C++20 in the near future is a reasonable place to be today.
> It uses modern C++17+ code
Ha ha ha, that's funny. It uses pre-98 C++ code, that's set in stone because of extension/UNO APIs. Yes, you can use C++17 in a bunch of places, but not for the basic structures, classes, idioms etc.
And - that's coming from a huge LibreOffice supporter. Speak at conventions, got the T-shirts, everything.
You are referring to the UNO API. The internal code is most definitely not stuck in "pre-98 C++ code".