LETTERS

One Good Answer...

In the October 1991 issue, Steve Summit's "C Q&A" had a question proposed on how to write a generic macro to swap two values. The answer given was that there was no good answer. Certainly this is true in general for pointers and floating-point values. However, for integer and character values, the following is a simple solution: #define SWAP(a,b) a^=b; b^=a; a^=b.

By using UNION statements, pointer, and floating-point values can also be swapped. But I admit that it surely would be a special case if the above could be used without a lot of setup.

Ron Harper

Houston, Texas

What's a MODder to Do?

Dear DDJ,

In reference to Jeff Duntemann's "Structured Programming" column (November 1990) about the MOD function in Turbo Pascal, Jeff states that in Turbo Pascal, -17 MOD 7 returns -3, whereas -17 modulo 7 should be 4. If I remember from my mathematics classes correctly, in modulo 7 arithmetic, -3 is equivalent ("congruential to") 4. There are 7 congruencer classes in modulo 7 arithmetic. They are:

  ...-14-7071421...
  ...-13-61-81522...
  ...-12-5291623...
  ...-11-43101724...
  ...-10-34111825...
  ...-9-25121926...
  ...-8-16132027...

This can be seen through use of the graphical interpretation of the modulus operator Jeff gives in his article --count clockwise (for positive numbers) or counterclockwise (for negative numbers) and see which numbers leave you at each position on the "dial." It is conventional to name as a representative of a congruence class for modulo n the value between 0 and n-1. Turbo Pascal (and QuickBasic and other programming languages) return a different representative.

To return the desired representative, Jeff's method of using Turbo Pascal's TRUNC (truncation) operator and forcing it to round in the proper direction if a negative value is encountered appears to work. In QuickBasic, the FIX operator seems to return the same results as does Turbo Pascal's TRUNC. The MOD operator appears to give the same results in both languages. There are two options which are probably more straightforward than the method you use to return the desired representative:

Add n to the result of i MOD n if it is less than 0; that is, k=i MOD 7: IF k<0 then k=k+7.

Build your own MOD using an equivalent of QuickBasic's INT operator as k=i-7*INT(i/7).

INT x "returns the largest integer less than or equal to" x, whereas FIX x "returns the truncated integer part" of x. The difference between INT and FIX is that, for negative x, FIX returns the first negative integer greater than x, while INT returns the first negative integer less than x.

So, in conclusion, I wouldn't consider the MOD operator to be "wrong" in Turbo Pascal (or QuickBasic)--it just returns a representative of the correct congruence class which may not be the one that you (or the rest of your program) are expecting.

David Hall

Moscow, Idaho

Example 3

  String name ="myfile";
  String ext=".dat";
  String fullname=name+ext;
  FILE *fp=fopen (fullname, "r"); // missing '\0' terminator
  FILE *fp=fopen (fullname+' \0',"r"); // calls malloc!!

The purpose of having a string class is to permit the code in Example 3 without the need of a time- and memory-consuming conversion.

The C standard library contains many functions accepting C string arguments. Many compilers supply these functions in tight assembler code. Why should we be discouraged from using these C standard library functions? What are the advantages of rewriting all that proved and widely used code?

An often used argument against the C string is that determining the end of the string can be time consuming. A String class can easily overcome that disadvantage by storing the current length of the string. To speed up concatenation, the class could also store the current size of the reserved memory and assign memory in chunks.

There is a reason why the proposed ANSII class, specifying that a string can contain the "\0" character and that it is not terminated by the "\0" character, will not be used very much:

Millions and millions of lines of code in libraries accept C strings as arguments. To use the proposed string class, a conversion routine, probably reserving heap memory for temporary storage, must be called before a call to a function accepting a string argument. A major feature of C++ is that it is easy to use existing C libraries. It would be a waste of programming power to rewrite all that code just so functions would accept ANSII C++ strings.

What programmers really need is a dynamic string class that makes string handling as easy as in Basic, and also allows the use of C libraries. Classes like that have been published. The ANSII committee should not invent new things or change accepted conventions, but should generate a useful standard that combines the advantages of the different versions already in use.

Helmuth Schmalzl

San Luis Potosi, Mexico

Less is More

Dear DDJ,

This is in regard to Jack Woehr's September 1991 article, "Forth: A Status Report." I have received copies of Forth BASIS proposals for a few years, only to see that the standard was a growing set of words. I felt the standard should be on the Core Word Set (original 83 word set?). All other words should be in a routine library that can be chosen and compiled by the end user if needed. The idea is to give the end user the tightest or smallest kernel to start with for the platform being developed on.

William B. Higinbotham

Brookhaven, New York.

Why Buy the Cow When the Milk is Free?

Dear DDJ,

This is in response to the "Editorial" in the October 1991 issue concerning "pay-per-use" software. There really is no reason to pay to use software, if software is as free as air (paraphrasing the GNU manifesto). You just have to know how to find it. Many talented people (including GNU) are replacing and enhancing ~NIX with free software. One problem ~ vendors tend to hide their source c~, making it difficult for users to fix bugs. It makes life much easier when you have readable source code.

