3 ms·
Fat pointers are a good idea, but I think it’d be a better idea to store the start and evd pointers instead of a pointer to the first element and a size_t.
by KingLancelot 4y ago
Fat pointers are a good idea, but I think it’d be a better idea to store the start and evd pointers instead of a pointer to the first element and a size_t.
- 1980phipsi 4y agoWhy?
- masklinn 4y agoI'd guess it's because that's what C++ does. Though it's unclear to me that C++-style iteration (where you increment a running pointer until you reach an EOI pointer) is much used in C.
- WalterBright 4y agoStoring two pointers into the same array is a memory safety problem. It's hard to implement a borrow checker when there are two live mutable pointers into the same memory object.
- int_19h 4y agoI would expect the borrow checker to treat a slice as a logical pointer to all elements that are addressable through it, regardless of how it's implemented under the hood.
- int_19h 4y agoThis pattern originated in C; C++ iterators were specifically designed to fit it when it was already established.
- andrewmcwatters 4y agoI've never heard of a good argument for this as compared to a capacity, length, and data struct. If you have a start and end pointer and you move either one, you don't know what the original size of the allocation was.
- KingLancelot 4y ago[dead]
- ntrel 4y agoD doesn't store capacity in each slice. This allows a slice to fit in registers more often. Instead for GC allocated slices, the GC will store metadata before the first element of the allocation. That does make it slower to access, particularly when the slice points past the first element, but it is cached to speed up repeated accesses to the same allocation. Repeated appending can be further speeded up by using a dedicated Appender type.