Hi! I''m kinda new in using MS Visual C++ 6.0, and currently I''m facing something that bothers me. I noticed there are 2 default compilation configurations: Release and Debug. My problem is that the program I made compiles without problems in both configs. However, if I used Debug to compile it, it has some problems in memory access (uninitialized pointers don''t point to NULL automatically. Due to that, some of my "if (pointer != NULL)" statements become true, causing the program to read data from the pointer that points to an uninitialized value). When I use the Release config, this problem doesn''t occur. But I can''t use the Debug feature with this configuration. Is it possible to turn on the debugging feature in the Release configuration?

Not the answer you were looking for, but you probably should never assume that an uninitialized pointer will be NULL. If you want this just declare it equal to NULL:
i.e.
int *p = NULL;

BASSOFeeSH
><>

I guess probably the most obvious answer to the pointer issue is to make sure you initialize all your variables, including the pointers, which is always a good practice. Otherwise you''re going to have worse problems than the Debug/Release issue... you will never be able to be sure of the behavior of your program on other systems.

The point of the Debug/Release is to allow the developer better access to his or her code during runtime without bloating it beyond recognizeability in the final release. When you compile in Debug, MSVC uses special libraries and memory allocation settings so that you can step through your code in the debugger and watch your stack and the values of your variables change. This is a very nice thing. Release is for final versions, so that you can distribute it to people who aren''t developers and therefore don''t have all the special libraries and other files that you have. Release versions also don''t require all the extra stuff that lets you step through your code, so your resulting executable and memory usage will be smaller. My usual tendency is to compile in Debug most of the time so I can keep an eye on things while running, and then do an occassional build in Release mode to ensure that there aren''t been any issues with Release. You will, on occassion, have code that works in Debug but not in Release due to the special memory allocation done to allow you to step through code and view variable values in Debug mode. This is pretty rare tho, and when it happens it''s a real pain to debug.

-fel

I would suggest two things:

Number one: Ratchet up your warning level, so that you get the
"Variable ''Foo'' May have been used without being initialized" warning.

Number two: always explicitly set your pointers to NULL when you declare them.



Notwen

I''ve tried initializing the pointers to NULL when I was trying to figure out what was wrong with it, and it still doesn''t recognize it as the proper NULL. Not too sure why... it could be the way I coded. I''ll try restructuring it and see if it works.

Something is unsetting the pointers.

I just had this exact problem. In my case I was loading in structs from a file which had bad pointers that weren''t NULL anymore.

Run it in debug mode, the ASSERT window will pop up, hit RETRY, it''ll crash, and then got to View... Debugger Tools... Callstack on the menu. This should show you which one of your functions is causing the problem.

What logistix said, that''s your best route

OK here we go.

When using MSVC and the debug build, since I see this a lot, I figured I would put my $0.02 worth on this topic as follows:

When you dynamically request new memory instead of giving you the basic number * sizeof(type) you get that PLUS about 40 bytes of extra memory used for debugging purposes. What this amounts to is a way to check for buffer over-runs and pointers that link memory blocks together in case of memory leaks etc. ( BTW, the extra memory is for just that, not for you to clean up or do anything with )

So to try to make this clear and easy to understand when you make a pointer you can assign it null, as you should; or the way I''ve been taught, however when you allocate memory or do anything with it in the debug build, the "old school" way of dealing with pointers doesn''t apply due to the fact the it calls a special _malloc_dbg version. In a nut shell this is what you get when you allocate:

NoMans land: 0xfd
( This is just straight up over-runs, bad toad - bad bad toad )

Freed blocks: 0xdd

New objects: 0xcd
( The most common and not freed properly )

and also 0xcc

So the point I''m trying to get across here is that if you don''t use ASSERT or VERIFY macros for debug, the way microsoft want''s you to do today, but maybe not tomorrow and certainly not the way you did yesterday, then UNWIND your callstack and look at a memory dump of the pointer in your function that you found and you can get an idea of what your are doing ( or in some cases not doing ) with the pointer in question.

Hopefully this helps somewhat. It''s more insight to the compiler rather than an answer to the post but as the old saying goes: You can give a man fish and feed him for a day; Teach a man to fish, and feed him for a lifetime.

--Your friendly soldout bit pusher