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?

[Karl Heinz Buchegger]

Aing wrote:

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;
}
/////////////////////////////////////////////////////

Since FreeStruct is a member function of Date, there is no need to
pass it something it can access anyway. There is also no
need to call FreeStruct from the destructor, since the object
is going to be deleted anyway. But this is not related to your problem.
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?

Definitly. But the problem is located somewhere else in your code.
What you see are just the symptoms. Watch out for array overflows, dangling
pointers etc.

--
Karl Heinz Buchegger
kb******@gascad .at

[Ron Natalie]

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message news:40******** *******@gascad. at...

> 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?

Definitly. But the problem is located somewhere else in your code.
What you see are just the symptoms. Watch out for array overflows, dangling
pointers etc.

There seems to be some confusion.
FreeStruct takes a Date but it is passed the date_struct*. Even if he
somehow manages to bash it to compile with a cast, he's still memsetting
using the size of the containing object (Date). Depending on what "other stuff"
is in the class that he omitted form the listing, the results could be catastrophic.

[lilburne]

Ron Natalie wrote:

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message news:40******** *******@gascad. at...

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?

Definitly. But the problem is located somewhere else in your code.
What you see are just the symptoms. Watch out for array overflows, dangling
pointers etc.

There seems to be some confusion.
FreeStruct takes a Date but it is passed the date_struct*. Even if he
somehow manages to bash it to compile with a cast, he's still memsetting
using the size of the containing object (Date). Depending on what "other stuff"
is in the class that he omitted form the listing, the results could be catastrophic.

Even if he was memsetting Date he's likely to get into problems. The
idiom of initializing by memsetting C type structures seems to a MS
thing, which doesn't work with C++ structs and classes where you are
likely to zap the vtable pointer.

[Karl Heinz Buchegger]

Ron Natalie wrote:

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message news:40******** *******@gascad. at...

> 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?
Definitly. But the problem is located somewhere else in your code.
What you see are just the symptoms. Watch out for array overflows, dangling
pointers etc.

There seems to be some confusion.
FreeStruct takes a Date but it is passed the date_struct*.

I blamed this to not posting the actual source code but instead retyping
it in the newsreader.
Even if he
somehow manages to bash it to compile with a cast, he's still memsetting
using the size of the containing object (Date). Depending on what "other stuff"
is in the class that he omitted form the listing, the results could be catastrophic.

--
Karl Heinz Buchegger
kb******@gascad .at

[Karl Heinz Buchegger]

lilburne wrote:

Ron Natalie wrote:

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message news:40******** *******@gascad. at...

>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?

Definitly. But the problem is located somewhere else in your code.
What you see are just the symptoms. Watch out for array overflows, dangling
pointers etc.

There seems to be some confusion.
FreeStruct takes a Date but it is passed the date_struct*. Even if he
somehow manages to bash it to compile with a cast, he's still memsetting
using the size of the containing object (Date). Depending on what "other stuff"
is in the class that he omitted form the listing, the results could be catastrophic.

Even if he was memsetting Date he's likely to get into problems. The
idiom of initializing by memsetting C type structures seems to a MS
thing, which doesn't work with C++ structs and classes where you are
likely to zap the vtable pointer.

true.
But the OP used a POD struct.
memsetting to 0 should not be a problem in this case.
--
Karl Heinz Buchegger
kb******@gascad .at

[Peter Lee]

>>>> Ron Natalie writes:

Ron> There seems to be some confusion. FreeStruct takes a Date
Ron> but it is passed the date_struct*. Even if he somehow
Ron> manages to bash it to compile with a cast, he's still
Ron> memsetting using the size of the containing object (Date).
Ron> Depending on what "other stuff" is in the class that he
Ron> omitted form the listing, the results could be catastrophic.

Even if m_data represented a Date object, he's passing a reference to
the address of that object. Seems like he would get a compile error
since the func expects (Date& lpData).

Also memset requires the address and would need to be
memset(&lpData, 0,sizeof(Date)) ;

since a reference is passed in.
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;
}

[Andrey Tarasevich]

Aing wrote:

Anyone knows what can be cause of this problem?

For starters, try posting real code. The code that you posted doesn't
even compile, since you are trying to pass a 'Date*' argument as 'Date&'
parameter.

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

Karl Heinz Buchegger wrote:

...
Even if he was memsetting Date he's likely to get into problems. The
idiom of initializing by memsetting C type structures seems to a MS
thing, which doesn't work with C++ structs and classes where you are
likely to zap the vtable pointer.

true.
But the OP used a POD struct.
memsetting to 0 should not be a problem in this case.
...

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'.

--
Best regards,
Andrey Tarasevich

[Rob Williscroft]

Andrey Tarasevich wrote in news:10******** *****@news.supe rnews.com:

Karl Heinz Buchegger wrote:

...
Even if he was memsetting Date he's likely to get into problems. The
idiom of initializing by memsetting C type structures seems to a MS
thing, which doesn't work with C++ structs and classes where you are
likely to zap the vtable pointer.

true.
But the OP used a POD struct.
memsetting to 0 should not be a problem in this case.
...

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 ?

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