When this feature https://bugreports.qt-project.org/browse/QTBUG-7287 will be released in Qt?
When this feature https://bugreports.qt-project.org/browse/QTBUG-7287 will be released in Qt?
How should we know?
If you have a problem, CUT and PASTE your code. Do not retype or simplify it. Give a COMPLETE and COMPILABLE example of your problem. Otherwise we are all guessing the problem from a fabrication where relevant details are often missing.
If someone finishes the patch, including the documentation, gets it past the basic code review process and argues the case for having it in the first place then it may get into a future Qt. Since nobody has touched the bug since 2010 I don't think anyone's need to scratch this itch is strong enough.
But without this functional - Qt shared pointer mechanizm is no full - it's not useful!! I port small tree class from boost to Qt, some like this
class TreeNode
{
public:
void addChild(QSharedPointer<TreeNode> p);
private:
QWeakPointer _parent;
QVector<QSharedPointer<TreeNode>> _childs;
};
inside method addChild(boost realization) new child TreeNode field _parent was assigned to shared_from_this - in Qt realization i can't do this.
Besides TreeNode is parent class to other types and they can add child nodes themself. So I need to rewrite common architecture of my application - I don't want do this.
So implement something with the same functionality. However I don't see why you can't get the same behaviour with just QSharedPointer and QWeakPointer. I don't see a need for any other pointers here.
Isn't it enough to just keep a weak pointer to itself in the object and promote it to strong ref if needed?
I have an alternative approach in mind if the weak pointer approach doesn't work.
Last edited by wysota; 19th November 2012 at 06:32.
oh my god facepalm.gif
Simple realization of addChild
Qt Code:
TreeNode::addChild(boost::shared_ptr<TreeNode> p) { if (!p._parent.expired()) throw std::runtime_error("TreeNode can't have multiple parents!"); p._parent = shared_from_this(). //!!!!!!!!! _childs.push_back(p); }To copy to clipboard, switch view to plain text mode
That's a bit like saying the C++ standard library is not useful because it does not have a "shared_from_this" mechanism either. Clearly that's why Boost implemented the functionality. You can use the Boost shared_ptr/weak and shared_from_this with a program that also uses Qt, so I'm not sure where the real problem is here.But without this functional - Qt shared pointer mechanizm is no full - it's not useful!!
Fun ) C++ standard library have "shared_from_this" mechanism
http://en.cppreference.com/w/cpp/mem...ared_from_this
Yes it was written in this way(boost + Qt) but I don't like code style mixing, so I rewrote it in clear Qt, because Qt no uses default c/c++ code style like in stl orClearly that's why Boost implemented the functionality. You can use the Boost shared_ptr/weak and shared_from_this with a program that also uses Qt, so I'm not sure where the real problem is here.
boost. It's difficult to support projects with multiple codestyles - it's very bad practice.
If I want such constructions then I usually implement "explicit sharing" like approach. I have a public object that acts "like a pointer" and private object that holds the data. It is the private object that is shared and copying the public object only increases reference count of the private component. Then I don't need pointers to the public object because I can always copy it and destroying the last instance of the public object also destroys the private component.
Qt Code:
class Object { public: Object() { d = new ObjectPrivate; } Object(const Object &other) : d(other.d){ } int x() const { return d->x; } void setX(int x) { d->x = x; } Object childAt(int i) const { return d->children.at(i); } void addChild(Object o) { d->children.append(o); o.d->parent = *this; } Object& operator=(const Object &other) { d = other.d; return *this;} private: QSharedPointer<ObjectPrivate> d; }; class ObjectPrivate { public: int x; Object parent; QList<Object> children; };To copy to clipboard, switch view to plain text mode
Building a tree from such object is trivial then. The construction is more "OOP-ish" than using pointers with the exception that creating a copy of the object doesn't actually make a copy of the data (which is ok in this case).
Yes, it's a kind of pimpl (not completely because there is no "implementation" in the private component, just data). I call this construction a "pointer without pointers".
Could be, I didn't test the code before posting.But I see BUG in this code ) - it seems recursive parent destruction - you must use QWeakPointer for parent.
Bookmarks