Todd
The CDROM version of VC++ has the older version (supporting 16-bit Windows)
on it as well (I think - can someone check and post here?)
>depending on your target platform, but Borland's will target any Intel
>platform (DOS, Win16, NT, Win 95). Borland compiles only for Intwl hardware,
And OS/2 too, no?
Are you saying that MS VC++ is not a native c++ compiler? I find this pretty
difficult to believe.
-------------------------------------------------------------------
Robert C. Elmer rel...@vt.edu
Software Engineer "What, me worry?"
Tetra Tech, Inc. (703)385-6000
As for the compilers, i would go with Borland till the last penny in my
pocket. I simply don't trust Microsoft well enough to put my programming
efforts into their complier, let alone the linker.
In a previous posting, Joe Borkoles (jbor...@jpmorgan.com) writes:
> Borland C++,v4.5 is not perfect and has bugs, but it works and works
> well. It tracks the ANSI standard closely and comes with a great
> Windows class library (OWL) and a free upgrade to Windows 95 compatability.
> It has one of the most mature implementations of templates on the PC platform.
> (The most mature?)
--
o_, o, o- o_, o_ o || Only when we can trust
)-' -/|' '=( ), ^ ' (\ ^o || those who are different
>\ / > >' >\ >^' >\ >\' || from us, WILL there be
Stand for something, or you'll fall for everything || peace on earth.
I think what is meant by the comment is that MS has never released a C++
compiler that implements the complete (or even almost complete) C++
specification available at the time. Borland has always tried to stay
as close to the spec as possible.
#define _FLAMETHROWER_
MS basically said "Screw the spec. We'll decide what C++ features the
developer needs." It took serious pressure from the developer
community to make MS add exceptions and templates(which still are not
right).
#undef _FLAMETHROWER_
Just my .02
Michael
>
>>depending on your target platform, but Borland's will target any Intel
>>platform (DOS, Win16, NT, Win 95). Borland compiles only for Intwl [sic] hardware,
>
>And OS/2 too, no?
-------------------
Yes, in a separate product. In the same vein, MS supposedly compiles P5 optimized code; at
least, there's a compiler flag (/G5) for it. The exe's seem to run slower with this optimization...
go figure.
Mike.
>
>In article <dubois.74...@uwo.ca>, John Dubois <dub...@uwo.ca>
wrote:
>
>The CDROM version of VC++ has the older version (supporting 16-bit
Windows)
>on it as well (I think - can someone check and post here?)
>
Yes, the CDROM version of VC++ 2.0 also contains VC++ 1.51 (1.5 with bug
fixes). It also contains the OCX development kit for 16 and 32 bit
platforms.
Rich
I have to agree with the rest of those posting. Borland is the better
compiler. I have seen this type of discussion on this group before and
the only reason I have seen posted to use VC++ is that Microsoft is in
better financial shape and they own Windows.
Steve
It's a matter of interpretation. Some very major and IMO absolutely
essential aspects of C++, namely templates and exceptions, are not
implemented in VC1.5, and from what I understand are implemented in a
buggy manner in VC2.0.
Plus, there's the fact that MFC is so very C-with-classes-like, it's painful
to use. It's built and designed with all of the cons of Smalltalk and none
of the pros.
So, is it "real" C++? Well, truthfully, I don't think so, because even if
the compiler eventually ends up supporting more of the latest specs, the MFC
library is barely past C. That's not to say that it's useful, because I
think MFC is better than plain SDK. However, VC2.0 certainly is not very
C++-like, either in the compiler's feature list or in the design of the
class library. Just read Stroustrup's books and see how often MFC (partly by
consequence of the compiler's limitations) uses exactly the concepts and
techniques that Stroustrup had hoped C++ library designers would _not_ use.
-------------------------------------------------------------------------------
Steve Willer <wil...@io.org> This space reserved.
Team OS/2
Need a good FTP for OS/2? Try ftp://hobbes.nmsu.edu/os2/32bit/unix/ncftpb4.zip
If the issue is open, then I have to say that Borland C++ for OS/2
allows portability of code to a large installed base of 32-bit OS
users. It seems like OWL would require little more than a re-compile
going from Windows to OS/2. Of course, all of my applications are
OS/2 only, and until threads are available on more Windows PC's I don't
care to port the other way.
When will Microsoft support OS/2? NEVER. I'll bet they'll make it
difficult for users of their compilers to migrate to OS/2. Borland seems
to make an significant effort to support both.
Steve Goodridge
NCSU
(Totally Warped)
>I am interest in purchase a Visual C++ compiler. Which manufacture is
>currently recommended, Borland or MicroSoft.
>Todd
Depends what your're looking for. If you want the latest technology You will
have to use Borland or VC++ 2.0 (VC++ below 2.0 do not support templates,
exception handling, etc.) VC++ 2.0 runs only on Win32, but the Borland product
runs on Windows, Win95 and NT. You will need a different version of VC++
depending on your target platform, but Borland's will target any Intel
platform (DOS, Win16, NT, Win 95). Borland compiles only for Intwl hardware,
but Microsoft will (eventually) target MIPS, ALPHA, and possibly others...
Microsoft has far more marketing clout and is a good product, but I think that
Borlands product is better (technically) and they've had years more
experiance..
A little bit of history .....
Microsoft had an ANSI-ish compiler long before ALMOST anyone else, in the DOS
market. Who was first??? "Wizard", which developed into Turbo C.
I'll just add that another (nasty) Microsoft advantage is that
they support (their own) new APIs before anyone else. I use
microsoft VC2 right now because I have to (I do NT development),
but not a week goes by that I don't wish I was still using BC.
(please no flames about 'you can change', its too late).
In short
compiler: Borland's better
Ansi compliance/features: Borland
enviroment: Borland (by a little)
Framework: Borland's OWL kicks MFC's butt
Classes: Borland ( good containers, Mickeysoft's is too lame to consider)
Experts: Microsoft (grudgingly, they are better, especially for OCX)
New API support: Microsoft (of course)
>
> The Borland / Micro$oft choice is really quite simple. It's a choice
> between technology and security.
>
> Borland's products are always several years further along in terms of
> compliance with the language specification. Borland was an early adopter
> of object oriented development (preceding Micro$oft by more than 4 years)
> and this results in application frameworks (OWL and Turbovision) and run
> time libaries (both the standard and the add on containers) that are
> highly object oriented, extensible and robust. Micro$oft, on the other
> hand, offers C style libraries with a touch of objects, but generally
> they don't do a good job of encapsulating, abstracting or simplifying
> development. In a very real sense, they're beginner's attempts at class
> hierarchies, and it shows. This is not a knock, since Micro$oft is
> really only 2 years into OOP thinking. You cannot expect them to equal
> Borland's 6-7 years.
>
> Micro$oft, on the other hand, is profitable and stable. They are never
> going to give you a good deal on anything (they don't have to), and often
> they will encourage you to go in one direction (OS/2, NT, etc), so that
> they can go in the opposite direction and gain a competitive edge by
> being far earlier off the starting block, but they will be around. You
> are not going to get fired for buying Micro$oft. They will not go out of
> business. YOu can always hire someone that knows the stuff cold within
> days if you need to, and it is the defacto (if mediocre) standard. When
> Micro$oft introduces a bug (such as the illegal way they take C++ member
> function addresses) and MFC needs it, you see Watcom, Symantec and others
> add the same bug to their compilers (although with a warning) in lock step.
> That's industry clout, if the stability and power of your language vendor
> are more important to you than the quality of the tools, that's a good
> choice to make. You're also betting that you'll never need to port to OS/2,
> which might be safe bet (but not if you ever do international business).
>
> Borland may be out of business next year, but I think the tools will
> survivie somewhere. But who knows? There is certainly a lot of worry
> with using Borland tools. Plenty of managers will be fired if they have
> problems getting out product because suddenly Borland tools are not
> upgraded or Micro$oft puts out some secret Windows sh*t in there tools
> that Borland can't replicate for a year. Borland is now leaner, meaner
> and back to their roots. I think it is a good strategy, but it may be
> too little, too late.
>
> Here's my choice: Borland tools run rings around Micro$oft. I want to
> write full fledged cross platform apps with a fully object oriented
> framework and an exception throwing run time library. I don't want to
> dumb my code down and rewrite it later when Micro$oft comes up to speed.
> I am confident that Borland gives me such a great productivity edge, and
> allows me to write such superior code that they are the better choice in
> the long run even if they go out of business. I can always rewrite the
> interface to an app in MFC, and if I wait, MFC will only get better. Why
> bother with it now when it is so C like? If Borland goes under, I'll
> port what I need out of OWL into MFC. The point is, I'm not going to let
> Micro$oft hold me back.
>
> Your choice may vary, but as I say, its a simple tool superiority vs
> business stability decision. Do you need better tools or are Micro$oft's
> "good enough". Do you need better tools, but don't want to risk losing
> your job? I think everybody will fall out a little different on this
> continuum...
> --
>
This is true, but now Borland is directing its efforts almost exclusively
at development products. In a related note, Delphi might rock MS if
things work out. But, alas, this is a c++ group.
>From: ka...@telerama.lm.com (Jim Kownacki)
>Newsgroups: comp.lang.c++
>Date: 25 Feb 1995 15:45:11 -0500
>Organization: Telerama Public Access Internet, Pittsburgh, PA
>You are simply incorrect on this one. MSC 6.0 was their first ANSI
>compliant C compiler. Their methods of variable type promotions in mixed
>expressions was particularly nonstandard, and the 5.1 to 6.0 was quite a
>painful transition to windows developers, many of whom discovered than
>Microsoft's min and max windows macros now often gave different results.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well, aren't they supposed to ? ;-)
>
>6.0 had no purpose in life other than to add ANSI compatibility and to
>remove the reentrancy problems in their run time libraries for OS/2,
>which Micro$oft was very much pushing at that time. Sorry, but late 1990
>was rather late to finally bring an ANSI compliant C to the table, at
>least on the PC platform.
>--
>
--
Stefan Tilkov MLC Ratingen, Germany
s...@mlc-ratingen.de
Phone +49 (0) 2102 8506 20
Fax +49 (0) 2102 8506 30
I find it hard to believe that BC++ will ever die. A lot of people
depend on it and it is quite simply better than VC+-. Borland sold Quattro
Pro to Novell and it is kicking as much as it ever was.
Note that Borland has released Delphi recently. Delphi runs rings around
Visual Basic and Microsoft will unlikely ever be able duplicate its
capabilities with anything like VB. Look for cross platfrom blooming
of Delphi in the future. Delphi will go cross platform much more easily than
VB. And your apps will as well with it.
Also note that Borland has something like 250 Million in cash still, and
thus the cutbacks are neither "too little" nor "too late" IMO.
Paul Pedriana
NAK
For details you might wat to check for new announcements at
ftp://ftp.borland.com/... or http://www.borland.com/ and follow until you
get to the recent news pages.
--Mick Brown (lfirra...@bix.com)
Er, according to a recent WSJ, it was more like $47 million. But of
course, Lotus is trying to get $100 million or so.
Four years ago I started C programming (after some years of BASIC and PASCAL). And I used
Borland. Of course, because it was the cheapest I could get (I knew nothing about GNU :-).
And I was quite happy with it. It was the time when i wrote fopen(file, "rt") and such things
and all went well. My projects became larger and contained usually more than 20000 lines of
code. This was the time when the real problems started. I needed make files instead of project
files. I noticed that the Borland make utility is quite bad for some things and I switched to
microsoft's make. (Surely it has no "batch things" - these {} commands - but this is not that
important.)
In an average of two times a week I sat down and debugged the damn project.
This drove me real crazy until
I noticed that I found a compiler bug.
For instance:
I noticed that the compiler was removing a c=*p++; operation. I turned all optimization
options off, and the compiler did exactly the same. I turned several optimizing options on
and the executable file was exactly the same as before. (that should be very unlikely with
a size of 150000 Bytes)
Then I put dummy statements al around until the compiler was able to include the c=*p++;
Then came the time I needed Windows programming and tried it with BC 3.1. I tried it with OWL
and it was at least easier than pure C. A friend needed a program and I wanted to make him some
kind of reversi. I tried to draw some bitmaps and after 1092 draw-calls windows crashed.
I really don't know, why I couldn't get this done. After a week I switched to Microsoft and
the program was done within 6 or 7 hours. (Surely this 1092-crash is a hint for lost handles
or something, but I couldn't find the error in my code.) This is not a fault of BC or MSC
but it seems that I can have fewer problems when using MSC.
Another friend had a problem with C++ under OS/2. This was the time of BC4OS/2 v1.0. Man was
this thing buggy! I used the IDE 2 hours and I lost half o fmy brain cells. Tried to watch
a variable. The debugger told me, that there is no such variable. 15 minutes later I found out
that the compiler did not compile the files I was editing. I don't know which ones it used,
but not the ones in the project. I saved them. Nothing. I exited teh IDE. Nothing.
I did a system shutdown. Nothing.
10 Minutes later I built a new project, moved the source files to the new project and compiled.
What a fun! The compiler used the source files! And my variable was there!
But: tried to create a Vector class. I was not able to make BC use the copy-ctor or the
assignement operator I implemented. No way. This was when 2 hours were over and I was a little
nervous because of the coffee.
A friend tried to do some 32bit development under TASM. It is really nice if you see that
TASM does make a "mov eax, 4" out of a "mov eax, [4]". This is really nice! Of course, TASM
doesn't do that always, but this one was quite interesting.
One word about Borland Pascal: (because I am just talking about borland)
They have a variable in their runtime library which contains the memory address of the code
which caused the runtime error (if any). Using this one you can provide an exit function
which traps such errors and makes a memory dump. OK. everything is fine until you move to
protected mode. Then the address is filled with a segment ID. (Otherwise the IDE couldn't find
the erroraddress) And the real memory pointer is lost. Of course your exit function comes up
AFTER that "patch". After three hours of debugging and test apps and lots of coffee and
browsing through the manuals (no way to get a tech support in time) I found the thing with
the segment ID. Man, was this a fun! Now I have to use a patched RTL (Thank god they ship
the source code) and I get more and more trouble with this "TURBO.TPL-load" on startup of the
IDE because I cannot find some variables etc. ok. Nothing more about BP7.0. No person should
be forced to use BP7.0 but life's hard :-)
Now I use Watcom and Microsoft. Watcom for commandline proggies, Microsoft for Windows and
Borland for the DOS apps which need a Window-Interface (I'm looking for a window-library
which I could use with standard C/C++ and which follows some kind of SAA, but I didn't find any)
Also I tried to port TVision to MSC. No way. I wonder what BC did to TVision which makes it
that hard for MSC. (I tried the lib which came with BC3.1)
Never had a problem with Watcom until now. Never had a problem with MSVC until now. And my
projects are still of 20000-40000 lines. (Of course some small ones in between :-) ).
It seems that borland implements quite a lot of features and always has something of the
new things which the others do not have. But the compiler engine seems to be less reliable.
And I wonder what is more important: A compiler with all the new features or one which is
at least more secure than the "advanced" one.
Now to express my compiler preferences: Use Microsoft for development (unless you're under
OS/2 :-) Use Watcom for final compile if possible. If you can use GCC, use it. For critical
apps use only Watcom. And if you are really forced to, use BC.
Oh, one interesting thing:
There was a thread about "(a>b) ? c=a : c=b;". I tried this with several compilers and *ONLY*
GCC complained about that. No warnings from Borland or Microsoft. I don't remember what Watcom
said.
ok. now i'm done. any flames please to /dev/null or if you can't hold yer horses, email me.
Its really painful to have this group with thousands of articles if you look at it after 4-5 days.
One last word: These are only my experiences with BC, MSC, WC. I do not want you to take this
for the only truth to believe in. Another thing: I do not think MSC is *THE* best compiler,
but its the best for my needs.
(God! I wonder how many flames and mails I get for that :)
=============================================
Rainer Schwarze
email: schw...@imn.th-leipzig.de
m5sc...@zeus.rz.th-leipzig.de
=============================================
Other than that, I'd agree that BC++ is superior. It's certainly a lot
easier to use.
--
Will Briggs || Sig for alt.aquaria: There's a lot of sex in my
Dept. CSE, UTA || apartment; too bad it's all in the fish tank.
Arlington, TX 76019 || ...for alt.stupidity: Bluggablugga(hick)schnorf!
(817) 273-3399 || ...for comp.ai: Ignore previous, I'm perfectly sane.
It's true that Microsoft is the more stable company, but that doesn't mean
you will get any more support for the products they offer, than from a "less
stable company" that MAY go out of business.
Visual C++ 1.5 is a case in point. Instead of selling an enhanced version,
with template support etc., Microsoft abandoned the product, forcing
developers to choose between a mediocre C++ compiler, or switching development
to Windows NT/Windows 95, because the new (somewhat less mediocre) compiler
will run only on NT/Win 95.
Unfortunately, they forgot to outlaw the use of Windows 3.1 and forcing
everyone to switch to NT.
For me doing consulting and product development, the choice is easy. If the
customer wants me to use Visual C++/MFC, I do. It's much more profitable,
since it takes considerably longer to get the job done and all those hours
add up.
On the other hand, when I have a say in the matter, the choice is clearly
Borland C++/OWL. It is a much more productive environment.
Karsten
>rainer schwarze (schw...@imn.th-leipzig.de) wrote:
>> Then came the time I needed Windows programming and tried it with BC 3.1. I tried it with OWL
>> and it was at least easier than pure C. A friend needed a program and I wanted to make him some
>> kind of reversi. I tried to draw some bitmaps and after 1092 draw-calls windows crashed.
>> I really don't know, why I couldn't get this done. After a week I switched to Microsoft and
>> the program was done within 6 or 7 hours. (Surely this 1092-crash is a hint for lost handles
>> or something, but I couldn't find the error in my code.) This is not a fault of BC or MSC
>> but it seems that I can have fewer problems when using MSC.
>This is just one obvious example, but from your post, it seems that most
>of your problems stem from your lack of knowledge of the the Windows API
>and your compilers and language. This Borland bashing is really pretty
>unsubstantiated as a result.
>I personally find numerous Micro$oft compiler bugs. More than I find
>with Borland.
>--
:-) very nice.
I did not want to answer such things, but I cannot get to sleep until I do... :-)
Just to tell the things:
1) I told that this seemed to be my fault, because this simply cannot be something
with a compiler.
2) I did it in borland, it didn't work. One day later I did it in MS, it worked. My knowledge
surely did not grow very much during 8-10 hours sleeping. :-)
3) The code I wrote had nothing to do with several classes, because in BC3.1 you cannot use
classes to display bitmaps, because there are none. So it was C.
ok. oh! just now i read this "lack of knowledge of the language". hmmm.
My lack of language knowledge
causes me to get my projects better done in MS than in BC? when MS has this *WONDERFUL* IDE?
(to make it clear: this was a joke) Oh! and Watcom is easier to use if I have a remarkeble lack of
knowledge? hmmm.
greetinx
rainer
>rainer schwarze (schw...@imn.th-leipzig.de) wrote:
>> Then came the time I needed Windows programming and tried it with BC 3.1. I tried it with OWL
>> and it was at least easier than pure C. A friend needed a program and I wanted to make him some
>> kind of reversi. I tried to draw some bitmaps and after 1092 draw-calls windows crashed.
>> I really don't know, why I couldn't get this done. After a week I switched to Microsoft and
>> the program was done within 6 or 7 hours. (Surely this 1092-crash is a hint for lost handles
>> or something, but I couldn't find the error in my code.) This is not a fault of BC or MSC
>> but it seems that I can have fewer problems when using MSC.
>This is just one obvious example, but from your post, it seems that most
>of your problems stem from your lack of knowledge of the the Windows API
>and your compilers and language. This Borland bashing is really pretty
>unsubstantiated as a result.
>I personally find numerous Micro$oft compiler bugs. More than I find
>with Borland.
>--
I agree wholeheartedly. Show me a compiler and I will find you a bug! I use
Borland 3.1 at work 4.02 at home, and Sun 3.01 at school and I have few of the
problems I see here. Most of the problems seem to be with those who have not
done their research for the compiler they're using, don't know their platform,
or their target environment. I write code in all the above and even port it
to-from DOS to unix, to os/2 with few problems. I thoroughly design my
application before I start, research potential problem, reasearch the paper
docs, help files and man pages for problems that do occur. Amazingly, I
usually find most problems are a result of an error on my part.
IMHO, if one invests more than the minimum amount of time in the proper
design, knows one's hardware, software and the language; problems occur but
rarely require one to abandon the compiler one is using. Most of my colleages
and peers at school start designing by writing code! The best instuctor I
ever experienced, required more paperwork up front than code!
> > A little bit of history .....
> > Microsoft had an ANSI-ish compiler long before ALMOST anyone else, in the DOS
> > market. Who was first??? "Wizard", which developed into Turbo C.
> You are simply incorrect on this one. MSC 6.0 was their first ANSI
> compliant C compiler. Their methods of variable type promotions in mixed
> expressions was particularly nonstandard, and the 5.1 to 6.0 was quite a
> painful transition to windows developers, many of whom discovered than
> Microsoft's min and max windows macros now often gave different results.
> 6.0 had no purpose in life other than to add ANSI compatibility and to
> remove the reentrancy problems in their run time libraries for OS/2,
> which Micro$oft was very much pushing at that time. Sorry, but late 1990
> was rather late to finally bring an ANSI compliant C to the table, at
> least on the PC platform.
> --
This is correct. But it fails to note that Borland has not yet produced an
ANSI C compiler.
Well, this is a bit unfair since, to my knowledge, no one has produced a
compiler which actually complies completely with the standard. But Borland
is a lot further from the standard than most and shows no interest in
fixing standard violations.
Examples:
1. Borland's run time library uses quite a few identifiers which
are not reserved, open and close for example. This was reported
to Borland in fall of 93. According to Borland it has not been
fixed in 4.5.
2. The fflush() function flushes input streams. This in itself is
not a violation since the result of applying fflush() to an input
stream is undefined behavior. However, in some circumstances the
call fflush(0) will flush input streams; this is not allowed
by the standard. This was reported to Borland in spring of 94.
According to Borland it has not been fixed in 4.5.
Note that these are the worst kind of violation. The compiler accepts
correct code and produces an incorrect program without warning.
1995 is even later to be bringing an ANSI compliant C to the table. Of
course, there is no guarantee that Borland will bother -- they just don't
seem to care to do more than claim that their compiler is compliant.
--
Mike Rubenstein
I personally find numerous Micro$oft compiler bugs. More than I find
with Borland.
Are you really using BC, Which Version ??
Our project compiles fine with:
SUN CC 3.01, CC 4.0, Microsoft 1.5, 2.0, Watcom and gcc...
we had only a few problems with BC3.1 (stream-library) but with
BC4.0 NO CHANCE (!) . We currently testing (again) BC4.5 but
until now without success.
There are a lot of errors in every compiler I know, but mostly
we could work around these bugs(and you can find the bugs!!!!).
We had no success to work around the BC-Bugs!
cu
Michael (m...@wupmon.wup.de)
--
+-------------------------------+--------------------------------------+
| Michael Lechner | Wiechers & Partner Datentechnik GmbH |
| | Forschung & Entwicklung |
| | An der alten Ziegelei 2 |
| eMail: m...@wupmon.wup.de | D-40771 Monheim (Germany) |
+-------------------------------+--------------------------------------+
==================================================================
Pi Sheng Chang
Depart. of Electrical Engineering, Signal Processing Group, UCLA.
e-mail : psc...@ee.ucla.edu, psc...@icsl.ucla.edu