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

VRonin

@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

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.

VRonin

@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

Could 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

… concrete example of what you are suggesting?

sierdzio

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.

elfring

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?

sierdzio

@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

Accessing data of a QVariant is possible and trivial, if necessary.

Can the data access become more convenient (and safe) for customised data types?

VRonin

@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

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?

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::data and QVariant::value<T>. e.g.: index.data().value<QString>();. Don't think you can do better.
Can you show us how would your new implementation 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

elfring

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.

I find this information partly inappropriate because I contributed a (questionable) test case in this forum.
Source code might distract from the really relevant software development ideas, doesn't it?

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?

VRonin

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

elfring

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?

VRonin

@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

elfring

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?

VRonin

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

elfring

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?

sierdzio

@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