Pointer arithmetic #1954
Replies: 3 comments
-
Please see the answer at #1941 (comment) (separate type) |
Beta Was this translation helpful? Give feedback.
-
The proposal in #1941 comment is to have a "incrementing pointer type". Rust originally had many pointer types, adding to language confusion, and after the initial assessment, they dropped the number of pointer types. Carbon should learn from this experience. Incrementing pointers is a regular high performance operation, it would be a shame if Carbon for "safety" reasons prevented this high performance practice. |
Beta Was this translation helpful? Give feedback.
-
I agree that this seems like something to keep an eye on: we likely don't want a combinatorial explosion of different pointer types covering all possible sets of facilities. But as somewhat of a counterpoint, in C++ we have both references (which are somewhat analogous to Carbon pointers) and pointers (which would be somewhat analogous to a nullable "incrementing pointer type" / array iterator), and I don't think that ends up being too many. Perhaps having all four combinations of nullable/not-nullable and indexable/not-indexable might be a bit much? Do you have a link to more information about the Rust experience? |
Beta Was this translation helpful? Give feedback.
-
Hi. I'm generally pleased with the design choices Carbon has made, however my biggest concern is lack of pointer arithmetic. Typically when constructing large buffers (eg. creating graphics objects / vertices), we iterate through each a large block of data and pointer increment is the most natural mechanism. When populating network protocol buffers again, we offset the target memory address. All these operations use a modify and post increment expression (eg. *p++ = value), relying on pointer arithmetic. Without pointer arithmetic, we need an additional offset index, and need to constantly increment the offset. Without checking the compiled code via compiler explorer, I'd be suprised if indexing matched the speed of pointer arithmetic (on the contrary, I expect the compiler to produce better code with pointer arithmetic). Lack of pointer arithmetic doesn't improve code safety, and increases code size, and can potentially produce slower code. So how does lack of pointer arithmetic benefit developers wanting to produce the fastest code.
Beta Was this translation helpful? Give feedback.
All reactions