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

[lars.knoll at nokia.com]

On 3/7/12 2:25 PM, "ext Marc Mutz" <marc.mutz at 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.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
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development