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.m...@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
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
