[Development] final value classes: some background information and plans

[Marc Mutz]

On Wednesday March 7 2012, Jedrzej Nowacki wrote:
> What are you trying to solve?

I'm trying to prevent that people with a Java mind from running into the C++ 
trap that inheriting from a base class with a public non-virtual destructor 
may invoke undefined behaviour. Looking at the number of "add virtual 
destructor" commits, and dividing that by the number of new polymorphic 
classes added, even we ourselves aren't doing too well.

Andre said "Qt is meant to be useful". That's true, but it's also meant to be 
safer than raw C++. But if Qt class design doesn't even follow the basic 
guidelines of C++ class design (as laid out in e.g. Sutter/Alexandrescu), 
then how can it hope to be safer?

You shouldn't look at the Qt-project developers when discussing interfaces. 
You should look a the Qt programmers in the trenches that happily write 
QColor * c = new QColor(...), as blissfully ignorant of the resource leak as 
they are of Sutter/Alexandrescu. So, Qt can either default to safety or it 
can default to the sharp edge. If you think the latter is acceptable, I urge 
you to run a Qt Open Enrollment training as an eye-opener. Hell, I inherited 
QPtrList publicly when I started out, and I would have been glad if the 
compiler told me I shouldn't do that.

> Using raw pointers may be unsafe but it 
> doesn't mean that the functionality should be removed from C++. I agree
> with Andre blocking inheritance is really radical move, that doesn't buy us
> much apart of SC problems.

This is not meant to silence compiler warnings. This is meant to make Qt safer 
to use. It only triggers on code that deserves to be broken. As is adding 
explicit to ctors, as is disabling implicit conversion from QByteArray to 
const char*.

Unlike the Qt3->4 SiC changes, this doesn't aim to break some of the most 
fundamental idioms in Qt (e.g. "you pass object names to the constructor"), 
so comparing this change to the Qt4 SiCs, as someone on #qt-labs did, is a 
gross exaggeration, IMO.

That said, I agree that breaking lots of code is undesirable. That's why for 
the containers I proposed to make a safe-as-baseclass version available 
(QBasicContainer), so existing designs can be ported with minimal effort, if 
they need to be ported at all (they could just define Q_DECL_FINAL_CLASS 
away). But I don't see the need to do this for all value classes.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions