Archived

This topic is now archived and is closed to further replies.

are we forced to live with GC on VC.NET?

This topic is 5129 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

ok, ive just tried vc.net and i think it is quite cool. managed c++ for example rocks and the garbage collector its even better..but, are we forced to use it even on native c++? just try this out: new project, win32 application, console and empty. int main( int argc, char *argv[] ){ char *str1 = new char[3]; str1 = "foo"; std::cout << str1 << std::endl; str1 = "major foo"; std::cout << str1 << std::endl; return 0; } this does compile without any errors, and debugging it will result with everything ok. damn! is there a way i can make that illegal on vc.net? i mean, im used on one way of programming and all of a sudden i have to live with that garbage collector thing.. its good, but that way i cant for example port my programs to other OS''s because ill never be sure if there is a memory leak on my program. tnaks a lot.

Share this post


Link to post
Share on other sites
Try this->

right click on your project
(bring up project properties page)
Configuration Properties->C/C++->General
Switch COMPILE TO MANAGED to off

I believe managed IS NOT DEFAULT though (in C++)

[edited by - paulcesar on November 30, 2003 10:24:58 PM]

Share this post


Link to post
Share on other sites
there are only 2 options:

"not using managed extentions"
"assembly support"

int both them it still compiles and runs with no problem.

is there another way of avoiding that?

thanks.

Share this post


Link to post
Share on other sites
i know its native C++ but the problem is that the debugger doesnt get the leak. and when i run the program it runs with no excpetion. everythin ok. that didnt happen with vc6 nor it didnt happen without the .net framework installed. the program should crash! but it doesnt! and my question is why? why does that works without any problem and without any notice from the debugger?

Share this post


Link to post
Share on other sites
A memory leak doesn't necessarily mean the program will crash, just that there is a chunk of memory you won't be able to get to. I don't believe the debugger catches memory leaks, but there are 3rd party programs and ways to code it so you can catch them.

