Giuseppe D'Angelo (18 March 2024 12:12)
> Therefore, when one creates a QObject subclass with an event()
> override, then:
>
> * either they didn't know about the fact that it was public in
> QObject, and thought it was protected/private (because virtual
> functions should normally be protected), without think about the
> above C++ """feature""" at all, etc. (mistake in good faith);
>
> * or they were *deliberately* trying to change the access level, i.e.
> trying to *outsmart* C++, but that goes nowhere; making it more
> restrictive simply doesn't work (can be bypassed by upcasting,
> breaks generic code that codes against the interface, breaks
> subclasses).
Or they could be thinking: "surely that *should* be protected in QObject,
so I'll make it protected in my derived class so that *when* someone
gets round to (at a major version change) making QObject::event()
protected, this overload shall be ready-protected in support of that."
Whether that's a good plan or not is another story, but it's another
possible motive.
Eddy.
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
