Re: an algorithm with interruption in the middle
Alf P. Steinbach wrote:
* Carlos Moreno:
James Kanze wrote:
Anyone having seen
"1950's style spagetti" would certainly agree that even the
worst abuse of break and continue are still a far cry from
unconstrained use of computed goto and its brethren.
Do we even *have* the tools, in C++, to write truly 1950's
spaghetti code?? :-)
Sort of. The 1950's computed goto lives on in C++, somewhat reduced in
power (you can't go to an arbitrary address) as the switch statement.
And as long as you don't have destructors that need to be invoked
automatically, there's always longjmp. Which I and many others once
used to implement simple co-routines and "active objects" in C++.
You can make similar spaghetti, but it's more work. What's
missing is the arithmetic if, for example: a statement which
always jumped somewhere, so the following statement was
unreachable unless it had a label. (You could shuffle the cards
in a complex decision tree, and the code would still work.) Or
a real computed goto, which could goto another function. Or
multiple entry points into a function.
And of course, in Cobol, you could specify which "paragraphs"
made up the function at the call site. (On the other hand, you
couldn't pass parameters to the function, so you had to use
global variables.)
What's lacking is the super-duper subroutine concept from TAOCP where
you store the address where the subroutine should return, directly in
the subroutine's final jump instruction, before "calling" the subroutine
by jumping to one of its many entry points.
That's more at the assembler level. I remember working on such
a processor once. The real fun began when you tried to write a
re-entrant function on it.
If you go back 30 or more years, you can find some really wierd
things at that level. The first machine I worked on
professionally didn't have any indexing or indirect addressing.
To iterate through an array, you incremented the address in the
load/store instruction; otherwise, you build a new load/store
instruction on the fly, and executed it.
Combined with computed jump
addresses this allows any amount of impenetrability one could dream of.
Emulating that in standard C++ would be hard or perhaps impossible, I
think, without some kind of interpreter action.
You can always write machine code into a buffer on the stack,
and then invoke a function through a pointer to execute into it.
(I actually did that once. The profiler said I didn't have a
choice. Or rather that the only other choice involved
duplicating code 8 times, on a machine with only 64 KBytes.)
Thinking about this, it hit me that we really have tackled the spaghetti
control flow problem, more or less, so much that we can't reproduce it,
due to the influence of luminaries like Edsger W. Dijkstra, but that we
/still/ haven't made even a small dent in the problem of spaghetti data
flow -- we still have those globals and pointer aliasings and outside
initializations coming out of the blue from the most unexpected quarters
at the most unexpected and inconvenient times, and whatnot, instead of
programming to some reduced set of more high level concepts like the
"structured programming" execution flow control constructs.
Again, creating unexpected aliasing via pointers in C++ is a lot
harder than simply miscopying a common data block in Fortran.
Real spagetti data means not using even struct, not to mention
class. But you're right that the progress hasn't been nearly as
great as in control flow.
Of course, for everything they take away, they give something
back. Fortran didn't have struct, but it didn't have pointers
either. And I've seen at least one program with spagetti
inheritance, with a typical most derived object at least ten
levels from the lowest base, and every level with multiple
inheritance and virtual base classes. And if you look at some
of the template code being written these days...
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]