The C++ Language -
A Cornerstone of Computing in the 1990's.



[This is the unedited version of a magazine article which appeared as one of three articles in: Your Computer mazagine, Dec’90. pp 64-72, The Federal Publishing Company, NSW, Australia.]

The computer industry to be sure, is guilty of falling for fads and the onslaught of jargon in the industry is probably second to none. Under the disguise of jargon, a new fad can be pushed onto the market that is really just a conglomerate of existing ideas, refocused into another virgin market. What you then get, is state-of-the-art conferences with globe trotting gurus, spreading the word - very expensively. Over the last two decades we've had many new dawns with Relational Databases, Expert Systems, Neural Networks, 4GL's, CASE, Object Oriented Programming and much more. So how do you pick a major advance from those re-packaged wares, refashioned with new jargon and a new emphasis? How do you pick the minor gain in a vertical market from major advance to the computing mainstream?

I don't pretend to know, but when you strike a fundamental advance, a quantum leap, I believe it should hit you like a loaded semi-trailer. Well at least akin to Newton being struck on the head by a falling apple. This has now happened to me just twice in computing over a period of 12 years, with my experiences limited to just some of those `new dawns'. Conversely, I know I was very lukewarm about Expert Systems when I became aware that what they were calling a 'Frame' was a re-hashed version of a 'Table' in relational database terminology. And that you could deliver a working Expert System in a good old language like FORTRAN say, with a series of IF THEN ELSE statements.

I was first definitely 'struck' back in 1983 by Codd's Relational Database concept. The underlying maths, which E.F Codd formulated back in 1971, has foundered nothing less than a Theory of Information. With his Rules of Normalisation, you can go into an organisation that has been in business for 100 years. Gather a whole stack of basic information about their enterprise. Then, without prior knowledge of that business, by systematically following through the 'rules', you can tell them the optimum form of their corporate information systems - right down to how their manual card decks should have been organised in the first place!


SQL - the Babel Fish.

But the thing is, going from theory through to products that become dominant in the marketplace of the working world, takes a lot of time. The hardware platform has got to have an acceptable price/performance ratio. The software tools have got to be developed, refined and optimised. And the application developers have to be educated. For example the relational database language SQL, grew out of Codd's work. Yet it is only establishing itself as the dominant database technology, about now. With Microsoft’s delivery of their SQL Server (and a few other SQL engines such as Oracle’s), they have really just bridged the PC and the mainframe worlds, just in time for SQL to dominate corporate computing throughout the 1990's - some 20 years on. (NB. The sorts of things you can now do across machines includes: using a spreadsheet program on a PC, to pluck a chunk of refined data speedily from a mainframe database, with SQL acting behind the scenes as a go-between, and depositing it in your user-friendly spreadsheet - making SQL a bit like the Babel-fish in Douglas Adams "The Hitchhikers Guide to the Galaxy" i.e. For non-fans, in this work of science fiction there is a small fish, that when inserted in your ear, lets you understand any foreign language directed your way. It feeds on brain waves from the communicator and its excrement is your native language)

My second computer oriented revelation came along middle of last year when I was struck by Object Oriented programming in the form of the C++ language. And I have been working exclusively in C++ ever since. While there are many object oriented languages such as, Eiffel, Objective C, Objective PASCAL, Turbo PASCAL V5.5, and the grand daddy Smalltalk, it is C++ that has so very recently risen to the top of the heap. If the SQL engines of today represent the commercial maturing of Relational Database concepts (i.e. pragmatic, robust, efficient - yet ideologically foundered), then C++ is the same to Object Oriented Programming. And for you programmers who might have been put off C, never mind C++, don't be intimidated by the ++. I definitely contend that C++ is a much easier language to learn and program in, than straight C - more on that later.

However, my conversion didn't come straight away. It took a while for the penny to drop - I mean the apple. What I have always needed to get a grip on any new concept, is a good solid example. I was slogging away trying to read the odd book on the subject, and struggling to see any major benefit over conventional languages. I started recoding some conventional programming tasks in C++, such as linked lists, and sorts etc, but I found myself continually falling back into C (which is a sub-set of the C++ standard). In short, I was having some trouble breaking out of my conventional programming mind-set. And it was primarily due to two mistakes, which I aim to save you from, if you want to walk down the C++ path.

