为什么在Scheme中无法调整SRFI-4向量的大小？
我看到 SRFI 4 没有提到调整向量大小。我正在使用 f64vectors（我需要快速访问），并且我希望能够快速调整它们的大小（类似于 C 中的 realloc 所做的），并且不一定复制整个向量。
由于我没有找到任何对“resize-f64vector”过程的引用，我想知道为什么它不存在（如果创建一个新向量并复制是我唯一的选择）。
I see that SRFI 4 does not mention resizing of vectors. I'm using f64vectors (for which I need fast access), and I'd like to be able to resize them quickly (similar to what realloc does in C), and not necessarily copy the whole vector.
Since I didn't find any references to a "resize-f64vector" procedure, I'd like to know why it doesn't exist (and if making a new vector and copying over is my only option).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
几个原因。
通过在语言中使用同质向量类型，编译器可以对性能做出一些可靠的假设。理想情况下，在某些高度优化的场景中，对向量的引用可能只是指向内存块的点。并不是说任何计划实现实际上都做到了这一点，但它们可以做到这一点。
鉴于此，几乎每次调整向量大小时，它都像是复制到可以保存新向量的新内存位置。这只是它的原始真相以及记忆的排列方式。
因此，鉴于此，您可以看到，如果我拥有的只是一个指向内存的指针，如果该缓冲区被更改和移动，那么我的指针将不再有效。它指向旧的记忆。
但是，如果我可以假设我的内存大小永远不会改变，那么这是一个安全的赌注，作为编译器的优化，我的向量的内存永远不会改变，并且我可以将该向量表示和引用为简单的指针记忆。
这就是同构向量的主要目标，即可以更快地访问专用内存块。
由于调整向量大小几乎不可避免地涉及副本，因此您也可以显式地显示该副本，使编译器能够完全了解向量引用的更改。
Couple reasons.
By having a homogeneous vector type within the language, the compiler can make some solid assumptions about performance. Ideally, in some heavily optimized scenarios, the reference to the vector can be little more than a point to a block of memory. Not saying any Scheme implementations actually do this, but they can do this.
Given that, almost every time a vector is resized, it's most like copied to a new memory location that can hold the new vector. Just the raw truth of it with the way memory is laid out.
So, given that, you can see how if all I have is a pointer to memory, if that buffer is changed and moved, then my pointer is no longer valid. It points to the old memory.
But if I can assume that my memory size will never change, then it's a safe bet, against as an optimization by the compiler, that the memory for my vector will never change, and that I can represent and reference that vector as simply a pointer to memory.
And that's the primary goal of the homogeneous vectors, to give potentially faster access to specialized blocks of memory.
Since resizing a vector almost inevitably involves a copy, you may as well make that copy explicit, giving the compiler full visibility to the changes in the reference to the vector.
Gambit-C 方案可以收缩向量 ，但如果你想要一个通用的解决方案，那么你就不走运了。您可以使用比需要更大的向量，以避免频繁的重新分配和复制，例如每次需要更多空间时将向量加倍，并记录实际使用的槽数。
Gambit-C Scheme can shrink vectors, but if you want a general solution you are out of luck. You can use vectors of a bigger size than needed to avoid frequent re-allocation and copying, like doubling the vector everytime you need more space and keeping a count of the number of slots really used.