There is one caveat here that I found after running into some issues with the unit tests. When you convert members from pointers to scoped pointers, even if you keep the destruction ordering consistent (by re-ordering the members in the @interface decl), the objects are destructed much later than before.
eg, before when things being cleaned up from, say BrowserWindowController dealloc (ie, before the call to super dealloc), now the destruction chain looks like (from the bottom up): ... now things owned by scoped_ptrs are destroyed here 5 org.chromium.Chromium 0x00152f4a -[BrowserWindowController .cxx_destruct] + 48 6 libobjc.A.dylib 0x94a709d0 object_cxxDestructFromClass + 111 7 libobjc.A.dylib 0x94a71683 _internal_object_dispose + 34 8 com.apple.Foundation 0x95996570 NSDeallocateObject + 224 9 com.apple.AppKit 0x93d31ba6 -[NSResponder dealloc] + 130 10 com.apple.AppKit 0x93ebad26 -[NSWindowController dealloc] + 449 ... before things were destroyed here... 11 org.chromium.Chromium 0x00153e88 -[BrowserWindowController dealloc] + 62 12 com.apple.AppKit 0x93dcdb22 -[NSWindowController release] + 158 Note that the C++ objects are being released long *after* the window controller is already gone. If anything was holding a weak reference to the NSWindow, they're in big trouble unless they've retained it (which was the bug I discovered earlier). So these classes are still wonderful and self-documenting and full of goodness, but you should make double-sure you understand what's going on when you do a conversion. -- Mike Pinkerton Mac Weenie [email protected] --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
