51–60 of 148 posts
Earlier quoted context omitted.
Never pushed it that far. Mentioning safety in a C or C++ context was viewed very negatively back then.
We are working towards this though and a lot of this already works: https://godbolt.org/z/EP3cP3qGs
Earlier quoted context omitted.
We are working towards this though and a lot of this already works: https://godbolt.org/z/EP3cP3qGs
The vec macros currently there directly call realloc()… that's gonna exclude any custom allocator setups… and the string code uses the vecs :/
But yes, I was thinking about making a custom-allocator version of vec.
Earlier quoted context omitted.
The vec macros currently there directly call realloc()… that's gonna exclude any custom allocator setups… and the string code uses the vecs :/
The example shown does not use vec from my experimental library. But yes, I was thinking about making a custom-allocator version of vec.
Interestingly the article doesn't mention two-dimensional arrays and they're curios because they bring a certain asymmetry with them. It always tripped me over the most in C because I otherwise find the language very "symmetrical". It often feels like in design of this language the beauty of expressing certain things took priority over readability or safety which I admire in a way. But somehow not in the case of the…
I mean, just like with 1 dimensional arrays, it depends on the context. Array memory is on the stack. 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. If your 2d array sits on the stack, then inferring memory layout is pretty easy. If you are dealing with pointer that was passed to a function, then you can't ass…
Right, but 2d arrays come into this picture with their own quirks again. You're not just passing the size as the parameter, you can pass it as a "special" parameter that influences how the compiler will interpret other parameters. E.g. in C99 you can do this:
void do(size_t x, size_t y, int a[][y]);
Of course it's still generalizable as "all but the outermost dimensions should be known" and for 1d array the outermost dimension is the only dimension. Still, this whole thing always felt a bit odd to me.
[flagged]
Embedded programming is still in C for a lot of micro controllers and whatnot. If you’re programming with limited resources it’s essential to understand pointers and arrays. Likely you won’t be doing anything useful without them
Earlier quoted context omitted.
Learning to program with pointers is enormously useful. It's simply bad software engineering to not use typing to enforce constraints on access to pointers (or addresses, or however you'd like to term them)
IIRC that talk of about using indices (u32) to represent data in an array. That is orthogonal to representing that information in the type system since you can just type the index
Earlier quoted context omitted.
C's biggest mistake. But in other news most don't know that a[3] == 3[a]
I didn't understand why a[3] == 3[a], but i found this stackoverflow that explains it. https://stackoverflow.com/a/16163840 In C a[i] is converted to *(a+i) internally. i[a] is converted to *(i+a). Array names also act as pointers in c. so (a+i) or (i+a) give an address (using pointer arithmetic) that is dereferenced using
[flagged]
Most modern languages start with fixing C's warts (good) but then at some point turn into 'tech manifestos' (for lack of a better word). C is refreshingly devoid of opinion and that's what makes it so extremely flexible and timeless.