when do i need to set all back to Null??

hi all,

sometimes when i look to some programs, the variables(mostly char) will be set to NULL when the program ends.

i would like to ask when do i need to do so?
if i have a program which have hundreds/thousands of char(or string) is there any problem to the memory or to any other problem found if i dun point them back to NULL?

thank you for helping

The only thing you actually have to do when exiting a program, is to free up memory you've allocated.

Thus, any time you use 'new', you must use 'delete'. Any time you use 'malloc' or 'realloc', you must use 'free'.

It's that simple. Anything not dynamicly allocated doesn't need to be set to anything on exit.

Quzah.

mmmm i understand what you mean....do you mean that the definition of the string or char does not really have a location in the memory? so i don't have to free up them?

It does have a location in memory, but a variable you declare like this

char a;
int b;

will free itself when your program exits (or the function finishes, or whatever)

Classes automaticly call destructors; other variables, that have not been dynamicly created, are automaticly destroyed when they go out of scope.

Anything you dynamicly allocate must be freed. (By dynamic, I mean anything you create using 'new', 'malloc', or 'realloc'.)

Quzah.

thanks .....i should back to the basic before going forward....^_^

Also, it's never REQUIRED to set anything back to NULL, but it's useful for debugging purposes. As a general rule, if the pointer doesn't point to anything, make it NULL. For example, this is legal:

Code:

int * piVar;

/* == More code (1) == */

piVar = new int[30];

/* == More code (2) == */

delete[] piVar;

/* == More code (3) == */

but here, piVar is only useful during the block labelled "More code (2). If it was used at some point during "More code (1)" or "More code (3)", it MIGHT give us an error, or (even worse) it might only fail during unpredictable cases. That is particularly likely in the case of More code (3). Code that appears to work is the worst kind of broken code. I made that bold because I cannot stress enough how much trouble "working" broken code can cause.

Look at this better code below:

Code:

int * piVar(NULL);

/* == More code (1) == */

piVar = new int[30];

/* == More code (2) == */

delete[] piVar;
piVar = NULL;

/* == More code (3) == */

piVar is still only usable during block #2, but now any attempt to use it during blocks #1 or #3 will fail at runtime, all the time. They would still be errors, but they couldn't hide behind the mask of unpredictable success, so we can isolate and eliminate them with relative ease. Further, if we always keep all pointers NULL unless they point to something, then we can simply test to see if a pointer is NULL to know if it points to anything or not.

Lastly it often makes destructors easy. It's legal to call delete or delete[] on a NULL pointer (the standard says it will do nothing, and is not an error), so we can delete all pointers without checking if they are valid. If they are valid, they are deleted. If they weren't valid, they should be NULL and "deleting" them does no harm.