Is deleteAllChildren() needed if using ScopedPointers, etc?


#1

It wasn’t until after I wrote lots of code that I eventually stumbled upon ScopedPointers, and I have recently gone through lots of code and converted any Component ptrs to ScopedPointers. I used to use deleteAllChildren() in my class destructors to help tidy up, although, if only using ScopedPointers is this ever necessary?

To test I made a simple class that creates a TabbedComponent (scopedptr) and a scopedptr instance of a custom class that subclasses Component. It seems to shutdown just fine without any leaked components or warning. If I add deleteAllChildren() in the destructor, I get the following: "malloc: *** error for object 0xe34180: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug

Does this mean that the ptr/object is already freed and deleted before deleteAllChildren() trys to free and delete it(or vice versa)? Anyway, looks like I don’t need deleteAllChildren() but thought I’d ask as it would probably be good to fully understand, and also in case there are instances where I have ScopedPointers, and want to still use deleteAllChildren() (if there was a good reason?)…

edit: originally wrote safeptr instead of scopedptr :slight_smile:


#2

You don’t need deleteAllChildren(), because when the ScopedPointer gets out of scope, it delete its pointer automatically.
When the ScopedPointer is a class member, it will called after the class destructor. (like a constructor in a internaliser-list, is called before the class constructor)


#3

Personally I steer clear of deleteAllChildren() nowadays, and the library only uses it in a few places. There are occasionally times when it’s the best option, but I prefer ScopedPointers, or better still: make your child component a member of the parent, so there’s no separate allocation or deletion needed at all - that’s the pattern that I now use wherever possible.


#4

In my app the UI can be customized. There are “panels” in the window, into which Components can install themselves. A panel doesn’t even know who its children are, and the children can change. So deleteAllChildren() is a natural fit for me. Each control is fully self contained (i.e. no one “listens” to it).

A hassle of using a ScopedPointer is that it exposes the class declaration to the header file. Either that, or you need a forward declaration. For a Component that has many different types of children, it bloats the header.

Now I’m not saying not to use ScopedPointer, because it sure is useful for a lot of things, but be aware.


#5

I agree. The bigest issue with scoped pointer in general, is that it’s fixed design.
If you either add or remove children dynamically you can’t use scoped pointer even for your fixed components.
Same goes for child as member object directly (plus the fact that you need to be able to call the child’s constructor in your initializer list). If you have a TableListBox and your parent class is also a model, you can’t use “this” in the constructor so you’re struck.

Anyway, in 90% of the cases it’s not the case so that’s a life saver to either use members or scoped pointer.


#6

Thanks guys!