initialization and destruction order for class members

[Dennis Jones]

Hello,

I have a class that will eventually look something like this:

class TTableHolder
{
private:
boost::scoped_ptr<TSession> FSession;
boost::shared_ptr<TTable> FTable;

public:
TTableHolder(TServer &AServer)
: FSession( new TSession( &AServer ) ),
FTable( new TTable, TableReleaser( FSession.get() ) ) {}
};

I am pretty sure that the order of initialization for members in an
initializer list is based on the order of their declaration in the class.
That is, since FSession is declared before FTable, I can write the
initializers in any order I want, and FSession will always be initialized
before FTable, thus guaranteeing (I think) that FTable will get a valid
FSession object when it is initialized.

I have two questions:

1) Is my understanding of the order of member initialization correct? Or is
it compiler-dependent?

2) Assuming initialization order is specified by the language, and is based
on member declaration order, what is the order of their destruction? Are
they destructed in reverse order? Obviously, I want FTable (which is a
shared_ptr) to be destroyed before FSession, as FSession is used by FTable's
custom deleter.

Should I prefer to make FSession a shared_ptr instead? If I do that, will
the existence of FTable's custom deleter guarantee that the reference count
of FSession is not decremented to zero, thereby ensuring that FSession will
be valid at the time of FTable's destruction?

Is there a better way to write this that will guarantee the desired
construction/destruction order of class members?

Thanks,

Dennis

 

[Victor Bazarov]

I have a class that will eventually look something like this:

class TTableHolder
{
private:
boost::scoped_ptr<TSession> FSession;
boost::shared_ptr<TTable> FTable;

public:
TTableHolder(TServer &AServer)
: FSession( new TSession( &AServer ) ),
FTable( new TTable, TableReleaser( FSession.get() ) ) {}
};

I am pretty sure that the order of initialization for members in an
initializer list is based on the order of their declaration in the
class.

That's correct.

That is, since FSession is declared before FTable, I can write
the initializers in any order I want, and FSession will always be
initialized before FTable, thus guaranteeing (I think) that FTable
will get a valid FSession object when it is initialized.
Right.

I have two questions:

1) Is my understanding of the order of member initialization correct?
Or is it compiler-dependent?

2) Assuming initialization order is specified by the language, and is
based on member declaration order, what is the order of their
destruction?

Reverse to their construction.

Are they destructed in reverse order? Obviously, I
want FTable (which is a shared_ptr) to be destroyed before FSession,
as FSession is used by FTable's custom deleter.

Should be alright.

Should I prefer to make FSession a shared_ptr instead? If I do that,
will the existence of FTable's custom deleter guarantee that the
reference count of FSession is not decremented to zero, thereby
ensuring that FSession will be valid at the time of FTable's
destruction?
Is there a better way to write this that will guarantee the desired
construction/destruction order of class members?

If your 'FSession' is essentially owned by FTable, then it might be
better if the ownership is actually expressed, and not implied.

V

 

[Dennis Jones]

If your 'FSession' is essentially owned by FTable, then it might be
better if the ownership is actually expressed, and not implied.

Thanks for your reply, Victor. Looks like I am safe in trusting the order
of initialization and destruction.

No, 'FSession' is not owned by "FTable," in fact, the relationship is
actually the other way around -- a TSession owns zero or more TTables
(though my sample code does not reflect this). TSession is responsible for
destroying any TTables it owns when it is destroyed, but there are times
when a TTable must be destroyed without destroying the TSession that owns
it, in which case, the TSession must help with its destruction, which is why
I provide a custom deleter.

However, your question does help me to identify some issues that I still
need to think through as I design the system.

Thanks,

- Dennis