On 3/7/12 2:25 PM, "ext Marc Mutz" <marc.m...@kdab.com> wrote:
>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. You do realize that we're 6 weeks past our feature freeze? Lars > >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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
