[Development] QList

[Marc Mutz]

On Friday 24 March 2017 16:34:17 Thiago Macieira wrote:
> Em sexta-feira, 24 de março de 2017, às 01:34:18 PDT, Marc Mutz escreveu:
> > I listed _the_ three use-cases where inheritance is the tool of choice:
> > 
> > 1. modelling is-a
> > 2. inheriting to reuse
> > 3. reimplementing virtual functions
> > 
> > If your use-case is not one of the three, then inheritance is not the
> > right tool.
> > 
> > Clearly, by now, it's neither (1) nor (3). So if anything, it needs to be
> > (2).
> > 
> > And I'm arguing that it's not (2), either, because you can only re-use a
> > subset of QStringView API, and need to wrap the other half anyway. (2) is
> > really only interesting for pure OO languages with no concept of free
> > functions. In C++, we have free functions.
> 
> Marc, philosophical question then:
> 
> Are you of the opinion that private inheritance has no purpose and should
> never be used?

No, and if you look at code I have written over the years, you will see that I 
do use it.

One thing I've looked into in the past is this: Q6Polygon should inherit a 
Q6VectorBase<QPoint> that also Q6Vector<QPoint> inherits. This will allow easy 
specialisation of QVector<T*> by inheriting QBasicVector<const void*>.

I can even think of a similar pattern for QStringView/QLatin1(String|
View)/QUtf8(String|View), though I guess that just enable_if'ing functions out 
of the primate template will do the job just fine, so the three classes would 
be mere typedefs of the template.

But in these cases, we're reusing next to 100% of the functionality, by way of 
lots of using Base::foo; This is not the case for QString : QStringView. 
They're completely unrelated, because one if owning and the other is non-
owning.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts