Increasing usage for C++ new operators based on data model indexes?

VRonin

@elfring said in Increasing usage for C++ new operators based on data model indexes?:

How would you like to clarify a possible mapping from data model indexes to pointers further?

That's what we are asking you to propose.
We can't think of a way unfortunately

elfring

We can't think of a way unfortunately

Why do you stumble on limitations in your imaginations here?

sierdzio

@elfring said in Increasing usage for C++ new operators based on data model indexes?:

Unfortunately, I could not extract corresponding indications of understanding for my proposal so far.

Because you have not proposed anything. Show an API and it will be judged. Show a usage example of that API and it will help us know if the API is convenient. Measure with benchmark and we'll know if it improves performance.

Without concrete foundations, any idea can be argued endlessly without result.

J.Hilk

@elfring said in Increasing usage for C++ new operators based on data model indexes?:

We can't think of a way unfortunately

Why do you stumble on limitations in your imaginations here?

I guess that will depend on this basic clarification:
Are you familiar with the usage of placement new?

VRonin

@elfring said in Increasing usage for C++ new operators based on data model indexes?:

Why do you stumble on limitations in your imaginations here?

Honestly I just think I'm not smart enough to get into this. It wouldn't be the first time. On the other hand I'd be really happy to see how it could be implemented so I could learn something new

elfring

Show an API and it will be judged.

Can this application programming interface be just “placement new” (which got the parameters “row” and “column” passed)?

VRonin

@elfring said in Increasing usage for C++ new operators based on data model indexes?:

Can this application programming interface be just “placement new” (which got the parameters “row” and “column” passed)?

See, I struggle already, what would the return type be? (void* is a bit useless...)

elfring

See, I struggle already, what would the return type be?

C++ new operators are returning non-void-pointer types, don't they?

VRonin

I still can't see a way forward.
The simplest example would probably be QStringListModel. Could you help me understand how the placement new operator would work in that case?

elfring

Could you help me understand how the placement new operator would work in that case?

Can you understand already that “placement new” provides a pointer to an existing object?

VRonin

Yes, I can't see a safe way to use that pointer though

elfring

Yes,

I find this answer confusing in combination with the subsequent information.

I can't see a safe way to use that pointer though

You are used to the application of ordinary pointers.

auto x(new my_ball);

How many ball variants would you manage by your QStringListModel example?

VRonin

of, let's say you have a new that takes the row as an int parameter (QStringListModel has only 1 column).

I imagine that the implementation would check that the argument is within the range (row>=0 && row < lst.size() ) and then return something like &lst[row] (which is of type QString*).

Now we are back to the point we discussed here. How can we make sure that if the QString is modified then the dataChanged signal is sent?

elfring

of, let's say you have a new that takes the row as an int parameter (QStringListModel has only 1 column).

I imagine that the implementation would check that the argument is within the range (row>=0 && row < lst.size()) and then return something like &lst[row] (which is of type QString*).

This kind of feedback fits also to my imaginations.

How can we make sure that if the QString is modified then the dataChanged signal is sent?

Corresponding solutions will become interesting if you would like to modify the determined string object at all.

VRonin

@elfring said in Increasing usage for C++ new operators based on data model indexes?:

Corresponding solutions will become interesting

I agree but, once again I have no idea how to implement solutions. Do you?

elfring

…, once again I have no idea how to implement solutions.

I find this hard to believe. It might take another while until you feel more comfortable with related software design approaches.

A class can still offer functions which perform a specific change alone (as before the programming interface extension).
The user class should take responsibility for mutable C++ references (as usual). Will it put special function calls into destructor implementations?

VRonin

I find this hard to believe.

I'm not joking, I really can't think of a decent way

The user class should take responsibility for mutable C++ references

I disagree. This is a recipe for disaster

A class can still offer functions which perform a specific change alone

This might work for QStringListModel as all the elements are QString but as soon as you move just 1 step further and look at QListModel (the model behind QListWidget) where the stored data can be of any type, even a custom one defined by the user, your argument kinda falls apart, doesn't it?

kshegunov

@elfring said in Increasing usage for C++ new operators based on data model indexes?:

Does your software development experience include the usage of placement new?

Yes, but then I wonder does yours?

You are used to the application of ordinary pointers.
auto x(new my_ball);
How many ball variants would you manage by your QStringListModel example?

You don't seem to understand that the model is the boundary between the application-level code (i.e. user programmers) and the system-level code (for brevity only, it's the Qt library not the whole system). At that boundary the system code has to provide the means for the application code to map the data, and at the same time the library provides the display of said data.

At the point when the system is compiled the application-level code does not exist, so the system-level programmer (in this case the Qt Project contributor) can not and will not use anything of type that's unknown to the system. Unknown types include every user type the application provides itself, granted the exception the system has put in place a way for the type to be made known to the system. The latter is done through the meta-type system in Qt, and QVariant is aware of it.

Is your ball known (i.e. defined) when the models are developed? Of course not. Then the models can't in any conceivable way create that type. The models are generic and use QVariant so they can map multitude of types, not only your own ball.
Again, provide code that demonstrates your idea, so we can have a reasonable discussion.

elfring

This is a recipe for disaster

How many questionable applications do you notice then for the QVector class (for comparison)?

…, your argument kinda falls apart, doesn't it?

This model is for private use by the widget so far, isn't it?
Can you eventually get a desire to fiddle with list elements from a data model directly?

VRonin

@elfring said in Increasing usage for C++ new operators based on data model indexes?:

How many questionable applications do you notice then for the QVector class (for comparison)?

QVector is not a QObject subclass. it doesn't have to take care of sending signals to notify other parts of the program that something changed/was added/was removed/was moved.

This model is for private use by the widget so far, isn't it?

No. Absolutely not. I often use (and abuse) the model framework even in application that do not have a view.
It's also used in QML.

Can you eventually get a desire to fiddle with list elements from a data model directly?

I don't because I realise how badly it can break the entire framework. The internals of the data model should be handled by the model only, not get exposed otherwise it becomes simply unmanageable