Mac STL & OOP Tutorial
This is a small guide for potential programmer which briefly introduces two fast evolving directions in modern programming: algorithm programming using STL and OOP programming with Class Library like Apple MacApp, Metrowerks PowerPlant, MacZoop, Microsoft MFC, Whisper or just any other.
These things sound too complex...
Do not worry. Learn by example approach will always work (well, almost). You have to have a little of programmer's mentality :-)
What you should be familiar with?
Basic C and C++.
Although this tutorial is Macintosh-centric, you can use all STL-based algorithm examples on any platform which have up-to-date C++ compiler with template support.
Which development environment?
Apple Project Manager with GCC under MacOS X or Metrowerks CodeWarrior Pro 5 or later.
What is STL?
STL (Standard Template Library, now part of Standard C++ Library) was designed by Alexander Stepanov, Meng Lee and David Musser and allows reach set of generic algorithms (search, sort, stable sort, swap, partition, etc.) and containers (vector, map, set, etc.) to be used with standard and user-defined data structures which meet certain requirements. In other words, programmers do not have to reinvent wheel anymore.
What is a Class Library?
Usually class library is a set of classes which shields OS calls and provides necessary methods for basic functioning of application under particular OS: GUI management, file handling, multithreading, etc. Often such class libraries called application shells. The advantage of such class library is obvious:
Why C++ and not JAVA?
Well, let's face the facts and reality. JAVA will never completely replace traditional programming languages like C++ for the number of reasons. In fact, only people who are not fluent in programming could claim that JAVA will kill everything (even Microsoft Windows) and will make all software platform-neutral. First of all, what is the JAVA? It is not only object-oriented programming language, derived from C++ (like many people think), it\s rather complete runtime shell (JAVA Virtual Machine, or JVM) with its own default programming language, which runs under certain OS or hardware. JAVA applets or applications can be compiled into byte-codes, which are OS and CPU neutral, or into machine code for particular OS and CPU for better execution speed (yes, OS and CPU, because JAVA programs compiled into machine code for x86 Linux will not run under x86 Windows), or from byte-codes to machine codes during runtime (if JVM supports JIT, Just In-time Compiling). Cross-platform compatibility is somewhat limited, because of not all OS support the same version of JVM. Software written for latest version of JVM often will not run under earlier versions. Speed comparison between C++ and JAVA software compiled into machine code is almost always flawed.
Test routines with standard operations like loops, branches, integer and floating-point arithmetic will be compiled into similar machine code no matter of programming language. JAVA slowdown arises when software needs native OS calls. This requires extra glue code and data conversion because different OS have different internal representation of the even logically similar data.
Also, JVM itself have a number of bugs (all software have bugs and vice versa), and when running under buggy OS, nobody knows, how bugs of OS and JVM will influent to each other. Just recall what happened to ill-fated JAVA Corel Office: very slow, buggy, and limited package have been dropped because of no light at the end of tunnel. Statements that JAVA applications are very compact also untrue: if you add size of JAVA program to the size of JVM you will see they are not so small. JAVA currently fills niche where C++ have never been the best: platform-neutral browser applets, database front-ends, networking component software. For example, networked accounting and stock control systems usually consist of database SQL server and client for user data entry, transactions and report processing. Client itself is pretty simple piece of software whose speed mostly depend of server power. Writing such client in JAVA hits several targets with one stone: cross-platform compatibility, very limited client's workstation requirements, shorter development cycle thanks to JAVA built-in range checking and garbage collection (with speed penalty not noticeable for this kind of software), and thus, saving a LOT of money (cheapest PC hardware, no licensing fees for free OS like Linux, etc.). When it comes to development of complex software, one feature really missing from JAVA is template support. This makes impossible to use generic algorithm libraries the same smart way they used in C++. However, a company called ObjectSpace developed product called JGL (The Generic Collection Library for Java), which is open source and free. It is not so elegant, universal and efficient as STL but still usable.