[edited by - Vangelis on November 30, 2003 12:48:16 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by a2ps
i know its native C++ but the problem is that the debugger doesnt get the leak. and when i run the program it runs with no excpetion. everythin ok. that didnt happen with vc6 nor it didnt happen without the .net framework installed. the program should crash! but it doesnt! and my question is why? why does that works without any problem and without any notice from the debugger?

Why would the program crash?

That code would not crash in VC6 just like it doesn't crash in .NET

As others have stated the debugger does not let you know about memory leaks, it only tells you when you stomp on some other app's memory (and then only because Windows throws an exception).

EDIT: Upon looking over the code again, I see it's only not crashing out of sheer luck. You don't allocate enough memory to store "foo\0", much less "major foo\0"

[edited by - glassJAw on November 30, 2003 12:58:58 AM]

Share this post


Link to post
Share on other sites
There are debug memory leak checker functions under win32/console apps that you can use to output mem leaks into debug output window. Almost the same thing as under mfc which is built in for you.

Share this post


Link to post
Share on other sites
quote:
Original post by glassJAw

EDIT: Upon looking over the code again, I see it's only not crashing out of sheer luck. You don't allocate enough memory to store "foo\0", much less "major foo\0"

[edited by - glassJAw on November 30, 2003 12:58:58 AM]


He is assigning pointers, not copying the actual characters, so it wouldn't crash even if he is unlucky, it's perfectly valid. But of course the 3 bytes he allocated in the beginning wouldn't be freed.

It would probably crash though if he tries to delete str1 before the program ends, after str1 is assigned a sting literal(after str1="foo";. Because he would then be trying to delete the memory where the string "major foo" is stored, and that could be a readonly area in the exe. Even if it's writable, deleting memory stored in the exe image would crash the program.

Another thing worth mentioning, is that the c++ standard is compromising a bit here to be compatible with c.
quote:
From the draft c++ standard(i don't have the final here)


A string literal (2.13.4) that is not a wide string literal can be converted to an rvalue of type “pointer to
char”; a wide string literal can be converted to an rvalue of type “pointer to wchar_t”. In either case,
the result is a pointer to the first element of the array. [Note: this conversion is deprecated. See Annex D.
] For the purpose of ranking in overload resolution (13.3.3.1.1), this conversion is considered an arraytopointer
conversion followed by a qualification conversion (4.4). [Example: "abc" is converted to
“pointer to const char” as an arraytopointer
conversion, and then to “pointer to char” as a qualification
conversion. ]


Which basically means that you should avoid char* str1="foo"; The right way to do it is, const char* str2="foo";



[edited by - fredizzimo on December 1, 2003 4:20:26 AM]

Share this post


Link to post
Share on other sites
quote:


char *str1 = new char[3];

str1 = "foo";

std::cout << str1 << std::endl;

str1 = "major foo";

std::cout << str1 << std::endl;





This will cause a memory leak, but the debugger doesn''t (normally) show it.

If you placed this code snippet in an MFC project, which also sets the heap up to detect memory leaks (possibly MFC does the leak detection?)

IIRC, there is a way to get the debug heap to detect memory leaks, but I cannot remember how at the moment, and I''m too lazy to look it up

Share this post


Link to post
Share on other sites
it''s not a memory leak, since after your program exits the OS will take back the memory anyways...for simple things like a wee program you have it doesn''t matter....I usually never call free or delete when doing a programming contest

Share this post


Link to post
Share on other sites
thank you all for the replys

i guess the memory leak (by not calling the delete) wouldnt cause the program to crash, it would just leave a block of memory around for no use.

but i guess i was wrong by thinking that assigning a string bigger than the space i reserved for it would cause the crash.

i know now that it doesnt, altought it may overwright other data

str *a = new char[4]; //for "foo\0"
strcpy( a, "major foo" );
that wont crash the program but may overwright other data.

BTW, is there any tool to sheck for memory leaks besides MFC?

thanks.

Share this post


Link to post
Share on other sites
quote:
Original post by a2ps
BTW, is there any tool to sheck for memory leaks besides MFC?



Ahh, now that I am home, I can finally become "unlazy":

Yes, There is a tool to check for leaks besides MFC, and it''s readily available. A little digging tonight yeilded this gem of a function (I did recall correctly):


_CrtDumpMemoryLeaks();


It should be called at the end of the program (before exit, or maybe the destructor of a cleverly created static object.)

It returns true if there are leaks. False if not. Upon a true return... or, even better (from MSDN):

quote:

The function can be called automatically at program termination by turning on the _CRTDBG_LEAK_CHECK_DF bit field of the _crtDbgFlag flag using the _CrtSetDbgFlag function.



There''s more info available, and can be found by searching MSDN for the function listed above. There''s alot the debug heap can do.

Share this post


Link to post
Share on other sites
quote:
Original post by fredizzimo
He is assigning pointers, not copying the actual characters, so it wouldn''t crash even if he is unlucky, it''s perfectly valid. But of course the 3 bytes he allocated in the beginning wouldn''t be freed.



Ah of course. I got confused by the allocation of three bytes. I guess he didn''t actually do anything with them >_<

Share this post


Link to post
Share on other sites
Take a look at the debug common runtime (look up _CRTDBG_*). Specifically, this function: _CrtDumpMemoryLeaks. Along with it there are other options, such as flags you can set which may be useful (look up _CrtSetDbgFlag).

Do not rely on this function. It is not 100%, and reports many allocations as leaks which are not. That said, it can be pretty helpful.

EDIT: MRaiford beat me to it.

[edited by - BrianL on December 2, 2003 8:16:19 PM]

Share this post


Link to post
Share on other sites
In MSVC7 there''s a compiler option to help catch stack-overuns. The VC team focused on making it fast enough to leave in release builds too.

Project Properties->C/C++->Code Generation->Buffer Security Check
(/GS)

There''s also Basic Run-Time Checks, which you can use in debug builds to find problems (/RTCsu)

Those combined with the already present memory tracker makes it easy to track down problems and finds them automatically. It''s a nice system.

If you did a release build, it wouldn''t report memory leaks, and it would have optimized your memory allocation out of the code (so it really would not have leaked!).

Share this post


Link to post
Share on other sites