[Development] Should QObject::event() be protected or public?

[Marc Mutz]

On 15.03.24 21:21, Jaroslaw Kobus via Development wrote:
[...]
> Just found some reasoning, though not sure how much valid it is:
> https://www.learncpp.com/cpp-tutorial/hiding-inherited-functionality/
> 
> Probably there are more resources about this topic in the internet.

That page doesn't look very trustworthy.

The first example is valid. One can make something public that was 
protected in a base class, because it doesn't violate Liskov's 
Substitution Principle: One can still do everything one can do with the 
base class with the derived class, too. One can just do more with the 
derived class, which is pretty common (one can get text() from a 
QLineEdit, but not from a QWidget (well, except via its Q_PROPERTY)).

The member variable thing sounds very wrong. I'd be surprised if it 
compiled. If it does, it's probably something new in C++23 or 26 whereby 
you can use `using` for more general renaming, like

    struct insert_result {
       iterator it;
       bool inserted;
       using first = it; // was std::pair before, keep .first working
       using second = inserted;
    };

I saw a proposal for that floating around some time ago, but don't know 
the status of it.

In general, just because C++ lets one do something doesn't mean it's a 
good idea. Apart from the C ballast, C++ itself is a language with a 
huge design-space, and four decades of cruft. Only very few planes in 
that design space make sense in general, they change with each C++ 
version, and even fewer of them make sense in any given project context.

There's a reason why CppCoreGuidelines are so huge and why TTLOFIR is 
growing so rapidly: C++ projects need hundreds or thousands of rules to 
tailor C++'s vast design space to something that's acceptable for the 
project. Do the work, or die from technical debt. The core of Qt 
(qt.git) is pretty consistent, still, but we have dozens of modules, and 
hundreds of contributors now of extremely varying experience, and C++ 
has evolved a lot since C++98, so I think we need to codify a lot more 
stuff than we have done in the past (and, where possible, have tools 
check it). Look at all the google-specific checks in clang-tidy for example.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B