Live data from Hacker News

Carbon’s most exciting feature is its calling convention

foonathan.net

201–210 of 223 posts

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

#201

Earlier quoted context omitted.

But why not use an empty base class instead? That seems both more idiomatic and simpler. And since C++ supports multiple inheritance, there's no limit to how many empty base classes you could have.

Using an empty base class is idiomatic C++ for solving the problem comex is talking about (marker types) although it has some pretty annoying consequences. Whether it's "simpler" probably depends on whether to you "simpler" means, "how I'm used to in C++". But it doesn't have any bearing on the problem I was talking about, if you were to instantiate your empty class it has non-zero size. C++ just doesn't have ZSTs.

Ok, I misunderstood the thread a bit and was only commenting on the marker issue. I do thing that a type-level marker is "simpler" in a more general sense than checking whether a struct has a particular field, even if that field takes up no space in the struct.

Now, related to ZSTs, I think the main reason why C++ doesn't have this is that C++ really doesn't have any good support for constant values. Sure, you can mark something `const` but that rarely means too much - specifically, it can never add any new semantics to a type, it only removes some options.

One consequence of this is your example - a `const vector` can't be a simple counter of how many T are in the vector even if the T type has a single possible value: the language can't really use the fact that the array is `const` to change its layout.

An even worse consequence is that a `const vector * const` (a const pointer to a const vector of T) is not covariant (it can't be initialized with a const pointer to a const vector of a subtype of T), even though it should be: the language just won't use the fact that it is `const` in this way.

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

#202
post #56

Earlier quoted context omitted.

I may be overlooking something, but I don’t see a realistic use case for having multiple empty tuples without an address. If you have those, I don’t see any way to discriminate between them. If so, why would you ever want to have more than one of a given type? Is there some template code that might accidentally try to create them?

Rust `Set ` is implemented as `Map `. Go is similar, but you have to do it manually. Zero-sized types mainly have use in generics (so yes-ish by templates, but not accidental).

Still, why would you ever have multiple, if there’s no way to discriminate between them because you can’t mutate them or obtain their address?

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

#203
post #178

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.

The point is: C++ libraries compiled for Windows with MSVC are not ABI compatible with C++ libraries compiled for Windows by GCC or clang.

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

#204
post #48

Earlier quoted context omitted.

I have been burned many times in the past by "the compiler is allowed to optimise something away". You write your code assuming such an optimisation will happen, and for some reason, the compiler decides not to apply the optimisation. Perhaps the wind was blowing in the wrong direction, or it was in a bad mood, or you forgot to specify -fvisiblitly=hidden. The exciting part here is that it happens by default, and the…

I don't think that fvisibility=hidden on its own is sufficient, it does not allow the compiler to break the call abi as the function could still be called from another .o (which will only know the mangled name of the original function). You need fvisibility=internal (or maybe fno-semantic-interposition but I'm not sure if it's enough).

I think you just need LTO if you want full optimization without regards for the ABI constraints

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

#205
I realize this is unrelated to the blog post but it is related to Carbon… If you are creating an off-ramp language from C++ wouldn’t you keep the syntax as close to C++ as possible? The syntax looks like it would be more familiar to a Rust developer than a C++ developer.

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

#206
post #186

Earlier quoted context omitted.

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.

Yeah, but there will probably be a window in which that offramp is generally interesting. If the worldwide C++ codebase moves along, carbon becomes less accessible as a viable choice.

Ironically, Google (googletest, gRPC, etc.) has been more agressive than most in dropping support for older C++ standards.

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

#207
post #89

Earlier quoted context omitted.

Carbon is probably Gamedev's best chance of moving beyond c++ But you are going to need some minimal buy-in from Microsoft first, if not Sony and Nintendo too. The great thing about carbon is that you can incrementally shift a codebase over from c++, and there are no problems interacting with existing c++ APIs, so the required amount of buy-in is pretty much just "yes, you can use a 3rd party compiler" and maybe some…

What about rust?

As much as I love Rust, it really has a significant impedance mismatch at the low-level with GameDev.

Things must be initialized in Rust. Things must have a single identifiable owner. Things really want to be immutable.

Sure, you can duck these in Rust with lots of "unsafe". But, if you do that, are you really gaining anything from using Rust?

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

#208

Calling convention? That's the most exciting feature? It doesn't boost productivity, reduce compile times, offer a larger standard library or create a boost a reasonable language would provide? No thanks google. I've been saying that for years now. You jumped the shark

The author has expertise in C++ and is excited about a C++-like language that addresses the pain point of C++'s calling convention which will _never_ be fixed by the standards committee due to their commitment on backwards compatibility. This was not an overview of the language, so this comment seems a little uncharitable to the author.

Having slightly better optimizations due to changing ABI doesn't sound worth the friction of having another language in the codebase. Especially when the guys who invented it (google) is famous for sunsetting things and couldn't get their peers to use bazel, the other thing google invented

I don't care if this sounds uncharitable, I see the pitfalls and I seen so many people get sucked in to prior pitfalls

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

#209

Earlier quoted context omitted.

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.

Yeah, but there will probably be a window in which that offramp is generally interesting. If the worldwide C++ codebase moves along, carbon becomes less accessible as a viable choice. Ironically, Google (googletest, gRPC, etc.) has been more agressive than most in dropping support for older C++ standards.

Since Apple and Google have focused on their own languages, clang steam went out, as no one else seems that interested in improving ISO C++ support, rather the LLVM foundations, which require C++17 as basis.

If the likes of Intel, AMD, ARM, IBM, Embarcadero,.... don't step up in ISO C++ support at upstream, clang will stay mostly C++17 with some bits and pieces from C++20.

It is already ironic, that after so many years of being joked for their non-standard extensions, VC++ has the best ISO C++20 support.

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

#210
post #33
post #14

Earlier quoted context omitted.

Some of the biggest problems with C++ come from its backwards compatibility with C. Yes, it wins you users in the short term, but it's a pain to support as both languages evolve

The binary compatibility is the big deal. The other safe languages have explicitly taken the view the interop with C++ is bad, and so we should instead do interop with the significantly less safe C instead. The real killer is that the lack of any interaction with C++ means that you can’t do any real incremental adoption of one of those safe languages in any big security critical projects. Saying that the solution to…

.NET has always supported interop with C++, first with Managed C++, then C++/CLI, and nowadays via Windows Runtime (C++/CX and C++/WinRT).

Likewise JNI has always had support for COM like models, and the C API is written in such way that the struct layouts can be used as C++ classes instead, with implicit this on method calls.

Post reply on HN