is delete[] necessary?

[Jack Klein]

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.

#1. Please don't quote signatures. If you want to use Google instead
of a proper newsreader, find the option that turns them off, of, if
there isn't one, trim them manually.

#2. Where exactly in ISO 14882 (the C++ language standard) did you
find the statement processes and reuse of memory? Where, in fact, in
the C++ standard, do you find any requirements that it places on
operating systems?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[John Brawley]

"Rolf Magnus" wrote > > On Jan 27, 1:49 pm, Gerhard Fiedler

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".

Bingo.

However, I'm also not averse to doing it _right_, if not "pretty."
Now that I have the program, and am adding to it and "improving" it,
whenever I run across something more elegant or better or shorter or faster
(please: always faster), I'll put it in if it a) doesn't break the program I
know (I've been lost for many days before, changing some little thing that
was working...), or b) doesn't require a massive rewrite or c) doesn't
demand more of my limited brain than exists...

Thanks all again.

 

[John Brawley]

"Gerhard Fiedler"> On 2008-01-26 23:23:22,

Thank you very much.
(What does it mean: "destructors aren't executed" ?) [dels]
_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++?

Absolutely: sheer _speed_.
I even built a new computer mostly to run the program.
I read that C was the fastest available, hence C++ as its evolution, got
selected.
I'd have tried assembly if I thought I could have understood it.

The program calculates and adjusts positions of points in a spherical 3D
space, until the user either decides the points are arranged as expected, or
there's a power outage.
The program writes a file on keyboard command and at exit: all the points'
locations, and three necessary parameters.

User entry section is large. I'm adding a filereader, to defeat the power
outages or any other glitch that could shut down the program before I want
it to stop.
The filereader can't be in a function because the database is an array and I
can't emit an array from a function (and I saw in an earlier message that
emitting a pointer to an array is also somewhat "iffy").

The program already exists and works perfectly (ugly code, but working
program...), so I'd be really scared to try to rewrite it just to use a
std::Vector instead of the array[] it now uses.

Therefore the filereader has to go in main(), and if I read the file, I then
have to skip over the entire user-input section.
I can do it with a switch(var), but I still can't figure out how to avoid
the GOTO that skips over the user section....
(If this is better in a different thread, please tell me and I'll take it
there....)

.......And thanks to you and all for extending this delete[] ?? thead; I'm
learning much.

 

[Ian Collins]

The program already exists and works perfectly (ugly code, but working
program...), so I'd be really scared to try to rewrite it just to use a
std::Vector instead of the array[] it now uses.

A classic case where a safety net of thorough and robust unit tests
would remove your fear....

 

[John Brawley]

"Ian Collins" wrote

The program already exists and works perfectly (ugly code, but working
program...), so I'd be really scared to try to rewrite it just to use a
std::Vector instead of the array[] it now uses.

A classic case where a safety net of thorough and robust unit tests
would remove your fear....

Uh... (*smile*) ...elaborate, possibly?
I have ooodles of little .cpp files, tests of all the pieces that went into
the program, and a half-dozen incremental versions of the program, in
various states of completion (historical records, in case I really screw up
and lose my current best program .cpp file)....
But I'm unfamiliar with the phrase "unit tests".

(I tried to understand C++ Vectors before I settled on my 'new array[]'
method, but could not "get" them. I only grasped arrays when I "saw" them
as a row of slivers of bytes of hardware memory. I still don't "get"
pointers, but am trying to.)

 

[kwikius]

whenever I run across something more elegant or better or shorter or faster
(please: always faster), I'll put it in if it a) doesn't break the program I
know (I've been lost for many days before, changing some little thing that
was working...)

This is an old problem. And the standard solution is by using a so-
called "version control system".

Essentially you keep all your code in a database and check out a copy
when you want to work on it, then check it back to the database when
you are done. You can usually add some documentation to the changes
you made. The database keeps a "history" of all your previous work.

The database will let you "rollback" to a previous version, and also
provides the ability to show the difference ("diff") between two
versions of a source file.

http://tinyurl.com/2ps9bt
(List of some version control systems on Wikipedia).

In practise you can put anything you like in the database, data files
etc, etc..

regards
Andy Little

 

[John Brawley]

"kwikius"On Jan 27, 11:03 pm,

This is an old problem. And the standard solution is by using a so-
called "version control system".

