Increasing usage of references for non-value objects?

JKSH

@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.

elfring

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?
1. Call a function like “QStandardItem::data” so that you get a QVariant object.
2. 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)?

JKSH

@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 or QAbstractTableModel. I don't think QStandardItemModel is well-suited for handling custom, complex data types.

elfring

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?

JKSH

@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

Will any extensions make software development easier here?

I don't think so.

I am curious on how needed extensions can eventually move into Qt software libraries.

JKSH

@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?

JKSH

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?

elfring

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

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?

JKSH

@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.

elfring

how can you emit the "itemChanged()" signal?

I would use a simple function call for this purpose.
Are you looking for any other answer?

VRonin

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

JKSH

@elfring said in Increasing usage of references for non-value objects?:

how can you emit the "itemChanged()" signal?

I would use a simple function call for this purpose.
Are you looking for any other answer?

I need you to think about it some more.

Imagine these methods become available in a future version of Qt:

QVariant& QStandardItem::dataRef(int role)
void* QVariant::internalPointer()

These are the kinds of "extensions" that you wanted when you said "Increasing usage of references for non-value objects" right?

With these functions, are you sure you can modify the data inside a QStandardItem without copying anything AND emit the required signal? Write some example code to try it.

elfring

Imagine these methods become available in a future version of Qt:

I guess that they can become useful for protected member functions.

These are the kinds of "extensions" that you wanted when you said "Increasing usage of references for non-value objects" right?

These suggestions can eventually fit to my imaginations. The mapping of (internal) data to custom information might need C++ function templates.

…, are you sure you can modify the data inside a QStandardItem without copying anything AND emit the required signal?

I propose to distinguish better between efficient data access and signal transmission for the discussed use cases.

kshegunov

@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.

And factories to create those objects too, right? Sounds more like Java. There's no reason to throw abstractions over simple classes that don't need them. Factories for the sake of factories and interfaces for the sake of interfaces is what Java does, it's verbose and slow and gives you nothing in return. There's a factory here and there and an interface here and there in Qt, but where it is needed, not just for the sole purpose of implementing patterns. To finish that rant off - why do you want to force heap allocations onto me? I prefer and use the stack wherever possible as it's faster and safer, you now want me to new every single object I create?

Model adaptors

To what end? Adapters for what exactly? You have proxy models, and models are (almost) perfectly matched to the views' interfaces, so what is that you want an adapter for? ... and you can always write your own if you need it to match your own class' interfaces.

Occasional Qt object construction without default parameters

Practically all Qt classes allow for default constructors. As for the default parameters themselves - it's just an implementation detail that's moot here.

If you have explicitly concrete examples of why any of the above is needed, I'm all ears, otherwise this is simply a theoretical debate with very little practical relevance.

elfring

…, you now want me to new every single object I create?

No. - But a lot of objects are generated by this operator as usual.

You have proxy models, …

How do you think about a test case for the topic “Support for QStandardItem proxies?” then?

If you have explicitly concrete examples of why any of the above is needed, I'm all ears, …

Would you like to take another look at a feature request like “Support for object creation based on constructors with parameters without default values”?

kshegunov

@elfring said in Increasing usage of references for non-value objects?:

No.

Then don't.

But a lot of objects are generated by this operator as usual.

I may usually drink coffee, but this doesn't mean I only drink coffee, does it?

How do you think about a test case for the topic “Support for QStandardItem proxies?” then?

Formally speaking the item delegates are already adapters, so I don't follow your point.

Would you like to take another look at a feature request like “Support for object creation based on constructors with parameters without default values”?

I have no idea why you want to force non-default-constructable objects to the designer. I see no gain in even trying to do such a thing, much less what would be the point of enforcing it ...

elfring

Formally speaking the item delegates are already adapters, so I don't follow your point.

Do you prefer to fiddle with delegates instead of adjusting data models by proxies (for simple displays)?

I have no idea why you want to force non-default-constructable objects to the designer.

Do you find any of the linked information helpful anyhow?

JKSH

@elfring said in Increasing usage of references for non-value objects?:

Imagine these methods become available in a future version of Qt:

I guess that they can become useful for protected member functions.

...

These suggestions can eventually fit to my imaginations.

Question: Are these are the kinds of "extensions" that you wanted when you said "Increasing usage of references for non-value objects"? If not, then please write some example code to show us your proposal. Without this, it is very difficult to discuss things.

…, are you sure you can modify the data inside a QStandardItem without copying anything AND emit the required signal?

I propose to distinguish better between efficient data access and signal transmission for the discussed use cases.

You are asking for the API to be changed to increase efficiency, but you must also realize this change makes the API design less intuitive which increases the risk of errors. (see @VRonin's post: "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" ) This is also considered premature optimization.

QStandardItemModel is a convenience class, so intuitive design is much more important than efficiency here.