Increasing usage for C++ new operators based on data model indexes?
-
Can you think of an example code, and paste it below, where it would?
I suggest to take another look at a specific implementation detail: How many function calls do you need finally to get access to a member variable within a customised data model so far?
wrote on 16 Oct 2018, 12:03 last edited by VRonin@elfring said in Increasing usage for C++ new operators based on data model indexes?:
How many function calls do you need finally to get access to a member variable within a customised data model so far?
2 chained.
QModelIndex::dataandQVariant::value<T>. e.g.:index.data().value<QString>();. Don't think you can do better.
Can you show us how would yournewimplementation look? Call this a test. You haven't wrote a single line of code in all your posts. I want to check that at least you have a rough idea of what you are talking about -
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
How many function calls do you need finally to get access to a member variable within a customised data model so far?
2 chained.
QModelIndex::dataandQVariant::value<T>. e.g.:index.data().value<QString>();. Don't think you can do better.
Can you show us how would yournewimplementation look? Call this a test. You haven't wrote a single line of code in all your posts. I want to check that at least you have a rough idea of what you are talking aboutwrote on 16 Oct 2018, 13:09 last edited byDon't think you can do better.
I imagine that a single function call will be a bit nicer. It can be that it will still need to combine the other mentioned functions.
(Reminder: The usage of the function “QVariant::value” is “unsafe” for non-core data types so far, isn't it?)You haven't wrote a single line of code in all your posts.
- I find this information partly inappropriate because I contributed a (questionable) test case in this forum.
- Source code might distract from the really relevant software development ideas, doesn't it?
Can you show us how would your
newimplementation look?Did other information sources show in sufficient ways already how such a function can be written?
-
Don't think you can do better.
I imagine that a single function call will be a bit nicer. It can be that it will still need to combine the other mentioned functions.
(Reminder: The usage of the function “QVariant::value” is “unsafe” for non-core data types so far, isn't it?)You haven't wrote a single line of code in all your posts.
- I find this information partly inappropriate because I contributed a (questionable) test case in this forum.
- Source code might distract from the really relevant software development ideas, doesn't it?
Can you show us how would your
newimplementation look?Did other information sources show in sufficient ways already how such a function can be written?
wrote on 16 Oct 2018, 13:42 last edited by@elfring said in Increasing usage for C++ new operators based on data model indexes?:
I find this information partly inappropriate because I contributed a (questionable) test case in this forum.
This is a great starting point. Let's assume the overloaded
newexisted. How would you use it in your example?Source code might distract from the really relevant software development ideas, doesn't it?
No, it really helps focusing on the problem, what really matters and what is overhead.
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
I find this information partly inappropriate because I contributed a (questionable) test case in this forum.
This is a great starting point. Let's assume the overloaded
newexisted. How would you use it in your example?Source code might distract from the really relevant software development ideas, doesn't it?
No, it really helps focusing on the problem, what really matters and what is overhead.
wrote on 16 Oct 2018, 14:15 last edited byHow would you use it in your example?
I would not use extra statements in the implementation of the constructor from the class “my_views” because this test case tried to check other details.
No, it really helps focusing on the problem, what really matters and what is overhead.
I prefer an other clarification approach.
Which names can you imagine for functions which determine a pointer data type for a model index?
-
How would you use it in your example?
I would not use extra statements in the implementation of the constructor from the class “my_views” because this test case tried to check other details.
No, it really helps focusing on the problem, what really matters and what is overhead.
I prefer an other clarification approach.
Which names can you imagine for functions which determine a pointer data type for a model index?
wrote on 16 Oct 2018, 14:23 last edited by@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Which names can you imagine for functions which determine a pointer data type for a model index?
userType()as already usedTo clarify a single index can contain multiple data points of non-homogeneous data type
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Which names can you imagine for functions which determine a pointer data type for a model index?
userType()as already usedTo clarify a single index can contain multiple data points of non-homogeneous data type
wrote on 16 Oct 2018, 14:48 last edited byuserType()as already usedThis function returns the data type “int”.
What would you like to say for pointers within data models?To clarify a single index can contain multiple data points of non-homogeneous data type
This information seems to point an other software development concern out.
Would you like to introduce another case distinction? -
userType()as already usedThis function returns the data type “int”.
What would you like to say for pointers within data models?To clarify a single index can contain multiple data points of non-homogeneous data type
This information seems to point an other software development concern out.
Would you like to introduce another case distinction?wrote on 17 Oct 2018, 07:13 last edited by@elfring said in Increasing usage for C++ new operators based on data model indexes?:
What would you like to say for pointers within data models?
While my point is that you shouldn't use pointers as data because it create unclear ownership of that piece of memory, this constructor allows you to specify the usertype you want that pointer to be identified by
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
This function returns the data type “int”.
In C or C++ there's no alternative. You can't have a function that changes return type based on its body. The only way to downcast safely is to keep a track of what type you want to return (here an integer that represent the return value of
qMetaTypeId<T>()).This information seems to point an other software development concern out.
Would you like to introduce another case distinction?There's nothing new to introduce, different arguments to
QModelIndex::datareturn different data roles. -
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
What would you like to say for pointers within data models?
While my point is that you shouldn't use pointers as data because it create unclear ownership of that piece of memory, this constructor allows you to specify the usertype you want that pointer to be identified by
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
This function returns the data type “int”.
In C or C++ there's no alternative. You can't have a function that changes return type based on its body. The only way to downcast safely is to keep a track of what type you want to return (here an integer that represent the return value of
qMetaTypeId<T>()).This information seems to point an other software development concern out.
Would you like to introduce another case distinction?There's nothing new to introduce, different arguments to
QModelIndex::datareturn different data roles.wrote on 17 Oct 2018, 07:55 last edited byWhile my point is that you shouldn't use pointers as data because it create unclear ownership of that piece of memory, …
This is one way of thinking around the strict usage of value objects while I would prefer to avoid unnecessary data transfers as much as possible.
The ownership information can be managed also by other means, can't it?The only way to downcast safely is to keep a track of what type you want to return …
I imagine that additional software design options can be relevant here.
…, different arguments to QModelIndex::data return different data roles.
- “Data copies” are returned for each possible role.
- Can any function provide a reference (and not a pointer) for a specific object within this data model?
-
While my point is that you shouldn't use pointers as data because it create unclear ownership of that piece of memory, …
This is one way of thinking around the strict usage of value objects while I would prefer to avoid unnecessary data transfers as much as possible.
The ownership information can be managed also by other means, can't it?The only way to downcast safely is to keep a track of what type you want to return …
I imagine that additional software design options can be relevant here.
…, different arguments to QModelIndex::data return different data roles.
- “Data copies” are returned for each possible role.
- Can any function provide a reference (and not a pointer) for a specific object within this data model?
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
I would prefer to avoid unnecessary data transfers as much as possible
Recommended reading: John Carmack's take on functional programming
-
While my point is that you shouldn't use pointers as data because it create unclear ownership of that piece of memory, …
This is one way of thinking around the strict usage of value objects while I would prefer to avoid unnecessary data transfers as much as possible.
The ownership information can be managed also by other means, can't it?The only way to downcast safely is to keep a track of what type you want to return …
I imagine that additional software design options can be relevant here.
…, different arguments to QModelIndex::data return different data roles.
- “Data copies” are returned for each possible role.
- Can any function provide a reference (and not a pointer) for a specific object within this data model?
wrote on 17 Oct 2018, 08:37 last edited by@elfring said in Increasing usage for C++ new operators based on data model indexes?:
I imagine that additional software design options can be relevant here.
I haven't seen any better solution ever in my life
The ownership information can be managed also by other means, can't it?
Yes but as I said it becomes unclear. How can you assure a slot connected to, for example,
dataChangedis not accessing memory the owner already deleted?“Data copies” are returned for each possible role.
And this is the key point you don't understand. Qt uses a very cheap copy method (the implicit sharing) that is a basically a fancy
std::shared_ptr. Copying by value astd::shared_ptrdoes not copy the data pointed by it.
This covers any native and almost all Qt classes. Copying any of them by value has performance not significantly different from copying a pointer to those classes. Qt also give you the tools to apply that technology to your classes.
This means that all operations that you call “Data copies” are actually copying a pointer (ormemcpyup to 64 bits for native types) and adding 1 to a reference counter. As discussed above smart pointers and reference counters are the direction modern C++ is moving to.You can still think the "good old way" was better and that's fine but that can't influence the design of other projects that decide to go the "modern way"
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
I imagine that additional software design options can be relevant here.
I haven't seen any better solution ever in my life
The ownership information can be managed also by other means, can't it?
Yes but as I said it becomes unclear. How can you assure a slot connected to, for example,
dataChangedis not accessing memory the owner already deleted?“Data copies” are returned for each possible role.
And this is the key point you don't understand. Qt uses a very cheap copy method (the implicit sharing) that is a basically a fancy
std::shared_ptr. Copying by value astd::shared_ptrdoes not copy the data pointed by it.
This covers any native and almost all Qt classes. Copying any of them by value has performance not significantly different from copying a pointer to those classes. Qt also give you the tools to apply that technology to your classes.
This means that all operations that you call “Data copies” are actually copying a pointer (ormemcpyup to 64 bits for native types) and adding 1 to a reference counter. As discussed above smart pointers and reference counters are the direction modern C++ is moving to.You can still think the "good old way" was better and that's fine but that can't influence the design of other projects that decide to go the "modern way"
wrote on 17 Oct 2018, 09:11 last edited byAnd this is the key point you don't understand.
I got special software development views around the handling of data copies.
… that can't influence the design of other projects that decide to go the "modern way"
I find that it can be more important to distinguish an other design aspect than “software modernisation” here.
I would occasionally like to get direct access to some memory locations also by the general programming interface of data models.The class “std::shared_ptr” supports the member functions “get” and “operator[]”.
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
An item can be added to a model. Its position is identified by a corresponding model index, isn't it?
yes but the item exists even if no index points to it. just like an element in space exists even if nothing points to it
A pointer from the heap can be used together with a simple index for a buffer (an array).
I don't see ho this is related
Do Qt data models manage just vectors of pointers internally?
No, you are free to design the internals however you want
Can the mentioned coordinate be connected then with a pointer for a specific object within the data model in a similar way?
the coordinate "is" the pointer. the point being that given a
QModelIndexthe model can map 1:1 an item in its internal structure.Such descriptions can be generally helpful.
The pdf book I linked should be a great starting point
wrote on 24 Oct 2018, 13:58 last edited bythe coordinate "is" the pointer.
Will software libraries evolve further around the suggestion “Add support for usage of placement new together with data model indexes”?
-
the coordinate "is" the pointer.
Will software libraries evolve further around the suggestion “Add support for usage of placement new together with data model indexes”?
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Will software libraries evolve further around the suggestion “Add support for usage of placement new together with data model indexes”?
No they will not.
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Will software libraries evolve further around the suggestion “Add support for usage of placement new together with data model indexes”?
No they will not.
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Why do you think in this direction?
Experience.
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Why do you think in this direction?
Experience.
wrote on 25 Oct 2018, 05:27 last edited byDoes your software development experience include the usage of placement new?
-
wrote on 25 Oct 2018, 07:57 last edited by
Does your software development experience include the usage of
QAbstractItemModel?I wouldn't question @kshegunov 's abilities as he's firmly in the top tier of developers contributing on this forum.
-
Does your software development experience include the usage of
QAbstractItemModel?I wouldn't question @kshegunov 's abilities as he's firmly in the top tier of developers contributing on this forum.
wrote on 25 Oct 2018, 08:45 last edited byDoes your software development experience include the usage of
QAbstractItemModel?My knowledge is growing also in this software area.
… he's firmly in the top tier of developers contributing on this forum.
This is fine.
Our experiences are varying in several areas, don't they?
Understanding difficulties can happen then when someone (like me) dares to present special development ideas.
-
Does your software development experience include the usage of
QAbstractItemModel?My knowledge is growing also in this software area.
… he's firmly in the top tier of developers contributing on this forum.
This is fine.
Our experiences are varying in several areas, don't they?
Understanding difficulties can happen then when someone (like me) dares to present special development ideas.
wrote on 25 Oct 2018, 08:59 last edited by@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Understanding difficulties can happen then when someone (like me) dares to present special development ideas.
Sorry if it came out wrongly before, we are not against new development ideas at all, not on this forum and not in the Qt Project.
I think what is clear from the discussion above is that nobody here can think of an elegant, efficient, functional and safe way to introduce the concept you suggest in the
QAbstractItemModel(or any of its subclasses) interface.
Having said that, you are correct by sayingOur experiences are varying in several areas, don't they?
So our point is, if you have an idea for an implementation then please go ahead and propose it to the community. I'd be very happy to participate in the review process of such an innovation as well as I might end up learning something new (punt not intended)
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Understanding difficulties can happen then when someone (like me) dares to present special development ideas.
Sorry if it came out wrongly before, we are not against new development ideas at all, not on this forum and not in the Qt Project.
I think what is clear from the discussion above is that nobody here can think of an elegant, efficient, functional and safe way to introduce the concept you suggest in the
QAbstractItemModel(or any of its subclasses) interface.
Having said that, you are correct by sayingOur experiences are varying in several areas, don't they?
So our point is, if you have an idea for an implementation then please go ahead and propose it to the community. I'd be very happy to participate in the review process of such an innovation as well as I might end up learning something new (punt not intended)
wrote on 25 Oct 2018, 09:06 last edited by…, if you have an idea for an implementation then please go ahead and propose it to the community.
I guess that progress will depend on this basic clarification:
Are you familiar with the usage of placement new?