Thank you very much for the helpful words.
I do keep all old pieces. There're not enough of them to require a
management system.
I didn't mean I feared getting lost without a life preserver; I fear getting
lost _anyway_.

My case is unusual: a 'handyman' using somebody else's (Python or C++)
toolbox: I only use the tools in the box that I need at the moment. I don't
know what tools are in the box until I have to use one..

I literally don't _remember_ how to do some things that I did before.
Example: I wrote the working program in C++ over a year ago, but when I went
back into coding to add the needed filereader, I looked at my program's
source and a good third of it was beyond me. ( _I_wrote_it_, and it was
gibberish to me.)

My "fear" is having to re-search and re-learn things I already used and the
effort/learning curve in something new, not the loss of what I did before.
I sometimes don't _understand_ what I did before.

This is the fate of a putative cosmographer nonprogrammer whom nobody will
believe or give a moment to unless he can show a working computer model of
his cosmography.
I got tired of being ignored because I had no communicable model.
(*smile*)

You and all have been very helpful this time.
I think I can now do the filereader, even if I have to employ one more
GOTO....

 

[kwikius]

"kwikius"On Jan 27, 11:03 pm,



Thank you very much for the helpful words.
I do keep all old pieces.  There're not enough of them to require a
management system.
I didn't mean I feared getting lost without a life preserver; I fear getting
lost _anyway_.

My case is unusual: a 'handyman' using somebody else's (Python or C++)
toolbox: I only use the tools in the box that I need at the moment.  I don't
know what tools are in the box until I have to use one..

I literally don't _remember_ how to do some things that I did before.
Example: I wrote the working program in C++ over a year ago, but when I went
back into coding to add the needed filereader, I looked at my program's
source and a good third of it was beyond me. ( _I_wrote_it_, and it was
gibberish to me.)

My "fear" is having to re-search and re-learn things I already used and the
effort/learning curve in something new, not the loss of what I did before.
I sometimes don't _understand_ what I did before.

The following is a case of "do as I say, not as I do"

Ideally IMO You should document what you have done in as much detai as
you can spend time on, and then make documentation a continuing part
of the whole process. A version control system helps at the
implementation level, but at a higher level trying to write a precis
of what you are doing is very good for clarifying what you are doing
for yourself, and will also make it much easier to explain to others.

Some minimal documentation in the source code at the top of a function
can work except that sometimes code gets changed while the old
documentation doesnt

I think its fair to say that most programmers don't spend enough time
on documentation, but in the long term it saves time and code that is
well documented tends to outlast code that isnt.

regards
Andy Little

 

[Ian Collins]

"Ian Collins" wrote

The program already exists and works perfectly (ugly code, but working
program...), so I'd be really scared to try to rewrite it just to use a
std::Vector instead of the array[] it now uses.

A classic case where a safety net of thorough and robust unit tests
would remove your fear....

Uh... (*smile*) ...elaborate, possibly?
I have ooodles of little .cpp files, tests of all the pieces that went into
the program, and a half-dozen incremental versions of the program, in
various states of completion (historical records, in case I really screw up
and lose my current best program .cpp file)....
But I'm unfamiliar with the phrase "unit tests".

If your tests are good enough, you can change the implementation (for
instance substituting std::vector for arrays), perform any fixes
necessary to get any broken tests to pass again and know your
application still works.

 

[John Brawley]

If your tests are good enough, you can change the implementation (for
instance substituting std::vector for arrays), perform any fixes
necessary to get any broken tests to pass again and know your
application still works.
Ian Collins.

Thank you Ian.
I may try that.
Have a good day, please. You and others here are the most helpful I've
known.

 

[John Brawley]

"kwikius" On Jan 28, 1:11 am, "John Brawley"

"kwikius"On Jan 27, 11:03 pm,

Example: I wrote the working program in C++ over a year ago, but when I went
back into coding to add the needed filereader, I looked at my program's
source and a good third of it was beyond me. ( _I_wrote_it_, and it was
gibberish to me.)

The following is a case of "do as I say, not as I do"

(*grin*)

Some minimal documentation in the source code at the top of a function
can work except that sometimes code gets changed while the old
documentation doesnt

I'll do more as you suggest.
I'm heavily documented inside my source (_I_ need to remember what I did and
why).
I also have its "purpose" rather fully explained at my website.

