By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,134 Members | 1,942 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,134 IT Pros & Developers. It's quick & easy.

will it leak?

P: n/a
Some doubt appeared by chance.When i compiled it with vc7.1 and run it
on windows,the "string" constructed in class destructed follow the
class, but when i compiled it with g++/gcc and run it on ubuntu,
problems came out.It seems that the "string" is still alive when the
class destruct.
why?here is the code:
#include <iostream>

using namespace std;

class A {
public:
int i;
string a;
bool b;
public:
void SetInt(int iV)
{
i = iV;
}
void SetBool(bool bV)
{
b = bV;
}
void SetChar(const char* aV)
{
a = aV;
}

A()
:i(0),
a(""),
b(false)
{
}
~A()
{
// a.clear();
}
};

const char* msg;
char* cstr;
void foo(A* ca)
{
ca->SetInt(10);
cstr = new char[14];
if (cstr)
strcpy(cstr, "hello world!");
printf("CSTR:%p\n", cstr);
ca->SetChar(cstr);
ca->SetBool(true);
}

void test(const char* str)
{
msg = str;
}
int main()
{
A* ca = new A;
foo(ca);
printf("INT:%d\tSTRING:%s\tBOOL:%s\n", ca->i, (ca->a).data(),
ca->b?"true":"false");

test((ca->a).data());
delete cstr;
printf("DATA:%s\n", msg);

delete ca;

printf("CSTR:%s\n", cstr);
// delete cstr;
printf("DATA:%s\n", msg);
}

Nov 6 '06 #1
Share this Question
Share on Google+
11 Replies


P: n/a
very obscure. which string still alive, how do you know it is alive?

ABAI
lylone wrote:
Some doubt appeared by chance.When i compiled it with vc7.1 and run it
on windows,the "string" constructed in class destructed follow the
class, but when i compiled it with g++/gcc and run it on ubuntu,
problems came out.It seems that the "string" is still alive when the
class destruct.
why?here is the code:
#include <iostream>

using namespace std;

class A {
public:
int i;
string a;
bool b;
public:
void SetInt(int iV)
{
i = iV;
}
void SetBool(bool bV)
{
b = bV;
}
void SetChar(const char* aV)
{
a = aV;
}

A()
:i(0),
a(""),
b(false)
{
}
~A()
{
// a.clear();
}
};

const char* msg;
char* cstr;
void foo(A* ca)
{
ca->SetInt(10);
cstr = new char[14];
if (cstr)
strcpy(cstr, "hello world!");
printf("CSTR:%p\n", cstr);
ca->SetChar(cstr);
ca->SetBool(true);
}

void test(const char* str)
{
msg = str;
}
int main()
{
A* ca = new A;
foo(ca);
printf("INT:%d\tSTRING:%s\tBOOL:%s\n", ca->i, (ca->a).data(),
ca->b?"true":"false");

test((ca->a).data());
delete cstr;
printf("DATA:%s\n", msg);

delete ca;

printf("CSTR:%s\n", cstr);
// delete cstr;
printf("DATA:%s\n", msg);
}
Nov 6 '06 #2

P: n/a
Sorry for my english...here are the results running on windows and
ubuntu.
when windows:
CSTR:003708A0
INT:10 STRING:hello world! BOOL:true
DATA:hello world!
CSTR:葺葺葺葺葺葺葺葺葺葺葺葺z
DATA:葺葺葺葺葺葺葺葺葺葺葺葺葺葺葺 葺?

when ubuntu:
CSTR:0x804a018
INT:10 STRING:hello world! BOOL:true
DATA:hello world!
CSTR:
DATA:hello world!

When compiled and run on linux, the string "a" was valid after class A
was destructed,it could be printed correctly,why?
Nov 6 '06 #3

P: n/a
"lylone" <ly************@gmail.comwrote in
news:11**********************@i42g2000cwa.googlegr oups.com:
Sorry for my english...here are the results running on windows and
ubuntu.
when windows:
CSTR:003708A0
INT:10 STRING:hello world! BOOL:true
DATA:hello world!
CSTR:葺葺葺葺葺葺葺葺葺葺葺葺z
DATA:葺葺葺葺葺葺葺葺葺葺葺葺葺葺葺 葺?
when ubuntu:
CSTR:0x804a018
INT:10 STRING:hello world! BOOL:true
DATA:hello world!
CSTR:
DATA:hello world!
When compiled and run on linux, the string "a" was valid after class A
was destructed,it could be printed correctly,why?
A few things:

1) Undefined behaviour: You allocate to cstr with new[], but use delete
to dispose of the memory.

2) Undefined behaviour (assuming you used delete[]): You use the cstr
pointer after you have already deleted the memory.

3) Undefined behaviour: You used a pointer obtained from a string object
after a modifying operation was performed on that string (specifically:
destroying it).
In all three cases, the string "a" (and I presume you meant: ca->a when
ca was properly allocated) was _never_ valid after class A (well, the
instance of class A that ca was pointing to) was destructed. It just
happened to "work" in some cases. That's the result of Undefined
Behaviour: whatever the compiler feels like doing.
Nov 6 '06 #4

P: n/a
Oh,it's a test.I code this test on purpose,so i modify it
abnormal,then i find something happened out of control...
In my test code, the instance of class A was allocated at heap, then
destructed,but the string a did not be reclaimed.Then i want to know,
when i allocate a class containing string at stack, then leave it, will
it cause memory leak when running on linux?
What happened behind memory allocation? It's the problem of STL?And
what can I do when i code on linux system?I means, how can i avoid
these undefined behaviour?

