On Sun, 2011-01-23 at 13:18 +0100, ThorstenB wrote:
> 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
>> Windows/MSVC should have the same problem.
And worse ;=(( if that is possible...
In MSVC Debug mode, lots of memory, including function
stack variables, etc, are filled to a 'known' pattern,
0xdd, 0xee, etc, which can cause REAL problems, like -
class foo {
std::string s;
char * p;
void ~foo();
};
void foo::~foo() {
if (p)
free(p);
}
will for sure result in a windows error dialog
when the class goes out...
And agreed, you can NOT just use memset(). In
the above foo case, the string s; is NOT a zero,
but is initialized, by compiler generated code, to
be an allocated (null) string, which is NOT the
same as zero (0)!
And this pattern setting in functions allows the
compiler to warn of a variable uninitialized by the
function, and of stack over/under runs at run time,
etc... but also misses initializations like the following,
which is annoying :-
int val;
sscanf( buf, "%d", &val );
if (val) ...
So yes, MSVC has these problems also ;=))
And I am not so sure MSVC even zeros static variables,
unless specifically set to NULL/0, unlike as suggested
for gcc, thus say :-
static char * cp;
void func() {
if (cp == NULL)
cp = malloc(val);
can also be a problem...
Regards,
Geoff.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
