[comp.windows.ms.programmer] Borland C++ bug and impressions

sdavid@infmx.informix.com (David Sherrick) (03/04/91)

I have been doing some testing with Borland C++ with some existing programs. 
The first problem I noticed was that Turbo Debugger would not switch from my
application to the Debugger when I typed ctrl-alt-sysrq.  Borland technical
support told me that this is a known bug with some systems.  I am using an
IBM PS/2 Model 70 with an IBM keyboard.

The second thing I noticed (much to my surprise), when I compiled the same
source code with MSC 6.00 and Borland C++.  The MSC executable was smaller
than the Borland executable (24k vs 28k) and I had optimization turn OFF 
in MSC and ON in Borland C++.

But, being a big Borland fan I am giving them the benefit of the doubt.

p.s. Also had 1 unexplained crash out of bcx while on the phone with Borland
     support.


David Sherrick

Disclaimer: The opinions presented here are soley mine and do not reflect the
opinions of Informix Software Inc.

ced@apollo.HP.COM (Carl Davidson) (03/05/91)

From article <1991Mar4.144002.4355@informix.com>, by sdavid@infmx.informix.com (David Sherrick):
> 
> The second thing I noticed (much to my surprise), when I compiled the same
> source code with MSC 6.00 and Borland C++.  The MSC executable was smaller
> than the Borland executable (24k vs 28k) and I had optimization turn OFF 
> in MSC and ON in Borland C++.
> 
> But, being a big Borland fan I am giving them the benefit of the doubt.
> 

Could the difference in size be due to the optimizer unrolling loops, etc.?

Carl Davidson  (508) 256-6600 x4361    | 
The Apollo Systems Divison of          |  It doesn't TAKE all kinds,
The Hewlett-Packard Company            |  there just ARE  all kinds.
DOMAIN: ced@apollo.HP.COM              | 

cadsi@ccad.uiowa.edu (CADSI) (03/05/91)

From article <502b302b.20b6d@apollo.HP.COM>, by ced@apollo.HP.COM (Carl Davidson):
> 
> Could the difference in size be due to the optimizer unrolling loops, etc.?

Good point!  Hey just so the rest of you don't get caught feeling stupid,
If you do things like:

#if defined(__WINDOWS__)
#if defined(_WINDOWS)
#if defined(_Windows)

its really _Windows.  The online help says __WINDOWS__ will be defined
whenever any of the -W options are used for bcc(x).  The manual says its
_WINDOWS.  Then last but not least, the readme file says its _Windows.
Sheesh!!  OOOOhhh I just hate messin' around with my own stupid time and
unobservance (sp?).

ed@odi.com (Ed Schwalenberg) (03/05/91)

In article <1991Mar4.144002.4355@informix.com> sdavid@infmx.informix.com (David Sherrick) writes:

  The first problem I noticed was that Turbo Debugger would not switch from my
  application to the Debugger when I typed ctrl-alt-sysrq.  Borland technical
  support told me that this is a known bug with some systems.  I am using an
  IBM PS/2 Model 70 with an IBM keyboard.

A workaround seems to be to use standard mode.  Too bad for those of us with
386-only code to debug.

  The second thing I noticed (much to my surprise), when I compiled the same
  source code with MSC 6.00 and Borland C++.  The MSC executable was smaller
  than the Borland executable (24k vs 28k) and I had optimization turn OFF 
  in MSC and ON in Borland C++.

Try using TDUMP on both executables and see where the space goes.  Also, both
MSC and BC have multiple optimization switches; reports like this are useless
unless you specify exactly which optimizations were enabled.

mlord@bwdls58.bnr.ca (Mark Lord) (03/08/91)

In article <502b302b.20b6d@apollo.HP.COM> ced@apollo.HP.COM (Carl Davidson) writes:
<From article <1991Mar4.144002.4355@informix.com>, by sdavid@infmx.informix.com (David Sherrick):
<> 
<> The second thing I noticed (much to my surprise), when I compiled the same
<> source code with MSC 6.00 and Borland C++.  The MSC executable was smaller
<> than the Borland executable (24k vs 28k) and I had optimization turn OFF 
<> in MSC and ON in Borland C++.
<> 
<Could the difference in size be due to the optimizer unrolling loops, etc.?

Differences like these are almost always due to the varying implementations
and packaging of the library routines.  As such, the larger your program gets,
the less significance this will have.
-- 
 ___Mark S. Lord__________________________________________
| ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) |
| MLORD@BNR.CA   Ottawa, Ontario | Personal views only.   |
|________________________________|________________________|