Click above to get retro games delivered to your door ever month!

Clipper Summer '87 and 5.0

   RLIB contains libraries for both Clipper Summer '87 and Clipper 5.0.
   The 5.0 version of RLIB was specifically written to take advantage of
   the new Clipper LOCAL and STATIC storage classes.  This results in
   optimized function performance, object code size reduction, and symbol
   and address resolution at compile time rather than at run time.


   Local and Static Variables

   Probably the most important change to Clipper was the addition of true
   Local and Static storage classes.  I will not attempt to go into an
   explanation of these storage classes, the Clipper manual does a good
   job of that.  I do want to add my two cents worth.  Local and Static
   variables finally let you truly hide information within a function.
   Not only are local variables not visible below the function (in
   routines which the function calls, unlike PRIVATE variables), but
   their name is resolved at compile time.  This means simply that if you
   have a local variable in your function named HOURLYRATE that this is
   only meaningful in your source code.  Once it is compiled the need for
   the name is gone, it is resolved to an offset address in your code.
   In Clipper Summer '87, your executable ended up with a symbol (some
   text), HOURLYRATE, contained in the .EXE file.  Aside from the 16 to
   22 or so bytes of space that consumed for each variable, it was there
   for the poking at run time.

   Static variables are exciting for the same, yet an additional reason.
   Values you assign to static variables aren't released when the
   function exits.  This means you can write functions that can remember
   details about the state they were in, and have that information
   available the next time the function is invoked.  Again, the Clipper
   manual does a very good job of explaining these concepts as do a
   number of third party publications.

   The Clipper 5.0 version of the RLIB library makes extensive use of
   LOCAL and STATIC variables, not only for more efficient and faster
   functions, but also as a matter of good code form.  I just want to
   stress my feeling of satisfaction over the inclusion of Locals and
   Statics into Clipper 5.0.


   Macro Differences

   Unfortunately, this is not a perfect world.  One of the things I
   stressed as a benefit of RLIB version 2.0 was that it came (as does
   version 3.0) will full source code included.  When Nantucket upgraded
   Clipper to a new version, the RLIB owner would only have to re-compile
   the RLIB functions to create an upgraded RLIB.  Libraries that were
   written in C and Assembler, and particularly those that poked into the
   internals of Clipper, would have to be upgraded by their authors
   before you could get your upgrade.  Well, my upgrade plan was fine as
   long as Clipper itself maintained 100% upgrade compatibility with
   itself.  Unfortunately, this was not the case.  There are a few areas
   where Summer '87 and 5.0 code behave differently, most importantly in
   the handling of macros.

   This macro handling incompatibility affected two of the RLIB 2.0
   functions, CHANGED() and MREPLACE().  They didn't act the same when
   compiled under Clipper 5.0.  Specifically, the aliasing in the REPLACE
   statement does not work under Clipper 5.0 the way it did in Summer
   '87.  If you have a memory variable with the same name as a database
   field, you normally override the default field by prefacing the memvar
   with the M->.  This works fine if you do it explicitly, but not if it
   is done through a macro reference.  So the code: REPLACE
   &malias.->&mfield WITH M->&mfield works fine under Summer '87 but does
   not under 5.0.  Clipper 5.0 still retrieves the database field
   contents in the code M->&mfield so the REPLACE does nothing but
   replace the field with itself!  The fix is to embed the M-> memvar
   qualifier within the macro variable.  In the example above, the
   expression REPLACE &malias.->&mfield ... is replaced with REPLACE
   &mfldvar ...where MFLDVAR is the string "M->FIELDNAME".


   A Macro Example

   To illustrate the problem, compile the sample program below under
   Summer '87 and 5.0 and observe the results.


      *-- Create a simple database named "TEST"
      *-- with a single character field named "DATA" of length 12

      USE test
      APPEND BLANK
      REPLACE data WITH "FIELD DATA"
      M->data = "MEMVAR DATA"
      ? data              && prints "FIELD DATA" as expected
      ? M->data           && prints "MEMVAR DATA" as expected
      memvar = "data"     && assign the memvar name for macro reference
      ? M->&memvar        && 5.0 prints "FIELD DATA" S'87, "MEMVAR DATA"
      memvar = "M->data"  && embed the M-> reference in the memvar
      ? &memvar           && 5.0 now prints "MEMVAR DATA"
      USE
      RETURN

   These differences have been fixed in RLIB by altering the expression
   of macros and, in the 5.0 library, by replacing macro references with
   code blocks and new Clipper functions for getting and putting field
   values.  The new Clipper functions for accomplishing these tasks are
   far superior to using macros so the rule of thumb is that you can
   probably do without macros in Clipper 5.0.

   RLIB Differences

   There are a few differences between the Summer '87 and 5.0 versions of
   the RLIB library.  These differences are limited to functions that are
   not appropriate in one or the other library.

      SETCURSOR()  Clipper now has its own internal SETCURSOR() function.
                   The Summer '87 version of RLIB has a SETCURSOR()
                   function that takes a single numeric value as an
                   argument, and is compatible with the 5.0 version.
                   Since Clipper 5.0 now has a SETCURSOR() function, it
                   is not present in the 5.0 version of RLIB.

      VALTYPEC()   This RLIB function is specific to, and only exists in,
                   the 5.0 version of RLIB.