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