borland.txt

开放源码的编译器open watcom 1.6.0版的源代码

	Product:	Borland Turbo-C++ 1.0

	Author:		Marshall P. Cline, Ph.D.
			ECE department
			Clarkson University
			Potsdam, NY  13676

	Voice:		315-268-3868
	Secretary:	315-268-6511
	FAX:		[phone]

	Internet:	[e-mail]
	Alternate:	[e-mail]
	Bitnet:		BH0W@CLUTX
	UUnet:		uunet!clutx.clarkson.edu!bh0w

	Copyright:	The Author releases this to the Public Domain

	Revisions:	BugList-Date	BugList-Version
			11 Jun 90	1.0.1
			09 Aug 90	1.0.2
			14 Aug 90	1.0.3
			29 Aug 90	1.0.4
			20 Sep 90	1.0.5


Copyright:
    This file, along with code fragments it contains, is PUBLIC DOMAIN.
    That means no one (including myself) can restrict its use/distribution.
    In particular, you can't copyright it.  No one can.  Not even me.

Contributions:
    If you have a TC++ bug to report, please email to the above addresses.
    But please try to find/send a work-around to the problem/bug.
    Also please explicitly state that your comments/code are public domain.

=============================================================================
=============================================================================

Several classlib\include\*.h have #include "foo.h" rather than <foo.h>.
This will only cause a problem if you have an indentically named header file
in your current working directory (#include "file.h" starts in current dir,
then searches the "standard places"; <file.h> only searches standard places).
Note that TC++ by default doesn't find the classlib header files; if you want
it to, add the line to turboc.cfg:  -IC:\TC\CLASSLIB\INCLUDE

-----------------------------------------------------------------------------

Some include files have #ifndef __FILENAME_H, others have #ifndef _FILENAME_H.
(inconsistent #leading underscores).  See for example sortable.h vs set.h, etc.

-----------------------------------------------------------------------------

TCCNVT.EXE (the configuration file converter) isn't in the distribution.

-----------------------------------------------------------------------------

`make -n' looks for and reads `builtins.mak' ONLY if it's in the current dir.
Naturally this is a bug, since make can't give an accurate picture of what a
real `make' would do without the macros and implicit rules in `builtins.mak'.

>Craig Orsinger/[e-mail]/R&DAssoc/3625 Perkins L SW/Tacoma,WA 98499:
>This also happens if you call "make" from your makefile. I don't know if this
>occurs if the makefile and "make" program are on the same disk partition, but
>it definitely does when they are not. My work-around was to use the new
>"search path" feature of make to tell it where the "builtins.mak" file is.

-----------------------------------------------------------------------------

<iostream.h> always includes <mem.h> which slows compilation some.  In fact
<iostream.h> doesn't need `NULL', and only needs memcpy() if _BIG_INLINE_ is
defined, which will probably be rare.  Therefore the line
        #include <mem.h>        // to get memcpy and NULL
can be replaced with:
        #ifdef _BIG_INLINE_
        #include <mem.h>        // to get memcpy
        #endif
Since nearly everything includes <iostream.h>, and since relatively few things
will want _BIG_INLINE_, this should be a winner.  Note however that some code
might assume <iostream.h> pulls in <mem.h>.

-----------------------------------------------------------------------------

<iomanip.h> needs <iostream.h> but doesn't get it.  Add this to <iomanip.h>:
        #ifndef __IOSTREAM_H
        #include <iostream.h>
        #endif

-----------------------------------------------------------------------------

There is no <new.h>.  I constructed the following work-alike.  It should go
into your standard include directory (where <iostream.h> is, for example):
	// new.h
	// Author: Dr. Marshall Cline/ECE Dept/Clarkson Univ/Potsdam,NY 13676
	// Email: [e-mail]
	// Phone: Voice: 315-268-6511; Fax: [phone]
	// Copyright: The Author releases this to the Public Domain, 9-July-90.
	// Date: 9-July-1990
	// Please include these acknowledgements when distributing this file
	#ifndef __NEW_H
	#define __NEW_H
	#ifndef _SIZE_T
	#define _SIZE_T
	typedef unsigned size_t;
	#endif
	void*  operator new(size_t size, void* ptr);
	// _new_handler is a ptr to a parameterless function returning void
	extern void (*_new_handler)();
	void (*set_new_handler(void (*replacement_handler)()))();
	#endif __NEW_H

-----------------------------------------------------------------------------

Bug in istream: an extremely common C++ main input loop is something like:
		while (cin >> chunk) chunk.do_something();
This works under the condition that istream::operator void* returns 0 (false)
after the input stream reads past EOF (or encounters an error).  TC++'s
iostream.h is consistent with its documentation [programmer's guide p.183] in
stating that this operator returns 0 only when istream::fail() is true (when
failbit, badbit or hardfail are set), but unfortunately `fail' doesn't get
set after you've read past EOF.  The correct operation is to return 0 (false)
on the read after you've run into EOF as well [Lippman p.384], which CAN BE
accomplished by the _bad bit being set wnen seeking past end-of-file [Lippman
p.402].  This can be fixed by changing "ios::operator void*()" in <iostream.h>
as follows:
	inline _Cdecl ios::operator void* ()
	{ return (state & (eofbit|failbit|badbit|hardfail)) ? 0 : this; }
NB: the `official' (if there is such a thing in these pre-ANSI-C++ days)
behavior of istream::operator>> isn't clear.  I've discussed this matter with
both Borland, and with a collegue who is in charge of certain C++ libraries
inside AT&T, and no one is yet sure what is really ``supposed'' to happen.
The above patch (checking the eofbit) appears to work correctly, but it may
be that a more comprehensive solution is eventually in order.  In any event,
most people's code doesn't run around checking individual bits inside an ios,
so the above is probably `safe'.

-----------------------------------------------------------------------------

There is an error in TCC that isn't in TC (they generate different code).
[Borland is as surprised that they'd behave differently as I was; I'd imagine
the internals are identical, and this assumption has be confirmed by Borland].
When a virtual fn is called from a non-virtual inline member, the virtualness
of the call vanishes.  Compile the following with `tcc -vi':
        #include <iostream.h>
        class B {
        public:
          virtual void virt();
          void nonvirt() { cout << "B::nonvirt() calling "; virt(); }
        };
        class D : public B {
        public:
          void virt();
        };
        main()
        {
          D d;
          (&d)->nonvirt();  // B::nonvirt() should call D::virt()
          d.nonvirt();      // ditto
        }
        void B::virt() { cout << "B::virt()\n"; }
        void D::virt() { cout << "D::virt()\n"; }
Unfortunately both of these call B::nonvirt().
Ie:Both d.nonvirt() & (&d)->nonvirt() translate to "call near ptr @B@virt$qv".
Obviously these should be virtual function calls.  This is a serious error, as
calling a virtual from a non-virtual is fairly common.  Note: if B::virt() is
a pure virtual (another legal operation, but perhaps not as common), the call
to "@B@virt$qv" generates a linker error (there is no B::virt()!).  If
B::nonvirt() is a regular (non-inline) function (either by moving it out of
the class, or by `-v' or `-vi-'), TCC generates the correct code.  Strangely
enough, TC appears to *always* generate the correct code.

-----------------------------------------------------------------------------

The 1.2 streams package (called <stream.h>) is nice, however AT&T treats the
inclusion of <stream.h> as an alias to <iostream.h>.  Therefore you should
rename it from <stream.h> to <oldstream.h>, and let <stream.h> simply be:
		#include <iostream.h>