Mistake number 1 was choosing the wrong book to read first up. I started by reading (not to be confused with comprehending) `The C++ Programming Language' by Bjarne Stroustrup, who works at AT&T Bell Laboratories and is the creator of the language. It sort of left me with a dizzy feeling. This is the sort of book you need if you are going to write a C++ compiler. All I wanted to do was become a skillful user of such a compiler. As it happens, there was a limited supply of C++ texts this time last year. But that has all changed. The start of the flood of C++ books has arrived (see list below). If you like the practical approach, and an author who is up to his armpits in cutting code, then a really great book to start with is `Using C++' by Bruce Eckel. A second good book is `An Introduction to Object-Oriented Programming and C++' by R.S. Wiener and L.J. Pinson. This second book is useful early on because it covers such fundamental concepts to C++ as Classes, Derived Classes, Inheritance, Polymorphism and Virtual Functions, in a concise, clear and best of all, brief manner. The `brief' is good, because you can quickly go back for a re-read of the appropriate page from time to time, until the concept you are struggling to attain full comprehension of, finally sticks in your brain.

My second mistake was to try and do programming tasks I was an old hand at, in a conceptually new language. Even though you can do things like linked-lists beautifully and quite revolutionary in C++, a good grasp of the new concepts is necessary first. I figured I should really start to program something that closely resembled real objects in the physical world. As it happened, I had a board game (the cardboard and plastic variety) in my in-tray that had been there for many months. It had been suggested to me by its inventor who lives next door, that I should render this board game as a computer based one, some time when I had a spare moment or two! Now I had dabbled in graphics very briefly in the past, with sprites in G-PASCAL on a Commodore 64 and in driving the odd plotter from Fortran 77 on a Cyber mainframe, but expert I certainly wasn't - that's why the in-tray had become home for this game.

So I throw down the challenge to C++. If it was so damn good it should enable even me, to become a games programmer in vivid VGA graphics no less! In eight days I had this working prototype (see Fig.1 - in VGA graphics on a PC). The hexagonal pieces can be selected and moved around the board with the arrow keys, at a speed reminiscent of a Commodore Amiga (And for that matter, I could take the program over to an Amiga. Replace 5 underlining low level graphics function calls - i.e. moveto, lineto, etc. Recompile it. And it would run on that machine too! That is one of the beauties of C++. It is a multi-platform language like its unforgiving little brother C). I can rotate the coloured boxes clockwise or anti-clockwise by selecting the A or C keys. What I had was the basic mechanics for a computerised version of the strategy board game METAGON - an Australian Design Award winner back in 1983. The moment I saw this electronic mechanisation, actually work as planned, and all without a serious hitch, I felt this shiver down my spine, followed by a warm inner glow. I instantly became a C++ convert.

Don't be misled into thinking C++ is just great for graphics work. Not so. It lends itself to almost any programmable task. It is just that a task which includes distinct visual objects (such as game pieces or the popdown windows of a user-interface - ideal for WIMP interfaces), make it easy for your mind to grasp the change in thinking needed, to move from programming in a conventional language, to an object oriented language.


Why C++ over the Others?

I have been a member of SIG-OOPLAD (Special Interest Group on Object Oriented Programming Languages, Applications and Design) of the ACS (Australian Computer Society), since its inaugural meeting in November 1989. And just one of the things attendance there has done for me, is to expose me to the diverse groups using object oriented languages. The languages they use are just as diverse. As are the applications. That's what this group is all about - it’s "a forum for the exchange of ideas, experiences and information amongst all those using the Object-Oriented paradigm". During each meeting, held quarterly, in Melbourne, the exponents of a different language seem to stake a claim through their speakers, for their chosen language to eventually rule supreme. There's the SMALLTALK `Programmers Liberation Front' camp, speaking in been-there-done-that tones (being relatively old, SMALLTALK has a very extensive built-in class library). Then the Eiffel `Front for the Liberation of Programmers' faction, did nothing less then produce as a speaker, their holy leader, Bertrand Meyer, the languages inventor and continuing developer (courtesy of TELECOM bringing him to our shores)! Each group of different language supporters is a minority. (NB. I have listed a Bertrand Meyer book below, as it is a good general one on the object oriented paradigm - regardless of the language chosen.)

