I really thought this was gonna be about carbon atoms and molecular interactions, in some kind of geeky, programmer-friendly analogy.
Me too, and I even already knew that Cabon the language exists!
Carbon’s most exciting feature is its calling convention
191–200 of 223 posts
Re: Carbon’s most exciting feature is its calling convention
#192Carbon 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…
I wish it was D.
Re: Carbon’s most exciting feature is its calling convention
#193Carbon 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…
I suppose that's what you end up with if your stated goal is to replace C++.
There already were several options instead of using C++, but some minds are wired in that way after many years of training.
Re: Carbon’s most exciting feature is its calling convention
#194Carbon 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…
Carbon being "absolutely bathed in the utter fictions of C++" is a feature not a bug.
The goal of Carbon is explicitly _not_ to be a new general purpose programming language. In the docs, the authors even advise people to use Rust instead for greenfield projects. The goal of Carbon is to support migrating existing C++ codebases to some new safer language.
Re: Carbon’s most exciting feature is its calling convention
#195Carbon 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…
This is just so unfair to a project whose explicitly stated purpose is to be a better C++ and just that to ease the transition and porting of code from one to the other. Even they say, if you are not working with a C++ codebase, don't bother using Carbon, use something else. Great shot but make sure to aim at the target next time.
Re: Carbon’s most exciting feature is its calling convention
#196Carbon 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…
This is just so unfair to a project whose explicitly stated purpose is to be a better C++ and just that to ease the transition and porting of code from one to the other. Even they say, if you are not working with a C++ codebase, don't bother using Carbon, use something else. Great shot but make sure to aim at the target next time.
Unsafe languages are fossil fuels and Carbon is natural gas. Yeah, a small improvement over coal, but an incrementalist addition that only reduces the magnitude, not the direction. Still digging in the wrong direction, IMHO.
And I standby my original assessment that the design is very obviously lacking in long-term experience in another language.
Re: Carbon’s most exciting feature is its calling convention
#197Earlier 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.
But "C++ on Linux" isn't "C++". It's a subset of C++ usage. The lack of competing compilers on some OS might be a feature of those OS, or in the eyes of some mabye even a failure of those OS, but it's certainly no feature of the language. ABI compatibility isn't about using the same binary on different OS, it's about running binaries from different compilers/compiler versions/compiler configurations in the same process.
Re: Carbon’s most exciting feature is its calling convention
#198Earlier quoted context omitted.
How would you define object identity if different objects can have the same value and the same address? To my mind, an object is a value with a unique identity. How else would you define it? And if you want a billion empty values, then yes, those could all be implemented by the same object - it's pretty easy to implement, even though it would be ncie for a compiler to do it automatically (like how Java normally gives…
> How would you define object identity fn main() { let vs = [(), (), (), (), ()]; for v in vs { println!("{:?}", v); } } This loop will five times print "()", because `v` will iterate through all five elements of `vs`. Are this values are identical or they aren't? I don't know, it doesn't matter, isn't it? But I think of them as of different values: they are different members of `vs`.
They are the same value, but with different identities. vs[0], vs[1] etc. are different objects, but they are all initialized with the same value. The difference is kind of irrelevant for a constant object like an empty tuple.
But imagine the following program:
fn main() {
let mut vs = [(1,), (1,), (1,), (1,), (1,)];
vs[0].0=2;
for v in vs {
println!("{:?}", v);
}
}
By the way, note that your example should be completely equivalent to the following C++ program:
int main() {
using namespace std;
auto vs = vector>{tuple(), tuple(), tuple(), tuple()};
for (auto v : vs) {
cout Re: Carbon’s most exciting feature is its calling convention
#199Earlier quoted context omitted.
> which a compiler obviously sees Not if it's in a different compilation unit, it doesn't. Or if it's just not inlining the function for some reason, then it probably also doesn't. Which is why Carbon's restriction here is so useful and practical.
Ok, I'm willing to accept be wrong here. My interpretation of what I read is that Carbon is disallowing taking the address of a parameter. Very specifically: void f(int i) { &i; /* disallowed */ } I think that's a trivial case and is hopefully obviously easy to detect, and I know we're considering relevance to escaping which this doesn't do, but it seems that taking the address is explicitly disallowed regardless of…
That is what Carbon prevents, yes. And, inside a particular function that does it, it's obviously easy to detect. But in the calling function, it's not easy to detect.
If in boo.cpp you call your g() function which is in foo.cpp, how does the compiler know if it's taking the address or not? It's in a different compilation unit. All the compiler knows at that point is there's a function 'g' that takes an int by reference. It has no idea what 'g' does with it, it doesn't even know where 'g' is - that won't be known until link time. So the compiler is forced to be conservative and allow for 'g' to do anything that C++ allows - which includes stashing the reference somewhere or const_cast'ing away a const& into a mutable reference.
This is where Carbon's win comes in. Since that behavior just isn't allowed, the compiler doesn't have to be conservative. It doesn't need to somehow see into different compilation units to perform helpful optimizations (critically for const unique_ptr& or const shared_ptr&)
Re: Carbon’s most exciting feature is its calling convention
#200Earlier quoted context omitted.
comex mentions this above. It's a nice hack, but it doesn't actually fix the problem I was talking about, you can give this attribute to a data member, which allows you to do the ZST marker type trick that is available in other languages, but you can't apply the attribute (at least, not as documented) to a type itself, those empty tuples are obliged to take up one byte each.
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.