Title: C++ compilers for MSDOS / MSWindows

Packages of C++ programming tools centred on a compiler are becoming so big that it is no longer pos-sible to do a comprehensive review of a single prod-uct let alone try to do a comparative review.

The ubiquitous benchmarks are rather meaningless because they do not compare like with like. Perhaps when the C++ language settles down to a reasonably stable and mature language it will be possible to pro-vide some sort of measure for comparison but for now any benchmark that will run on all the major contenders will not be doing the more up to date products justice.

For example, it is unfair to compare executable size between a compiler supporting exceptions and RTTI with one that does not. Actually many writers do not understand the issue of code size; they think that you just need to look at the size of the executable file. If you believe that this tells you anything about a pro-grams resource requirements I suggest that you should go and do your homework. It doesn't even tell you how much disk space you will need for a fully functioning release version of the program (there may be a whole bundle of support files needed by the ex-ecutable such as DLLs)

When you buy a compiler with, possibly, other tools in the package you need to know what you intend to do with it. Most programmers will be working in a well defined area where they have a need for some special facilities.

One of the things that puzzles me is that programmers do not place a higher priority on reliable compilation. The hobbyist may enjoy trying to identify bugs in the compiler but for the rest of us they are an expensive menace. We need to be able to trust our compilers to compile our code correctly. Bugs in a compiler are not a joke, nor are compilers that are based on a misinterpretation of whatever standard, working paper or draft that they claim to comply with.

Another feature that must be important for C++ (though not for C, as it is currently stable) is a belief that the compiler will continue to develop and sup-port changes in the language. For preference I would like my compiler to continue to compile legacy code as it did before while supporting new code correctly. If it cannot continue to support legacy code it should issue appropriate error or warning messages.

What I want to do in the remainder of this article is to point to those C++ compilers for MSDOS / MSWin-dows that I know about and suggest reasons why some of you might want to look closer at individual products. I would also like to hear from you about the product you are using, particularly if I have left it out.

If you do not use MSDOS/MSWindows please write in about the compiler package(s) you use on your platform highlighting any particular features you find important.

Please note that I cannot possibly know all about even a single product so just because I do not men-tion a specific feature does not mean that it is missing from a package.

Those of you involved in numerical computing probably know that Salford Software are one of the World leaders among producers of FORTRAN com-pilers and libraries. This means that they have an ex-cellent understanding of the numerical specialists needs and their C++ compiler has excellent facilities for using FORTRAN libraries.

Unfortunately as a relatively small company they have not involved themselves with C & C++ stan-dards. This means that they have sometimes got their C wrong and their C++ is based rather too much on hearsay rather than hard facts.

Don't get me wrong - their product is good and the advantages to numerical specialists are considerable but the rest of us might be better off looking else-where.

The implementation team that came with the product when Clarion absorbed JPI is one of the most tal-ented in the world and had an excellent C++ compiler as well as some very innovative facilities. You note that I have written in the past tense. Clarion's main priority is their high quality Database Development package and much of their recent development efforts have been in this direction.

C++ has moved on over the last three years. The Clarion C++ package is still an excellent one but little has been done to it recently. This goes to show just how able their implementation team are - few C++ compilers could retain any value if left with only minimal maintenance over the last couple of years.

The question that I have to ask is how long this situa-tion will continue. With a stable language such as C their compiler will be good for quite a number of years but this is not the case with C++. Without sub-stantial work the C++ compiler is going to rapidly loose ground over the next eighteen months.

If you are involved in database development work and can take advantage of a well integrated database and compilers Clarion's TopSpeed products are still worth the effort of mastering. If you have a need for mixed Pascal, Assembler, Modula 2 and C/C++ pro-gramming the product is still on the must check list.

The great advantage of the GNU C++ compiler is that it comes with the complete source code. For the en-thusiast who wants to tinker this is an outstanding property.

This is not the product for those who want a nice cheap compiler to learn C/C++ programming. By the time you have paid for acquiring it, paid for all the other tools you will need you will have spent the sub-stantial part of £100.

The GNU products are great value for money for those that have the expertise to use them, for the rest they are a mountain of frustration.

The other problem with G++ is that it is designed for easy conversion to many platforms, but its starting place is on UNIX type systems. This means that the design is for 32-bit flat memory. You can guess that this needs more than a little fixing to work on a stan-dard PC.

Definitely not for the inexperienced.

Like G++ this is a multi-platform product with an expectation that you will be using 32-bit flat memory. As a commercial product the only acceptable fix is to provide a DOS-extender. Unfortunately the DOS compiler needs an extender but it is not part of the standard package.

