141–150 of 223 posts
I have to say, and pardon me for saying so, but Carbon seems to be utterly uninteresting to me. They are not solving any interesting problems that shows me that they are creating a modern language. 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 locatio…
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…
...yes? The C++ is absolutely ABI stable, and is described in excruciating detail, as demonstrated by all those C++ libraries, that you don't have to recompile for on every OS update. I suspect you're confusing when you make an ABI change, without changing the A P I, which is indeed an easy thing to do: You have to make sure that you only add members to the end of objects, however that exact constraint also applies t…
C++ ABI doesn't even exist, there are several competing standards (much fewer now than there used to be) and nothing is guaranteed even between different compiler versions, let alone different compilers. Not that long ago we used to have two implementations of std::string in gcc you had to choose from and if the library you're linking with chose another one, you were out of luck.
Earlier quoted context omitted.
Well, Apple was a little clever with Carbon for this reason, because it was a C based API. I'm not sure how you get Carbon from C++.
Apparently, although it's not likely to occur under most conditions, you can form a monatomic carbon C²⁺ ion by shooting a laser into very high-temperature carbon: https://sciencetrends.com/the-charge-of-a-carbon-ion/ https://aip.scitation.org/doi/10.1063/1.4966987 "Up to C⁴⁺ ions are observed." And I guess you could also write the C²⁺ ion as "C⁺⁺" if you wanted. :-)
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?
You actually have to wrap all the c++ functions in c functions, and then call those c functions from rust. Which requires either making manual wrappers, or automated wrapping tools that handle the specific idiosyncrasies of the library you are calling.
Which is a massive barrier; Gamedev standardised on c++ and there are so many c++ libraries.
In comparison, Carbon is designed from the ground up to automatically have bi-directional inter-op with c++. It's what the language is designed to do.
Earlier quoted context omitted.
I think the alias analysis “pro” is overblown, it’s UB to take the address of a parameter via any mechanism other than explicitly taking the address - which a compiler obviously sees, and because it’s UB the compiler optimizes is free to assume no one is taking the address. Then for any parameters that are passed by reference the compiler has to assume there are other references so there’s no gain. Honestly the only…
> I also loathe their desire to listen to the BNF maximalists insistence on not having any “ambiguity” from Odd that you put ambiguity in quotes. I guess it's not real ambiguity then. Ivory tower academics, as you see them, actually care about stuff because it affects you. I've heard too many times the knee-jerk response of "it's just theory" as if that actually meant anything. Try implementing it yourself and you'd…
Because a parser is never really ambiguous is it? Nobody writes a parser that has a random decision on which rule to take.
Earlier quoted context omitted.
> I also loathe their desire to listen to the BNF maximalists insistence on not having any “ambiguity” from Odd that you put ambiguity in quotes. I guess it's not real ambiguity then. Ivory tower academics, as you see them, actually care about stuff because it affects you. I've heard too many times the knee-jerk response of "it's just theory" as if that actually meant anything. Try implementing it yourself and you'd…
> Odd that you put ambiguity in quotes. I guess it's not real ambiguity then. Because a parser is never really ambiguous is it? Nobody writes a parser that has a random decision on which rule to take.
It's still ok talk about the grammar as being ambiguous no matter what a purported implementation of such grammar is deterministic (because it ultimately does not implement the actual grammar)
Earlier quoted context omitted.
> And because C++ says "one past the end" pointers are a thing, both these pointers can exist. While one-past-the-end pointers are allowed to exist, they are not allowed to be dereferenced. > these pointers are the same... right The entire point of provenance is that even though their numerical values are the same, they are not the same. > Neither C nor C++ currently actually explain how this works for their "abstrac…
> it can be inferred from other things that the standard does say. The compiler authors didn't just make it up. They didn't "just make it up" but well, here's (a draft of) TS 6010 explaining where it comes from, alas it's not "inferred from other things that the standard does say" but rather riffing on a phrase from a discussion about a defect report... ""In a committee discussion from 2004 concerning DR260, WG14 con…
Earlier quoted context omitted.
Fragile base class problem is solved, then? When did that happen?
No, but that's also not relevant as C++ is ABI stable. 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. I can then go back to my library, and make a bunch of ABI safe changes, just as I would have to do in C, and compile my library again, with yet another compiler. At that point the…
> 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 virtual method calls can crash (unless you follow certain rules, e.g. no virtual destructors, no overloaded virtual methods, etc.)
With 32-bit code, compilers won't even use the same calling convention by default... (look up 'thiscall')
EDIT: strange to see that someone downvoted...
Earlier quoted context omitted.
> Odd that you put ambiguity in quotes. I guess it's not real ambiguity then. Because a parser is never really ambiguous is it? Nobody writes a parser that has a random decision on which rule to take.
In parser theory there is such a thing as an ambiguous grammar. Parser generators detect such a grammar and never produce an actual parser for it. So in a sense most parser that you actually use don't have ambiguous grammars by definition. That said, you could have a manually written parser that thinks it implements an "ambiguous grammar", but in reality chose an deterministic (even if possibly arbitrary l) resolutio…
I think parser generators were a mistake.
Earlier quoted context omitted.
In parser theory there is such a thing as an ambiguous grammar. Parser generators detect such a grammar and never produce an actual parser for it. So in a sense most parser that you actually use don't have ambiguous grammars by definition. That said, you could have a manually written parser that thinks it implements an "ambiguous grammar", but in reality chose an deterministic (even if possibly arbitrary l) resolutio…
I guess I don't understand why we use languages for writing grammars that let you express ambiguity in the first place. I think parser generators were a mistake.