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

[kshegunov]

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

I find this information inappropriate.

Yeah, me too.

I chose to respond in different ways.

Yeah, me too.

• Are there any developers around who can clarify design extensions without thinking only in source code?

We don't think only in source code, but we find it as a useful way to clarify what we mean. Are you able to clarify your design extensions through source code?

• Can the original development idea become more interesting?

Not unless you make it more interesting by including some source that we can discuss.

Can the clarification of design aspects from a function template declaration help here?

Nope, but a class with its function bodies would help.

[elfring]

Are you able to clarify your design extensions through source code?

My published software development activities demonstrate that such contributions can happen.

Not unless you make it more interesting by including some source that we can discuss.

How will your interests evolve for application programming interfaces expressed in the format of function template declarations?

Nope, but a class with its function bodies would help.

Can it occasionally be more helpful to clarify software design properties before attempting a specific implementation?

[kshegunov]

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

My published software development activities demonstrate that such contributions can happen.

Not from what I was able to see.

How will your interests evolve for application programming interfaces expressed in the format of function template declarations?

They will not. My interests have evolved already and in their current state of evolution they require hard facts, evidence if you will.

Can it occasionally be more helpful to clarify software design properties before attempting a specific implementation?

Occasionally it can, but not in this case.

[elfring]

They will not.

Can this kind of feedback express another kind of change resistance?

Occasionally it can,

It is nice that you can follow this view to some degree.

but not in this case.

I prefer a stricter separation between a software design draft and a possible prototype implementation here.

[kshegunov]

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

Can this kind of feedback express another kind of change resistance?

I don't resist change. You have not proposed a change but a hypothesis, it's yet to be proven if it can be made into a change.

I prefer a stricter separation between a software design draft and a possible prototype implementation here.

That's your prerogative, just don't expect people to write the code for you.

[VRonin]

Since we didn't make it explicit so far: we think your idea is really, really, bad. We tried to explain you why it's bad but you either decided to ignore us or just don't understand models enough to see the faults.

Proposing useful extensions is one thing, making us waste time discussing changes that are so bad they would get shot out in the first code review stage is another

[elfring]

we think your idea is really, really, bad.

So it seems that we stumble on a conflict because of varying imaginations for further software evolution.
Our ways of thinking about software design aspects are generally different.

I am curious if any other Qt user or contributor would like to adjust the mentioned design details any more.

[VRonin]

Ok, let's start a vote.

Anybody here thinks the design "proposed" above has any reason to exist?

[kshegunov]

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

Ok, let's start a vote.

Fine, I'll bite.

Anybody here thinks the design "proposed" above has any reason to exist?

No due to the "design" not having addressed all any of the issues raised in this thread. Being incomplete and practically inapplicable, which is my beef with it, makes the proposition more of a theoretical hypothesizing than a design proposition. Here's what is to be done, so to have it considered as a proposition for a change:

1. Motivation:
   • There's no clear distinction why this change is needed. The QModelIndex class is already very light and can be passed around by value extremely cheaply. Why would introducing a heap manager be better.
2. Structure & design
   • There's no clear way to tell how the memory management is to be done - the placement new requires a memory block to begin with. What class and how is going to manage the memory blocks throughout the application and how?
   • There's no clarity how the interface between Qt code and user code is going to work.
     • Templates with QObjects is not an option, and deriving from QObject is necessary to have signal-slots.
     • Templates with models means making promises about binary and source compatibility hell. The API would define the private internals of the class and once set there's no going back to fix it for a period of a major version turnaround. (Notable warnings in the documentation that the containers should not be subclassed!)
     • Even if we assume the above is solved instantiation of the models will make binaries extremely fat.
     • Templates are distinct types, so QAbstractItemModel<MyType> is different from QAbstractItemModel<YourType>. Only way to solve is to have an interface (purely abstract class) that is to be referred in the user code. Possible, but hardly worth it; the vtables are going to get enormous.
     • Above statement also implies that the views have to be templated, as they have no notion of the user type until an instantiation of the model happens, which is in the user code. Practicality goes out the window.
3. Implementation
   • No implementation provided.
   • The sheer amount of changes needed means that basically half the Qt toolkit needs to be reimplemented.

[VRonin]

Of course I'll cast my -1 vote as well.

I'll add to point 1:

• If the data contained in the model is all of basic types or implicitly shared types then it's possible to already use the current framework without ever triggering any expensive* copy

, to point 2:

• There's no clarity on how to support different types in different roles
  • would we need an additional template argument for each used role beyond Qt::UserRole? is so the problems above grow exponentially with the roles

And to point 3:

• No possible implementation for a reliable dataChanged emission if model internals are exposed directly

---

*expensive = a copy that implies more that a:

• memcpy of less than 65bits and
• an increase/decrease of a numeric reference counter