4 ms·

> but most C++ engines are very long lived, going back decades While true the engines are also staffed and can absolutely keep up with changes. They regularly

> but most C++ engines are very long lived, going back decades While true the engines are also staffed and can absolutely keep up with changes. They regularly are tasked with new toolchains, platforms, OSes, and APIs to leverage already. This would just be more of the same, and if you look at the goals of the paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html#goals http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213... That lines up pretty damn well to what game engines want as well. > One of the main reasons to stick with C++ (and C) is that the investment you put in the code you're writing right now, no matter how fugly it is, will be there and keep working in the future. I think you should read the actual paper instead. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213... The things they talk about actually abandoning are things like byte sizes other than 8-bits or source code in file systems that don’t support file extensions or nested directories. Chances are any existing C++ codebase is already not compatible with such systems that they want to more formally deprecate/abandon in the first place.

theamk 7y ago
You are talking about section 1.8. I agree, it is not that scary. What is scary, however, are sections 2.1 and 2.2. They contain stuff like this: > Our experience is that providing broad ABI-level stability for high-level constructs is a significant and permanent burden on their design. It becomes an impediment to evolution, which is one of our stated goals. This does not name it, but doesn't this refers to all those discussions about changing internal representation of std::string, std::vector and so on? This does sound pretty scary. Once you have separate classes for "C++23 std::string" and "older std::string", you can no longer link together files built with different versions.. and this means you lose a lot past compatibility.
- kllrnohj 7y ago
  > you can no longer link together files built with different versions True but this is already something that isn't really "supported" broadly. Some standard libraries work hard to keep that working, but others tend not to, and nobody knows if it's supposed to work reliably or not. And support for this binary compatibility also varies across platforms, like I don't think Microsoft bothers since you're supposed to always bundle a specific version of the runtime with your binary. Single-version prebuilt libraries become more of a problem, but are those that widespread vs. source-based libraries? But I think the broader point here that the paper is really pushing is for the committee to actually make a statement on things like this instead of their historically vague "it sort of works but we're not saying it will or indeed saying anything at all"

theamk 7y ago

You are talking about section 1.8. I agree, it is not that scary. What is scary, however, are sections 2.1 and 2.2. They contain stuff like this: > Our experience is that providing broad ABI-level stability for high-level constructs is a significant and permanent burden on their design. It becomes an impediment to evolution, which is one of our stated goals. This does not name it, but doesn't this refers to all those discussions about changing internal representation of std::string, std::vector and so on? This does sound pretty scary. Once you have separate classes for "C++23 std::string" and "older std::string", you can no longer link together files built with different versions.. and this means you lose a lot past compatibility.

kllrnohj 7y ago
> you can no longer link together files built with different versions True but this is already something that isn't really "supported" broadly. Some standard libraries work hard to keep that working, but others tend not to, and nobody knows if it's supposed to work reliably or not. And support for this binary compatibility also varies across platforms, like I don't think Microsoft bothers since you're supposed to always bundle a specific version of the runtime with your binary. Single-version prebuilt libraries become more of a problem, but are those that widespread vs. source-based libraries? But I think the broader point here that the paper is really pushing is for the committee to actually make a statement on things like this instead of their historically vague "it sort of works but we're not saying it will or indeed saying anything at all"