为什么数组范围基元会消耗它们的源？

Question

专用于内置数组的范围基元会消耗它们的源，但可以轻松设计一个范围系统，该系统宁愿基于源的 .ptr（乍一看更灵活).

struct ArrayRange(T)
{
    private T* _front;
    private T* _back;

    this(ref T[] stuff) {
        _front = stuff.ptr; 
        _back = _front + stuff.length;
    } 
    @property bool empty(){return _front == _back;}  
    @property T front(){ return *_front;}  
    @property T back(){return *_back;}    
    void popFront(){ ++_front;}
    void popBack(){--_back;}
    T[] array(){return _front[0 .. _back - _front];}
    typeof(this) save() {
        auto r = this.array.dup;
        return typeof(this)(r); 
    }  
}

void main(string[] args)
{
    auto s = "bla".dup;
    // here the source is 'fire-proofed'
    auto rng = ArrayRange!char(s);   
    rng.popFront;
    assert (s == "bla");
    assert (rng.array == "la");
    // default primitives: now the source is consumed 
    import std.array;
    s.popFront;
    assert (s == "la");
}

为什么默认系统不基于指针算法，因为弹出前端意味着reallocations/less效率？

这种设计有什么基本原理吗？

Answer 1

我同意你的看法，没有理由在每个 popFront 重新分配。还好不是后来发生的事情！

popFront 机制与您介绍的机制非常相似，source 不会被消耗，只会消耗您调用 popFront 的数组（因为，它毕竟是流行音乐）。您实现的是切片数组时发生的情况：您获得原始数组的参考范围：

auto a = [1, 2, 3]; 
auto s = a[];
s.popFront;
assert(s == [2, 3]);
assert(a == [1, 2, 3]);

.dup 用于提供数组的副本，以便您可以安全地修改副本而不更改原始数组，因此它复制原始数组然后为该副本提供输入范围。当然你可以修改副本（这就是重点），popFront 会改变它但仍然使用指针算法而不改变源。

auto a = [1, 2, 3];
auto s = a.dup;
s.popFront;
assert(s = [2, 3]);
assert(a = [1, 2, 3]);

.dup 本身可能看起来不是很有用，因为我们将它与数组一起使用，但在处理 "pure" 范围时它真的很重要，因为范围通常懒得不使用它。由于范围的副本被消耗而不是初始副本，我们可以安全地将此副本传递给函数并且仍然保持我们的初始惰性范围不变。

为什么数组范围基元会消耗它们的源？

Why do th array range primitives consume their sources?

d

range

pointer-arithmetic