1

In C++, if you pass an anonymous object as an argument to a named object method, does the anonymous object get deleted when you delete the named object?

The library I'm using for a project expects pointers to objects for most of its own objects' methods, a la:

WContainerWidget::addWidget(WContainerWidget* widget) {/*...*/}

and in their examples they often use the new operator when constructing these objects. 

WContainerWidget* aFoo = new WConainerWidget(/*args*/);
aFoo->addWidget(new WText(/*args*/));

If I delete aFoo, will the anonymous WText() object be deleted?

Am I to trust that their implementation will take care of these deletions without sorting through their source code, or should I avoid the exemplified behaviour, and explicitly name/delete everything myself?

Improve this question
8
  • 2
    There's nothing special about passing in a "new Foo" to a method. Unless the API takes ownership of that object, then it's your responsibility to explicitly delete it. That said, if their examples show this pattern, I would expect the API to manage the lifetime of what was passed int. Check the documentation. Commented Apr 16, 2012 at 15:11
  • you could check it.. double freeing is a runtime error on most platforms. Commented Apr 16, 2012 at 15:12
  • 1
    Without finding a reference in the documentation: either, the framework (Webtoolkit) is responsible for ownership of subobjects in the "window hierarchy" after attaching them (which would be the norm for any GUI-toolkit I know of), and in that case you are not allowed to delete the anonymous subobjects (double free), or the framework explicitly says that it's your responsibility to free anonymous objects (which would put enormous effort on the programmer to correctly manage memory). Search for object ownership in the documentation of your framework. Commented Apr 16, 2012 at 15:14
  • 1
    Try to inherit from wWidget then delete parent container and see if it calls your destructor Commented Apr 16, 2012 at 15:30
  • 1
    This is a badly defined interface. The passing of pointers is silly idea as there is no concept of ownership associated with it. This makes using the interface next to imposable without actually fully understanding how the Widget library and how it treats pointers. As it happens if you dig into the documentation you find: http://www.webtoolkit.eu/wt/doc/reference/html/overview.html When inserting a widget in the widget hierarchy, ownership is transferred to its parent in the tree. Commented Apr 16, 2012 at 16:53

3 Answers 3

Reset to default
4

Yes the widget takes ownership and it is automatically destroyed:

http://www.webtoolkit.eu/wt/doc/reference/html/overview.html

When inserting a widget in the widget hierarchy, ownership is transferred to its parent in the tree.

This is a badly defined interface. Its from the old school were people were still defining interface like C interfaces.

The passing of pointers is silly idea as there is no concept of ownership associated with it as such modern C++ libraries have shifted to using the concept of smart pointers. This provides a mechanism to document in the code (and enforce by the compiler) the concept of pointer ownership.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Thanks, and see my comment above. I feel like a dolt that I didn't catch that in the overview. I'm glad someone else was paying attention ./grin
3

Not automatically, no. The WContainerWidget object will need to know that it "owns" the WText object, and it will need to ensure that something deletes it at the appropriate time.

That would traditionally mean that WContainerWidget has a list of Widget* values, and in the ~WContainerWidget destructor, it goes through and calls delete on each stored value.

You could also use a smart pointer (such as auto_ptr, if that's all you have, or else shared_ptr, either from Boost or from C++11) to hold each WText* value, and that will ensure the object gets freed whenever the smart pointer is destroyed.

Improve this answer

4 Comments

Oh, wow. I hadn't heard of those smart pointers before. Thanks. I'll look into that.
I think auto_ptr is completely broken because of the copying behavior, the best you can do (if you don't have a compiler that ships std::shared_ptr or maybe std::tr1::shared_ptr) is to use Boost.
shared_ptr can be located in tr1 namespace should be supported by most / all compilers
The Wt library is not designed to be used with smart pointers. So all the comments (the main points by Rob are still good) here are bad advice. About the only useful smart pointer here is std::auto_ptr which you can use while creating the children but you must call release() when you call addWidget() as the widget assumes ownership of the transferred pointer (having two owners is NOT a good idea).
1

The answer is simply: NO (*)

You get a dangling pointer and in the end a memory leak

(* not so absolute)

there are ways to do a new while preserving the control over the object (overload the new operator of the class). However, this is uncommon. A more common approach is to use an object factory. In that case you won't see a new

Improve this answer

3 Comments

Thank you! I've been experiencing some leakage, and was wondering if this was the cause.
This is a strong claim. Can you point to some documentation stating that the library will not claim ownership of the pointer? This cannot really be answered with just the code in the question.
I cannot. Which is why I'm trying to investigate where to start looking. Perhaps I should have said, "if this could be part of the cause" instead. I am not blaming the framework. I'm just trying to understand what may/may not be the issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.