131–140 of 223 posts
I was very confused by what the author is pointing out in the opening Point / Print example. ("[T]he compiler is allowed to convert that to a T" -> wait, why did the compiler change a struct to an int32?) I think this boils down to: Carbon defaults to passing parameters that fit in a single register by value, and all others by const reference. This affects a few things you might take for granted in C++, like whether…
Earlier quoted context omitted.
Consider this C code (also "works" if compiled as C++): int main(void) { int x = 0; int arr[1]; int *p = arr + 1; *p = 42; return x; } On a lot of systems (e.g., https://godbolt.org/z/jYqM8TT3Y ), it just so happens that `x` is right above `arr` on the stack, so that code will return 42. But that code is absolutely UB. The more general name for this concept is "pointer provenance". Basically, you can't pull pointer v…
That's a buffer overflow. The optimizer doesn't need to reason about changing the behavior of such things.
However in practice you can do this, and walk the stack to find the parameters or what have you, and then you’ve got a pointer to a parameter without the compiler being aware of it. But this is all explicitly UB, so it’s ok for the compiler to be unaware of it, and it’s free to do whatever codegen it wants given the assumption that UB can never happen.
Spent a terrible amount of time hunting down C++ bottlenecks. It has almost never been about unintended copying of structs or classes. It usually boils down to someone assuming that a particular collection or algorithm won't be on the critical path, and using a lazy O(N^2) solution. Then the codebase grows, use cases shift, someone puts another O(N^2) algorithm around an existing O(N^2) and the whole thing explodes.…
Earlier quoted context omitted.
> The other safe languages have explicitly taken the view the interop with C++ is bad It's not that it's inherently bad, it's just insanely difficult to do and, probably, isn't worth the pain. Carbon's approach to solving this problem includes embedding a custom C++ compiler as part of its toolchain, and at this point it's just the idea, who knows if they will be able to actually do it. > they are all hell bent on no…
Interop with c++ is definitely inherently bad.
Earlier quoted context omitted.
I think the statute of limitations on “confusing name” when Mac OS Carbon was removed from OS X 10 years ago has passed.
Carbon was removed two years ago.
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.
Scope-bound resource management, like C++. GC and ARC are for people that need shared ownership, which is pretty much always a bad idea.
Earlier quoted context omitted.
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…
As an example, look at this issue from the mold linker: https://github.com/rui314/mold/issues/584
They are looking at creating an embeddable custom dynamic linker in order to greatly reduce loading times, by fixing locations as the file gets loaded in.
The equivalent in Carbon would (for example) be to create a new type of exception handling that changes how we think about exceptions, performance and their cost. Perhaps something like the static exceptions that Herb Sutter has been working on. Instead, they are not adding exceptions at all.
You will have to excuse my disappointment.
A C++ replacement that is just as difficult to bind/link/work with in other languages as C++ itself just seems like a missed mark, despite the fact I know this is not on their priority list at all.
I hope my read of this is wrong, and it will be easy to bind and link to from other languages after all.