So my claim to C++ being the dominate force in object oriented programming, certainly should not be construed as representing SIG-OOPLAD's in general. However, the individual proponents of each of the language factions, and their hardware platforms, and their applications, tell a great deal by themselves. Follow-up your own enquiries. Draw your own conclusions: SMALLTALK proponent: Operations Research boffins for Life Insurance company, working on dedicated SUN workstations, for once-off corporate mission application. Hardware expense - no object. Applications resultant size and execution speed - not an issue. Delivery date - yesterday. Eiffel proponent: Used at TELECOM Research Laboratories for a large, long term project called TORUS (Tools for Reachability Analysis and Specification?), on SUN workstations. C++ proponents: Consultants; software package developers; commercial vertical market application developers; academics; games programmer; on various hardware platforms including PC's running DOS and OS/2, and on Unix boxes.

C++ is a pragmatic marvel. It is a superset of the C language (i.e. any valid C statement is a valid C++ statement). It is largely due to C itself, being as much a high level assembler as it is a 3rd generation structured language, that this feat of coexistence has been pulled off by Bjarne Stroustrup. For all the power of the object paradigm C++ has over standard C, efficiency of the resultant executable code is usually little different from that produced by straight C code! In fact most of the C++ compilers on Unix boxes and some on PC's, pre-compile to C as an intermediate step to machine code. However Zortech C++ V2 and Borlands Turbo C++ (full AT&T V2 compatible), are native C++ code compilers, i.e. they go straight from C++ to machine code. They compile code fast and furiously on standard old PC boxes.

As an example of the power of C++ to reduce complexity, take Glockenspiel C++ (the DOS and OS/2 versions) which precompilers to Microsoft C. It has with it, a class library of interface routines called Commonview. Commonview is a forerunner of many like products for sure. Commonview encapsulates the entire Microsoft Windows and Presentation Manager interfaces in just 30 classes of object. The objects cover such user-interface gadgets as: scrollbars; Push buttons; Radio Buttons; Check Box; etc. Yet Windows has some 400 individual function calls, and PM has over 700, that the straight C programmer would have to contend with. As an example of the executable code efficiency, Commonview comes with a re-write of the example CardFile application that came with Windows V2.1 SDK coded in standard C. The C++/Commonview version has one line of code for every five of the C version. The runtime performance of this CardFile is indistinguishable from that original. The size of the executable when running, is actually quite a bit smaller than the C version, due to better use of Windows DDL (Dynamic Link Libraries)!

The weight of Microsoft behind a new language, is no small sign. They have reputedly been using Glockenspiel in-house and have announced plans to deliver their own C++ compiler sometime in the near future.

A strength of C++ is that its inheritance feature lets the programmer extend the capabilities of library classes - without access to the source code! [NB. A Class (e.g. circle) is the group name of a bunch of objects e.g. a series of actual occurrences of circle I might have declared and drawn on the screen]. For example, if you bought a high performance (fast) circle drawing class library, from a third party tools developer, who wouldn't part with his source code, and you want to customize your circles - no problem. If you want to modify his circle drawing class, to one that draws circles filled with yellow dots, you can. You just derive a new class that inherits all of the old ones features and capabilities, then add your own extra features - i.e. yellow dots. The appeal of extendable .OBJ/.LIB code, is a strong one in the commercial world.


Why is C++ so much easier than C?

