Initialization -- One Stage or Two Stage

  • Thread starter Brian Folke Seaberg
  • Start date
B

Brian Folke Seaberg

I have been examining the documentation for a class library written in C++.

It seems that most of the classes in that library use two stage initialization.
Objects are not ready for use after construction. Objects are ready for use
only after post-constructor initialization functions have been executed.

I prefer one stage initialization. I believe that upon completion of object
creation an object should be in a valid state and therefore immediately usable.


Are there practical reasons to split initialization into two steps?

What does one gain by doing so?






===============
Brian Folke Seaberg
===============

"A noble spirit embiggens the smallest man" -- Jebediah Springfield
 
V

Victor Bazarov

Brian said:
I have been examining the documentation for a class library written in C++.

It seems that most of the classes in that library use two stage initialization.
Objects are not ready for use after construction. Objects are ready for use
only after post-constructor initialization functions have been executed.

I prefer one stage initialization. I believe that upon completion of object
creation an object should be in a valid state and therefore immediately usable.


Are there practical reasons to split initialization into two steps?

What does one gain by doing so?

Have you tried asking the makers of that library?
 
H

Howard

Brian Folke Seaberg said:
I have been examining the documentation for a class library written in C++.

It seems that most of the classes in that library use two stage
initialization.
Objects are not ready for use after construction. Objects are ready for
use
only after post-constructor initialization functions have been executed.

I prefer one stage initialization. I believe that upon completion of
object
creation an object should be in a valid state and therefore immediately
usable.


Are there practical reasons to split initialization into two steps?

What does one gain by doing so?

I don't know why *they* chose to do it that way (you'd have to ask them),
but I can think of some reasons why one *might* want to do it that way:

For example, if it is likely that the class may be used in an array or
container, and the default constructor isn't sufficient to fully initialize
the class, then you might want an Init function that can be called on each
existing instance in order to later give it the rest of the information it
needs.

Or, if some sort of user interaction is needed prior to the class being
"useable", but you don't want to delay the creation of those objects until
the user is done such interactions?

Or if, for performance reasons, you want to create a "pool" of objects,
which you only later "initialize", when actually pulled from the pool,
speeding up the program start-up time.

Or, if you have objects which have interdependencies, then you might want to
wait until both objects are created, in order to then pass each of them the
information from the other (whether that's member data, or a reference or
pointer to the objects themselves).

Sure, there may be ways to tackle any of those issues without resorting to
"two-stage" initialization, but those are some reasons I can think of off
the top of my head.

On the practical side, I know that under Apple's new OS, this is the
preferred way of writing "components" [i.e., programs which can be
hosted/used by other programs via the Component Manager], so that the system
(or host application) can enumerate the available components without having
to wait for each of them to actually initialize. The idea is to do as
little as possible in the constructor, and defer everything else to an
Initialize call which can be made only when you actualy want to *use* a
specific component. This speeds up host application load times immensely,
especially on a system where there are lots of installed components.

-Howard
 
J

Jonathan Mcdougall

Brian Folke Seaberg said:
I have been examining the documentation for a class library written in C++.

It seems that most of the classes in that library use two stage
initialization.
Objects are not ready for use after construction. Objects are ready for
use
only after post-constructor initialization functions have been executed.

I prefer one stage initialization. I believe that upon completion of
object
creation an object should be in a valid state and therefore immediately
usable.


Are there practical reasons to split initialization into two steps?

What does one gain by doing so?

If you don't have the information necessary for the object's construction,
you need to postpone it. One way is to use the heap to construct the object
as necessary but there are circumstances where this is not preferrable
(stack based objects are usually more "efficient"). The only way left is
two-stage initialization.

The problem associated with it is that the object is in an invalid state.
Each function must make sure the object is valid, which requires these
functions to throw, to return an error or set a flag. This is a pain for
the library and the user, but it may be the only way.

A solution would be to provide both approaches, by providing an default
constructor for two-stage intialization plus a create() function and a
constructor with arguments for direct initialization. I think Microsoft
uses that a lot in its MFC.


Jonathan
 
H

Howard

Oh, I forgot the most important reason of all for doing it that way:

"Because my boss told me to!"

(And the corollary advanatage to doing it that way?... "I won't get fired!")

:)

-H
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top