Increasing usage for C++ new operators based on data model indexes?
-
yes but the item exists even if no index points to it.
Do software developers tend to create objects so they can work with them by a specific “address”?
I don't see ho this is related
The involved pointer manages information about the desired data type, doesn't it?
the coordinate "is" the pointer.
Do we come closer to a similar interpretation of the software situation?
the point being that given a
QModelIndexthe model can map 1:1 an item in its internal structure.Can this mapping become accessible also by a pointer which was provided by a C++ new operator?
The pdf book I linked should be a great starting point
Would you like to clarify the distribution status of the linked file?
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Do software developers tend to create objects so they can work with them by a specific “address”?
Yes, but the address is held by the internal structure, not by way of a
QModelIndex. Such internal structure is free to be whatever even a file, an SQL query, an item on the stack or one on the heap.The involved pointer manages information about the desired data type, doesn't it?
The
QModelIndexdoesn't own the data in any shape or form but other than that yes. In this case theQModelIndexwill hold anintindex (as row or column) so that it can be mapped 1:1 with the internal structure via an offset on the owning pointer that lives inside the modelDo we come closer to a similar interpretation of the software situation?
No because you think this pointers owns the data
Can this mapping become accessible also by a pointer which was provided by a C++ new operator?
Would you like to clarify the distribution status of the linked file?
I did not understand this questions, sorry
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Do software developers tend to create objects so they can work with them by a specific “address”?
Yes, but the address is held by the internal structure, not by way of a
QModelIndex. Such internal structure is free to be whatever even a file, an SQL query, an item on the stack or one on the heap.The involved pointer manages information about the desired data type, doesn't it?
The
QModelIndexdoesn't own the data in any shape or form but other than that yes. In this case theQModelIndexwill hold anintindex (as row or column) so that it can be mapped 1:1 with the internal structure via an offset on the owning pointer that lives inside the modelDo we come closer to a similar interpretation of the software situation?
No because you think this pointers owns the data
Can this mapping become accessible also by a pointer which was provided by a C++ new operator?
Would you like to clarify the distribution status of the linked file?
I did not understand this questions, sorry
Yes, but the address is held by the internal structure, …
Does this structure manage pointer data types for the model so that implicit data sharing will work for Qt classes?
No because you think this pointers owns the data
Not really for “QModelIndex” at the moment. - I can distinguish the properties of this class from the companion class “QPersistentModelIndex”.
Is another distinction needed between owning pointers and weak pointers?- Would anybody like to construct a C++ new operator for data models?
- Do you know any existing implementations for model storage allocators?
I did not understand this questions, sorry
How do you think about to recheck the distribution rights for book files?
-
Yes, but the address is held by the internal structure, …
Does this structure manage pointer data types for the model so that implicit data sharing will work for Qt classes?
No because you think this pointers owns the data
Not really for “QModelIndex” at the moment. - I can distinguish the properties of this class from the companion class “QPersistentModelIndex”.
Is another distinction needed between owning pointers and weak pointers?- Would anybody like to construct a C++ new operator for data models?
- Do you know any existing implementations for model storage allocators?
I did not understand this questions, sorry
How do you think about to recheck the distribution rights for book files?
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Does this structure manage pointer data types for the model so that implicit data sharing will work for Qt classes?
There is no imposed structure. It can be whatever you want.
Not really for “QModelIndex” at the moment. - I can distinguish the properties of this class from the companion class “QPersistentModelIndex”.
QPersistentModelIndexdoesn't own the data either, the only difference between the 2 is their response to changes in the position of the item they point. Returning to myQPointanalogyQModelIndexcan be seen as an absolute point in space, if the item at those coordinates move it will not follow, it will remain in that place,QPersistentModelIndexis a relative point and will move with the item it is pointingWould anybody like to construct a C++ new operator for data models?
Why would you want to?
Do you know any existing implementations for model storage allocators?
what is a "model storage allocator"?
How do you think about to recheck the distribution rights for book files?
I actually just googled the book title.
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Does this structure manage pointer data types for the model so that implicit data sharing will work for Qt classes?
There is no imposed structure. It can be whatever you want.
Not really for “QModelIndex” at the moment. - I can distinguish the properties of this class from the companion class “QPersistentModelIndex”.
QPersistentModelIndexdoesn't own the data either, the only difference between the 2 is their response to changes in the position of the item they point. Returning to myQPointanalogyQModelIndexcan be seen as an absolute point in space, if the item at those coordinates move it will not follow, it will remain in that place,QPersistentModelIndexis a relative point and will move with the item it is pointingWould anybody like to construct a C++ new operator for data models?
Why would you want to?
Do you know any existing implementations for model storage allocators?
what is a "model storage allocator"?
How do you think about to recheck the distribution rights for book files?
I actually just googled the book title.
Why would you want to?
The concrete target data types can vary while model indexes are resolved to QVariant objects as the default data.
A C++ new operator can provide a known pointer data type, can't it?what is a "model storage allocator"?
Some data structures in the C++ standard template library get such a parameter passed.
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Does this structure manage pointer data types for the model so that implicit data sharing will work for Qt classes?
There is no imposed structure. It can be whatever you want.
Not really for “QModelIndex” at the moment. - I can distinguish the properties of this class from the companion class “QPersistentModelIndex”.
QPersistentModelIndexdoesn't own the data either, the only difference between the 2 is their response to changes in the position of the item they point. Returning to myQPointanalogyQModelIndexcan be seen as an absolute point in space, if the item at those coordinates move it will not follow, it will remain in that place,QPersistentModelIndexis a relative point and will move with the item it is pointingWould anybody like to construct a C++ new operator for data models?
Why would you want to?
Do you know any existing implementations for model storage allocators?
what is a "model storage allocator"?
How do you think about to recheck the distribution rights for book files?
I actually just googled the book title.
-
Why would you want to?
The concrete target data types can vary while model indexes are resolved to QVariant objects as the default data.
A C++ new operator can provide a known pointer data type, can't it?what is a "model storage allocator"?
Some data structures in the C++ standard template library get such a parameter passed.
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
A C++ new operator can provide a known pointer data type, can't it?
If you mean that pointer to be
void *, then yes, formally. Howevervoid *(a.k.a. the "opaque pointer") is even worse, as you don't get any type safety with it.QVariantdoes the same thing, but more cleanly. It keeps taps on what data was put into it and even provides conversions through the meta type system.Some data structures in the C++ standard template library get such a parameter passed.
Are you willing to try and mix templates and
QObjects? If so, call me in, I want to watch the fireworks.It is just a function which should return a valid pointer for a storage location.
The model does not do storage! And that's what @VRonin has mentioned couple of times already. The model is your "map" to the data - what is located where, no more - no less.
Under which circumstances would C++ programmers call it like “new”?
Look, I get that you like
new, but the heap is approximately 10 (and sometimes more) times slower than the stack. There's no really conceivable reason for anyone to create the model index in the heap ... it just does not make any sense.Say you're working with points in 3d space - you have 3 coordinates that define the point (i.e. your structure/class has 3 members representing the coordinates), would you go around creating those objects representing points in the heap?
Read and abide by the Qt Code of Conduct
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
A C++ new operator can provide a known pointer data type, can't it?
If you mean that pointer to be
void *, then yes, formally. Howevervoid *(a.k.a. the "opaque pointer") is even worse, as you don't get any type safety with it.QVariantdoes the same thing, but more cleanly. It keeps taps on what data was put into it and even provides conversions through the meta type system.Some data structures in the C++ standard template library get such a parameter passed.
Are you willing to try and mix templates and
QObjects? If so, call me in, I want to watch the fireworks.It is just a function which should return a valid pointer for a storage location.
The model does not do storage! And that's what @VRonin has mentioned couple of times already. The model is your "map" to the data - what is located where, no more - no less.
Under which circumstances would C++ programmers call it like “new”?
Look, I get that you like
new, but the heap is approximately 10 (and sometimes more) times slower than the stack. There's no really conceivable reason for anyone to create the model index in the heap ... it just does not make any sense.Say you're working with points in 3d space - you have 3 coordinates that define the point (i.e. your structure/class has 3 members representing the coordinates), would you go around creating those objects representing points in the heap?
If you mean that pointer to be
void *, …No! - Must a C++ new operator provide a non-void pointer data type?
The model does not do storage!
It provides the generic programming interface for the desired data sources.
Derived classes will contain member variables which will manage storage in expected ways, won't they?Look, I get that you like
new, …C++ programmers are using this operator for various resource allocations.
I propose to increase the usage of the construct “placement new” also together with customised data models. -
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
A C++ new operator can provide a known pointer data type, can't it?
If you mean that pointer to be
void *, then yes, formally. Howevervoid *(a.k.a. the "opaque pointer") is even worse, as you don't get any type safety with it.QVariantdoes the same thing, but more cleanly. It keeps taps on what data was put into it and even provides conversions through the meta type system.Some data structures in the C++ standard template library get such a parameter passed.
Are you willing to try and mix templates and
QObjects? If so, call me in, I want to watch the fireworks.It is just a function which should return a valid pointer for a storage location.
The model does not do storage! And that's what @VRonin has mentioned couple of times already. The model is your "map" to the data - what is located where, no more - no less.
Under which circumstances would C++ programmers call it like “new”?
Look, I get that you like
new, but the heap is approximately 10 (and sometimes more) times slower than the stack. There's no really conceivable reason for anyone to create the model index in the heap ... it just does not make any sense.Say you're working with points in 3d space - you have 3 coordinates that define the point (i.e. your structure/class has 3 members representing the coordinates), would you go around creating those objects representing points in the heap?
@kshegunov said in Increasing usage for C++ new operators based on data model indexes?:
Look, I get that you like
new, but the heap is approximately 10 (and sometimes more) times slower than the stack.Just a question out of curiosity, because I remeber by instructor also telling me c++ heap allocation is slower than stack and slower than heap allocation in other languages.
Is there a different method in c++ to allocation memory instead of the standard
new? -
If you mean that pointer to be
void *, …No! - Must a C++ new operator provide a non-void pointer data type?
The model does not do storage!
It provides the generic programming interface for the desired data sources.
Derived classes will contain member variables which will manage storage in expected ways, won't they?Look, I get that you like
new, …C++ programmers are using this operator for various resource allocations.
I propose to increase the usage of the construct “placement new” also together with customised data models.@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Must a C++ new operator provide a non-void pointer data type?
It can provide whatever type you want it to, 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 ...It provides the generic programming interface for the desired data sources.
Indeed.
Derived classes will contain member variables which will manage storage in expected ways, won't they?
They may or may not. It's up to the user code to decide where and how the storage will be done. There may be no storage at all and the data to be fetched on the fly from someplace.
C++ programmers are using this operator for various resource allocations.
Many C++ programmers overuse this operator, especially those with limited experience.
I propose to increase the usage of the construct “placement new” also together with customised data models.
https://www.youtube.com/watch?v=iUQCFI02zZA
@J.Hilk said in Increasing usage for C++ new operators based on data model indexes?:
Just a question out of curiosity, because I remeber by instructor also telling me c++ heap allocation is slower than stack
It is. It's a call to the heap manager in the OS. The heap manager has to find a free place for your object before it can return you an address ...
A stack allocation is nothing on the other hand - you (rather the compiler) move the stack pointer to the appropriate offset from the stack base pointer and voila - you have memory. That also is the reason that you must know the size of the allocated object at compile time.and slower than heap allocation in other languages.
Nope!
Is there a different method in c++ to allocation memory instead of the standard new?
You have
*allocfrom the C runtime, the placement new if you're crazy enough to build your own heap manager (or for some very specific similar purposes), and of course you have my buddy - the stack.Read and abide by the Qt Code of Conduct
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Must a C++ new operator provide a non-void pointer data type?
It can provide whatever type you want it to, 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 ...It provides the generic programming interface for the desired data sources.
Indeed.
Derived classes will contain member variables which will manage storage in expected ways, won't they?
They may or may not. It's up to the user code to decide where and how the storage will be done. There may be no storage at all and the data to be fetched on the fly from someplace.
C++ programmers are using this operator for various resource allocations.
Many C++ programmers overuse this operator, especially those with limited experience.
I propose to increase the usage of the construct “placement new” also together with customised data models.
https://www.youtube.com/watch?v=iUQCFI02zZA
@J.Hilk said in Increasing usage for C++ new operators based on data model indexes?:
Just a question out of curiosity, because I remeber by instructor also telling me c++ heap allocation is slower than stack
It is. It's a call to the heap manager in the OS. The heap manager has to find a free place for your object before it can return you an address ...
A stack allocation is nothing on the other hand - you (rather the compiler) move the stack pointer to the appropriate offset from the stack base pointer and voila - you have memory. That also is the reason that you must know the size of the allocated object at compile time.and slower than heap allocation in other languages.
Nope!
Is there a different method in c++ to allocation memory instead of the standard new?
You have
*allocfrom the C runtime, the placement new if you're crazy enough to build your own heap manager (or for some very specific similar purposes), and of course you have my buddy - the stack.@kshegunov thanks for the info.
IIRC boost also has special allocation methods for faster instantiation of objects. But I'm not sure, never used that libary much.
-
Why would you want to?
The concrete target data types can vary while model indexes are resolved to QVariant objects as the default data.
A C++ new operator can provide a known pointer data type, can't it?what is a "model storage allocator"?
Some data structures in the C++ standard template library get such a parameter passed.
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
The concrete target data types can vary while model indexes are resolved to QVariant objects as the default data.
A C++ new operator can provide a known pointer data type, can't it?Isn't
dynamic_castwhat you want?@kshegunov said in Increasing usage for C++ new operators based on data model indexes?:
You have *alloc from the C runtime
Note for passers-by: If you use those to allocate complex types the constructor may/will not be called
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Must a C++ new operator provide a non-void pointer data type?
It can provide whatever type you want it to, 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 ...It provides the generic programming interface for the desired data sources.
Indeed.
Derived classes will contain member variables which will manage storage in expected ways, won't they?
They may or may not. It's up to the user code to decide where and how the storage will be done. There may be no storage at all and the data to be fetched on the fly from someplace.
C++ programmers are using this operator for various resource allocations.
Many C++ programmers overuse this operator, especially those with limited experience.
I propose to increase the usage of the construct “placement new” also together with customised data models.
https://www.youtube.com/watch?v=iUQCFI02zZA
@J.Hilk said in Increasing usage for C++ new operators based on data model indexes?:
Just a question out of curiosity, because I remeber by instructor also telling me c++ heap allocation is slower than stack
It is. It's a call to the heap manager in the OS. The heap manager has to find a free place for your object before it can return you an address ...
A stack allocation is nothing on the other hand - you (rather the compiler) move the stack pointer to the appropriate offset from the stack base pointer and voila - you have memory. That also is the reason that you must know the size of the allocated object at compile time.and slower than heap allocation in other languages.
Nope!
Is there a different method in c++ to allocation memory instead of the standard new?
You have
*allocfrom the C runtime, the placement new if you're crazy enough to build your own heap manager (or for some very specific similar purposes), and of course you have my buddy - the stack.…, 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.
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
The concrete target data types can vary while model indexes are resolved to QVariant objects as the default data.
A C++ new operator can provide a known pointer data type, can't it?Isn't
dynamic_castwhat you want?@kshegunov said in Increasing usage for C++ new operators based on data model indexes?:
You have *alloc from the C runtime
Note for passers-by: If you use those to allocate complex types the constructor may/will not be called
Isn't
dynamic_castwhat you want?Yes.
I prefer to avoid null pointers which can eventually be returned by such a cast operation.
-
…, 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.
@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 pointersIn 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?
@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 performancenew 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.
-
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.
@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