I think its fair to say that most programmers don't spend enough time
on documentation, but in the long term it saves time and code that is
well documented tends to outlast code that isnt.
regards
Andy Little

I enjoy writing anyway; I have this obsession that begs explaining; I can't
"write" (fine arts-like) in code; and I actually don't like math.
So I write a lot behind these //, and inside these /* */.

Have a very good day, Andy. You and others here are helpful beyond
expectation.

 

[James Kanze]

* 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. 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,

It can't be that fanatical about cleanup, given the amount of
memory it leaks.

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.

And it finishes far too quickly to suit me. Just the time to
write the core file, and it doesn't even wait for me to say I
want to exit. (Curiously enough, this problem *only* occurs
when reading news with Google news. And while the HTML that
Google sends out is particularly bad, that's still no excuse to
crash.)

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

That was much easier... ;-)

Ignoring real software engineering issues often is. (Sorry
about that, but I just couldn't resist the rejoinder. I know
that's not what you meant, and that you don't usually ignore
them, but I can't resist a snappy answer.)

 

[James Kanze]

Pure nonsense.

Not according to established software engineering principles.
Just because there are a lot of hackers writing a lot of junk
doesn't make it good practice.

 

[James Kanze]

The following is a case of "do as I say, not as I do"

You too.

Ideally IMO You should document what you have done in as much
detai as you can spend time on, and then make documentation a
continuing part of the whole process.

Ideally, you should document what you are going to do, before
doing it. Ideally, you should also document what you didn't do,
and why: why you didn't use algorithm X, which superficially
seems most appropriate, for example.

 

[James Kanze]

"Ian Collins" wrote

John Brawley wrote:
The program already exists and works perfectly (ugly code,
but working program...), so I'd be really scared to try to
rewrite it just to use a std::Vector instead of the
array[] it now uses.
A classic case where a safety net of thorough and robust
unit tests would remove your fear....

Uh... (*smile*) ...elaborate, possibly?
I have ooodles of little .cpp files, tests of all the pieces
that went into the program, and a half-dozen incremental
versions of the program, in various states of completion
(historical records, in case I really screw up and lose my
current best program .cpp file).... But I'm unfamiliar with
the phrase "unit tests".

If your tests are good enough, you can change the
implementation (for instance substituting std::vector for
arrays), perform any fixes necessary to get any broken tests
to pass again and know your application still works.

Not to be overly pessimistic, but...

-- There are some things that really can't be verified simply
by testing. The most obvious is the readability and
maintainability of the code---important issues in most
cases. But there are also a lot of threading issues which
don't lend themselves to testing, and some floating point
issues as well.

-- Knowing how to write effective tests is a software
engineering issue in itself, and is in some ways more
difficult that writing C++ or even good design (although
good design generally should lead to effective tests---in
both cases, you need to think about the corner cases, and be
sure they're handled correctly).

For something as direct as replacing a C style array with
std::vector, I don't think that the first is really much of an
issue, but given what John has said of his background, the
second very well could be.

 

[Krice]

delete[] label; // is this _necessary_ in this case?

Yes.
What is not neccessary are questions like that and threads
of non-discussion they generate.

 

[Gerhard Fiedler]

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

Is this your (plus a few other's) personal opinion, or is there some
evidence that this is more than opinion?

For example something like this:

apiType result;
for(;
{
callSomeApi( result );
if( someCondition( result ) )
break;
callSomeOtherApi( result );
}

AIUI, this can be transformed into a "non-break" solution in various ways,
but they either duplicate code (for example a pre-loop call to the setup
function) or introduce an additional boolean -- with the only purpose to
get rid of the break, without increasing clarity or improving anything at
all.

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.

I think in the example above, not using break would be obfuscation and
unnecessary complication, similar to some C code that would be perfectly
structured and readable with a few judiciously placed gotos and gets
convoluted and complicated just because the author thought that "gotos are
(always and in all ways) bad".

Gerhard

 

[John Brawley]

"Krice" wrote >

delete[] label; // is this _necessary_ in this case?

Yes.
What is not neccessary are questions like that and threads
of non-discussion they generate.

......What is a person (me, who began the thread) to do then, if a general
concensus before your post is that in my specific case it _isn't_ absolutely
necessary, but you enter with a simple "yes" and a comment and no 'why' to
the 'yes'?

I had some trouble getting my two delete[] lines right, and gave up for a
time (but the program ran without them), and I only put them in when I
finally understood their use.
.....Hence the question here, which I thought was valid, and the educational
aspect of getting an answer, valuable or useful if not to others, at least
to me.

Likely, not all of the people who come here begging for increased
understanding, are daily programmers or C++ writers who do it for a living.
You experts here are a necessary resource also to the mere student, or to
the person who has no choice but to write one program in order to get
something done.

 

[John Brawley]

"James Kanze" wrote

"Ian Collins" wrote

John Brawley wrote:
The program already exists and works perfectly (ugly code,
but working program...), so I'd be really scared to try to
rewrite it just to use a std::Vector instead of the
array[] it now uses.
A classic case where a safety net of thorough and robust
unit tests would remove your fear....

Uh... (*smile*) ...elaborate, possibly?

If your tests are good enough, you can change the
implementation (for instance substituting std::vector for
arrays), perform any fixes necessary to get any broken tests
to pass again and know your application still works.

Not to be overly pessimistic, but...
...

-- There are some things that really can't be verified simply
by testing. The most obvious is the readability and
maintainability of the code---important issues in most
cases. But there are also a lot of threading issues which
don't lend themselves to testing, and some floating point
issues as well.

Please, you bring up a worry: you say some floating point issues don't lend
themselves well to testing. I use double precision floating point almost
everywhere, and the program when running is in a constant state of doing
repeated Pythagorean 3D distance calcs and such.

What tests would have issues with floating piont, if your answer would be a)
of interest to you or others or b) not wildly offtopic?

(My "tests" so far have consisted of simple right-answer checks and of
sending the .exe I write with Windows 98 to friends with different operating
systems --albeit all Micro$soft'$-- and seeing if it chokes and dies or not.
(So far, not.))

......

-- Knowing how to write effective tests is a software
engineering issue in itself, and is in some ways more
difficult that writing C++ or even good design (although
good design generally should lead to effective tests---in
both cases, you need to think about the corner cases, and be
sure they're handled correctly).

....For something as direct as replacing a C style array with

std::vector, I don't think that the first is really much of an
issue, but given what John has said of his background, the
second very well could be.

Thank you. I'm unsure if it would be. The program is so simple in concept
(if difficult --for me-- to implement), that it's unlikely extensive tests
of its functioning would tell me much more than I already know, but it's
critical that it run without problems on other people's machines.

 

[John Brawley]

"Gerhard Fiedler" wrote >
James Kanze wrote:
Gerhard Fiedler wrote:

Is this your (plus a few other's) personal opinion, or is there some
evidence that this is more than opinion?
For example something like this:
apiType result;
for(;
{
callSomeApi( result );
if( someCondition( result ) )
break;
callSomeOtherApi( result );
}

AIUI, this can be transformed into a "non-break" solution in various ways,
but they either duplicate code (for example a pre-loop call to the setup
function) or introduce an additional boolean -- with the only purpose to
get rid of the break, without increasing clarity or improving anything at
all.

Please;
I think "never" is a bit strong: I have to break out of a loop because in a
real sense the program _is_ the loop. A forever-loop needs some sort of
conditional to get out of it, and if the conditional has to be put in the
middle of the loop somewhere, I don't see how to avoid leaping out of it
'down' to some minor termination cleanup details and an exit by using a
GOTO. (Mine is in a read-the-keyboard switch statement which also contains
manual control for modifying the running variables, and a couple of
on-the-fly filewriters).

I think in the example above, not using break would be obfuscation and
unnecessary complication, similar to some C code that would be perfectly
structured and readable with a few judiciously placed gotos and gets
convoluted and complicated just because the author thought that "gotos are
(always and in all ways) bad".
Gerhard

Thanks for that, Gerhard. I needed to 'hear' it.
"Always and in all ways" no GOTOs should maybe a guideline be (that I grasp
and may agree with), but Red Flags go up in me in almost any subject where I
run into one of those absolutes like "never" or "there are no exceptions."

(Pardon: I've seen one objection to this thread I started, so I guess I'm in
some violation or other, and will take any non-"is delete[]
necessary"-thread questions to a new thread.
Thanks lastly and to all for the help!)