www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/01/31/12:07:24

From: boylesgj AT lion DOT cs DOT latrobe DOT edu DOT au (Gregary J Boyles)
Newsgroups: comp.os.msdos.djgpp
Subject: DJGPP vs Borland C++.
Date: 24 Jan 1997 15:03:38 GMT
Organization: Comp.Sci & Comp.Eng, La Trobe Uni, Australia
Lines: 46
Distribution: world
Message-ID: <5caj0a$7kd@lion.cs.latrobe.edu.au>
NNTP-Posting-Host: lion.cs.latrobe.edu.au
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

I have found Borland C++ and Turbo C++ to be very buggy and there is no
way I would part with several hundred dollars for such unreliable
products. DJGPP is far supperior to any Borland products, at least as far
as DOS compilers go.

I have encountered many problems with Borland products as well as many of
the lectures and tutors at Latrobe University. The problems don't seem to
surface until you try to write large and complicated programs with them.
Some of the problems are as follows.

1) The IDE and PC will nearly always hang at some point when stepping
through a program with the integrated debugger.

2) Despite the fact that all optimizations are turned off the integrated
debugger will skip lines etc, the watch window will state that variables
are undefined when this is clearly not the case and the watch window will
state that a variable is optimized and not available when the execution
bar contains the variable. It makes it close to impossible to debug
anything!

3) The IDE freezes regularly on key presses, until you hit another key,
and you end up with two characters instead of just one.

4) The Turbo Debugger for DOS provides no way of tiling windows with a
single key press or mouse click as you can with the IDE.

5) Borland C++ 4.5 for Windows provides no way of changing the target
executable etc of a project except when you are creating a project (as far
as I can see).

6) The exe files they produce will nearly always hang at some point in
there execution and it seems to be often on entry to or exit from
functions which indicates that the stack is not being managed properley.

7) One exceptionally bizare problem was that one of my programs worked
perfectly when run from the hard drive but would hang when run from a
floppy (again on entry to a function).

I'm sure half these problems stem from that rediculous memory model system
and near and far pointers etc they have used.

What is also frustrating is that there is virtually nil run time error
support with programs just hanging the PC without even a hint as to what
went wrong such as 'segmentation fault'. Occasionally you may get 'stack
over flow' however half the time this seems to have nothing to do with
what went wrong.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019