Il 15/03/24 21:21, Jaroslaw Kobus via Development ha scritto:
To the point: we are talking here about decreasing the visibility of a member function in a subclass. The virtuality of the method isn't relevant I guess, is it?
It is relevant, since that's the whole problem: since event() is a virtual which is public in QObject, it's pointless to restrict it further in a subclass, because you can always place the call considering the object as-a QObject (=> upcast it) and bypass the restriction.
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).
I've never used it personally, but the fact that C++ language designers let it compile, even without a warning, makes me wonder that there were some reasons for it.
C++ has also 30? 40? years of crust. Why does C++ even allow different accessibility levels for different overrides to begin with?
My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence
smime.p7s
Description: Firma crittografica S/MIME
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