When I read Bruce Eckel's book, I had been programming in C++ for over 6 months. There are several things he says in the Preface that I really related to, straight away. One of them was: "Many people who learn the language discover a more mysterious benefit. Once a program compiles, it often seems to - just work right the first time." i.e. no serious bugs - just simple syntactical ones that the compiler picks up! I honestly haven't had a serious bug in C++ in over 12 months, and I can tell you that is uncharacteristic. My serious bugs in the past, in standard C, emanate from 2 sources: 1 - logical errors, where I thought I had nutted out a problem, but my solution was logically flawed. And 2 - bugs of the infamous pointer variety. (To any one out there that professes that they've never had pointer bugs in C, due to good programming technique, I contend that you haven't yet written a large enough slab of code. The chooks really only come home to roost when you approach a 64K chunk of executable code.)

Eckel goes on with his explanation of this uncanny bug vanishing trick, with "Although there is no way to measure or verify this benefit, it is probably due to the stronger type checking C++ has over C, and the structure even the most avid hackers are seduced into using when creating new data types." I would go much further than that. I contend that much can be attributed to the languages ability to fit the vast majority of applications like a glove. No more square pegs in round holes, simply means you are going to make far fewer logical errors in developing your algorithms, in the first instance.

With respect to dealing with pointer variables (i.e. variables that hold the physical addresses of other normal variables), C++ makes it possible for you to avoid their use entirely if you choose, through several aspects of the language. Although there are still situations where they are recommended for efficiency. However, you aren't forced to dive straight into pointer concepts in C++ as you were in straight C. i.e. Most programs consist of a mainline section of code, which calls numerous functions/subroutines to do specific jobs. If you want to move information across from the mainline to a function, in a programmer-friendly language like PASCAL, there are two ways to do it: 1. make a copy of the variable for use in the function - termed pass-by-value; or 2. refer to the original mainline variable (via its actual address) when down there in the function - termed pass-by-reference. When passing-by-value, any changes made down in the subroutine, don't affect the original variables value back in the mainline. When passing-by-reference, the changes you make down in the function are actually directly affecting the mainline variable. Programmers heavily use both situations. The C language doesn't pass-by-reference in the true sense. It allows you, the programmer, to simulate it, by passing pointer variables or addresses - and treating them as pointers down in the function, and hence forcing the new programmer into pointer concepts, very early in the piece. Since you must explicitly declare pointers or explicitly pass addresses, then in a sense, C only really passes-by-value.

Well, C++ changes all that. It has pass-by-reference in the PASCAL sense, so that no special treatment of the variable is necessary down there in the function. Hence you can avoid pointers in C++ for a very long while if you choose. And, if you avoid some of the terse, little used operators of C, and just concentrate on the C language constructs (i.e. if (...) ...; else...; do {...} while (...); ) inherited by C++, which after all, are not much different from the constructs in most modern day versions of conventional languages like PASCAL or a good non-standard BASIC. Then C++ is much more inviting as a conventional language over C, let alone for its object oriented features.

Four years ago I went from PASCAL to C as my language of choice and I found the experience disconcerting. The major factor was the increase in bugs over those I had experienced in PASCAL, and the obscure symptoms they produced making, cause and eradication difficult. It soon became clear that the power in C came with added responsibilities, and there were definite environmental hazards in the C workplace. I know I am not alone here. I teach C classes from time to time, and I have had numerous students coming from Turbo PASCAL, who after just a little time in C, are amazed at the silly things C lets you do to yourself. Some have reverted to PASCAL after bad experiences in C. However, these bad things associated with C, don't carry over into C++ proper (i.e. if you do things the C++ way). I have found C++ better than PASCAL when it comes to a lack of bugs. You can come from PASCAL or other structured languages, bypass C, go straight into C++ and be better off all round. In fact, to do so, you wouldn't be susceptible to falling back into old C habits as I was, when trying to get a grip on the object programming mentality.


A Choice of Compilers.

Zortech C++ V1. Glockenspiel C++. Zortech C++ V2. Borland Turbo C++. That's the order I bought them in, the order in which I have used them, and the order they have been removed from the hard disk - bar Turbo C++ which has remained. Yet they each have their strengths. The following is in no way an attempt to fully review them all here. But neither is it a preview. It really just offers some brief glimpses and a personal perspective on the things that should affect your decision in choosing - if you are in the market.

