Anyone knows what can be cause of this problem?

[Aing]

Anyone knows what can be cause of this problem?

////////////////////////////////////////////////////////////
typedef struct _date_struct {
int date,month,year ;
}date_struct;

Class Date {
private :
date_struct m_data;
public :
Date& operator=(const Date& );
//.. Other stuff
};

Date::~Date()
{
FreeStruct(&m_d ata);
}
Date& Date::operator = (const Date& SrcDate)
{
FreeStruct(&m_D ata);
///...
return * this;
}

void Date::FreeStruc t(Date& lpData) //<- here is the problem.
{
memset(lpData,0 ,sizeof(Date));
return;
}
/////////////////////////////////////////////////////

My application crashed because lpData was set to 0x0000014 or some
address around here. (I saw from DrWatSon log) But it doesn't happen
every I run the program. Anyone can tell me where this value from ? Is
there something wrong in my code?

[Andrey Tarasevich]

Rob Williscroft wrote:

...
No, it is still a problem. You must be thinking about 'memcpy', not
about 'memset'. Strictly speaking, 'memset' cannot be used to
zero-initialize 'int' objects. And 'int' objects is exactly what the OP
is storing in his/her POD struct called 'date_struct'.

I was under the impression that all C++ signed types have 1 of
3 formats 2s-compliment, 1s-compliment or signed magnitude, all of
these representation' s have value 0 when all bits set to 0,
so why doesn't:

int i;
memset( &i, 0, sizeof( int ) );

work ?
...

For type 'int' (and all integral types other than 'char', 'signed char'
and 'unsigned char') the total number of bits in value representation
could be smaller than the total number of bits in object representation.
Unused bits are called "padding bits". It is possible that values of
padding bits cannot be just arbitrary. Some combinations of padding bits
may produce invalid objects of type 'int' (trap representations ),
leading to undefined behavior.

For example, in some implementation object representation of type 'int'
might consist of 32 bits with only 31 bits used in value representation
and 1 remaining bit used for parity check. Let's say that in that
implementation the parity bit is always set so that the total number of
1-bits in a valid object of type 'int' is always odd. In this case
zeroing an object of type 'int' with 'memset' will produce a trap
representation and cause undefined behavior.

--
Best regards,
Andrey Tarasevich

[Rob Williscroft]

Andrey Tarasevich wrote in news:Jd******** ************@co mcast.com:

I was under the impression that all C++ signed types have 1 of
3 formats 2s-compliment, 1s-compliment or signed magnitude, all of
these representation' s have value 0 when all bits set to 0,
so why doesn't:

int i;
memset( &i, 0, sizeof( int ) );

work ?
...

For type 'int' (and all integral types other than 'char', 'signed
char' and 'unsigned char') the total number of bits in value
representation could be smaller than the total number of bits in
object representation. Unused bits are called "padding bits". It is
possible that values of padding bits cannot be just arbitrary. Some
combinations of padding bits may produce invalid objects of type 'int'
(trap representations ), leading to undefined behavior.

For example, in some implementation object representation of type
'int' might consist of 32 bits with only 31 bits used in value
representation and 1 remaining bit used for parity check. Let's say
that in that implementation the parity bit is always set so that the
total number of 1-bits in a valid object of type 'int' is always odd.
In this case zeroing an object of type 'int' with 'memset' will
produce a trap representation and cause undefined behavior.

Thanks, I'm sure I've been told this before, I hope I remember
it this time :)

Rob.
--
http://www.victim-prime.dsl.pipex.com/