| Summary: | Improve exception safety with smart pointers | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Markus Elfring <Markus.Elfring> |
| Component: | Portability-Runtime | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | caulier.gilles, finex, marcel.wiesweg |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 7.6.0 | |
|
Description
Markus Elfring
2008-01-01 20:54:39 UTC
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? ;-) |