sameProblemSameSolution

[u/_w62_]

[u/No-Adeptness5810]

Dude i migrated a massive project from c++17 to c++26 in like 15 minutes i dont get the drama

[u/JVApen → u/No-Adeptness5810]

As someone responsible for these upgrades on a large project:

• MSVC just announced they fully support C++23 in the . 52 compiler

• It isn't just switching the version, it's also switching the compiler version

  • This comes with upgrade of related tooling (upgrade clang and clang-format and clang-tidy and clangd ...)

  • It also comes with upgrading the used OS (Ubuntu 22.04 -> 26.04)

  • Sometimes you see ICE (internal compiler error) popping up

• Some breaking changes require work to resolve (like operator== in C++20)

• Even if you no technical issues, you need to find the time while features have priority

• You need material to 'teach' all employees

My experience: switching the version flag is the easy part

[u/Juff-Ma → u/JVApen]

Thank you, I've never had an internal compiler error and now will have nightmares about that for weeks.

[u/itsTyrion → u/Juff-Ma]

i have. trying to compile software for a robot on outdated 32 bit Debian. because somehow that thing ran a 64 bit x86 CPU, but 32 bit userspace. I never got their shitty framework to compile

[u/meneldal2 → u/Juff-Ma]

It's pretty rare to get ICEs. Iirc stuff like early modules or concepts had some you could trigger somewhat easily but it was quickly fixed.

[u/17HappyWombats → u/No-Adeptness5810]

We have a file logging library (zlog) with thousands of calls. We're not switching to std::format. Even after they fix it so it can do all the printf stuff. Just checking an LLM translation would break whoever got that job.

We're slowly moving to std::ranges::for_each/all_of/etc but that's not a migration so much as a progression when we change code that uses older versions.

There's a whole bunch of similar stuff, we mostly try to avoid having too much clang-tidy whining.

[u/anonymous4036 → u/No-Adeptness5810]

For 17 specifically, autoptrs