On Monday, 23 January 2023 09:19:07 PST Scott Bloom wrote: > One of the limiting factors in general, is we would prefer NOT to have 2 > compilers with very different c++ support. There have a been a number of " > C++11/14/17 etc" that have been partially implemented on one, and not on > the other. Unfortunately, NOT always protected by the "version switch". > > The biggest one that hit me, is std::make_unique which didn't exist on g++ > but did on windows. So if used, when you go build on linux, you have to > clean up your code. There have been some others through the years. > > So in general, we try to keep their abilities as close as possible,
Thank you Scott, but you've answered the inverse of my question. You're talking about the ability to write code given a compiler you can't move from and what one needs to do to keep that working. I am asking why people are staying with the older one, if the new one is available and shouldn't (in theory) produce a compatibility burden with already-compiled code. On Linux, people generally use the compiler that their Linux distribution offers and many of them don't upgrade to another GCC major version after the initial release (CentOS/RHEL with the devtoolset being a notable exception). This implies to us that if a Linux distribution from 2018 is still a valid development environment, then GCC 8 must work too. But on Windows and on macOS, the compiler updates are disconnected from the OS version. Hence the question: if you can install compiler version Y using the same mechanism you installed version X, why won't you? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest