On 30/11/14 09:35, "Olivier Goffart" <oliv...@woboq.com> wrote:
>On Sunday 30 November 2014 06:37:11 Kevin Kofler wrote: >> Sze Howe Koh wrote: >> > I'm curious about the rationale behind this API design. I can't think >> > of any other Qt function that returns an implicitly-shared object by >> > pointer, so this seems inconsistent. e.g. QWidget::font() returns a >> > QFont by const-ref. >> >> Probably because the pointer can be null. C++ does not allow null >> references. (The compiler might let you get away with it, but in >>principle, >> it is not allowed.) > >That's not the reason because you can return a null pixmap >(QPixmap::isNull). > >I don't know the reason. It was probably always like that >( http://doc.qt.digia.com/2.3/qlabel.html#a1bd68 ) Exactly that. It’s been like that since Qt 1 times, where QPixmap was a non shared class you had to instantiate on the heap. We never changed this accessor for source compatibility reasons (I remember discussing this with Matthias when we moved from Qt 3 to Qt 4 ;-) ), but I agree it feels very wrong these days to return a pointer to a pixmap. Cheers, Lars > >I know that moc has work around for that kind of property so if the >getter >returns a pointer, it can deference it > > > >-- >Olivier > >Woboq - Qt services and support - http://woboq.com - http://code.woboq.org >_______________________________________________ >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