I have developed a cascading pop-down menu and text window series of object classes, with mouse support. I am using them for reincarnations of my existing packages and more. (see Fig. 2. for sample Application menu, using this class library) I have it working in all three compilers. The code is entirely written in C++ (i.e. heavily object oriented), apart from calling only a handful of low level functions for fast direct video update (e.g. gettext, puttext functions in Turbo; disp_peekbox, disp_pokebox in Zortech; and virdsect, viwrsect from a third party library from BLAISE Inc. in Glockenspiel). The size of the resultant .EXE code is:

Glockenspiel 23,879 bytes;
Zortech 24,453 bytes;
Borland Turbo C++ 22,594 bytes.


Glockenspiel C++.

Speed as a primary usability criterion for a computing system, is a heavily neglected one in the press. Partly because reviewers are often using hardware configurations well out of the price range of the average readers configuration. To diverge for a moment for a concrete example. Some time after desktop publishing was born on the Apple Macintosh, in the form of the brilliant program Pagemaker, I became a heavy user of both the Mac and program. But the particular Mac I used (512K), like the vast majority of Mac's then (and maybe now?), didn't sport an expensive hard disk. What you did then, was a lot of floppy disk swapping every time you tried to do something useful. The frustration level was immense. Many were the day I came close to throwing the Mac out a window of the non-metaphorical kind. What you had then, was a supposed revolutionary user-friendly interface on a machine configuration that absolutely negated its benefits.

Glockenspiel on a 640K, 12 MHz AT, 48 ms 20 Mbyte hard disk, DOS machine, is very much like that. First it precompiles to Microsoft C, which is then compiled into machine code. The compilation speed for Glockenspiel plus Microsoft, is an order of magnitude above those of Zortech and Borland (i.e. between 15 and 20 times slower). You are really talking a 33Mhz 386 or a 486 machine, with lots of memory and a fast hard disk, to use Glockenspiel productively. To be fair, Glockenspiel was shoe-horned down from Unix to DOS, and done so quite well given the constraints. From version 1.2E on (and Commonview V1.0A on), it could automatically swapped out to disk when compiling large files (up to a limit) on a minimally configured 640K DOS machine. (Of course the OS/2 version, on the appropriate hardware, would be a comparative luxury) The first golden rule a program must pass for acceptability, is that it must work. Glockenspiel has done that, slowly but flawlessly.

