this post was submitted on 06 Jan 2024
44 points (95.8% liked)
Programming
17453 readers
128 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I read through the better part of a linked thread: https://forum.dlang.org/thread/ncbawciyybdksecurmsc@forum.dlang.org?page=1. And wow, as a C++ user, I'm not sure if I should feel blessed about how stable and backwards-compatible the language is, or that D users must be bonkers to put up with the breakages. Using C++ both professionally and for hobby projects, in the last 5 or so years I can remember encountering exactly 1 (gcc) compiler bug. There was a simple workaround + someone else had already reported it so with the next minor update the bug was fixed. And the code that triggered it was a nested CRTP spawn of hell so I didn't blame the compiler from borking on it in the first place, it would've been better for everyone had it never compiled :p
Upgrading a major C++ compiler version was never free in my experience, but even when working in a codebase with ~2M LOC the upgrade (e.g. 14 -> 17) was something that could be prepared in a set of feature branches by one person over the span of one, maybe two weeks. That's for fixing compile errors, I don't remember if we had issues with runtime errors due to an upgrade, but if we did it must've been minor because I remember the transition to 17 was pretty smooth. Note that 14 -> 17 requires changing the requested C++ version for the project, which is different from upgrading the actual compiler, i.e. you can do the latter without the former and your code should not require any changes.
That greatly depends on your project, what dependencies it has, and what's involved in the migration. For example, I recall a previous project I worked on that experienced a considerable amount of non-trivial issues when upgrading to C++14 due to unforeseeable curve balls. One of them was caused by a third-party dependency toggling
constexpr
versions of its member functions only on C++14, which caused a bunch of obscure linker errors as old symbols were no longer available.