C++ returning references

Question

Looking at making a GUI library for a game engine. I generally avoid pointers if I don't need them and in my below example I find that I don't and it works, but just curious if this design is generally considered good practice or if anyone has comments on it.

int main()
{
    // all widgets are positioned and sized according to the window size
    Window wndOptions("wndOptions");

    Button cmdExit("cmdExit");

    // the window doesn't own the widgets nor does it create the widgets so it's not responsible for deleting the widgets
    wndOptions.AddWidget(&cmdExit);

    // this is how you can find a control and get it casted also. make your variable a reference
    Button& test = wndOptions.FindWidget<Button>("cmdExit");

    test.SetPosition(50, 25);

    return 0;
}

As you can see the idea is that you create your controls (button in this case) and pass a pointer to them to the Window. Then you can find the control by name returning a reference to that control in which you can manipulate the control. It's a bit pointless to use FindWidget() in this example since I have the cmdExit variable, but if I was to pass the window around this would be a way to find and use controls.

The biggest issue I have is that FindWidget() might not find a widget. Right now I throw an exception as not finding a control I would deem as a true exception and not something that should happen much if at all.

Any comments about the usage being done this way?

Answer 1

Looks good so far, although I'm wondering about one thing:

Why would a Window not own the widgets? Seems perfectly reasonable to me, since it already has the capability to store and return them. Who else would own them?

If widgets actually have multiple owners, I'd suggest using std::shared_ptr - it makes the ownership explicit and prevents mistakes like passing pointers to local stack variables etc. In fact, I'd generally use smart pointers as much as possible.

Returning references and throwing exceptions are both good choices in my eyes.

Answer 2

Throwing an exception should mean that a piece of code somewhere catches the exception and handles it in an appropriate manner.

This might mean reporting the error back to the user to fix. Exceptions can be caused by transient situations where the handling mechanism is to try again later.

If it is a programming error that causes the widget not to be found, you might use an exception but an assert is likely to be preferable.

You would use shared_ptr if the widget does have more than one "owner" and clean-up depends on when the last reference is let go. Sometimes shared_ptr is also often used as a convenient way to store the items in a collection as it has the right semantics, even if, in a sense, the collection "owns" it.

If not finding something is a "normal" condition then you would have to return a pointer not a reference.