Also, its class library of WIMP user interface routines named Commonview, is impressive. If you have an application destined for WINDOWS and OS/2 Presentation Manager (PM) simultaneously, and XWindows on UNIX, and the MAC - then development in Glockenspiel compilers is a sure bet (you'll need to buy a different version of the compiler for each machine - the DOS version alone costs around $1000 in Australia). With heavy use of Commonview for your user interface, you can move your C++ source code from machine to machine, with little or no changes to your source code. I'll qualify that by saying I've only used the DOS version with the Windows version of Commonview, and never tried such a transition. But Glockenspiel guarantees no code changes going from MS Windows to PM. And minimal changes going to the other available platforms.

Secondly, if you have a heavy investment in existing compiled third party C libraries, in Microsoft C, which you intend to call from C++. And if you lean heavily toward Microsoft as your supplier of development tools. Then Glockenspiel must be a contender, at this stage of the game. And remember, Microsoft themselves have been used this package and spoken well of it. (Examples of cooperation at some level exist, such as a public domain program produced by Glockenspiel that translates Turbo PASCAL to Microsoft Quick C.)

Zortech C++ V2.

Zortech was the first native C++ compiler on the PC (to my knowledge). i.e. it goes straight from C++ to machine code. As mentioned, this approach is an order of magnitude faster than the translators of the Glockenspiel variety (the guts of the translators are usually licensed from AT&T, the C++ keepers). It has had a big head start on Turbo C++, becoming available here about November 1989. It came with an editor called ZED, which is fairly primitively integrated with the compiler, when compared with Borland language products. In no time at all, your code gets too big to compiler in the editor, so you quickly resort to command line compilations. Mind you, Glockenspiel strictly provides a command line compiler, with no attempt at an integrated programmers editor.

However, Zortech V2 is a very mature product. It has a very fast graphics library included called Flash Graphics. It has a text mode display library of routines called the Display package, that gives you access to fast direct video routines, essential for your application to compete in the modern marketplace. It has all the standard C system functions built-in (e.g. mkdir, chdir and the directory tree building functions like, findfirst and findnext, etc.). Zortechs intention seems clear to me. They came out with a product that didn't have third party library developers support, right off. So they themselves provided most of the tools necessary for a developer to produce a state-of-the-art DOS based application.

Significantly, Zortech supports Microsoft Windows development. i.e. their linker can link in code from the Windows SDK (Software Development Kit). This is the case with Windows 2.1, but I haven't personally tried it with Windows 3 SDK yet. And lastly, Zortech have an OS/2 version of their compiler. While I haven't used it, I know of a large vertical market software house in Melbourne, that have settled on this version to development OS/2 Presentation Manager applications.

Borlands Turbo C++

The significance of Borlands C++ is partly eluded too by the reaction of two of their language market competitors, very soon after its release:

- Microsoft were caught without a C++ compiler of their own anywhere near completion. They opened their language development unit to the press, outlining the future language development tools destined for the market in the coming year or so - in what could be construed as damage control mode. Reassuring comments on a future Microsoft C++, featured heavily.

- Zortech announced they were superseding their recent DOS version 2.0 of C++, with 2.1 which allows developers to compile "applications with large and complex class hierarchies on PC's with 80286/386 or 486", using extended memory technology from Rational Systems. This is an attempted catch-up with the VROOMM technology in Turbo C++ (see below).

Prior to Turbo C++'s release, the rumours were that Borland would put some C++ extensions (but not the full AT&T V2.0 specification) into Turbo C 2.0, and call it Turbo C 3.0. Well Borland caught everyone off guard. They came out with a full blown AT&T V2 implementation of C++ - months before anybody expected. In addition they have completely revamped the previous environment seen with Turbo C 2.0 and Turbo Pascal 5.5. (see Fig. 3 - it's called the IDE for Integrated Development Environment) As a near trivial example of its improvements, it now has full mouse support. In addition, the package both uses VROOMM technology and lets you put VROOMM technology into your applications. In short, VROOMM is almost automatic code overlaying that allows large programs to fit into smaller amounts of memory. While it can use extended or expanded memory, it can also swap code to disk when the necessary memory can't be found. VROOM is the technology they used to develop their highly acclaimed spreadsheet QUATTRO PRO, enabling it to run in as little as 512K, when LOTUS needed 1Meg for version 3 of 1-2-3. It is the technology they are putting into their database system Paradox. Turbo C++ is the first of their language products to use VROOMM. And it clearly demonstrates the new vitality VROOMM has giving to 640K limited DOS machines. For example I opened 40 files at once (in different windows), then compiled one of them that was sizable - no problem. It's the sort of technology that puts a smile on your face.

Turbo C++ comes in Standard or the Professional pack. The more expensive option has the new Turbo Debugger V2, Turbo Assembler V2 and the Turbo Profiler V1 - a tool for finding the performance bottle-necks in your programs. All up, nine manuals compared with 4 in the Standard version.

Don't think the newness of Turbo C++ means it is not a mature product. Quite the reverse is true. It starts somewhere beyond Zortechs second go at C++ with their V2.0. Borland entered the C market with Turbo C V1.0 quite some years back, the quality and performance of which, very much competed with Microsoft’s up-market C V5.1 Optimising compiler, plus Quick C 2.0, combined. Borland have a habit of understating their technology via there version numbers. Another example of this is Turbo PASCAL 5.5. The transition from 5.0 to 5.5, took their PASCAL from a conventional language to an object oriented language, with features and terminology very similar to the C++ object capabilities. And I am sure their experience in developing Turbo PASCAL 5.5, which has been on the market for over a year, went a long way in getting their C++ out the door so fast, and in such top-of-the-heap condition.

A Temptation to Borland?

