Best aspects of C

Re:Best aspects of C by johannes1234321 on Tuesday November 17, 2020 @02:57PM (#25128845)

Thee is an important difference between C++ and Rust: C++ tried to play the game by being a superset of C (even started as a precompiler to C) and many C programs are valid C++ (well, many C programs aren't valid C, let's ignore that here) Thus C++ always carries C's legacy along so that there is always the C way of doing things, and then the C++ way of doing things. Rust cut that part of, while allowing to call C functions.

[ Parent | on HN ]

Re:Best aspects of C by einpoklum on Tuesday November 17, 2020 @03:50PM (#25129635)

Also, Rust has taken the path of backwards-incompatible changes, while the C++ language designers/committee go to great lengths to maintain near-perfect backwards compatibility with older versions of the language (and refuse to allow for ABI-breaking changes! Grr!)

[ Parent | on HN ]

Re:Best aspects of C by MaxBarraclough on Tuesday November 17, 2020 @04:04PM (#25129810)

> and refuse to allow for ABI-breaking changes!

Did you mean API? The C++ ABI situation is famously unstable.

[ Parent | on HN ]

Re:Best aspects of C by einpoklum on Tuesday November 17, 2020 @05:17PM (#25130667)

No, I did mean the ABI. See this paper, for example, about the argument:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p186...

"there is a non-trivial amount of performance that we cannot recoup because of ABI concerns. We cannot remove runtime overhead involved in passing unique_ptr by value, nor can we change std::hash or class layout for unordered_map , without forcing a recompile everywhere etc. etc."

[ Parent | on HN ]

Re:Best aspects of C by MaxBarraclough on Tuesday November 17, 2020 @05:23PM (#25130723)

Thanks for the link, interesting skim-read.

I thought passing template instantiations over an ABI boundary was generally discouraged and thought to be asking for trouble. I guess this isn't really at odds with what the paper is saying though - it could still be that a lot of people are doing so.

edit Thinking about Hyrum's Law, [0] mentioned in the article, makes me think perhaps there was an upside to Java firmly refusing to support any kind of ahead-of-time compilation for so long. It fully closed the door on any funny business distributing Java packages as brittle precompiled native-code blobs, ensuring the bytecode format remained the way that Java packages were distributed, presumably avoiding some fraction of the issues C++ now faces.

Of course, Java still has backward-compatibility obligations, but unlike in C++ they align pretty well with API compatibility, if I understand things correctly.

[0] https://www.hyrumslaw.com/

[ Parent | on HN ]

Re:Best aspects of C by int_19h on Thursday November 19, 2020 @03:36PM (#25154039)

There's nothing particular about template instantiations that makes them any different from any other object. The only problem with using them at ABI (or rather, linker) boundary is that instantiations have to be explicit - but that's what "extern template" is for.

[ Parent | on HN ]

Re:Best aspects of C by jcelerier on Tuesday November 17, 2020 @06:16PM (#25131203)

> The C++ ABI situation is famously unstable.

is a couple ABI breaks for std::string between C++98 and C++20 that unstable ? You can write code that uses std::string today and links against a .so built a long time ago (modulo compiler bugs of course, thus the various versions here: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Optio...). GCC & libstdc++ go to great lengths to preserve ABI compatibility.

[ Parent | on HN ]