This is a very high quality compiler but with very little else in the package. It is one of the most up to date C++ compilers available (the only commercial one that supports 'namespace' on a DOS platform.

The front ends for a very wide range of platforms are as identical as possible (sometimes a limitation of a platform results in some resource having to be dum-mied) and for those that have a need for multi-platform high quality development this is a product that should be on the inspection list.

However, the product is very expensive by PC terms, though cheap for UNIX. If you need versions for more than one platform you should talk to Metaware about prices as they sell each version separately.

If you want a single package for the whole range of Microsoft platforms as well as OS/2 then this is probably the most cost effective solution. Watcom have always produced high quality compilers coupled with a number of support tools. Until this last release they have relied on command line use. Those with the expertise to use an editor such as ED or MicroEmacs could integrate much for themselves but the remain-der have had to flounder around. Fine for the dedi-cated 'real programmer' but tough for the rest who just want to knock together a quick solution to to-day's problem.

With release 10 Watcom have done two important things. They bundled all the versions for different platforms (DOS, OS/2, MSWindows and Windows NT) on to one CD and provided support for 32-bit as well as 16-bit code and for provision of executables for all the above as well as DOS text, DOS extended and WIN32s.

They have also provided their first cut at an IDE. Pretty primitive still but at least a step in the direction that many programmers want.

The price without printed manuals (you do get a 'Getting Started' on paper) makes their product one worth spending time on.

One outstanding feature of their compiler is its debug support for release code. I wish all the others would emulate it.

Serious programmers should take some time to find out about this product even if you eventually decide it is not for you.

The ancestry of Symantec C++ should tell you to expect a really innovative product, at least a year ahead of its rivals. Unfortunately history will also lead you to expect a badly bugged product. That Symantec (like Zortech whom they bought) has one of the better technical support departments doesn't make up for lost time discovering that the problem is not in your code but in the compiler.

The new release which is about to come out (may be already out by the time you read this) will be very attractively priced and will include features that most programmers only dream of. A parser that has been uncoupled from the compiler so that your code can be parsed prior to compilation. After parsing an ex-cellent graphical browser allows you to inspect your code much more effectively at the time when such inspection is of most value. You can even modify inheritance hierarchies in the browser and get auto-matic modification of the code.

Incremental compilation and compilation distributed over a network are just two more of the goodies that wait for you to explore.

The one thing that I cannot know about is the reliability of the compiler. If Symantec have got that right this time then this will be the compiler that oth-ers will have to match.

The only problem is that it is only for Microsoft plat-forms.

Symantec C++ 7.0 might be cost effective for nov-ices but that will depend on the degree to which Sy-mantec have managed to clean up their IDE.

Definitely one to watch. I hope this one succeeds be-cause it has so much that I want to use.

I have no doubt that for the novice Turbo C++ or Turbo C++ for Windows is the cost effective point of departure. You will get an easy to use IDE and a very solid compiler. This is the product that has been de-signed for such users and for those for whom cost is a primary consideration. At the moment I just do not see another competitor in the market. (I think that those who think that Visual C++ standard edition meets such needs should look carefully at its limita-tions - those that want to do pure Windows pro-gramming simply should be looking at Visual Basic).

Borland C++ had become an excellent and very reli-able product by the time it reached release 3.1. They then tried to do a single massive leap forward and support almost all the contents of the C++ Working Paper as of Summer '93.

There were two dire consequences. They invested many resources in trying to solve interpretation and definition problems that WG21/X3J16 are still working on (this has an unfortunate consequence that Borland now have a decided motivation in seeing the WP adopt their solutions even if careful consideration suggest a different one). The other problem was that they produced a compiler that was buggy. I know that the compilers of most of their rivals are also bug rid-den but the users of such products already expected this. Users of Borland C++ 3.1 had come to expect a solid and stable product and it has been a rude shock to enter the real world of poor quality compilers - great features, a pity it doesn't compile my code to run the way I wrote it.

Release 4.02 did much to fix the bugs but the damage had been done. Many Borland devotees had lost con-fidence in the product.

A new release, 4.5, is due to ship soon. It doesn't add very much more apart from OLE2 support. What I hope is that it will put Borland back on course as producers of reliable and easy to use development tools.

Note that the Turbo products have retained their reli-ability because they have not tried to be 'leader of the pack' with the result that they are the leaders for those they are targeted at.

I should say one other brief thing, and that concerns OWL. Both the original product that was based on a method that WG21/X3J16 eventually rejected and the newer OWL2 were fine added value products unfor-tunately they have not captured the third party market which means that if you do not use a Borland com-piler you will not use OWL 1/2. This makes switch-ing between compilers more difficult.

Up until the recent release of 2.0, VC++ has been based on a rapidly dating specification for C++. This problem will remain for those that want to continue programming in 16-bit environments. They have no choice as 2.0 requires Windows NT 3.5 (or Chicago, sorry, Windows 95 when that finally makes it out of the box). On a long term basis Microsoft's strategy is perfectly sound. In three years time we will be wondering how anyone ever dreamt of managing with a DX33, 4 Mbytes of RAM and a paltry half gigabyte hard-drive. Unfortunately we have to get from here to there. Most ACCU members do not have the resources to run Windows NT 3.5 so VC++ 2.0 is not available to them.

For C++ programmers, the earlier versions of VC++ do not support language features that most of us now expect.

The strong point of these packages has been the growing adoption of MFC by third parties. The early versions do a reasonable job of encapsulating the Windows API. For technical reasons programs using MFC are likely to leak resources. What's new? :-)

The newest versions of MFC are more robust and I would expect them to work more reliably in an ex-ception handling environment.

Microsoft tell me that something like 80% of their developers use hardware that can run Windows NT 3.5. I am not sure what this means as I would expect that a far smaller percentage of C++ programmers use such equipment. Perhaps that reflects the differ-ence between being a C++ programmer and being an MSWindows developer.

Well that's my best shot at C++ compilers for DOS/MSWindows.

I will need rather more help next time when I want to do a pass over C++ compilers for OS/2. If you use one, could you write to me and let me have your thoughts and experiences.