Letters

Dear DDJ,

In Michael Swaine's recent column about object-oriented programming on SD '88 ("Programming Paradigms," June issue) there was a question: Are there any rules to decide what objects to define? I think--in contrast to the panelists--there is a good way to construct programs with well-chosen objects. Of course, if you start from scratch nothing will be changed for the better.

My answer is simply to use algebraic specification to define the problem and its solution. That means use a specific style of functional programming with precise semantics. You have to define entities by functions and conditional equations to enhance and combine the specifications to describe the problem at hand. This way you will easily get a well-structured problem solution, telling what is to be done.

And now consider object-oriented programming as the way to tell how the solution is to be realized on the computer. You will find a direct correspondence between specification modules and objects needed in the implementation. I can't speak here about all the other--and more essential--merits of this approach because there is not enough room. But I think we should favor the use of formal methods already in the design phase to overcome such questions as the one mentioned above--and a lot of other difficulties in programming.

Dr. Lutz Pietschker

Muhldorf, West Germany

Dear DDJ,

I like Kent Porter's "sub"stitute for the DOS dir command very much ("Structured Programming," August issue). You may be interested in a minor error in the source code: in function SizeInK, "IF size MOD Blocksize < >0" should be "IF files.size MOD Blocksize < > 0." I stumbled on this when I used "sub" on a TEX pixel directory which happened to contain files with exactly 4,096 bytes.

William F. Trench

Trinity University

San Antonio, Texas

Dear DDJ,

It was interesting to read Martin Stitt's article on action diagrams--or action charts as he calls them ("Using Action Charts," September issue). These diagrams have been around for some time, competing against other diagramming methods for attention. I find action diagrams rather useful for defining mini specs in data flow diagrams. They are clear, concise, and much more accepted by the user community and the programming staff than structured English.

However, typing all those macros to create such a diagram is tedious and diminishes its effectiveness. I have created a split screen action diagram editor which relieves analysts of having to worry about the constructs, and instead, they can concentrate on showing the logic flow. I urge readers to contact me for a free copy at 6087 Dana Dr., Norcross, GA 30093; 404-925-3122.

Sam Johnson

Norcross, Ga.

Dear DDJ,

I really appreciated Ratcliffs and Metzener's article on Pattern Matching ("Pattern Matching by Gestalt," July issue). It was excellent! I was also quite intrigued with the algorithm itself, but like all real programmers, I dislike having to use assembly language.

Dear DDJ,

The review of the current state of C compilers in the August issue was very interesting. ("Speed Trials: Five Cs Compared.") I was especially pleased to see that you tested code generation and its correctness. This gives a better feeling for the quality of the compiler than using only the benchmark timings.

However, I was puzzled by the emphasis on debuggers. There were no details on what made one debugger stand above the others, but it's something of a moot point anyway. Software debuggers are not the best tool for the job and should not influence the rating of a compiler.

Specifically, every software debugger I've seen is weak in three places. I've use Microsoft's Codeview, so I'll use it to illustrate my points, but the same criticisms apply to other debuggers too.

1. Transparency. Adding the debugger to the system should not change the behavior of the application program. Software debuggers almost all fail here because they load below the program in RAM. A program that passes data on the stack (like C, for example,) may act differently when loaded at the higher location. Beside that, the RAM used by the debugger is that much less heap available to the program. Codeview is particularly bad here--not many serious programs won't notice the loss of 200K.

2. Independence. The performance of the debugger should require as little as possible of the other parts of the system. At a minimum, it should not expect the program to leave the interrupt vector table alone. Good ones shouldn't depend on DOS, either. Codeview fails here, too. Trash the keyboard interrupt vector, and down it goes.

3. Reliability. The debugger should be able to protect itself from the application. C programs are famous for crashing when people use uninitialized pointers and romp through memory that doesn't belong to them. Some software debuggers claim to use the capabilities of the 80386 to protect themselves. Some may work. The one I tried didn't.

The only thing I've found that meets these requirements is a hardware-based debugger. I use Periscope, but there are others out there too. Periscope uses 64K of memory on an expansion board to store its code and data. The memory can be installed in memory space, which is unavailable to the program in the first place, so you lose no bytes for your application. The memory is write-protected so your application can't trash it, too. Furthermore, Periscope reloads the interrupt vectors it needs for I/O while it is active, so your programs can even trash them and not crash the debugger. Their real trump, though, is the hardware trace circuitry on the board. You can run at full speed, quietly monitoring the running application; then break out to the debugger when a programmable break condition occurs; and then examine the hardware traceback buffer to see exactly what your program was doing before and after the break condition occurred. Periscope even has source-level debugging if that's what you want. I've used it to debug a 500K application which loads under DOS then deletes DOS and disk BIOS from the system entirely while it's running to use the extra heap. Try that with Codeview!

In short, software debuggers fall far short of what is attainable with hardware based products. This being the case, it's not fair to rate these top line compilers on the basis of the accompanying debuggers. Anyone who's serious about debugging (meaning their job is on the line) probably won't use them anyway. The protection capabilities of the 80386 open the way for software products that make the grade, but they aren't here yet, and you can bet they won't be freebies when they come.

Jim Castleberry

Orlando, Fla.

_LETTERS_

<a name="01e6_000a">

int simil (s1, s2)
/* Ratcliff/Obershelp Pattern Matching */
char *1, *2;
{
  short l1, l2;

  l1 = strlen(s1);
  l2 = strlen(s2);

  if (l1 == 1)                 /* check for the easiest case */
    if (l2 == 1)
      if (*s1 == *s2)
        return(100);

  return(200 * GCsubstr(s1, s1 + l1, s2, s2 + l2) / (l1 + l2));
}

int GCsubstr(st1, end1, st2, end2)
/* recursive greatest common sub-string */
char *st1, *end1, *st2, *end2;
{
  register char *a1, *b1, *s1, *a2, *b2, *s2;
  short max, i;

  if (end1 <= st1)              /* s1 empty */
    return (0);
  if (end2 <= st2)              /* s2 empty */
    return (0);
  if (end1 == st1 + 1)          /* s1 has one char, */
    if (end2 == st2 + 1)        /* and s2 has one char. */
      return(0);                /* They cannot be equal. */

  max = 0;
  b1 = end1; b2 = end2;

  for (a1 = st1; a1 < b1; a1++)
    for (a2 = st2; a2 < b2; a2++)
      if (*a1 == *a2)
        {               /* How long is the common sub-string? */
        for (i = 1; a1[i] && (a1[i] == a2[i]); i++)
          ;
        if (i > max)
          {
          max = i; s1 = a1; s2 = a2;
          b1 = end1 - max; b2 = end2 - max;
          }
        }
  if (! max)
    return (0);

  max += GCsubstr(s1 + max, end1, s2 + max, end2);        /* RHS */
  max += GCsubstr(st1, s1, st2, s2);                      /* LHS */

  return(max);
}