Re: C++ fluency
On May 7, 6:00 am, Jerry Coffin <jcof...@taeus.com> wrote:
In article <4a02059c$0$2721$cc2e3...@news.uslec.net>,
n...@nowhere.com says...
[ ... ]
Hint: nobody said it was perfect under any and all
conditions. Anyone even looking for such a methodology is
wasting their time.
Though his particular example may have been somewhat obscure,
he points to a much more general type of problem: code that
involves synchronizing multiple threads of execution is almost
impossible to test.
Testing of sequential code can only prove that the code works
correctly for the specific cases that were tested, and it
could still have bugs for other cases. Care in selecting the
cases you test helps you _guess_ that the code works for a lot
more cases than you really test.
With multiple threads of execution, though, passing a test
doesn't even assure you that the code is correct for the
specific case(s) you tested. Code that's dead wrong can still
pass tests an arbitrary percentage of the time.
I think a better way of characterizing the problem is that the
various latencies are part of the "input". The problem isn't
that the code behaves differently for the same input; the
problem is that the set of input is almost infinite, and that
you usually have no way of controlling it for test purposes.
(I've vaguely heard of systems for small, embedded processors,
where you could control the timing of external events, but I've
never actually seen one. And of course, you have absolutely no
control over when Windows or Unix does a context switch.)
(And I'd simply love it if someone could prove me wrong about
the above.)
--
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