On 2017-03-23 19:27, Thiago Macieira wrote:
On quarta-feira, 22 de março de 2017 01:27:54 PDT Marc Mutz wrote:
NAK to inheriting from QStringView, publicly or privately. NAK to
adding
another pointer.
BTW, just to be clear: I am not accepting this discussion as closed. I
only
had this idea a while ago, so I have not yet throught it completely
through,
so I reserve the right to discuss it later.
In the mean time: why do you care if some class derives from
QStringView?
Because it's _wrong_.
It does not model is-a, so public inheritance is out of the question.
QString cannot use a lot of QStringView functions (like mid()) without
changing at least the return type, so inherit-to-reuse-implementation is
also not valid.
Last, there are no virtual functions in QStringView that QString would
want to reimplement.
So, of the three use-cases for inheritance, none are relevant here, so
it follows that inheritance is not the tool to use. You may consider
composition, though, as I said, I'd rather provide free functions that
most QString/View methods forward to than picking one class and calling
its methods from all others.
We certainly need to discuss the presence of an extra pointer inside,
as that
has a cost. But derivation?
Derivation is the strongest coupling mechanism in C++, after friendship.
Do I need to mention QPolygon and what pain it's inheritance from
QVector<QPoint> has caused? (FTR: cf. end of qvector.h and
qvector_msvc.cpp).
Thanks,
Marc
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