Nov 6 '06 #5

P: n/a

lylone wrote:
Some doubt appeared by chance.When i compiled it with vc7.1 and run it
on windows,the "string" constructed in class destructed follow the
class, but when i compiled it with g++/gcc and run it on ubuntu,
problems came out.It seems that the "string" is still alive when the
class destruct.
why?here is the code:
#include <iostream>

using namespace std;

class A {
public:
int i;
string a;
bool b;
public:
void SetInt(int iV)
{
i = iV;
}
void SetBool(bool bV)
{
b = bV;
}
void SetChar(const char* aV)
{
a = aV;
}

A()
:i(0),
a(""),
b(false)
{
}
~A()
{
// a.clear();
}
};

const char* msg;
char* cstr;
void foo(A* ca)
{
ca->SetInt(10);
cstr = new char[14];
if (cstr)
strcpy(cstr, "hello world!");
printf("CSTR:%p\n", cstr);
ca->SetChar(cstr);
ca->SetBool(true);
}

void test(const char* str)
{
msg = str;
}
int main()
{
A* ca = new A;
foo(ca);
printf("INT:%d\tSTRING:%s\tBOOL:%s\n", ca->i, (ca->a).data(),
ca->b?"true":"false");

test((ca->a).data());
delete cstr;
printf("DATA:%s\n", msg);

delete ca;

printf("CSTR:%s\n", cstr);
I think this is undefined behavior. The pointer points to deleted
data.
// delete cstr;
printf("DATA:%s\n", msg);
}
Nov 6 '06 #6

P: n/a


lylone wrote:
Oh,it's a test.I code this test on purpose,so i modify it
abnormal,then i find something happened out of control...
In my test code, the instance of class A was allocated at heap, then
destructed,but the string a did not be reclaimed.Then i want to know,
when i allocate a class containing string at stack, then leave it, will
it cause memory leak when running on linux?
The object allocated on stack will be destroyed and its destruction
function will be called. It is how the smart pointer be implemented.
What happened behind memory allocation? It's the problem of STL?And
what can I do when i code on linux system?I means, how can i avoid
these undefined behaviour?
Nov 6 '06 #7

P: n/a
Oh,i still have some trouble.

If the data has been deleted, would it be printed correctly?Or, we say
it's a undefined behavior?Opposite,if a pointer points to a data can be
printed correctly, is the data valid(not deleted)?

I'am missing...

Nov 6 '06 #8

P: n/a
deleted does not mean disappear.
this is regarding the memory management model. normally, if a memory is
freed, the content of the memory is not cleared to zero, just lay their
to wait next usage.

for example:

char *p = malloc(128);
strcpy(p, "abcde");

the memory pointed by p is covered by "abcde", and, the pointer 'p' is
linked to a memory allocation table, whose purpose is to avoid
re-allocate a same memory block starting p.
then you free(p), it just de-link the p from the memory allocation
table, only allow after allocation can use the memory occupied by p.
what about the "abcde" in location p? it decides the system behavior to
whether or not clear it.

lylone wrote:
Oh,i still have some trouble.

If the data has been deleted, would it be printed correctly?Or, we say
it's a undefined behavior?Opposite,if a pointer points to a data can be
printed correctly, is the data valid(not deleted)?

I'am missing...
Nov 6 '06 #9

P: n/a
lylone wrote:
Oh,i still have some trouble.

If the data has been deleted, would it be printed correctly?Or, we
say it's a undefined behavior?Opposite,if a pointer points to a
data can be printed correctly, is the data valid(not deleted)?

I'am missing...
We just don't know. That's what undefined means.

After the data is deleted, we cannot access it anymore. The pointer to it is
invalid. You are not allowed to use an invalid pointer for anything (except
assign it a valid value). It you do that anyway, just about anything can
happen - the language standard doesn't say what. It is undefined!
Bo Persson
Nov 6 '06 #10

P: n/a
lylone wrote:

Please quote enough of the previous message to allow for context.
Oh,it's a test.I code this test on purpose,so i modify it
abnormal,then i find something happened out of control...
What you are doing is a pointless exercise. There is no defined
behavior for Undefined Behavior. You won't learn anything about the C++
language by breaking code. Learn the rules of the language, and know
that violating them usually puts your program into some indeterminant
state.

Brian
Nov 6 '06 #11

P: n/a
Thanks all! Now I think I have found my way!

"Binary д
"
deleted does not mean disappear.
this is regarding the memory management model. normally, if a memory is
freed, the content of the memory is not cleared to zero, just lay their
to wait next usage.

for example:

char *p = malloc(128);
strcpy(p, "abcde");

the memory pointed by p is covered by "abcde", and, the pointer 'p' is
linked to a memory allocation table, whose purpose is to avoid
re-allocate a same memory block starting p.
then you free(p), it just de-link the p from the memory allocation
table, only allow after allocation can use the memory occupied by p.
what about the "abcde" in location p? it decides the system behavior to
whether or not clear it.

lylone wrote:
Oh,i still have some trouble.

If the data has been deleted, would it be printed correctly?Or, we say
it's a undefined behavior?Opposite,if a pointer points to a data can be
printed correctly, is the data valid(not deleted)?

I'am missing...
Nov 7 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.