Increasing usage of references for non-value objects?
-
Since most Qt objects are using implicit sharing I don't see that big problem here... http://doc.qt.io/qt-5/implicit-sharing.html
-
I don't see that big problem here...
There are also parts of data structures to consider which are not “implicitly shared”.
-
@elfring said in Increasing usage of references for non-value objects?:
There are also parts of data structures to consider which are not “implicitly shared”.
I can't follow you - when the object is implicit shared it doesn't matter if one of it's elements is implicit shared or not...
-
I can't follow you
I suggest to take another look according to growing data structure sizes.
- when the object is implicit shared it doesn't matter if one of it's elements is implicit shared or not...
- An object can contain further elements which are sharable.
- Custom data structure members might need special treatment, don't they?
-
An object can contain further elements which are sharable.
As i said above - as long as the object is implicit shared it does not matter at all.
@elfring said in Increasing usage of references for non-value objects?:
Custom data structure members might need special treatment
There you have full control over the data structure so you can do what you want with it e.g. returning it as const ref in getters or whatever.
-
@elfring said in Increasing usage of references for non-value objects?:
There is a data structure category which is known as “value object”. Copying of contents should often be avoided for other data types.
A lot of functions return objects as values while the usage of references would occasionally be preferred then. Can this software situation be improved anyhow also for the Qt class library?Can you give a few examples of problematic functions in Qt?
-
Can you give a few examples of problematic functions in Qt?
The Qt documentation provides the following information.
“…
Many C++ classes in Qt use implicit data sharing to maximize resource usage and minimize copying. Implicitly shared classes are both safe and efficient when passed as arguments, because only a pointer to the data is passed around, and the data is copied only if and when a function writes to it, i.e., copy-on-write.
…”Pointers belong to the category “value object”.
But the situation can become more interesting if you would need direct access for the data structures they refer to, can't it?Under which circumstances would you like to fiddle with C++ references any more?
-
@elfring said in Increasing usage of references for non-value objects?:
Can you give a few examples of problematic functions in Qt?
The Qt documentation provides the following information.
“…
Many C++ classes in Qt use implicit data sharing to maximize resource usage and minimize copying. Implicitly shared classes are both safe and efficient when passed as arguments, because only a pointer to the data is passed around, and the data is copied only if and when a function writes to it, i.e., copy-on-write.
…”Pointers belong to the category “value object”.
But the situation can become more interesting if you would need direct access for the data structures they refer to, can't it?Under which circumstances would you like to fiddle with C++ references any more?
I'm sorry, I can't understand you.
Let's start from the beginning. You said "A lot of functions return objects as values while the usage of references would occasionally be preferred then."
Now, please do these 2 steps:
- Name one function that returns objects as values.
- Describe how you can improve that function by using references.
-
Let's start from the beginning.
- Do you work with any data structures that are not implicitly shared?
- How do you think about the following use case?
- Call a function like “QStandardItem::data” so that you get a QVariant object.
- This object can eventually be converted to an instance of a custom data type by the function “QVariant::value”.
Would you like to avoid extra data copies there occasionally (when you try to modify the custom object in-place instead)?
-
@elfring said in Increasing usage of references for non-value objects?:
- Do you work with any data structures that are not implicitly shared?
Yes I do. When I implement a custom value object or data structure, I usually don't make it implicitly shared. Instead, I tend to store them as raw pointers or
shared_ptr
.- How do you think about the following use case?
- Call a function like “QStandardItem::data” so that you get a QVariant object.
- This object can eventually be converted to an instance of a custom data type by the function “QVariant::value”.
Would you like to avoid extra data copies there occasionally (when you try to modify the custom object in-place instead)?
Thanks, I think I've got a better understanding of what you want now. Your goal is to modify the data inside a
QStandardItem
without copying anything, is that right?So far, you're trying to achieving your goal by changing QVariant and/or changing QStandardItem
Let me propose an alternative solution: Subclass QStandardItem: https://forum.qt.io/topic/95037/support-for-constructing-qstandarditem-objects-from-qvariant-references/16
If you're willing to go further, I even recommend subclassing
QAbstractItemModel
orQAbstractTableModel
. I don't thinkQStandardItemModel
is well-suited for handling custom, complex data types. -
Your goal is to modify the data inside a
QStandardItem
without copying anything, is that right?Yes. - This is a software area where I am also looking for corresponding solutions.
I don't think
QStandardItemModel
is well-suited for handling custom, complex data types.- It is another useful programming interface, isn't it?
- Will any extensions make software development easier here?
-
@elfring said in Increasing usage of references for non-value objects?:
I don't think
QStandardItemModel
is well-suited for handling custom, complex data types.- It is another useful programming interface, isn't it?
Yes, it is a useful tool for certain use-cases.
Based on your requirements though, (custom data type + clean software design + no converting/copying data), other tools are better for your use-case.
- Will any extensions make software development easier here?
I don't think so.
-
@elfring said in Increasing usage of references for non-value objects?:
I am curious on how needed extensions can eventually move into Qt software libraries.
What extensions do you want? Adding a constructor (
QStandardItem::QStandardItem(const QVariant&, int)
) is discussed at https://forum.qt.io/topic/95037/support-for-constructing-qstandarditem-objects-from-qvariant-references -- do you have any others in mind? -
Back to the original topic of this post (Accessing internal data of a QStandardItem):
Imagine that an extension lets you get a reference/pointer to the internal data of
QStandardItemModel
. When you edit the data in-place, how will you notify the view that you have edited the data? -
do you have any others in mind?
Yes, of course.
- Programming interfaces which return pointers can be encapsulated so that null pointer checks will be performed at fewer source code places.
- Model adaptors
- Occasional Qt object construction without default parameters
-
@elfring said in Increasing usage of references for non-value objects?:
When you edit the data in-place, how will you notify the view that you have edited the data?
The signal “itemChanged” should be emitted, shouldn't it?
Good! You're right, the object needs to emit a signal to notify the view.
Next thing to think about: If you get a pointer/reference to the data inside a QStandardItem and you modify the object directly... how can you emit the "itemChanged()" signal?
@elfring said in Increasing usage of references for non-value objects?:
- Programming interfaces which return pointers can be encapsulated so that null pointer checks will be performed at fewer source code places.
- Model adaptors
- Occasional Qt object construction without default parameters
I'll have a look through these ideas and reply later.
-
You are over engineering.
You don't need to reinvent the wheel. Just make your custom data class use implicit sharing as well. This way you can extract it from a variant cheaply (only a pointer is copied).Modifying the internal object from outside the model and then emitting the dataChanged manually is a hack and a breach of S.O.L.I.D