Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Carbon’s most exciting feature is its calling convention

foonathan.net

Post reply on HN
Print view View original

181–190 of 223 posts

Re: Carbon’s most exciting feature is its calling convention

#181

Post by spacechild1 »

wizofaus wrote: post #176
olliej wrote: post #170

Earlier quoted context omitted.

[edit due to the above edit I just saw: wasn't me, I didn't see what you said as being inherently bad and so deserving of downvoting, otherwise I wouldn't have bothered replying :-/] That sounds like what you're saying is that gcc or clang fail to conform to the platform ABI, which is a compiler bug. If a compiler wishes to ignore platform ABI, it doesn't make the ABI not a thing. But if you are comparing ABI compati…

Surely if GCC's vtable layout isn't compatible with that used by MSVC then COM couldn't possibly work? Not much of the rest of the Win32 API would care though, other than DirectX and possibly a few more modern additions I'm not aware of.

Luckily, GCC's vtable layout is compatible with COM, but that's because COM puts certain restrictions on how you write C++ classes. Most notably, you must not define a virtual destructor and you must not use overloaded virtual methods. It just so happens that the main difference between MSVC and GCC/Clang concern the implementation of virtual destructors (the former uses 1 entry, the latter uses 2 entries) and the vtable ordering of overloaded virtual methods. This means that COM is not affected!

Re: Carbon’s most exciting feature is its calling convention

#182

Post by zasdffaa »

chrisseaton wrote: post #175
zasdffaa wrote: post #174

Earlier quoted context omitted.

PEGs are ambiguous, just that that's resolved by rule ordering. From the wiki page ( https://en.wikipedia.org/wiki/Parsing_expression_grammar#Amb... ) "A PEG parser generator will resolve unintended ambiguities earliest-match-first, which may be arbitrary and lead to surprising parses"

> PEGs are ambiguous You're misunderstanding the rhetoric there - they're unambiguous by construction because they deterministically resolve earliest-match-first - a well-defined rule. It's impossible to write an ambiguous PEG. Any grammar you write in a PEG is never ambiguous. A grammar you write using a CFG can be ambiguous. As your own link says "Unlike CFGs, PEGs cannot be ambiguous". Or read Ford's original pape…

You're the expert, thanks for the pointers!

Re: Carbon’s most exciting feature is its calling convention

#183

Post by spacechild1 »

olliej wrote: post #170
spacechild1 wrote: post #148

Earlier quoted context omitted.

The C++ standard does not define an ABI. > I can take any C++ compiler, and I can compile any C++ library, and then I can take some other compiler and compile some other piece of C++ that calls my library, and it will Just Work. This is most definitely not true. It just happens that clang and gcc are mostly compatible, but MSVC and clang/gcc is not! For example, vtables are implemented differently and therefore virtu…

[edit due to the above edit I just saw: wasn't me, I didn't see what you said as being inherently bad and so deserving of downvoting, otherwise I wouldn't have bothered replying :-/] That sounds like what you're saying is that gcc or clang fail to conform to the platform ABI, which is a compiler bug. If a compiler wishes to ignore platform ABI, it doesn't make the ABI not a thing. But if you are comparing ABI compati…

Thanks for your reply!

First off, I work mainly in C++ (Windows, Linux, macOS and some embedded) and I don't hate the language. I really wished that C++ had a well-specified ABI, but the sad reality is that it doesn't.

> if the code generated by a compiler targeting a given platform, does not match the ABI used by that platform, the problem is the compiler is generating broken code.

The compiler only has to correctly implement the C++ standard. The standard does not specify things like calling conventions, struct padding, implementation of virtual functions, so the compiler is free to do anything it wants. (Whether that is a good idea is another topic.)

> No, vtables are implemented incorrectly by the compiler.

The C++ standard does not even mandate that virtual functions are implemented with vtables.

> The ABI for vtables is specified for every non-trivial platform. The ABI for argument parameter ordering is specified for every platform. The ABI for struct layout and struct padding is specified for every platform.

AFAIK, Microsoft does not officially specify a C++ ABI at all (correct me if I'm wrong!) The only thing that comes close is COM - which can be implemented with a restricted subset of C++, but is really language-agnostic.

> Importantly, claiming that it's a sign that C++ doesn't have an ABI, or that ABI isn't stable, is simply incorrect. The fact that it exists as a name we can reference is an indication that the ABI matters enough that it is specified.

'thiscall' is not part of the C++ standard, it is a calling convention invented by Microsoft. The C++ standard does not talk about calling conventions at all.

> Mercifully in the consumer 64-bit every compiler seems to have essentially gravitated to the itanium ABI

This is true on Linux, but Microsoft specifies its own 64-bit calling convention (https://docs.microsoft.com/en-us/cpp/build/x64-calling-conve...) and leaves other parts of the C++ ABI unspecified.

Generally, you are right that some platforms, like Linux, have a de-facto C++ ABI, but that is not the same as saying that C++ itself has a well-defined ABI - which is simply not true.

Your initial claim was that binaries compiled with different compilers are always compatible (apart from possible library ABI mismatches). We both may wish this were true, but it is false in the general case (and specifically on Windows).

Re: Carbon’s most exciting feature is its calling convention

#184

Post by [deleted] »

olliej wrote: post #178
spacechild1 wrote: post #171

Earlier quoted context omitted.

This happens to work on Linux where the two major compilers (gcc and clang) are (mostly?) compatible. Windows is a different story: C++ code build with MSCV is generally not compatible with GCC/clang and vice versa, the most notable differences being vtable layout and default 32-bit calling conventions.

[edit: and I just realized I replied to you elsewhere. sigh. keeping it classy :-/] Windows is a different platform, so comparing it to linux isn't relevant, any more than saying I can't run the code I compiled for sparc on a ppc Mac.

[deleted]

Re: Carbon’s most exciting feature is its calling convention

#185

Post by t6jvcereio »

> Passing things by const T& is always good, right? After all, you’re avoiding a copy!

I find the tone strange. I understand that the author doesn't believe the statement. But I've never met anyone for whom performance matters and believes this. So, who's the audience here?

Re: Carbon’s most exciting feature is its calling convention

#186

Post by TillE »

humanrebar wrote: post #127
bbkane wrote: post #6

I really think the most exciting feature of Carbon (indeed, it's justification for existence) is its backwards compatibility with C++, followed closely by it's more modern and flexible governance structure. Even the docs in the repo say you should avoid Carbon unless you have lots of C++ code you need to interact with.

To be fair, the compatibility is a design goal, not a complete feature as such. Even C++ struggles to be compatible with C++. I expect Carbon to have at least as hard a time with it, especially given the "bazaar" that is the C++ build and packaging ecosystem. I also expect that Carbon will have a hard time tracking C++ as it evolves. It could freeze C++ feature development? Or it could target an old and aging C++ sta…

The compatibility target is C++17, which I imagine was chosen primarily to avoid the complexity of modules in C++20. They're also excluding non-trivial preprocessor macros, and saying that you'll probably have to write a bit of glue code in some unusual situations.

It's a very realistic take on C++ interop, but still well beyond anything offered by other languages.

Re: Carbon’s most exciting feature is its calling convention

#187

Post by titzer »

Carbon is what happens when you have a ton of experience programming in C++ and nothing else whatsoever. It is absolutely littered with joyful declarations of "hooray, we fixed this thing in C++", when in reality it absolutely bathed in the utter fictions of C++ and has no perspective on the entire universe of other things that we could base languages on.

I give it a -1 on innovation, it's so obviously stuck in a cul-de-sac in the design space that I see no hope for it. "We'll get around to memory safety eventually". Riiight.

That said, I'm glad they at least made the leap to, "Hey, we could actually use something other than C++?"

Re: Carbon’s most exciting feature is its calling convention

#188

Post by formerly_proven »

TillE wrote: post #186
humanrebar wrote: post #127

Earlier quoted context omitted.

To be fair, the compatibility is a design goal, not a complete feature as such. Even C++ struggles to be compatible with C++. I expect Carbon to have at least as hard a time with it, especially given the "bazaar" that is the C++ build and packaging ecosystem. I also expect that Carbon will have a hard time tracking C++ as it evolves. It could freeze C++ feature development? Or it could target an old and aging C++ sta…

The compatibility target is C++17, which I imagine was chosen primarily to avoid the complexity of modules in C++20. They're also excluding non-trivial preprocessor macros, and saying that you'll probably have to write a bit of glue code in some unusual situations. It's a very realistic take on C++ interop, but still well beyond anything offered by other languages.

If the goal of Carbon is considered to be an off-ramp for Google's C++ projects, then Carbon does not have to evolve with C++. Google can just say "we use up to C++17 and Carbon" for these projects.

Re: Carbon’s most exciting feature is its calling convention

#189

Post by [deleted] »

olliej wrote: post #170
spacechild1 wrote: post #148

Earlier quoted context omitted.

The C++ standard does not define an ABI. > I can take any C++ compiler, and I can compile any C++ library, and then I can take some other compiler and compile some other piece of C++ that calls my library, and it will Just Work. This is most definitely not true. It just happens that clang and gcc are mostly compatible, but MSVC and clang/gcc is not! For example, vtables are implemented differently and therefore virtu…

[edit due to the above edit I just saw: wasn't me, I didn't see what you said as being inherently bad and so deserving of downvoting, otherwise I wouldn't have bothered replying :-/] That sounds like what you're saying is that gcc or clang fail to conform to the platform ABI, which is a compiler bug. If a compiler wishes to ignore platform ABI, it doesn't make the ABI not a thing. But if you are comparing ABI compati…

[deleted]

Re: Carbon’s most exciting feature is its calling convention

#190

Post by golemotron »

chubs wrote: post #119

I searched on several sites to find out what their memory management strategy is but couldn’t figure it out. GC? ARC? Whatever Rust does? Would love to see where this fits. Exciting to see a neat new language though! Also my second favourite feature of rust and swift is Enums with associated values, I can’t see any info on this but I saw a blog mention they have it.

> I searched on several sites to find out what their memory management strategy is but couldn’t figure it out.

Carbon might be shy about its footprint.

Post reply on HN