Marty Leisner

Rochester, New York

C Fans and Otherwise

Dear DDJ,

I like the new "C Language Q&A" feature very much. I tend to agree with Jeff Duntemann's assessments of C (as a "sorry mess," for example -- March 1989). Still, C is what I use. I am always glad to see warnings about hazy aspects of the language. Gimpel's lint advertisements are likewise stimulating, though of course they don't print the answers.

Mr. Duntemann may be interested to learn that I switched from Pascal because it is so different on OS-9 and MS-DOS. I find C less confusing than attempting to remember which Pascal I'm using.

Charles Marsh

Monroeville, Pennsylvania

Dear DDJ,

I enjoyed your May 1991 issue, as I do each issue. However, in reading the "Programmer's Bookshelf" by Andrew Schulman I see that he could not be considered a C fan. Can't fault him too much for that, as it seems my favorite programming columnist (Jeff Duntemann) doesn't appear to be enamored with it either. It is, however, in the C++ form, my favorite. I therefore feel obligated to point out what appears to be a misunderstanding of operator overloading.

On page 138, column 2, paragraph 1, the statement is made: "Nor can you overload operator ^() to mean exponentiation and check if (n == 2^64 - 1) because in C--I mean in C++, the ^ operator is unary not binary." Example 4 demonstrates that this is not the case.

Example 4

  /*******************************************************
  CLASS    :  cMyInt
  PURPOSE  :  demonstrate overloaded xor operator
  DESCRIPTION  :  useless
  LAST UPDATE  :  4-15-1991 21:51:03
  PUBLIC  :
  MEMBER FUNCTION      CALL WITH     RETURNS
  cMyInt               void
  cMyInt               int i
  operator =           int i         cMyInt&
  operator ^           int i         int
  operator int         void          int
  ********************************************************/
  class cMyInt {
     long Val;
     public:
     cMyInt ( void ) { Val = 0; }
     cMyInt ( int i ) { Val = i; }
     cMyInt& operator =( int i ) { Val = (long) i; return *this; }
     int operator ^( int i );
     operator int( void ) { return (int) Val; }
  }; // class cMyInt
  int cMyInt::operator ^( int i ) {
     if ( i == 0 ) {
          if ( Val == 0 ) return 0;
          else return 1;
  }
     int exp = ( i < 0 ) ? ( i * -1): i;
     long l = Val;
     if ( exp > 1 )
        for(--exp; exp; exp--) 1 *= Val;
     return (int) 1;
  }
  main() {
     int i = 3;
     cMyInt m;
     m = i;
     if ( ( ( (cMyInt) 4^2 ) - 1 ) == 15 ) {
      printf("%d ^ 4 = %d\n", (int) m, m ^ 4 );
      printf("\tc's version is %d ^ 4 = %d\n", i, i^4);
     }
     else printf("\tIt didn't work!\n");
  }

If your example class BigInt has been properly defined to handle integers large enough and includes the definitions for:

  BigInt::Bigint( int ); BigInt& BigInt::operator ^( int );

your code would work in this form:

  if (n == ( (BigInt) 2^64 ) - 1 ) {...}

A cast is necessary in order for the compiler to "know" that we want the overloaded operator for a power function, not the xor function that would be used on the char 0x2. The extra parens are necessary because while we can overload the operators all we want, we cannot change the precedence which they receive, and xor has a lower precedence than minus.

xor is not unary in any language I have ever tried.

Compiled with Turbo C++, Version 1.01, the output from the above test program looks like this:

   C:\ > test 3 ^ 4 = 81
   c's version is 3 ^ 4 = 7

I admit, however, that I don't know any way to pass a 20-digit integer in C++ except as a string. Nobody's perfect. C++ gives me the low-level control that I want and the reusability and ability to build in error detection--correction of objects. It also has the notation system that makes the most sense to me, which is probably the only true reason for preferring it over Turbo Pascal. It just seems more natural to code:

  int a, b, c; a = b = c = 0; a = ++c; b = ++c; ++c += a;

than the Pascal way:

    var a, b, c: integer; a := 0; b := 0; c := 0;
    c := c + 1; a = c; inc( c ); b := c; inc (c, a + 1 );

I do wish however, that there were a way to say:

  function funcA( a, b, c: integer): integer;

(although this would take more space), rather than:

  
  int funcA( int a, int b, int c );
  // shouldn't have to repeat int three times.  K&R missed the boat there, or 
  rather the improvements to K&R did.  With K&R you could say:

  int funcA( a, b, c )
  int a, b, c; {... }

Prototypes are an improvement, but we lost something too.

As always I enjoyed DDJ. Thanks for a great mag, and keep it coming.

Jerry E. Howton

Madisonville, Kentucky