HELP, WE'RE DROWNING!!

[Peter Holzer]

mouse at thunder.mcrcim.mcgill.edu (der Mouse) writes:

>I did (Turbo C, at least).  The only advantages of it I can see over
>the Sun cc is the fine-grained control over warning generation and a
>certain degree of ANSIness.  Comparing it to gcc, I see no advantages.

When I have have to work on an ASCII-Terminal, I see many
advantages. E.g. source code and compiler error messages are
simultaneously visible. If I have an X-terminal, still one advantage
remains. The debugger. Turbo-Debugger is the best debugger I have ever
seen. Dbx isn't more powerful, and not nearly as comfortable.

>A partial list of disadvantages I find in 2.0 (these are just the ones
>I can remember or find in a quick skim of the manuals):

>- Memory models

That's not the fault of the compiler but of the hardware (of course the
compiler could just use 32bit pointers everywhere, but sometimes you
want to save space or execution time. If you don't care, just always
use the large memory model, and don't care about the rest).

>- Not free

True, but not expensive, either. TC++ Pro costs $170 and comes with
30cm manuals.

>- Source not available

That's a pity. But most people don't know enough of compilers to fix
bugs anyway. And the library source is available (Though at additional
cost).

>- "Integrated" environment's editor is almost unconfigurable

Yes, I miss vi. But using the integrated environment is faster than using 
vi, make and a debugger.

>- "text" vs "binary" stupidity in the I/O libraries

This stupidity is mandated by ANSI for OS's (and almost-OS's like
Mess-DOS) where lines are not separated by a single character. You may
blame Microsoft (that's what everybody does) or ANSI (only if you have
a better idea how you can handle all those different definitions of
`line' in different OS's) but the compiler/library-writers didn't have
a choice.

>- The reference manual says "is available on UNIX systems" about many
>   routines which are not present in 4.3BSD.  It's not just a confusion
>   of "UNIX" with "System V", either, because they're careful to draw
>   the distinction at times; eg, see the entries for assert and dup2.
>- For some routines, they say "is available on UNIX systems" when this
>   is not true: there is a different routine, with the same name and
>   usually with similar functionality, but it is *not* the same.
>   (chmod is an example.)

Yes. The `portability'-paragraph isn't what it should be. Even worse
than not distinguishing between UNIX-versions or not telling the
differences between UNIX-chmod and DOS-chmod is that they haven't even
got the ANSI-functions right. I can't remember it off the top of my
head, but I found at least one function which was marked `available on
UNIX', when it really was mandated by ANSI, or vice versa.

>- Make is pretty stupid; in particular, it has no default rules, as far
>   as I could tell.

I don't know about the default rule (I never used it with UNIX), but
Borland-Make has some features that make it better than UNIX-Make. It
extracts information about included header files out of the object file
(sort of built-in makedepend) and it has conditionals. So you could
write:

!ifdef __MSDOS__
CC	= tcc
LIBS	= -lmyx.lib
!else
CC	= gcc
LIBS	= -lX11
!endif

which makes configuring easier than for standard Unix make.
I think this feature is new in TC++ 1.0, it was not in TC 2.0
Unfortunately, Borland decided to use some obscure binary format for
project files, so you can't convert them to/from makefiles by simple
sed/awk/whatever-you-like scripts.


--
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp at vmars.tuwien.ac.at                 |     Tony Rand |