[Development] QAbstractItemModel::createIndex(void const*)?

[Matthew Woehlke]

So, I was fiddling with something of a "toy" application yesterday that
implements a tree model... long story short, I ended up trying to write
some code like:

return createIndex(row, column, &m_foo);

...which fails to compile with 'no suitable overload for (int, int, Foo
const*)'.

But... why *isn't* there such an overload? Is there any reason not to
add one? (Should I submit a patch doing so?) I think doing so is BC and
*mostly* SC, with the SIC parts being on the list of "acceptable
breakage". (Note: This would require also adding a std::nullptr_t
overload to disambiguate the `createIndex(x, y, nullptr)` case, and
presumably adding equivalent QModelIndex ctor overloads.)

[Konstantin Shegunov]

Hi,

Post by Matthew Woehlke
But... why *isn't* there such an overload?

Your object is const, so the implicit cast to void * fails.

Post by Matthew Woehlke
Is there any reason not to add one?

I'd say the question is rather, is there really a reason to add one?

Usually the data is contained in a non-const object, presumably in the
model itself, so the pointer isn't ordinarily pointing to an immutable
object.
Do you need to enforce the const?

Kind regards.

[Jean-Michaël Celerier]

Post by Konstantin Shegunov
Usually the data is contained in a non-const object, presumably in the

model itself, so the pointer isn't ordinarily pointing to an immutable
object.

sure, but the methods that generally call createIndex
(QAbstractItemModel::index for instance) are const, so your members are
const too, so you have to const_cast<T*>(&m_data.getMyObject(row, column));

Post by Konstantin Shegunov
Hi,

Post by Matthew Woehlke
But... why *isn't* there such an overload?

Your object is const, so the implicit cast to void * fails.

Post by Matthew Woehlke
Is there any reason not to add one?

I'd say the question is rather, is there really a reason to add one?
Usually the data is contained in a non-const object, presumably in the
model itself, so the pointer isn't ordinarily pointing to an immutable
object.
Do you need to enforce the const?
Kind regards.
_______________________________________________
Development mailing list
https://lists.qt-project.org/listinfo/development

[Matthew Woehlke]

Post by Konstantin Shegunov

Is there any reason not to add [createIndex(int, int, void const*)]?

I'd say the question is rather, is there really a reason to add one?

Well, in my project, I did (add the overload to my own model). Requiring
the caller to explicitly cast is annoying, and I don't see any benefit.

Post by Konstantin Shegunov
Usually the data is contained in a non-const object, presumably in the
model itself, so the pointer isn't ordinarily pointing to an immutable
object.

Right. Mostly. Note that in my original example, I was supplying a
pointer to a member of my model. Because index() is const, when I take
that address, I get a const pointer, even though the member itself isn't
const (and it would be okay for me to cast it to non-const when using it
in a non-const member).

It sounds like Jean-Michaël ran into the exact same problem.

Post by Konstantin Shegunov
Do you need to enforce the const?

In my case, no, and anyway it would be up to the user to DTRT if they
pass a pointer to an object that is actually immutable.

The point is, the pointer is going to be coerced into a quintptr anyway,
so there is no particular reason why we *shouldn't* accept a const
pointer as the data... not having that overload just forces the user to
explicitly recast the pointer themselves.

[Konstantin Shegunov]

Post by Matthew Woehlke
Right. Mostly. Note that in my original example, I was supplying a
pointer to a member of my model.

This seems like an odd thing to do. How I usually operate is to have the
model as proxy for the actual data storage.

Post by Matthew Woehlke
Because index() is const, when I take
that address, I get a const pointer, even though the member itself isn't
const (and it would be okay for me to cast it to non-const when using it
in a non-const member).
It sounds like Jean-Michaël ran into the exact same problem.

True. I wonder why I haven't hit such a case, or maybe I have but just have
forgotten about it ...

The point is, the pointer is going to be coerced into a quintptr anyway,

Post by Matthew Woehlke
so there is no particular reason why we *shouldn't* accept a const
pointer as the data... not having that overload just forces the user to
explicitly recast the pointer themselves.

Indeed. Sounds reasonable, to me at least, to add an overload.