3 ms·

There's a lot there. Let's get the technical part done first. Historically after you create object files the linker doesn't care what c++ standard the source

There's a lot there. Let's get the technical part done first. Historically after you create object files the linker doesn't care what c++ standard the source was. So you could carefully combine different standards. I guess I have to establish I'm talking about the GNU toolchain here and that it's been a few years since I've done this. I'll try it again when I get home, maybe that all blows up now. Now about the other parts. I totally agree with you. However we're dealing with humans and if they see incrementing numbers then the word "upgrade" and "deprecated" and "unsupported", maybe even "inefficient" gets bandied about just because we're using numbers. We have to go back to the core lesson of Perl 6, it shouldn't have been called Perl 6 because it suggests a hierarchical comparison and relationship that isn't an accurate depiction of reality. I wish everyone was sincere and competent but there's a natural tenancy to act based on the context that a structure affords. Churchill stated it as "we shape our buildings and afterwards our buildings shape us". So if the standards are better understood as siblings of each other then we need to brand them accordingly and not through a structure that suggests hierarchy, quantity of features, and degrees of relevance. Thanks for your response. I enjoyed reading it

tialaramex 4y ago
> Historically after you create object files the linker doesn't care what c++ standard the source was. Mechanically this is true, but just because we can link object files together doesn't mean the resulting program makes sense. Suppose I have an object file I made with GCC's copy-on-write C++ 98 strings and then I linked that to an object file I made with GCC's modern C++ 11 short string optimised strings. If these objects think they're talking about the same string then the resulting executable is nonsense and will probably crash or misbehave badly. It might be helpful to think of WG21's attitude to compatibility as occupying a sort of "strategic ambiguity" akin to the US stance on Taiwan. For example when it comes to ABI changes, the committee voted that they shouldn't happen... yet. Not that they will happen within some horizon, but nor that they won't happen.
- kristopolous 4y ago
  Maybe you have a deeper understanding of the GNU GCC toolchain than I do but I'm able to link together languages with far more dramatic divergences than that. For instance, Go and C : https://go.dev/doc/install/gccgo https://go.dev/doc/install/gccgo (it's pretty far down, let me quote: "The name of Go functions accessed from C is subject to change. At present the name of a Go function that does not have a receiver is prefix.package.Functionname. The prefix is set by the -fgo-prefix option used when the package is compiled; if the option is not used, the default is go. To call the function from C you must set the name using a GCC extension.") I just had a small C program call a fmt.Println from a go library at my console to confirm. extern the declaration in C to match the calling convention of go, compile them to objects, then ld with the appropriate libs. Of course you can break the friendship they can have, this is programming, that's easy to do. This can be demonstrated with different C++ versions as well. The C/Go example was meant to show how extremely different languages can interact when you're careful enough in your build process.
- gpderetta 4y ago
  When gcc broke the string ABI they made sure that code that uses one version wouldn't link with code that uses the other one.
  - account42 4y ago
    Only for the most common case. Try e.g. struct muhahaha { std::string member; }; library.cpp98: oops(muhahaha param); program.cpp20: int main() { oops({"this will link just fine and there will be nothing warning you about your fate"}); }

tialaramex 4y ago

> Historically after you create object files the linker doesn't care what c++ standard the source was. Mechanically this is true, but just because we can link object files together doesn't mean the resulting program makes sense. Suppose I have an object file I made with GCC's copy-on-write C++ 98 strings and then I linked that to an object file I made with GCC's modern C++ 11 short string optimised strings. If these objects think they're talking about the same string then the resulting executable is nonsense and will probably crash or misbehave badly. It might be helpful to think of WG21's attitude to compatibility as occupying a sort of "strategic ambiguity" akin to the US stance on Taiwan. For example when it comes to ABI changes, the committee voted that they shouldn't happen... yet. Not that they will happen within some horizon, but nor that they won't happen.

kristopolous 4y ago
Maybe you have a deeper understanding of the GNU GCC toolchain than I do but I'm able to link together languages with far more dramatic divergences than that. For instance, Go and C : https://go.dev/doc/install/gccgo https://go.dev/doc/install/gccgo (it's pretty far down, let me quote: "The name of Go functions accessed from C is subject to change. At present the name of a Go function that does not have a receiver is prefix.package.Functionname. The prefix is set by the -fgo-prefix option used when the package is compiled; if the option is not used, the default is go. To call the function from C you must set the name using a GCC extension.") I just had a small C program call a fmt.Println from a go library at my console to confirm. extern the declaration in C to match the calling convention of go, compile them to objects, then ld with the appropriate libs. Of course you can break the friendship they can have, this is programming, that's easy to do. This can be demonstrated with different C++ versions as well. The C/Go example was meant to show how extremely different languages can interact when you're careful enough in your build process.
gpderetta 4y ago
When gcc broke the string ABI they made sure that code that uses one version wouldn't link with code that uses the other one.
- account42 4y ago
  Only for the most common case. Try e.g. struct muhahaha { std::string member; }; library.cpp98: oops(muhahaha param); program.cpp20: int main() { oops({"this will link just fine and there will be nothing warning you about your fate"}); }