Qt 未记录的方法 setSharable

发布于 2024-08-26 22:37:24 字数 471 浏览 10 评论 0原文

我偶然发现了一种方法,它似乎存在于所有数据对象中,例如 QList、QQueue、QHash...

到目前为止我什至进行了调查可以看到它的源代码,位于

inline void setSharable(bool sharable) {
    if (!sharable) detach(); d->sharable = sharable;
}

qlist 中。 h(第 117 行)。

但它对 QList、QQueue、QHash 等有什么影响呢?它与线程有什么关系吗(这听起来很合理)?

感谢您的任何回答,请仅在您有实际知识的情况下回答。

I stumbled about a method which seems to be present in all data objects like QList, QQueue, QHash...

I even investigated so far I can see the source code of it, which is

inline void setSharable(bool sharable) {
    if (!sharable) detach(); d->sharable = sharable;
}

in qlist.h (lines 117).

But what effect does it have on the QList, QQueue, QHash... ? And is it in any way related to threading (which sounds reasonable)?

Thanks for any answer, and please only answer if you got actual knowledge.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

小红帽 2024-09-02 22:37:24

没有人能说得更清楚了:

http://qt.nokia.com/doc/ 4.6/implicit-sharing.html

以这种方式实现容器是常见的做法。

No one could say more clear:

http://qt.nokia.com/doc/4.6/implicit-sharing.html

It is common practice to realize containers this way.

暗喜 2024-09-02 22:37:24

您所询问的可共享状态与多线程无关。相反,它是写时复制数据类(甚至是单线程数据类)的实现细节,用于分发对内部状态的引用。

考虑使用 CoW 实现的类 String(出于说明目的,此类在线程上下文中不可用,因为对 d->refcount 的访问不同步,它也不能确保内部 char 数组以 '\0' 结尾,并且可能会吃掉你的祖母):还有

struct StringRep {
    StringRep()
        : capacity(0), size(0), refcount(0), sharable(true), data(0) {}
    ~StringRep() { delete[] data; }
    size_t capacity, size, refcount;
    bool sharable; // later...
    char * data;
};

class String {
    StringRep * d;
public:
    String() : d(new StringRep) { ++d->refcount; }
    ~String() { if (--d->refcount <= 0) delete d; }
    explicit String(const char * s)
        : d(new StringRep)
    {
        ++d->refcount;
        d->size = d->capacity = strlen(s);
        d->data = new char[d->size];
        memcpy(d->data, s, d->size);
    }
    String(const String &other)
        : d(other.d)
    {
        ++d->refcount;
    }
    void swap(String &other) { std::swap(d, other.d); }
    String &operator=(const String &other) {
        String(other).swap(*this); // copy-swap trick
        return *this;
    }

一个示例 ; function each 用于 mutating 和 const 方法:

    void detach() {
        if (d->refcount == 1)
            return;
        StringRep * newRep = new StringRep(*d);
        ++newRep->refcount;
        newRep->data = new char[d->size];
        memcpy(newRep->data, d->data, d->size);
        --d->refcount;
        d = newRep;
    }

    void resize(size_t newSize) {
        if (newSize == d->size)
            return;
        detach(); // mutator methods need to detach
        if (newSize < d->size) {
            d->size = newSize;
        } else if (newSize > d->size) {
           char * newData = new char[newSize];
           memcpy(newData, d->data, d->size);
           delete[] d->data;
           d->data = newData;
        }
    }

    char operator[](size_t idx) const {
        // no detach() here, we're in a const method
        return d->data[idx];
    }

};

到目前为止一切顺利。但是如果我们想提供一个可变的operator[]怎么办?

    char & operator[](size_t idx) {
        detach(); // make sure we're not changing all the copies
                  // in case the returned reference is written to
        return d->data[idx];
    }

这种幼稚的实现有一个缺陷。考虑以下场景:

    String s1("Hello World!");
    char & W = s1[7]; // hold reference to the W
    assert( W == 'W' );
    const String s1(s2); // Shallow copy, but s1, s2 should now
                         // act independently
    W = 'w'; // modify s1 _only_ (or so we think)
    assert( W == 'w' ); // ok
    assert( s1[7] == 'w' ); // ok
    assert( s2[7] == 'W' ); // boom! s2[7] == 'w' instead!

为了防止这种情况,String 在发出对内部数据的引用时必须将自己标记为不可共享,以便从中获取的任何副本始终是深的。因此,我们需要调整 detach()char &像这样的operator[]

    void detach() {
        if (d->refcount == 1 && /*new*/ d->sharable)
            return;
        // rest as above
    }
    char & operator[](size_t idx) {
        detach();
        d->shareable = false; // new
        return d->data[idx];
    }

