Re: is delete[] necessary?
On Jan 28, 6:18 pm, "John Brawley" <jgbraw...@charter.net> wrote:
"James Kanze" wrote
[...]
-- 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?
Floating point is very, very tricky, because it's not linear.
Which means that at least in principle, and algorithm might work
for two values very, very near one another, and fail for a value
in between them. (And of course, the number of possible
floating point values generally precludes exhaustive testing.)
The result is that you do very, very careful numerical anaysis
to prove that your algorith will behave linearly over a given
range, despite the descrete nature of machine floating point,
then test the ends of the range exhaustively, and add a few
random tests elsewhere. In some cases, in fact, you'll find
that you'll have to use two different algorithms, depending on
the input, since no one algorithm will be linear over the entire
range---in such cases, of course, you'll test very insensively
around the switch-over point.
(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.))
Right-answer checks for what input? The problem is that an
algorithm which gives a correct answer for some input might give
a wrong answer for other input. (Although I've never actually
seen the case, I've heard stories---and it sounds plausible---of
functions that returned the correct answer for all but two or
three values in the entire floating point range. In one case,
at least, there were just a couple of values where the function
failed to converge, due to imprecisions in the floating point
arithmetic, and the program went into an endless loop.)
......
-- 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.
If you're using floating point, be very cautious about numeric
stability. Machine floating point are NOT real numbers, and
many of the rules of real number arithmetic don't always hold:
e.g. (a + b) + c != a + (b + c) in many cases.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34