A big surprise in Turbo C++ is the lack of ability to develop Microsoft Windows applications. Borland have been promising Windows development support in their languages, for quite a while now. Yet this, their latest product, doesn't sport it. One thing that crossed my mind a while ago, after realizing the power of C++, was just how much easier it would be for someone to develop a graphics interface for DOS in C++, compared with Microsoft’s 5 year exercise in C (and assembler), to get Windows 3 up to its full height. Of all the companies that could do it and that maybe could pull off the marketing, Borland comes to the top of the list in my mind. And they could do it in under 640K with their VROOMM technology. Remember they are also one of the leading developers in the OS/2 market with Sidekick and Paradox for that operating system. An under 640K graphical user interface, backed by a company with languages, spreadsheets, database systems and a word-processor, would have two distinct markets: OS/2 on machines with 3M memory plus; and the other being the 640K DOS marketplace - no fuzzy overlap there! Unlike the trouble Microsoft is having segmenting Windows from OS/2's market, given that most commentators claim a fast 286 and 2M of memory is the minimum necessary configuration for using Windows 3 effectively.

I get the feeling that this sort of temptation to other system developers, was a major factor in Microsoft spending $14M in launching Windows 3. Thereby making it a near impossibility for anyone else to succeed in marketing a competitor. So the most likely scenario then, for Borlands delay in MS Windows support, is that they aim to do the proper job. The very fact that all their recent products e.g. Turbo C++, Quattro Pro, and Turbo PASCAL 5.5, are shining examples of technical excellence, is an indication of what is to follow. No, Borland won't do a Zortech which just allows the programmer to link Windows code. I think their approach will be more like the Commonview object library in Glockenspiels C++ - i.e. something that manages the programming calls in windows from something like 400 individual functions to something like encapsulation in 30 or so object classes.

The Choice is Easy - in Retrospect.

If you are currently developing in Windows, and wish to move that development from C to C++ right away. You can choose either Glockenspiel or Zortech (unless Borland have come out with Windows support in the last 6 weeks). Further, if you don't have a pressing need to run your program on UNIX boxes or Macs as well as PC's, and you don't have at least a 33Mhz 386, then Zortech V2.1 is a good bet.

If developing for DOS and MS Windows development is not a hot priority, Turbo C++ is the go.

If you intend learning both C++ and the Windows development environment, I would learn the C++ ropes first. It will realistically take you about 6 months to get up to full productive speed in C++, from whatever language you come from. Then learn the Windows environment second. In the meantime all the players should have their cards on the table, and the tools available for windows development, will take the much of the hard work out of it anyway. So again, I'd learn towards Turbo C++. The price of Turbo C++ as a learning environment alone would cover itself in your time saved in the first week or two, over using its competitors. It comes in the extreme bargain category, and really deserves a full review, which I will do month after next.



Don't be mistaken. C++ is one of the corner stones of the computer industry for the 1990's. Between SQL engines, cheap 32 bit PC's, WINDOWS 3, OS/2 V2, user-friendly UNIX interfaces and C++, it seems we are in for one hot decade. If you thought the original PC in 1981 was a revolution - you ain't seen nothing yet! And you programmers out there who think it has all been done, "so why bother attempting to write the great Australian package", think again. The slate has been wiped clean. The opportunities have never been brighter and the software tools never better. Power hardware platforms never cheaper. Accept the challenge. Get a hold of a good C++ compiler like Borlands Turbo C++ or Zortechs C++ V2.1, get skilled up and start cutting code for you and your country!

[Next Month, I hope to entice you into coding up a very useful object class - A scalable digital watch-like font in C++ (see Fig. 4) I have developed in the course of writing a game.]

Steven Goschnick is a Partner in Melbourne firm, Solid Software. He has written 2 software packages for the PC: SEETREE - a DOS shell and file manager; and LOTTOCHECK - a lotto database and analysis system. He is a Member of the Australian Computer Society (ACS), and a member of the SIG-OOPLAD (Special Interest Group on Object Oriented Programming Languages, Applications and Design) of the ACS. He is a founding member of the newly formed SPAA - Software Publishers Association of Australia.

Books Mentioned - with brief comments:

Other Recent Books:


This article is copyright: ęSteve Goschnick,1990.