Increasing usage for C++ new operators based on data model indexes?
-
…, however I still don't see how you're going to have a generic type (i.e.
QAbstractItemModel) that deals with concrete types it does know nothing about ...Various data structures are accessible over pointers (or customised indexes?).
Does the class “QVariant” provide also a programming interface for pointer data types?
…, the placement new if you're crazy enough to build your own heap manager (or for some very specific similar purposes), …
I am trying to increase the software development attention for the latter.
wrote on 15 Oct 2018, 10:54 last edited by VRonin@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Does the class “QVariant” provide also a programming interface for pointer data types?
Yes using
QVariant::fromValueor via the constructor if the type is aQObjectsubclass.
hic sunt leones though as you need to make clear in your logic who owns the items pointed. In general aQVariantcontaining a owning pointer is a ticking time bomb toward memory leak and/or double deletion.I prefer to avoid null pointers which can eventually be returned by such a cast operation.
If you are certain of the downcast type you can even use
static_castand forget about null pointers -
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Does the class “QVariant” provide also a programming interface for pointer data types?
Yes using
QVariant::fromValueor via the constructor if the type is aQObjectsubclass.
hic sunt leones though as you need to make clear in your logic who owns the items pointed. In general aQVariantcontaining a owning pointer is a ticking time bomb toward memory leak and/or double deletion.I prefer to avoid null pointers which can eventually be returned by such a cast operation.
If you are certain of the downcast type you can even use
static_castand forget about null pointerswrote on 15 Oct 2018, 11:31 last edited byIn general a
QVariantcontaining a owning pointer is a ticking time bomb toward memory leak and/or double deletion.- The safe handling of object lifetimes is a general software development challenge.
- But this class is the only way to get data from a model so far, isn't it?
If you are certain of the downcast type you can even use static_cast and forget about null pointers
Can it be more convenient to let a C++ new operator (which can work also with extra allocation parameters directly) perform the desired data type conversion?
-
In general a
QVariantcontaining a owning pointer is a ticking time bomb toward memory leak and/or double deletion.- The safe handling of object lifetimes is a general software development challenge.
- But this class is the only way to get data from a model so far, isn't it?
If you are certain of the downcast type you can even use static_cast and forget about null pointers
Can it be more convenient to let a C++ new operator (which can work also with extra allocation parameters directly) perform the desired data type conversion?
wrote on 15 Oct 2018, 11:53 last edited by@elfring said in Increasing usage for C++ new operators based on data model indexes?:
The safe handling of object lifetimes is a general software development challenge.
But this class is the only way to get data from a model so far, isn't it?Yes, what I'm saying is that if you want to store a pointer in a
QVariantyou probably want a non-owning pointer. Keep the owning pointer somewhere else.Can it be more convenient to let a C++ new operator (which can work also with extra allocation parameters directly) perform the desired data type conversion?
No, new allocates memory.
static_castjust tell the compiler to treat a piece of memory as it was a different type.But this class is the only way to get data from a model so far, isn't it?
And here we come back to the fact that having your objects implicitly shared stored in a
QVariantdirectly is much more practical and has a negligible impact on performance -
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
The safe handling of object lifetimes is a general software development challenge.
But this class is the only way to get data from a model so far, isn't it?Yes, what I'm saying is that if you want to store a pointer in a
QVariantyou probably want a non-owning pointer. Keep the owning pointer somewhere else.Can it be more convenient to let a C++ new operator (which can work also with extra allocation parameters directly) perform the desired data type conversion?
No, new allocates memory.
static_castjust tell the compiler to treat a piece of memory as it was a different type.But this class is the only way to get data from a model so far, isn't it?
And here we come back to the fact that having your objects implicitly shared stored in a
QVariantdirectly is much more practical and has a negligible impact on performancewrote on 15 Oct 2018, 13:01 last edited bynew allocates memory.
Only if you do not use the construct “placement new”.
And here we come back to the fact that having your objects implicitly shared stored in a QVariant directly is much more practical
I guess that the run time consequences are more interesting then for the distinction if only pointers are transferred or complete “value objects” are copied.
and has a negligible impact on performance
There are software applications where more data transfers might not have a directly noticeable effect. But I guess that some C++ programmers have got a strong focus on software efficiency.
-
new allocates memory.
Only if you do not use the construct “placement new”.
And here we come back to the fact that having your objects implicitly shared stored in a QVariant directly is much more practical
I guess that the run time consequences are more interesting then for the distinction if only pointers are transferred or complete “value objects” are copied.
and has a negligible impact on performance
There are software applications where more data transfers might not have a directly noticeable effect. But I guess that some C++ programmers have got a strong focus on software efficiency.
This is getting pretty ridiculous ...
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Only if you do not use the construct “placement new”.
Yeah, which I have a creeping suspicion you haven't. The so called placement new is nothing more than going around calling constructors on a preallocated memory block. So where is this preallocated memory going to come from? It's going to materialize from the ether?
If you're intent on pushing this make-you-own-heap-for-models, I advise to create a proof-of-concept first, then we can have something to base a discussion on, otherwise - thanks but no thanks, I'm out of this conversation.
-
This is getting pretty ridiculous ...
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Only if you do not use the construct “placement new”.
Yeah, which I have a creeping suspicion you haven't. The so called placement new is nothing more than going around calling constructors on a preallocated memory block. So where is this preallocated memory going to come from? It's going to materialize from the ether?
If you're intent on pushing this make-you-own-heap-for-models, I advise to create a proof-of-concept first, then we can have something to base a discussion on, otherwise - thanks but no thanks, I'm out of this conversation.
wrote on 15 Oct 2018, 13:22 last edited byThe so called placement new is nothing more than going around calling constructors on a preallocated memory block.
I agree on this aspect.
But can you pass a “model index” as another allocation parameter (for existing data) to this C++ operator?
-
new allocates memory.
Only if you do not use the construct “placement new”.
And here we come back to the fact that having your objects implicitly shared stored in a QVariant directly is much more practical
I guess that the run time consequences are more interesting then for the distinction if only pointers are transferred or complete “value objects” are copied.
and has a negligible impact on performance
There are software applications where more data transfers might not have a directly noticeable effect. But I guess that some C++ programmers have got a strong focus on software efficiency.
wrote on 15 Oct 2018, 13:24 last edited by VRonin@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Only if you do not use the construct “placement new”.
Is your plan to do exactly what
dynamic_castdoes but using anewoperator? I mean it's possible but I don't see why you'd want to do it. How would you implement it?guess that the run time consequences are more interesting then for the distinction if only pointers are transferred or complete “value objects” are copied.
There are software applications where more data transfers might not have a directly noticeable effect. But I guess that some C++ programmers have got a strong focus on software efficiency.@VRonin said in Increasing usage for C++ new operators based on data model indexes?:
having your objects implicitly shared
With implicitly shared objects, the distinction from a pointer to a complete value object when copying is just an operator++ on an
int. 1 atomic instruction. 100000 times more efficient than adynamic_cast.
If you want to go into memory difference it's 32bits more. If 32 bits break your design then it's the design itself that comes into question -
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Only if you do not use the construct “placement new”.
Is your plan to do exactly what
dynamic_castdoes but using anewoperator? I mean it's possible but I don't see why you'd want to do it. How would you implement it?guess that the run time consequences are more interesting then for the distinction if only pointers are transferred or complete “value objects” are copied.
There are software applications where more data transfers might not have a directly noticeable effect. But I guess that some C++ programmers have got a strong focus on software efficiency.@VRonin said in Increasing usage for C++ new operators based on data model indexes?:
having your objects implicitly shared
With implicitly shared objects, the distinction from a pointer to a complete value object when copying is just an operator++ on an
int. 1 atomic instruction. 100000 times more efficient than adynamic_cast.
If you want to go into memory difference it's 32bits more. If 32 bits break your design then it's the design itself that comes into questionwrote on 15 Oct 2018, 13:32 last edited byIs your plan to do exactly what
dynamic_castdoes but using anewoperator?Maybe.
But these C++ operations provide different functionality, don't they?
With implicitly shared objects, the distinction from a pointer to a complete value object when copying is just an operator++ on an
int.Will it become nicer to avoid (or reduce) even the influence of object reference counting?
-
Is your plan to do exactly what
dynamic_castdoes but using anewoperator?Maybe.
But these C++ operations provide different functionality, don't they?
With implicitly shared objects, the distinction from a pointer to a complete value object when copying is just an operator++ on an
int.Will it become nicer to avoid (or reduce) even the influence of object reference counting?
wrote on 15 Oct 2018, 14:39 last edited by@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Will it become nicer to avoid (or reduce) even the influence of object reference counting?
C++ is moving in the opposite direction actually. If you try to suggest replacing
std::shared_ptr(which is a pointer + a reference counter) with raw pointers on Stack Overflow you'd better bring a helmet and kevlar vest because you are going to get shot.
The ISO C++ style guide goes one step further and even discourages the use of owning raw pointer and suggest ownership encapsulation (an implicitly shared object behaves as a smart pointer). If you don't like it, good luck convincing Herb Sutter and Bjarne Stroustrup himself.But these C++ operations provide different functionality, don't they?
Yes but so far you did not highlight any need for custom allocation, your problems all seem to come from casting.
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Will it become nicer to avoid (or reduce) even the influence of object reference counting?
C++ is moving in the opposite direction actually. If you try to suggest replacing
std::shared_ptr(which is a pointer + a reference counter) with raw pointers on Stack Overflow you'd better bring a helmet and kevlar vest because you are going to get shot.
The ISO C++ style guide goes one step further and even discourages the use of owning raw pointer and suggest ownership encapsulation (an implicitly shared object behaves as a smart pointer). If you don't like it, good luck convincing Herb Sutter and Bjarne Stroustrup himself.But these C++ operations provide different functionality, don't they?
Yes but so far you did not highlight any need for custom allocation, your problems all seem to come from casting.
wrote on 15 Oct 2018, 16:08 last edited bybut so far you did not highlight any need for custom allocation,
I suggest to reconsider the software situation once more.
A pair of row and column values (data model index, address or coordinate) can be passed as a parameter to a C++ new operator.
You can choose then if you need to work with fresh objects (using dynamic memory allocation) or would like to reuse existing data.Is the usage of the construct “placement new” a kind of customised operation?
your problems all seem to come from casting.
I hope that specific software development challenges can be adjusted when the new operator call takes care of casting to the desired target (pointer) data type already.
-
but so far you did not highlight any need for custom allocation,
I suggest to reconsider the software situation once more.
A pair of row and column values (data model index, address or coordinate) can be passed as a parameter to a C++ new operator.
You can choose then if you need to work with fresh objects (using dynamic memory allocation) or would like to reuse existing data.Is the usage of the construct “placement new” a kind of customised operation?
your problems all seem to come from casting.
I hope that specific software development challenges can be adjusted when the new operator call takes care of casting to the desired target (pointer) data type already.
wrote on 15 Oct 2018, 17:09 last edited by@elfring said in Increasing usage for C++ new operators based on data model indexes?:
A pair of row and column values (data model index, address or coordinate) can be passed as a parameter to a C++ new operator.
You can choose then if you need to work with fresh objects (using dynamic memory allocation) or would like to reuse existing data.
Is the usage of the construct “placement new” a kind of customised operation?Once again, the model implementation might or might not allocate data. This should not be a problem of the API user.
Could you please provide a concrete example of what you are suggesting?
Otherwise we are just discussing of theory and nobody is gaining any value out of it.
I will not continue the discussion until you provide at least a code snippet -
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
A pair of row and column values (data model index, address or coordinate) can be passed as a parameter to a C++ new operator.
You can choose then if you need to work with fresh objects (using dynamic memory allocation) or would like to reuse existing data.
Is the usage of the construct “placement new” a kind of customised operation?Once again, the model implementation might or might not allocate data. This should not be a problem of the API user.
Could you please provide a concrete example of what you are suggesting?
Otherwise we are just discussing of theory and nobody is gaining any value out of it.
I will not continue the discussion until you provide at least a code snippetwrote on 15 Oct 2018, 17:27 last edited byCould you please provide a concrete example of what you are suggesting?
Does the software situation become really more challenging for passing a few extra parameters to a (member) function when it is “accidentally” (or intentionally) called “new”?
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
A pair of row and column values (data model index, address or coordinate) can be passed as a parameter to a C++ new operator.
You can choose then if you need to work with fresh objects (using dynamic memory allocation) or would like to reuse existing data.
Is the usage of the construct “placement new” a kind of customised operation?Once again, the model implementation might or might not allocate data. This should not be a problem of the API user.
Could you please provide a concrete example of what you are suggesting?
Otherwise we are just discussing of theory and nobody is gaining any value out of it.
I will not continue the discussion until you provide at least a code snippetwrote on 15 Oct 2018, 19:55 last edited by… concrete example of what you are suggesting?
- https://isocpp.org/wiki/faq/dtors#placement-new
- https://en.wikipedia.org/wiki/Placement_syntax
- https://stackoverflow.com/questions/222557/what-uses-are-there-for-placement-new
- https://www.geeksforgeeks.org/placement-new-operator-cpp/
- http://blog.aaronballman.com/2011/08/the-placement-new-operator/
- https://thispointer.com/whats-placement-new-operator-and-why-do-we-need-it/
- https://eli.thegreenplace.net/2011/02/17/the-many-faces-of-operator-new-in-c
- https://archive.org/details/TICPP2ndEdVolOne
-
The first link clearly states:
ADVICE: Don’t use this “placement new” syntax unless you have to. Use it only when you really care that an object is placed at a particular location in memory. For example, when your hardware has a memory-mapped I/O timer device, and you want to place a Clock object at that memory location.
In case of model indexes, there seems to be no need to use placement new.
-
The first link clearly states:
ADVICE: Don’t use this “placement new” syntax unless you have to. Use it only when you really care that an object is placed at a particular location in memory. For example, when your hardware has a memory-mapped I/O timer device, and you want to place a Clock object at that memory location.
In case of model indexes, there seems to be no need to use placement new.
wrote on 16 Oct 2018, 08:43 last edited byIn case of model indexes, there seems to be no need to use placement new.
- Do you care if customised model data were “placed at a particular location in memory”?
- How do you think about to get direct access to object data which are managed by a class like QVariant?
-
In case of model indexes, there seems to be no need to use placement new.
- Do you care if customised model data were “placed at a particular location in memory”?
- How do you think about to get direct access to object data which are managed by a class like QVariant?
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
In case of model indexes, there seems to be no need to use placement new.
- Do you care if customised model data were “placed at a particular location in memory”?
No I don't.
- How do you think about to get direct access to object data which are managed by a class like QVariant?
I don't understand the question. Accessing data of a QVariant is possible and trivial, if necessary.
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
In case of model indexes, there seems to be no need to use placement new.
- Do you care if customised model data were “placed at a particular location in memory”?
No I don't.
- How do you think about to get direct access to object data which are managed by a class like QVariant?
I don't understand the question. Accessing data of a QVariant is possible and trivial, if necessary.
wrote on 16 Oct 2018, 09:03 last edited byAccessing data of a QVariant is possible and trivial, if necessary.
Can the data access become more convenient (and safe) for customised data types?
-
Accessing data of a QVariant is possible and trivial, if necessary.
Can the data access become more convenient (and safe) for customised data types?
wrote on 16 Oct 2018, 09:53 last edited by@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Can the data access become more convenient (and safe) for customised data types?
No.
get->change->set is mildly less convenient but infinitely safer.Can you think of an example code, and paste it below, where it would?
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Can the data access become more convenient (and safe) for customised data types?
No.
get->change->set is mildly less convenient but infinitely safer.Can you think of an example code, and paste it below, where it would?
wrote on 16 Oct 2018, 10:44 last edited byCan 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?
-
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
30/116