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