5 ms·
It's not really an extra pointer, unless you assume there are no alignment issues. If you assume that there's zero padding between members, then yes, you can do
by quicknir 11y ago
It's not really an extra pointer, unless you assume there are no alignment issues. If you assume that there's zero padding between members, then yes, you can do 1 pointer for storage + 1 per view. In the follow-up post, I plan to either do one pointer per view, or one integer per view, haven't decided which.
The thing is, who should solve it? The different approaches you listed have different advantages, there isn't one right answer. If the language itself solves it for you, you are stuck with whatever solution the language picked. This would be fine in a higher level language, but not in C++.
You're right though that individual devs shouldn't be solving it, it should be in a library. If there's enough interest in these posts, I'm happy to put up my work (fully fleshed out and documented) on a github for people to use.
- uxcn 11y agoI suspect the compiler will be better able to optimize offsets than pointers just because of the semantics required by the language, but I think you're right that it isn't necessarily one size fits all. Another possible solution might even be storing static bounds at specific intervals. Without numbers, I can only guess which would give optimal performance though. I think the library approach is right. It would be nice to see the language transparently support contiguous array members, but supporting it in a library will allow more people to use it regardless of compiler. It avoids the standards approval process and implementation as well, which take non-trivial amounts of time. The 0x/1y features definitely make it a lot more feasible. It would probably give people a better chance to play with the source if you could post a link to it somewhere. I'm not sure what you plan to license it under. I'll keep an eye out for the next post.