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.

▲

umanwizard 7 months ago | parent | next [-]

I'm stoked to hear they're on C++17 now.

When I contributed to LibreOffice (GSoC 2012) they were still on C++03 !

▲

badmintonbaseba 7 months ago | parent [-]

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.

▲

umanwizard 7 months ago | parent [-]

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.

	▲	bluGill 7 months ago \| parent [-]
		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.

▲

einpoklum 7 months ago | parent | prev [-]

> 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.

	▲	chris_wot 7 months ago \| parent [-]
		You are referring to the UNO API. The internal code is most definitely not stuck in "pre-98 C++ code".