is delete[] necessary?

[John Brawley]

Please;
Given something like:

main() {
int * label = new int[123456789];
for(;
if ( /* somecondition == true */) { goto end; }

/* do something sane for a long time*/

end:
delete[] label; // is this _necessary_ in this case?
return 0;
}

IOW, if the array[] is used right up until the program terminates, is it
necessary to delete the array[]?
(Does a terminated C++ program 'leave anything behind' that affects the
machine?
Doesn't termination of a program release any memory that was associated with
it?)

Tnx
jb

 

[michael.goossens]

Please;
Given something like:

main() {
int * label = new int[123456789];
for(;
if ( /* somecondition == true */) { goto end; }

/* do something sane for a long time*/

end:
delete[] label; // is this _necessary_ in this case?
return 0;

}

IOW, if the array[] is used right up until the program terminates, is it
necessary to delete the array[]?
(Does a terminated C++ program 'leave anything behind' that affects the
machine?
Doesn't termination of a program release any memory that was associated with
it?)

Tnx
jb

--
Peace
JB
(e-mail address removed)
Web:http://tetrahedraverse.com

Operating systems give memmory to the processes, processes can manage
this memmory. When a program terminates the operating system will know
and will reuse the memmory.

 

[Alf P. Steinbach]

* John Brawley:

Please;
Given something like:

main() {

In both C and C++ 'main' must have result type 'int'.

int * label = new int[123456789];
for(;
if ( /* somecondition == true */) { goto end; }

Use a 'break' instead of a 'goto'.

Or just use a 'return'.

Don't use 'goto'.

/* do something sane for a long time*/

end:
delete[] label; // is this _necessary_ in this case?
return 0;
}

IOW, if the array[] is used right up until the program terminates, is it
necessary to delete the array[]?

No.

But it helps.

In particular, it helps to avoid clutter when you use tools to check for
memory leaks.

(Does a terminated C++ program 'leave anything behind' that affects the
machine?

Depends on the program.

Doesn't termination of a program release any memory that was associated with
it?)

Depends on the operating system.


Cheers, & hth.,

- Alf

 

[peter koch]

Please;
Given something like:

main() {
int * label = new int[123456789];
for(;
if ( /* somecondition == true */) { goto end; }

/* do something sane for a long time*/

end:
delete[] label;  // is this _necessary_ in this case?
return 0;

}

IOW, if the array[] is used right up until the program terminates, is it
necessary to delete the array[]?
(Does a terminated C++ program 'leave anything behind' that affects the
machine?
Doesn't termination of a program release any memory that was associated with
it?)

This is not a C++ question, but from the point of view of C++ you do
have a memory leak. While some operating systems do free some
resources allocated by processes, not all operating systems do so, and
most (if not all) operating systems don't release all resources
acquired by a process.
If you program on any kind of "standard" operating system, the leak
will not propagate.
On a sidenote, prefer std::vector for new [].

/Peter

 

[Rolf Magnus]

Please;
Given something like:

main() {

You forgot to give main a return type.

int * label = new int[123456789];
for(;
if ( /* somecondition == true */) { goto end; }

/* do something sane for a long time*/

end:
delete[] label; // is this _necessary_ in this case?
return 0;
}

IOW, if the array[] is used right up until the program terminates, is it
necessary to delete the array[]?
(Does a terminated C++ program 'leave anything behind' that affects the
machine?

The C++ standard doesn't define what happens after your program finished
executing. So it depends on the system and the compiler.
I'm currently programming for a system that won't return any memory after my
program finished. But that doesn't matter much, since my program must never
finish. There is nothing that would "take over" afterwards.

Doesn't termination of a program release any memory that was associated
with it?)

If you are talking about PCs and the like, then usually the system does
automatically re-claim the memory after your program is gone. In that case,
the above program would not leak memory, but it still is considered sloppy
programming by some people, and a memory debugger might flag it as a memory
leak. Also note that destructors aren't executed.

 

[John Brawley]

* John Brawley:

In both C and C++ 'main' must have result type 'int'.

Yes; this was just a means to help clarify my question.
Balaji's example code, that helped me so much, didn't type the main(), and
compiled and ran, but in my existing program, where the new piece is going,
int already precedes main() { .

Use a 'break' instead of a 'goto'.
Or just use a 'return'.
Don't use 'goto'.

Um. That's a problem. I'm going to put a filereader into an existing
program, and I cannot find a way to jump around some of the existing code
without a goto....
I'll study more. Thank you.

IOW, if the array[] is used right up until the program terminates, is it
necessary to delete the array[]?

No.
But it helps.

Thank you very much.
This answers a longstanding question.

In particular, it helps to avoid clutter when you use tools to check for
memory leaks.

It's also probably "proper".
My program does delete[] its array(s); I'll leave it that way.

Depends on the program.


Depends on the operating system.

Thanks again.
No worries for me; this program leaves nothing behind, I'm sure.
I wanted the old question answered, and you did.

 

[John Brawley]

"Rolf Magnus" <

You forgot to give main a return type.

Yes (Alf said same. Same answer: code was for illustration only).

IOW, if the array[] is used right up until the program terminates, is it
necessary to delete the array[]?
(Does a terminated C++ program 'leave anything behind' that affects the
machine?

The C++ standard doesn't define what happens after your program finished
executing. So it depends on the system and the compiler.
I'm currently programming for a system that won't return any memory after my
program finished. But that doesn't matter much, since my program must never
finish. There is nothing that would "take over" afterwards.

OK, concensus appears to be no, it's not _necessary_ to delete[] the array
in this case, but it's good form, safer, and more portable.

My own main program (I'm trying to make a new piece) is never supposed to
terminate either, except for very small datasets, but if I want to use my
computer for something else without slowing down the calculations its doing,
I have to shut the program off. (Power outages also do that for me, which
is why I'm adding a filereader.)

If you are talking about PCs and the like, then usually the system does
automatically re-claim the memory after your program is gone. In that case,
the above program would not leak memory, but it still is considered sloppy
programming by some people, and a memory debugger might flag it as a memory
leak. Also note that destructors aren't executed.

Thank you very much.
(What does it mean: "destructors aren't executed" ?)

_All_ of my programming is sloppy. I'm not a programmer, just a person who
has no choice but to use a computer program to do what he wants done, and
nobody else would program it _for_ me (for less than $100 an hour....).
My actual code looks like a Python script, which is the first language I
wrote it in (and the program is the first serious program I ever wrote).
Any C++ programmer would call it (my code) not only sloppy, but inefficient,
ugly, misused, and probably several other not-so-complimentary things.
_But_: it does what it has to, does it fast, and does it exactly the way its
archetype says it should.

Thank again (and to all who responded).

 

[michael.goossens]

break and goto are concidered bad programming though, be aware of
that. Better is to define your loops with good boolean expressions.

 

[Gerhard Fiedler]

break and goto are concidered bad programming though, be aware of
that. Better is to define your loops with good boolean expressions.

I guess I missed the part where break entered the "bad programming". I
think it has its place, but then you may think what I'm doing is "bad
programming"

Also for goto... IMO it's not bad in itself, it just depends whether there
are better (easier maintainable, safer, etc.) constructs are available. Not
always there are (even though almost always).

<http://david.tribble.com/text/goto.html>

Gerhard

 

[James Kanze]

* John Brawley:

[...]

Use a 'break' instead of a 'goto'.

Or more likely:

while ( someCondition ) { ... }

It's generally bad practice to break from the middle of a loop.

(Comparing a boolean with "true" is also a symptom of not having
understood something as well.)

Or just use a 'return'.

Not in the middle of a loop.

[...]

IOW, if the array[] is used right up until the program terminates, is it
necessary to delete the array[]?

No.

But it helps.

In particular, it helps to avoid clutter when you use tools to
check for memory leaks.

Maybe, but I'm not sure that that's a valid reason. More valid
would be: what happens if he later modifies the code so that his
"main" is in fact a function called from within a loop.

Of course, done correctly, he doesn't need the delete[]. (In
over 15 years of C++, I've never used delete[].) He really
should be using std::vector here, and then, of course, the
question doesn't arise.

Depends on the program.

Depends on the environment. The C++ standard doesn't say what
happens after the program terminates. With a normal system,
there shouldn't be any problem.

 

[Gerhard Fiedler]

"Rolf Magnus"

Thank you very much.
(What does it mean: "destructors aren't executed" ?)

"delete" (and "delete[]") not only tells the heap manager to release the
memory, it also executes the destructor(s) of the objects. For simple types
like int or double that isn't much if anything, but for a more complex
class it can be substantial; for example, the class destructor may store
the class state in a file on disk. Aborting the process without properly
destroying the object (how and when that happens depends on the type of
object) obviously doesn't do any of what the destructor of a certain class
is supposed to do.

_All_ of my programming is sloppy. I'm not a programmer, just a person
who has no choice but to use a computer program to do what he wants
done, and nobody else would program it _for_ me (for less than $100 an
hour....). My actual code looks like a Python script, which is the first
language I wrote it in (and the program is the first serious program I
ever wrote).

Not to scare you, but IMO C and C++ are not the best suited languages for
sloppy programming. They are dangerous languages in the sense that they
leave a lot of room for doing things the wrong way, and require a decent
amount of learning to be able to use them safely. Is there a particular
reason why you want to move from Python to C++?

Gerhard

 

[James Kanze]

Please;
Given something like:
main() {
int * label = new int[123456789];
for(;
if ( /* somecondition == true */) { goto end; }
/* do something sane for a long time*/
end:
delete[] label; // is this _necessary_ in this case?
return 0;
}
IOW, if the array[] is used right up until the program
terminates, is it necessary to delete the array[]? (Does a
terminated C++ program 'leave anything behind' that affects
the machine? Doesn't termination of a program release any
memory that was associated with it?)

This is not a C++ question, but from the point of view of C++
you do have a memory leak.

It depends on your definition of memory leak. From a purely C++
point of view, the world ceases to exist when the program
terminates, the question has no meaning.

While some operating systems do free some resources allocated
by processes, not all operating systems do so, and most (if
not all) operating systems don't release all resources
acquired by a process.

This is true up to a point, but the number of resources not
covered is generally very, very small (e.g. temporary
files---good OS's might recover them, but neither Unix nor
Windows does). And you need to provide a mechanism for
recovering such resources anyway, because for better or worse,
there will be times when the program terminates without freeing
them.

If you program on any kind of "standard" operating system, the
leak will not propagate. On a sidenote, prefer std::vector
for new [].

I'd consider that more than a sidenote. Just use std::vector,
and the question doesn't arise. Including if you later wrap the
code in a function, and call it several times. With some of the
"something sane" occasionally throwing an exception.

The basic rule is to write clean, neat code, which works
regardless of the context where it is used, and which works even
if there are exceptions, etc. The question of whether the OS
will recover resources on program termination is one that you
should only ask at the system level---do I have to provide some
additional means to release this resource, e.g. in case of
abnormal termination, or will the system take care of it.

The one exception, of course, is static data, such as
singletons. If you define a singleton, its context is "fixed",
in some ways. In such cases, your main worry is that it will be
there when needed, which generally leads to *not* deleting it on
program shutdown.

 

[James Kanze]

On 2008-01-27 08:43:11, (e-mail address removed) wrote:

I guess I missed the part where break entered the "bad programming". I
think it has its place, but then you may think what I'm doing is "bad
programming"

It has a place in switch statements, but that's about the only
place it would be allowed in good programming. For it's use in
loops, of course, it's been recognized as bad programming
practice for a long time. Good programmers just don't use it
(except for fun, as when composing an entry to IOCCC).

Also for goto... IMO it's not bad in itself, it just depends
whether there are better (easier maintainable, safer, etc.)
constructs are available. Not always there are (even though
almost always).

The problem isn't goto, or break or any other language
tool---one of the best written programs I've ever seen was full
of goto's. (It was written in Fortran IV, and the author didn't
have any real choice.) The problem is program structure. In
C/C++, the language has the tools to create all of the
acceptable structures directly, so there is never any reason to
use goto or to break out of a loop, other than obfuscation.

Of course, a lot of programmers are still hackers, and you do
see a lot of it. Still, I've yet to see a case where the code
wasn't improved by rewriting it to avoid the goto or the break.

 

[kwikius]

On Jan 27, 1:49 pm, Gerhard Fiedler

Not to scare you, but IMO C and C++ are not the best suited languages for
sloppy programming. They are dangerous languages in the sense that they
leave a lot of room for doing things the wrong way, and require a decent
amount of learning to be able to use them safely.

The problem I have with this can be summed up in the statement.

"Those that never do anything wrong never do anything."

In reality you have to start somewhere and your first efforts are
bound to be a mess. Its inevitable, but shouldnt put you off.
Experience is the best tutor. Eventually it dawns why certain things
are bad, rather than never doing anything because it might be "wrong".

regards
Andy Little

 

[Alf P. Steinbach]

* James Kanze:

* John Brawley:
[...]

for(;
if ( /* somecondition == true */) { goto end; }

Use a 'break' instead of a 'goto'.

Or more likely:

while ( someCondition ) { ... }

It's generally bad practice to break from the middle of a loop.

(Comparing a boolean with "true" is also a symptom of not having
understood something as well.)

Or just use a 'return'.

Not in the middle of a loop.

On the contrary.

In C++ a loop with exit in the middle is best implemented as a loop with
exit in the middle.

In C++ the code must be prepared for exits at any point, to be exception
safe.

[...]

IOW, if the array[] is used right up until the program terminates, is it
necessary to delete the array[]?

No.

But it helps.

In particular, it helps to avoid clutter when you use tools to
check for memory leaks.

Maybe, but I'm not sure that that's a valid reason. More valid
would be: what happens if he later modifies the code so that his
"main" is in fact a function called from within a loop.

That's a different situation, where it's not "used right up until the
program terminates": changing the question, the answer's changed
accordingly.

Of course, done correctly, he doesn't need the delete[]. (In
over 15 years of C++, I've never used delete[].) He really
should be using std::vector here, and then, of course, the
question doesn't arise.

Depends on the program.

Depends on the environment. The C++ standard doesn't say what
happens after the program terminates. With a normal system,
there shouldn't be any problem.

The next question (which you snipped) concerned that aspect, the
environment.


Cheers, & hth.,

- Alf

 

[Rolf Magnus]

On Jan 27, 1:49 pm, Gerhard Fiedler


The problem I have with this can be summed up in the statement.

"Those that never do anything wrong never do anything."

That's a good statement for people who are willing to learn, but the OP
probably isn't willing to learn how to write good C++ code, but rather just
wants the current job done, considering his statement: "I'm not a
programmer, just a person who has no choice but to use a computer program
to do what he wants done, and nobody else would program it for me".

 

[Default User]

It has a place in switch statements, but that's about the only
place it would be allowed in good programming. For it's use in
loops, of course, it's been recognized as bad programming
practice for a long time. Good programmers just don't use it
(except for fun, as when composing an entry to IOCCC).

Pure nonsense.



Brian

 

[Pete Becker]

* James Kanze:

That's a different situation, where it's not "used right up until the
program terminates": changing the question, the answer's changed
accordingly.

Well, yes, it's a different situation, but it's not at all uncommon to
move code from main into another function. The point was, of course,
that the dubious benefit of skipping the delete is vastly outweighed by
the potential for errors if this sort of rearrangement is done.

 

[Alf P. Steinbach]

* Pete Becker:

Well, yes, it's a different situation, but it's not at all uncommon to
move code from main into another function. The point was, of course,
that the dubious benefit of skipping the delete is vastly outweighed by
the potential for errors if this sort of rearrangement is done.

Not that I disagree with that, but I think it is a narrow context that
is different from the narrow context of what was asked about. One
example of why I think it's a narrow context: when one generalizes to
the question of generally doing cleanup in anticipation of possible
future program changes, the cost of that cleanup can escalate. For
example, the Firefox browser is so fanatical about cleaning up in a
structured way that sometimes its memory consumption nearly doubles
after you close it, and it takes a Really Long Time to actually finish,
even if all that would be technically required would be to close a few
network connections, all the rest being internal memory structures.

So, I chose to answer only what was actually asked.

That was much easier... ;-)


Cheers,

- Alf

 

[Pete Becker]

* Pete Becker:


Not that I disagree with that, but I think it is a narrow context that
is different from the narrow context of what was asked about.

Yes, obviously.

One example of why I think it's a narrow context: when one
generalizes to the question of generally doing cleanup in anticipation
of possible future program changes, the cost of that cleanup can
escalate.

That's not the case here.

For example, the Firefox browser is so fanatical about cleaning up in a
structured way that sometimes its memory consumption nearly doubles
after you close it, and it takes a Really Long Time to actually finish,
even if all that would be technically required would be to close a few
network connections, all the rest being internal memory structures.

So, I chose to answer only what was actually asked.

Shrug.