什么时候再次将shareable状态重置回true?一种常见的技术是在调用非常量方法时对内部状态的引用无效,因此这就是将 shareable 重置回 true 的地方。由于每个非常量函数都会调用 detach(),我们可以在那里重置 shareable,这样 detach() 最终会变成:

    void detach() {
        if (d->refcount == 1 && d->sharable) {
            d->sharable = true; // new
            return;
        }
        d->sharable = true; // new
        StringRep * newRep = new StringRep(*d);
        ++newRep->refcount;
        newRep->data = new char[d->size+1];
        memcpy(newRep->data, d->data, d->size+1);
        --d->refcount;
        d = newRep;
    }

The sharable state you're asking about has nothing to do with mutlithreading. It is instead an implementation detail of copy-on-write data classes (even single-threaded ones) that hand out references to internal state.

Consider a class String that is implemented using CoW (for illustration purposes, this class isn't usable in threaded contexts, because accesses to d->refcount aren't synchronised, it also doesn't ensure that the internal char arrary ends in '\0', and might as well eat your grandmother; you have been warned):

struct StringRep {
    StringRep()
        : capacity(0), size(0), refcount(0), sharable(true), data(0) {}
    ~StringRep() { delete[] data; }
    size_t capacity, size, refcount;
    bool sharable; // later...
    char * data;
};

class String {
    StringRep * d;
public:
    String() : d(new StringRep) { ++d->refcount; }
    ~String() { if (--d->refcount <= 0) delete d; }
    explicit String(const char * s)
        : d(new StringRep)
    {
        ++d->refcount;
        d->size = d->capacity = strlen(s);
        d->data = new char[d->size];
        memcpy(d->data, s, d->size);
    }
    String(const String &other)
        : d(other.d)
    {
        ++d->refcount;
    }
    void swap(String &other) { std::swap(d, other.d); }
    String &operator=(const String &other) {
        String(other).swap(*this); // copy-swap trick
        return *this;
    }

And a sample function each for mutating and const methods:

    void detach() {
        if (d->refcount == 1)
            return;
        StringRep * newRep = new StringRep(*d);
        ++newRep->refcount;
        newRep->data = new char[d->size];
        memcpy(newRep->data, d->data, d->size);
        --d->refcount;
        d = newRep;
    }

    void resize(size_t newSize) {
        if (newSize == d->size)
            return;
        detach(); // mutator methods need to detach
        if (newSize < d->size) {
            d->size = newSize;
        } else if (newSize > d->size) {
           char * newData = new char[newSize];
           memcpy(newData, d->data, d->size);
           delete[] d->data;
           d->data = newData;
        }
    }

    char operator[](size_t idx) const {
        // no detach() here, we're in a const method
        return d->data[idx];
    }

};

So far so good. But what if we want to provide a mutable operator[]?

    char & operator[](size_t idx) {
        detach(); // make sure we're not changing all the copies
                  // in case the returned reference is written to
        return d->data[idx];
    }

This naïve implementation has a flaw. Consider the following scenario:

    String s1("Hello World!");
    char & W = s1[7]; // hold reference to the W
    assert( W == 'W' );
    const String s1(s2); // Shallow copy, but s1, s2 should now
                         // act independently
    W = 'w'; // modify s1 _only_ (or so we think)
    assert( W == 'w' ); // ok
    assert( s1[7] == 'w' ); // ok
    assert( s2[7] == 'W' ); // boom! s2[7] == 'w' instead!

To prevent this, String has to mark itself non-sharable when it hands out a reference to internal data, so that any copy that is taken from it is always deep. So, we need to adjust detach() and char & operator[] like this:

    void detach() {
        if (d->refcount == 1 && /*new*/ d->sharable)
            return;
        // rest as above
    }
    char & operator[](size_t idx) {
        detach();
        d->shareable = false; // new
        return d->data[idx];
    }

When to reset the shareable state back to true again? A common technique is to say that references to internal state are invalidated when calling a non-const method, so that's where shareable is reset back to true. Since every non-const function calls detach(), we can reset shareable there, so that detach() finally becomes:

    void detach() {
        if (d->refcount == 1 && d->sharable) {
            d->sharable = true; // new
            return;
        }
        d->sharable = true; // new
        StringRep * newRep = new StringRep(*d);
        ++newRep->refcount;
        newRep->data = new char[d->size+1];
        memcpy(newRep->data, d->data, d->size+1);
        --d->refcount;
        d = newRep;
    }
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文