On Sun, Jan 23, 2011 at 12:51 PM, Andreas Gaeb wrote:
>
> IIRC, gcc has a default initialization routine that sets new variables
> to zero unless they are explicitly initialized like
> int a=1;
>
Yes, but that's only the case for global and static variables. The start-up
code initializes the memory section for all global/static variables to zero
(the "bss" section). However, this does _not_ apply to dynamic memory -
hence, it doesn't work with dynamically created objects (as the JSBSim
instance in our case). Sometimes, heap memory _may_ be zero at the beginning
of a program - but there is no way one could rely on this. So, member
variables should be initialized manually in the constructor.
> If the initial value in this example is not zero, it has to be stored in
> the executable, increasing its size. When initializing to zero, the zero
> is not stored in the executable, it seems.
>
Right, linkers move non-zero global/static variables into a different memory
section than zero/uninitialized vars. So they only need to store a binary
image for the section of non-zero global variables - and just add code to
initialize the bss section to zero.
> - in the prologue of the main function, the stack is initialized to zero
> (this even seems not to be the case when using -O3...)
>
- gcc default initialization means putting the variable on the stack
> which is assumed to be zero because of the above
> - after a reset, new instances will not be created in fresh stack
> memory, but in sections that were freed when deleting the old instances
> - these sections were indeed freed but not zeroed
> - the new instances contain pieces of the leftovers of the previous
> instances
>
No, the JSBSim object is created on the heap memory - not on the stack. Only
local variables (including local static objects) are on the stack. Heap
isn't initialized, neither stack. So member variables have random values -
unless explicitly set. Most compilers provide warnings for uninitialized
local variables (on the stack), but unfortunately I don't know any compiler
(yet) producing warning for uninitialized member variables.
> > Definitely a good idea! Uninitialized members easily cause random (=very
> > ugly) problems - and such issues are a pain to debug. I'm strongly in
> favour
> > of initializing all variables/members in the constructor. And especially
> so
> > in a case like this, where few objects are created: even if initializing
> a
> > certain member wouldn't be necessary, it doesn't cost us much except a
> few
> > bytes of code - but no run-time performance at all.
> Though I'd also be in favor of this, it might be quite a lot of code to
> be added. Maybe it is an alternative to begin every constructor with
> something like
> memset(this, 0, sizeof(this))
>
Oh, please no! :) A few extra code lines don't matter - just add these
please. Even if there were 100 member variable initializers. Such a memset
would be highly compiler-/platform dependant - and we cannot allow this.
Also, the memset would destroy other data such as the object's "vtable",
which is initialized by default (and stores the pointers to the object's
virtual methods). And it's better to rely on the compiler being smart: if
you add 100 initializers for member variables to be zero, it's possible that
the compiler does something similar to a memset (but without destroying
other data). So, even performance doesn't matter.
> I was looking for something explaining when it is safe to rely on gcc's
> default initialization, if ever. Details on the difference between the
> member initialization list and assignments in the constructor code might
> also be helpful.
>
See above: never rely on initialization of member variables. Otherwise
dynamic objects won't work.
btw, all of the above is specific to gcc. Have the NaN issues been
> observed with other compilers?
>
>
Windows/MSVC should have the same problem.
cheers,
Thorsten
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
