Letters

Dear DDJ,

The article "Find that Function" caught my attention. I imagine every programmer, at some time, wants a list of functions or other declarations, particularly for a sizable program distributed over many source files.

I was surprised by the complexity of the code used to build the function list in Hymowech's Listing One (pages 70-74), perhaps 400 lines of code and comments. Surely there should a simpler way of doing this. The problem is how to extract all instances of a particular grammar element, the identifier of a function definition, from a source file presented as a character stream. This is made difficult by the start of the definition (function type, name, parameter declarations, and beginning of the function body) being commonly on more than one line, having a varied arrangement of white space and punctuation, comprising many different tokens, and possibly including comment lines.

Lex, a generator of automatons for lexical analysis, is admirably suited for this particular kind of pattern-matching problem. My example code gives Lex sources for two filters and a wrapping shell script. The definitions (FUNCSTRT, etc.) were written in the hope that they make self-explanatory the few pattern-action rules given at the end of each source, following the %% symbol. Mk_funclist.one and its dependents serve to build a table of functions from a list of C source files.

The seven rules in the two Lex sources duplicate, I believe, the essential actions of Listing One of "Find that Function." The design of Listing One assumes that preprocessor directives within the function body do not alter the curly brace balance. If this is not true, my second example shows that the preprocessor itself can be used to sort things out. A few changes in Listing One serve to change it into a generator of a list of all declarations, each on one line, with parameter declarations and return value given on the line for each function (a lint library).

  # MK_FUNCLIST.TWO
  echo"                   /*****FUNCTION LIST*****/\n"
  for i; do
          echo "\n/*'basename ${i}'*/"
          cat $ {i}| funcfilt1|/lib/cpp -P -Cl
                   funcfilt2|uncomment|funcfilt3
  done

  %{
  /*-FUNCFILT1: prepare for cpp execution of #ifdefs, etc.; */
  /*i.e., setup to restore #includes & remove code added by cpp */
  %}
  %%
  ^\#[ \t]*include.*$            {printf("/*%s*/\n", yytext);
          printf ("/*DINGDONGDELL*/\n");
          printf ("%s\n", yytext);
          printf ("/*DELLDONGDING*/\n:);}
  .|\n                              ECHO;

  %{
  /*-FUNCFILT2: remove cpp-included code, restore #include's */
  %}
  %START DING
  %%
  ^"/*DINGDONGDELL*/"$               BEGIN DING;
  ^"/*DELLDONGDING*/"$               BEGIN O;

  <DING>^"/*#"[^*]*"*/"$             ;
  <DING>.|\n                         ;
  ^"/*#"[^*]*"*/"$                   {yytext [yyleng-2] = 0;
           printf ("%s",  &yytext[2]);}
  ^[\t]*\n                           ;
  .|\n                               ECHO;

With Lex, awk, and other such armament in hand, there would seem to be little justification for coding the solution to a text manipulation problem from scratch. Programmers should be encouraged to use the excellent tools available and should have the knowledge to choose the one right for the job. I hesitate to suggest that Dr. Dobb's should take its readers through discussions of the internals or give tutorials on the use of "mature" tools like Lex, yacc, and awk. You could, however, take care to give readers programming examples that, rather than showing the long and wrong way to solve a problem, show them the appropriate use of tools.

John Rupley

University of Arizona

Tucson, Arizona

Dear DDJ,

I've read with interest the Ada articles in the September 1988 issue and hope to see more such features in the future.

In "Object-Oriented Dimensional Units," John Grosberg presents a useful example of how a dimensioned unit with a float-type value might be implemented as a reusable component in Ada. However, I think one of his main points is misleading.

In discussing the operations that the dimensional unit type Float_Unit.Class inherits from the predefined type Float, Mr. Grosberg notes that some operations are invalid. For example, 5 feet x 4 feet = 20 square feet, not 20 feet. He then states the "Ada provides no way to detect it (an invalid operation) at compile time" and presents a way to detect the error at run time.

One way to detect such an invalid operation at compile time is to implement the type "Class" as a private type. Objects of a private type may be manipulated only by the operations provided in the visible part of the spec. If invalid operations are not explicitly provided, then they are not available to a client. The integrity of the abstraction is thereby preserved, and invalid operation attempts are discovered at compile time.

Use of private (and limited private) types is even more important when a class is implemented as an array or record, which is often the case. Typically, individual components of a composite type need to be protected from manipulation by the clients. This is accomplished by use of private types which provide a more accurate abstraction, a cleaner interface for the client, more precise control of operations on the class, and minimization of side effects of any changes to the internal representation of the type.

The code on page 12 shows the revisions to Mr. Grosberg's Float_Unit spec required to make type "Class" a private type. "Class" is declared as type private instead of type Float. The private part is inserted at the end of the spec, and "Class" declaration is completed in the private part. The invalid function declarations are then removed from the spec. The Units_Error exception declaration is also removed.

In the Float_Unit body, only the removal of the invalid function bodies is required. Package Float_Unit is shown in Listing One.

Glenn A. Edwards

St. Petersburg, Fla.

John responds: My statement that "Ada provides no way..." sounds more absolute than I intended. I would have been more correct had I said "having chosen to make float_unit.class public, Ada provides no way...." Any method of doing something has advantages and disadvantages relative to the application. One most choose the method that best fits the circumstances. Mr. Edwards' method for making float_unit.class into a private type is the way I started the design of the float_unit package. For my application, however, I eventually chose to make the type public for two main reasons: First, I wanted to be able to use floating point literals with variables of the various units types. For example, I wanted to be able to say:

supply_voltage : volt.class := 5.2;   
or       supply_voltage := 10.0;

Second, I wanted to be able to use the range declaration and checking features that are available for floating point types in Ada. So, for example, I could do something like this.

supply_voltage: volt.class range 0.0
                    .. 10.5;

I think it is safe to say neither of these capabilities is available if the type is private. One could (if the type were private) obtain the effect of my first example by adding a function to the package to convert floating point to float_unit.class:

function to_class( f : float ) return
                    class;

and use it as an inherited function like this:

supply_voltage : volt.class :=
               volt.to_class(5.2);

But that seems less natural, and, besides, the range feature that I wanted still wouldn't be available. In addition, there is little reason to hide the fact that a dimensional unit is based on float, since that is the way we think about them anyway. It is only necessary to "hide" or restrict the ways they can be combined with each other. What I traded for the features I wanted was to postpone the checking of some invalid operations to run-time. By the way, if Mr. Edwards or any other readers are interested in an altogether different method of handling units in Ada, I recommend they check out the article "Dimensional Analysis in Ada" by Pat Rogers, published in the ACM Ada Letters, vol. 8, no. 5, Sept./Oct. 1988.

Dear DDJ,

I enjoyed reading Steve Upstill's article on RenderMan Shading Language("Photorealism in Computer Graphics," November 1988, but Figures 1 and 3 provided compelling examples of why software people have to be watched so closely out in the real world. The threads on the light bulbs are left-handed. And another thing: Threads are helixes, not spirals.

Fred Klingener

McLean, Virginia

Editor's note: Unfortunately, the slide was flopped during the printing process. The error was not the programmer's.

Dear DDJ,

Software Manual for Elementary Functions (by William J. Cody Jr. and William Waite, Prentice-Hall) should help Alan Clark, who needs a resource that lists fundamental algorithms for high-level functions that do not exist in machine code. (See "Letters," August 1988.) The book gives detailed implementation of sqrt, alog, alog10, exp, power, sin, cos, tan, cot, asin, acos, atan, atan2, sinh, cosh, tanh, and provides a test suite to boot.

Edmund Ramm

Kaltenkirchen, W. Germany

Copyright © 1989, Dr. Dobb's Journal