initialization and destruction order for class members

Hello,

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

class TTableHolder
{
private:
boost::scoped_ptr<TSessionFSession;
boost::shared_ptr<TTableFTable;

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

re: initialization and destruction order for class members

Dennis Jones wrote:That's correct.
Right.
Reverse to their construction.
Should be alright.
If your 'FSession' is essentially owned by FTable, then it might be
better if the ownership is actually expressed, and not implied.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

re: initialization and destruction order for class members

"Victor Bazarov" <v.Abazarov@comAcast.netwrote in message
news:enk4rj$3qf$1@news.datemas.de...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