Using many functions

[leoleoleo]

I'm reading a book in which a window class' constructor doesn't initialize all the implementation directly, instead it calls a function that calls another etc...

e.g.

 

window::window(T&t, X&x)
{ setup(t, x);}

void window::setup(T&t, X&x)
{
//initializing implementation details, size, title etc...
create(t, x);

void window::create(T&t, X&x)
{
//initializing the library Window
//...
}

Same with the destructor, callind a destroy() function instead of doing so in the destructor itself.

Is it just a matter of style or is it of any practical use?

[dhayden]

The advantage of having a setup() method is that it can be called after the object have been created to reinitialize it for some other usage. I'm sure that some people will frown on this, but it does happen.

But a setup() function should be sure to release any existing resources that the class uses, which implies that the object must contain valid data in the first place. In the example you give, window's trivial members will be uninitialized. Hopefully it doesn't have any.

Ditto for a destroy() function, so long as it leaves the object in a consistent state. Personally, I'd call it clear() instead of destroy() because I think that makes it clearer what it does.

[mbozzi]

An init()/setup() method is useful in cases where the work that would otherwise be done in the constructor requires dynamic dispatch. Virtual functions are not dispatched in a constructor.
It also allows the implementation to signal an error without throwing an exception.

It's harder to make a case for destroy()/uninit() except that it makes it possible to fail to release an object's resources without throwing an exception in a destructor.

This article does a good job of explaining the problem and some potential solutions:
http://www.kolpackov.net/projects/c++/eh/dtor-1.xhtml