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

81–90 of 223 posts

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

#81

Post by tialaramex »

gumby wrote: post #68
tialaramex wrote: post #25

C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct. If you've got a 1.6 billion empty tuples in variable A, 1.4 billion in variable B and 1.8 billion in variable C, C++ can't see a way to do that on a 32-bit operating system. It needs to give each empty tuple an address, so it must think of 4.8 billion integers between 0 and 2^32 and it can't do that, so your pr…

> C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct. With only three exceptions I can't think of a case where by default one would not want that. In the case you describe you would want all those objects to have unique addresses. If you wanted to have them overlap you should go to the effort to happen the way you want it to -- how could the compiler guess on it…

> In the case you describe you would want all those objects to have unique addresses.

I certainly don't, if you want unique addresses for indistiguishable objects I guess C++ is the perfect language for you but, what are you expecting to do with these addresses?

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

#82

Post by spookie »

olliej wrote: post #35
moralestapia wrote: post #21

Earlier quoted context omitted.

It's Google but yes, another instance of Embrace, Extend and Extinguish . I hope this doesn't take off, with my sincere apologies to the ones who have been working hard on this. The last thing the C/C++ ecosystem needs is becoming de facto owned by a private company.

In fairness this is as opposed to Go? Swift? Rust? Java? C#? Then C and C++ are defacto controlled by private companies: Google+Apple do pretty much all the clang development, MS does MSVC - if they choose not to implement a feature that’s approved, or implement one that isn’t, that is the de facto standard. You can argue it would require all three to agree on something, but that’s still essentially making WG21 somew…

Huh, aren't you forgetting someone?

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

#83

Post by dhosek »

Cyberdog wrote: post #66
labrador wrote: post #46

Earlier quoted context omitted.

Google engineers: "Let's make our languages hard to Google!" Google managers: "Whatever floats your boat. How about Go, Dart and Carbon?"

Swift was annoying in the early days since searches would bring up info on the international payment system. Lua and PHP have nice searchability. At least, it's fairly easy to weed out results on the Portuguese moon and the Philippine peso.

I remember trying to Lycos/Altavista/Yahoo info on C or C++ back in the 90s. Perl also ended up being a challenge because a lot of results would be things like http://example.com/cgi-bin/perl/irrelevant-result.

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

#84

Post by ad8e »

comex wrote: post #45
Denvercoder9 wrote: post #15

Maybe I'm missing something, but I don't see what's special about Carbon here. In C++ the compiler can also optimize pass-by-const-reference to pass-by-value, and they do. It just can't do it across an ABI boundary, but that should only be an issue with dynamic libraries, and Carbon has to follow the standard ABI there as well. Just make sure the compiler knows it doesn't have to follow the standard ABI for every sym…

That optimization is quite fragile. For example, try putting `puts("hello");` at the beginning of `add`. Now neither GCC nor Clang performs the optimization. Why? Because `puts` could theoretically modify the value behind the reference, so the value loaded is not necessarily the same as the value at the beginning of the function, which makes things more complicated, so both compilers give up. As another example, GCC…

Carbon doesn't do the next logical optimization, and only converts a const& parameter to a value. If a function has parameter "const struct_with_two_floats&", and reads it, calls puts(), then reads it again, Carbon will not be willing to optimize out the "redundant" read.

It seems odd to break with C++ semantics for small parameters only; I'd expect it to either break for all parameters or no parameters.

EDIT: looks like Carbon is not doing this optimization for small values either. Its docs on parameters say, "This binding will be implemented using a pointer, unless it is legal to copy and copying is cheaper". And the OP link says, "the compiler is allowed to convert that to a T [copy] under the as-if rule." That seems like no extra optimization is enabled other than changing the function calling convention. And the "as-if" rule would require looking at the function body to check if the value could be changed (by things like puts()). I hope my understanding is wrong because this does not make sense. The word "legal" is ambiguous, so hopefully they mean something else!

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

#87

Post by TillE »

bsder wrote: post #79
zeusk wrote: post #29

Earlier quoted context omitted.

Maybe the right question to ask is, why you have 4.8 billion empty tuples? And why you're still on a 32-bit system?

Gamedev, presumably. It's not unusual to have a LOT of triangles and coordinates flying around and GameDev is basically locked to C++ (for many good reasons even if I find C++ distasteful). Admittedly, those probably aren't running on 32-bit systems, nowadays ...

There are a zillion ways to handle sparse arrays or redundant values that don't depend on esoteric language features. You're not even losing any efficiency, you're probably gaining some because you know your domain.

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

#88

Post by tialaramex »

moralestapia wrote: post #21
bardworx wrote: post #17

Earlier quoted context omitted.

Microsoft. - don’t listen to me, it’s Google.

It's Google but yes, another instance of Embrace, Extend and Extinguish . I hope this doesn't take off, with my sincere apologies to the ones who have been working hard on this. The last thing the C/C++ ecosystem needs is becoming de facto owned by a private company.

At some point between here and like, shipping a language design and working prototype, the stated intent is to build a Foundation like for several other modern projects and then assign everything to the Foundation.

""We are planning to create an open source foundation and transfer all Carbon-related rights to it; our goal is for the foundation setup to be similar to other open source projects, such as LLVM or Kubernetes.""

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

#89

Post by phire »

bsder wrote: post #79
zeusk wrote: post #29

Earlier quoted context omitted.

Maybe the right question to ask is, why you have 4.8 billion empty tuples? And why you're still on a 32-bit system?

Gamedev, presumably. It's not unusual to have a LOT of triangles and coordinates flying around and GameDev is basically locked to C++ (for many good reasons even if I find C++ distasteful). Admittedly, those probably aren't running on 32-bit systems, nowadays ...

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 improvements to the debugger.

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

#90

Post by gumby »

tialaramex wrote: post #81
gumby wrote: post #68

Earlier quoted context omitted.

> C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct. With only three exceptions I can't think of a case where by default one would not want that. In the case you describe you would want all those objects to have unique addresses. If you wanted to have them overlap you should go to the effort to happen the way you want it to -- how could the compiler guess on it…

> In the case you describe you would want all those objects to have unique addresses. I certainly don't, if you want unique addresses for indistiguishable objects I guess C++ is the perfect language for you but, what are you expecting to do with these addresses?

You made an object rather than using an existing one. How is the compiler supposed to know that you wanted an existing object?
Post reply on HN