Version: 0.9.3 (using KDE KDE 3.5.7) OS: Linux Would you like to wrap pointer data members with the template class "std::auto_ptr"? http://en.wikipedia.org/wiki/Auto_ptr http://websvn.kde.org/trunk/extragear/graphics/digikam/digikam/albumfiletip.cpp?revision=750485&view=markup http://websvn.kde.org/trunk/extragear/graphics/digikam/digikam/albumhistory.cpp?revision=729732&view=markup http://websvn.kde.org/trunk/extragear/graphics/digikam/digikam/cameratype.cpp?revision=687121&view=markup http://websvn.kde.org/trunk/extragear/graphics/digikam/themedesigner/mainwindow.cpp?revision=719640&view=markup
Markus, Are you talking about data pointer used in 'd' private container class ? Gilles Caulier
Yes ... I see the following attributes as candidates for encapsulation. - d - m_backwardStack - m_forwardStack Will window objects delete themselves?
yes Qt object are deleted automaticly by Qt lib (like Java do). d container is deleted in destructor of main class... So no need to manage anymore. Valgrind do not report any memory leak here... Gilles Caulier
I doubt that the first AlbumStack object will be properly deleted if the second allocation will throw an exception in the AlbumHistory constructor. How do you think about the chance to omit explicit delete instructions? http://www.gotw.ca/publications/using_auto_ptr_effectively.htm
Marcel, What do you think about this entry. It's still valid ? Gilles Caulier
I think it's KDE style to rely on QObject mechanims for auto-deletion. We dont use exceptions (or catch them from libexiv2), so we won't throw any in constructors. Other than that, I am not familiar with std::auto_ptr
I'm agree with you Marcel. So i close this file... Gilles
Would you like to apply the template class "QSharedPointer" in the near future? http://doc.trolltech.com/main-snapshot/qsharedpointer.html#details
We use QSharedDataPointer in some appropriate places. We have no intended use for QSharedPointer at the moment.
Will Qt 4.5 become generally available with the class "QSharedPointer" in the next year? ;-)