Library managing lifetime of objects, use smart pointers or raw? - c++

Question

Rolling my own GUI library for a side-project. Refactoring to use smart pointers; however, I ran into an issue.
I'm aware that you do not want to to use smart pointers across DLL boundaries for obvious reasons. But I feel dirty using 'new' in application code. See below:
// MYFINANCEAPP.H
class MyFinanceApp : public Application
{
MyFinanceApp() : mMainWindow(make_unique<Window>())
{
mMainWindow->AddControl(*(new Button("testButton")));
}
private:
std::unique_ptr<Window> mMainWindow;
};
// WINDOW.H
class Window
{
public:
void AddControl(Control& control) //QUESTION: HOW DO I GET SMART POINTER HERE???
{
mControls.emplace_back(&control)
}
private:
std::vector<std::unique_ptr<Control>> mControls; //Want to use smart pointers so I am not responsible for managing...
};
Am I better to use C++98 style and semantics and handle it myself. Obviously I do not want to pass smart pointers across the interface boundary (i.e. AddControl), but I don't want to be responsible for handling the lifetime of the controls.
Additionally, I feel really dirty using new Button("testButton").

Answer 1

A reminder that ABI issues can be circumvented if you simply make a guarantee that you won't release a DLL compiled on a different compiler/version/platform than the primary executable.
At any rate, regarding your interface design:
void AddControl(Control& control) {
mControls.emplace_back(&control)
}
You've got a problem here, because
Control is Polymorphic (or at least seems to be based on what code you provided) which means you have to pass by reference or by pointer to get a "complete" object, but
You don't want to expose an interface where the user has to maintain raw pointers, even briefly, before passing them along to your application.
This is how I would design around this problem:
class Window {
public:
void AddControl(std::unique_ptr<Control> control) {//Note we're passing by value!
mControls.emplace_back(std::move(control));
}
private:
std::vector<std::unique_ptr<Control>> mControls;
};
Then, in your application:
class MyFinanceApp : public Application {
public:
MyFinanceApp() : mMainWindow(make_unique<Window>()) {
mMainWindow->AddControl(std::make_unique<Button>("testButton"));
}
private:
std::unique_ptr<Window> mMainWindow;
};
Note that this doesn't necessarily stop your users from doing something stupid, like
std::unique_ptr<Window> window_ptr = std::make_Unique<Window>();
Button * button = new Button("This won't be properly deleted!");
window_ptr->AddControl(std::unique_ptr<Button>{button});
delete button; //Whoops!
... But there wasn't necessarily anything stopping them from doing that in the first place.
An alternative is to have a "Factory" associated with the Controls. We'd first need to make a modification to AddControl:
Control & AddControl(std::unique_ptr<Control> control) {
mControls.emplace_back(std::move(control));
return *mControls.back();
}
struct ControlFactory {
static Button & create_button(Window & window, std::string button_text) {
std::unique_ptr<Button> button_ptr = std::make_unique<Button>(button_text);
Button & ref = *button_ptr;
window.AddControl(std::move(button_ptr));
//ref will NOT be invalidated, because the object will still exist in memory,
//in the same location in memory as before. Only the unique_ptr will have changed.
return ref;
}
};
And then you'd simply need to change the access modifiers on all your Control subclasses to not allow direct access to their constructors by end-user programmers. Something like this would probably suffice:
class Button : public Control {
/*...*/
protected:
Button() {/*...*/}
Button(std::string text) {/*...*/}
friend class ControlFactory; //Allows ControlFactory to access, even though access is protected.
};
Then your users would be storing references on their end, which is safer than pointers, though it does mean you need to guarantee that those references never outlive the application itself.