3 ms·

The problem seems to be one of command line interface. In the C/C++ world, you specify the language version using a flag passed to the compiler. e.g. -std=c++9

by mantap 7y ago

The problem seems to be one of command line interface. In the C/C++ world, you specify the language version using a flag passed to the compiler. e.g. -std=c++98 In most other programming languages, you specify language version by installing multiple copies of the compiler/interpreter and running the corresponding version. The C/C++ way works fine if your language spec is updated once every 3 years. It does not work fine for anything much more frequent than that. Until recently C and C++ were popular enough that the other approach didn't need to be accommodated. Now it does.

chaosite 7y ago
I agree with the point you're making, but you're actually wrong about C/C++. It's true that C/C++ compilers usually have a flag that gates language features. However, you're still using the same libc not matter which standard you've picked. For example, there were some changes made to format strings in C99, like parsing hexadecimal numbers with scanf. If you have a C99 libc, you'll always get that behavior, even if you specified "-std=c89".
the_why_of_y 7y ago
It's similar in Rust, you specify the language edition with a line in Cargo.toml. https://doc.rust-lang.org/nightly/edition-guide/editions/creating-a-new-project.html https://doc.rust-lang.org/nightly/edition-guide/editions/cre...
- umanwizard 7y ago
  Rust language editions are not similar to C++ standard versions. Every new version of the Rust compiler brings changes to the language, so the language you're actually using depends on the tuple (compiler version, edition), not just on the edition.
  - the_why_of_y 7y ago
    Rust language editions are similar but not equivalent to C++ standard versions, because compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. But you are correct to point out that old Rust editions will get new language features if they do not break existing code. https://hacks.mozilla.org/2018/12/rust-2018-is-here/ https://hacks.mozilla.org/2018/12/rust-2018-is-here/ The release process claims that the changes in new Rust releases are purely additive and backward compatible; the only exception is soundness fixes, which I'd expect affect a negligible amount of code.
    - umanwizard 7y ago
      > compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. This is not at all similar to C++ standards, and the specific case being discussed in this post demonstrates exactly why! Barring bugs in implementations, developers could develop against whatever version of the compiler they like, and as long as it supports the same language version, distro or OS maintainers wouldn’t have to update theirs, and everything would work. I worked on an open-source project that targeted C++11. It could build on basically any Linux distro you can imagine, even ones with very old versions of GCC. (it didn’t support BSD, but for unrelated reasons). This is the point the Rust project seems to miss when harping on about backwards compatibility: forwards compatibility is just as important.
      - the_why_of_y 7y ago
        Okay, I see what you mean; I guess if I were a Rust programmer I'd solve that by using rustup to install a fixed Rust release for development. However the Firefox project has decided to always require the latest stable Rust release. https://news.ycombinator.com/item?id=22022834 https://news.ycombinator.com/item?id=22022834 In practice for C++ I've found it expedient to whitelist some subset of functionality from newer standards, because there's often useful features that already work in the major 3 compilers, but it'll be another 3 years until the last of the compilers adds the last obscure bits for full support of the new standard.

by mantap 7y ago

chaosite 7y ago

I agree with the point you're making, but you're actually wrong about C/C++. It's true that C/C++ compilers usually have a flag that gates language features. However, you're still using the same libc not matter which standard you've picked. For example, there were some changes made to format strings in C99, like parsing hexadecimal numbers with scanf. If you have a C99 libc, you'll always get that behavior, even if you specified "-std=c89".

the_why_of_y 7y ago

It's similar in Rust, you specify the language edition with a line in Cargo.toml. https://doc.rust-lang.org/nightly/edition-guide/editions/creating-a-new-project.html https://doc.rust-lang.org/nightly/edition-guide/editions/cre...

umanwizard 7y ago
Rust language editions are not similar to C++ standard versions. Every new version of the Rust compiler brings changes to the language, so the language you're actually using depends on the tuple (compiler version, edition), not just on the edition.
- the_why_of_y 7y ago
  Rust language editions are similar but not equivalent to C++ standard versions, because compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. But you are correct to point out that old Rust editions will get new language features if they do not break existing code. https://hacks.mozilla.org/2018/12/rust-2018-is-here/ https://hacks.mozilla.org/2018/12/rust-2018-is-here/ The release process claims that the changes in new Rust releases are purely additive and backward compatible; the only exception is soundness fixes, which I'd expect affect a negligible amount of code.
  - umanwizard 7y ago
    > compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. This is not at all similar to C++ standards, and the specific case being discussed in this post demonstrates exactly why! Barring bugs in implementations, developers could develop against whatever version of the compiler they like, and as long as it supports the same language version, distro or OS maintainers wouldn’t have to update theirs, and everything would work. I worked on an open-source project that targeted C++11. It could build on basically any Linux distro you can imagine, even ones with very old versions of GCC. (it didn’t support BSD, but for unrelated reasons). This is the point the Rust project seems to miss when harping on about backwards compatibility: forwards compatibility is just as important.
    - the_why_of_y 7y ago
      Okay, I see what you mean; I guess if I were a Rust programmer I'd solve that by using rustup to install a fixed Rust release for development. However the Firefox project has decided to always require the latest stable Rust release. https://news.ycombinator.com/item?id=22022834 https://news.ycombinator.com/item?id=22022834 In practice for C++ I've found it expedient to whitelist some subset of functionality from newer standards, because there's often useful features that already work in the major 3 compilers, but it'll be another 3 years until the last of the compilers adds the last obscure bits for full support of the new standard.