Earlier quoted context omitted.
Bruh
Could you crawl back to reddit? Thanks
[deleted]
C array types are weird
131–140 of 148 posts
Re: C array types are weird
#132Re: C array types are weird
#133Earlier quoted context omitted.
The ABI is not the issue.
It's an issue if you want different software components to talk to each other without IPC.
Most languages can interoperate with the C abi without commiting you to using the language itself. In fact I can't think of a single language that both produces software people actually use and doesn't interoperate with the c abi.
Re: C array types are weird
#134Re: C array types are weird
#135Earlier quoted context omitted.
Maybe, but also irrelevant to the discussion because whether you write mat[b * A + a] by hand or mat[b][a] and let the compiler frontend expand then makes no difference to the optimizer.
You missed the point. Those two representations are equivalent, yes. But that's not what flattening loops mean.
You are telling me what my point was?
Re: C array types are weird
#136Earlier quoted context omitted.
So you would be equally critical of overloading [] for maps? Sorry, hard for me to relate, as I've overloaded [] (in, say, Python) to make life easy on everyone. People loved it. I hope you're aware that there is a long standing debate on whether overloading operators is good/bad, and it comes down to personal preference?
> So you would be equally critical of overloading [] for maps? No, I'm not sure how you got that impression. Overloading is great. It's also confusing when it does something completely different from what you intuitively expect.
If you're an old timer, you expect [] to index into an array, and you definitely do not expect it to do a lookup in a map/dict. Older languages just didn't include a dict-like structure in the language (technically, even C++ didn't).
Do you not see that for them, overloading [] for dictionary lookups is "something completely different from what you intuitively expect"?
Re: C array types are weird
#137Earlier quoted context omitted.
Not just this it is important to remember that there was no "aha!" moment where C was created whole-cloth by writing the first compiler in B then cross-compiling. The language B was evolved in-place by adding new features, then editing the compiler source to make use of those new features, then repeating. They simply started calling it "New B". At some point the language had evolved sufficiently that they decided to…
> Part of me suspects this was also because it was seen as "clever" at the time. Look ma, we let arrays turn into pointers! Isn't that clever? It was intentional and functional. The idea was basically a primitive kind of polymorphism, which allowed for functions intended to act on arrays to accept any size of an array to be passed in. It was redundant with pointer arithmetic, but allowed for communication of intent w…
> Actually pre-ANSI C technically didn't have function prototypes,
Thanks, I completely forgot they weren't called prototypes originally.
Re: C array types are weird
#138Earlier quoted context omitted.
> So you would be equally critical of overloading [] for maps? No, I'm not sure how you got that impression. Overloading is great. It's also confusing when it does something completely different from what you intuitively expect.
If you're an old timer, you expect [] to index into an array, and you definitely do not expect it to do a lookup in a map/dict. Older languages just didn't include a dict-like structure in the language (technically, even C++ didn't). Do you not see that for them, overloading [] for dictionary lookups is "something completely different from what you intuitively expect"?
More strikingly, C++ doesn't distinguish what Rust would call IndexMut and just Index, the use of the [idx] operator in a context where we'll mutate things and one where we don't want that.
Rust's HashMap implements Index because answer = map[name] is a perfectly reasonable thing to do, and if there is no key matching name then we panic, makes sense but it does not provide IndexMut so that you could write map[name] = answer because the edge cases are non-obvious so better to make you write what you meant.
C++ hash tables implement operator[] but the result is mutable, in order that map[name] = 123.0 can work which in Rust would be IndexMut and isn't provided. Because this is true, the index operation always succeeds, if you ask for map["not-present"] it creates the hash table entry for "not-present" and tries to store a default value ready to update it if you later assign to the reference.
Re: C array types are weird
#139Earlier quoted context omitted.
> Array memory is on the stack. Array memory can sit on either the stack or the heap. > The size of that array is actually not known at run time, its only known at compile time, where any reference to that length gets resolved by the compiled. This is also a bit misleading, in two ways. First, it's not clear what you mean by "size" here - the size of the memory block(s), or the shape of the array? Second, many people…
>Array memory can sit on either the stack or the heap. No, if we are using the definition of an array that is like int c[] = ..., that is always going to be on the stack. Heap continuous memory =/= array. You can use the [] operator to access it like an array, but fundamentally, as far as structures in C language are concerned, those 2 are different, because they get treated by compiler differently. >but the size is…
> int c[] = ..., that is always going to be on the stack
Why? In the following code, only c will be allocated on the stack:
int a[]={1,2,3};
foo() {
static int b[]={1,2,3};
int c[]={1,2,3};
}Re: C array types are weird
#140Earlier quoted context omitted.
At this point, C's #1 priority is not breaking things in existing implementations, though, Walter...
My proposal does not break existing code. https://www.digitalmars.com/articles/C-biggest-mistake.html
Yes it does:
>All it needs is a little new syntax