Increasing usage for C++ new operators based on data model indexes?
-
Two member functions “QAbstractItemModel::createIndex” are described in a terse way. I have got the impression that they can belong to the function category “memory allocation”.
Would you like to peform corresponding storage allocations then by customised C++ new operators which will be provided by known class libraries (including Qt)?
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
I have got the impression that they can belong to the function category “memory allocation”.
Nope, wrong impression. As you can see in the sources,
createIndex
does nothing but call the private 4 args constructor forQModelIndex
and return it by value.
It's just a safety measure to make sure you don't forget to set the model member ofQModelIndex
and prevents external users of the model to create an index manually that could potentially result in undefined behaviour.May I suggest chapter 3 of this book. Page 113 onward in particular
-
@elfring said in Increasing usage for C++ new operators based on data model indexes?:
Is an index for a data model similar to a pointer from the heap?
Not even close. It's more similar to a
QPoint
.
It's a container for a coordinate in a 3D space (row, column, hierarchical level) of a specific modelShould desired information be available also without a reference to an other book?
It is but following your posts it's clear you are quite confused so I thought I'd give you a reference that you can access for free that explain step by step how to custom models work
-
Not even close.
An item can be added to a model. Its position is identified by a corresponding model index, isn't it?
It's a container for a coordinate in a 3D space (row, column, hierarchical level) of a specific model
- A pointer from the heap can be used together with a simple index for a buffer (an array).
- Do Qt data models manage just vectors of pointers internally?
- Can the mentioned coordinate be connected then with a pointer for a specific object within the data model in a similar way?
I'd give you a reference that you can access for free that explain step by step how to custom models work
Such descriptions can be generally helpful.
-
@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
QModelIndex
the 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
-
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
QModelIndex
the 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
QModelIndex
doesn't own the data in any shape or form but other than that yes. In this case theQModelIndex
will hold anint
index (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?
-
@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”.
QPersistentModelIndex
doesn'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 myQPoint
analogyQModelIndex
can 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,QPersistentModelIndex
is 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.QVariant
does 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
QObject
s? 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. -
@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
? -
@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
*alloc
from 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.
-
@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_cast
what 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
-
…, 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.