Re: [gtkmm] Segfault on spin button initialisation

[pks timing com]

Richard Shaw writes:
 >
 > I can only presume that the initializations are getting reordered, and so
 > when zoom(adj) is called, adj is still uninitialised.  If so, is the
 > correct behaviour from the compiler?

I believe you're right on the money with your assumption.
gcc 2.95 and 3.2.1 warn about this, when the -Wall switch is set.
I would assume 3.3.4 will do so as well.  I assume there's a
more consersative warning switch than -Wall.

Wether or not you encounter problems at runtime likely depends on what's
under the hood of what's being declared/initialized, which is probably
why the compiler lets us get away with it in the first place ...

I assume declaring a plain old data structure and a pointer to it,
and out of order initialization of the pointer with the address of the
structure wouldn't cause any problems.  Asking an adjustment to do
work to do work with memory it hasn't yet had a chance to allocate or
initialize is a different story ...

Anyway, here's how 2.95.3, and 3.2.1 warn about declaration/initialization
order discrepancies:

`c++  -O -pipe  -Wall    -c blah.cc`

blah.cc:14: warning: member initializers for `int Foo::i'
blah.cc:15: warning:   and `int Foo::j'
blah.cc:20: warning:   will be re-ordered to match declaration order

... just one of those things where, twice in a life time, you might appreciate
your level of control, and get bitten by it five your six times, before
exercising it carefully :)