Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

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



  • 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.

    Can you show us how would your new implementation look?

    Did other information sources show in sufficient ways already how such a function can be written?



  • @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 new existed. 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.



  • 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?



  • @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 used

    To clarify a single index can contain multiple data points of non-homogeneous data type



  • userType() as already used

    This 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?



  • @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::data return different data roles.



  • 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?

  • Moderators

    @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



  • @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, dataChanged is 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 a std::shared_ptr does 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 (or memcpy up 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"



  • And 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[]”.



  • 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”?


  • Qt Champions 2017

    @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.



  • Why do you think in this direction?


  • Qt Champions 2017

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

    Why do you think in this direction?

    Experience.



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



  • 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?

    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.



  • @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 saying

    Our 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)



  • …, 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?



  • The project maintainers are seasoned (15-20 years experience) developers and are familiar with all aspects of standard C++ (especially its oldest parts like placement new).

    It's safe to assume a total mastery of the placement new concept by people reviewing code, don't worry



  • It's safe to assume a total mastery of the placement new concept by people reviewing code, don't worry

    This information is very promising.

    • Unfortunately, I could not extract corresponding indications of understanding for my proposal so far.
    • How would you like to clarify a possible mapping from data model indexes to pointers further?


  • @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



  • We can't think of a way unfortunately

    Why do you stumble on limitations in your imaginations here?


  • Moderators

    @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.


  • Moderators

    @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?



  • @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



  • 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)?



  • @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...)



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

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



  • 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?



  • 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?



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



  • 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?



  • 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?



  • 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.



  • @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?



  • …, 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?


  • 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?


  • Qt Champions 2017

    @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.



  • 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?