home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.pascal
- Path: sparky!uunet!psgrain!qiclab!leonard
- From: leonard@qiclab.scn.rain.com (Leonard Erickson)
- Subject: Re: Distributing TPUs
- Message-ID: <1992Dec31.121645.6747@qiclab.scn.rain.com>
- Reply-To: Leonard.Erickson@f51.n105.z1.fidonet.org
- Organization: SCN Research/Qic Laboratories of Tigard, Oregon.
- References: <1992Dec27.022633.14853@beaver.cs.washington.edu> <765338d8368876t211@witsend.uucp> <dmurdoch.254.725594757@mast.queensu.ca> <1992Dec29.163745.19275@nmsu.edu>
- Date: Thu, 31 Dec 1992 12:16:45 GMT
- Lines: 25
-
- trodgers@nmsu.edu (Thomas Rodgers) writes:
-
- >dmurdoch@mast.queensu.ca writes :
- >> It's a trade-off. .TPU files contain some optimizations that make
- >> compiling and linking go much faster than ic could with .OBJ files;
- >> these mean upward compatibility is essentially impossible.
-
- >Hmmm...Having used Borland's C++ product as well as their pascal
- >product, I think I would rather put up with slightly slower compile times
- >to get the ability to use .OBJ files, for several reasons. Borland's
- >C++ product is not that slow of a compiler, the biggest slowdown comes
- >from compiling all of those <.h> files, but you can pre-compile the
- >headers (not the greatest solution, but it works). Borland could go a
- >similar route with the Pascal units.
-
- Well, TPU files have a *big* advantage over OBJ and LIB files in one
- area. If I only use *one* function or procedure from a TPU, only the
- code required for *that* is incorporated in the final EXE. Ditto for
- constants defined in the TPU. Only the ones that get *used* are incorporated.
-
- --
- Leonard Erickson leonard@qiclab.scn.rain.com
- CIS: [70465,203] 70465.203@compuserve.com
- FIDO: 1:105/51 Leonard.Erickson@f51.n105.z1.fidonet.org
- (The CIS & Fido addresses are preferred)
-