C++ : Environmental/managerial issues
PART 2
Q1: What is C++? What is OOP?
C++ can be used simply as `a better C', but that is not its real advantage.
C++ is an object-oriented programming language (OOPL). OOPLs appear to be the
current `top shelf' in the development of programming languages that can manage
the complexity of large software systems.
Some OOP hype: software engineering is `failing' to provide the current users
demands for large, complex software systems. But this `failure' is actually
due to SE's *successes*. In other words, structured programming was developed
to allow software engineers to design/build HUGE software systems (that's a
success). When users saw how successful these systems were, they said, `More
--- give me MOOORRRREEEE'. They wanted more power, more features, more
flexibility. 100K line systems are almost commonplace nowadays, and they still
want more. Structured programming techniques, some say, begin to break down
around 100K lines (the complexity gives the design team too many headaches, and
fixing one problem breaks 5 more, etc). So pragmatics demands a better
paradigm than structured programming. Hence OO-design.
Q2: What are some advantages of C++?
GROWTH OF C++: C++ is by far the most popular OOPL. Knowing C++ is a good
resume-stuffer. But don't just use it as a better C, or you won't be using all
its power. Like any quality tool, C++ must be used the way it was designed to
be used. The number of C++ users is doubling every 7.5 to 9 months. This
exponential growth can't continue forever(!), but it is becoming a significant
chunk of the programming market (it's already the dominant OOPL).
ENCAPSULATION: For those of you who aren't on a team constructing software
mega-systems, what does C++ buy you? Here's a trivial example. Suppose you
want a `Foible' data type. One style of doing this in `C' is to create a
`Foible.h' file that holds the `public interface', then stick all the
implementation into a `Foible.c' file. Encapsulation (hiding the details) can
be achieved by making all data elements in `Foible.c' be `static'. But that
means you only get one `Foible' in the entire system, which is ok if `Foible'
is a Screen or perhaps a HardDisk, but is lousy if Foible is a complex number
or a line on the screen, etc. Read on to see how it's done in `C' vs `C++'.
MULTIPLE INSTANCES: The `C' solution to the above `multiple instances' problem
is to wrap all the data members in a struct (like a Pascal `record'), then pass
these structs around as if they were the `ComplexNumber' or whatever. But this
loses encapsulation. Other techniques can be devised which allow both multiple
instances and encapsulation, however these lose on other accounts (ex:
typedef'ing `Foible' to be `void*' loses type safety, and wrapping a `void*' in
the Foible struct loses an extra layer of indirection). So the `module'
technique loses multiple instantiations, but the `struct' technique loses
encapsulation. C++ allows you to combine the best of both worlds - you can
have what amount to structs whose data is hidden.
INLINE FUNCTION CALLS: The `encapsulated C' solution above requires a function
call to access even trivial fields of the data type (if you allowed direct
access to the struct's fields, the underlying data structure would become
virtually impossible to change since too many pieces of code would *rely* on it
being the `old' way). Function call overhead is small, but can add up. C++
provides a solution by allowing function calls to be expanded `inline', so you
have: the (1) safety of encapsulation, (2) convenience of multiple instances,
(3) speed of direct access. Furthermore the parameter types of these inline
functions are checked by the compiler, an improvement over C's #define macros.
OVERLOADING OPERATORS: For the `ComplexNumber' example, you want to be able to
use it in an expression `just as if' it was a builtin type like int or float.
C++ allows you to overload operators, so you can tell the compiler what it
means for two complex numbers to be added, subtracted, multiplied, etc. This
gives you: z0 = (z1 + z2) * z3 / z4; Furthermore you might want string1+string2
to mean string concatenation, etc. One of the goals of C++ is to make user
defined types `look like' builtin types. You can even have `smart pointers',
which means a pointer `p' could actually be a user defined data type that
`points' to a disk record (for example). `Dereferencing' such a pointer (ex:
i=*p;) means ``seek to the location on disk where p `points' and return its
value''. Also statements like p->field=27; can store things on disk, etc. If
later on you find you can fit the entire pointed-to data structure in memory,
you just change the user-defined pseudo-pointer type and recompile. All the
code that used these `pseudo pointers' doesn't need to be changed at all.
INHERITANCE: We still have just scratched the surface. In fact, we haven't
even gotten to the `object-oriented' part yet! Suppose you have a Stack data
type with operations push, pop, etc. Suppose you want an InvertableStack,
which is `just like' Stack except it also has an `invert' operation. In `C'
style, you'd have to either (1) modify the existing Stack module (trouble if
`Stack' is being used by others), or (2) copy Stack into another file and text
edit that file (results in lots of code duplication, another chance to break
something tricky in the Stack part of InvertableStack, and especially twice as
much code to maintain). C++ provides a much cleaner solution: inheritance.
You say `InvertableStack inherits everything from Stack, and InvertableStack
adds the invert operation'. Done. Stack itself remains `closed' (untouched,
unmodified), and InvertableStack doesn't duplicate the code for push/pop/etc.
POLYMORPHISM: The real power of OOP isn't just inheritance, but is the ability
to pass an InvertableStack around as if it actually were a Stack. This is
`safe' since (in C++ at least) the is-a relation follows public inheritance
(ie: a InvertableStack is-a Stack that can also invert itself). Polymorphism
is easiest to understand from an example, so here's a `classic': a graphical
draw package might deal with Circles, Squares, Rectangles, general Polygons,
and Lines. All of these are Shapes. Most of the draw package's functions need
a `Shape' parameter (as opposed to some particular kind of shape like Square).
Ex: if a Shape is picked by a mouse, the Shape might get dragged across the
screen and placed into a new location. Polymorphism allows the code to work
correctly even if the compiler only knows that the parameter is a `Shape'
without knowing the exact kind of Shape it is. Furthermore suppose the
`pick_and_drag(Shape*) function just mentioned was compiled on Tuesday, and on
Wednesday you decide to add the Hexagon shape. Strange as it sounds,
pick_and_drag() will still work with Hexagons, even though the Hexagon didn't
even exist when pick_and_drag() was compiled!! (it's not really `amazing' once
you understand how the C++ compiler does it -- but it's still very convenient!)
Q3: Who uses C++?
A: Lots and lots of companies and government sites. Lots.
Statistically, 20 to 30 people will consider themselves to be new C++
programmers before you finish reading the responses to these FAQs.
Q4: Does C++ run on machine `X' running operating system `Y'?
A: Most likely, `Yes'.
See the next question for a few specifics. Finding vendors isn't always easy.
If you're still stuck after reading this FAQ, try comp.lang.c++ and/or BIX.
Q5: What C++ compilers are available?
A: Lots. Here are a few:
* `Cfront' is USL's compiler. It compiles to C, so it is `technically' a
translator rather than native code compiler, but that doesn't make much
difference in practice (think of C as an assembly language). Many hardware
vendors bundle and/or sell a `cfront-based' C++ compiler.
* GNU C++ is freely copyable under the Free Software Foundation `copyleft'.
Usually called g++, it is available via anonymous ftp from prep.ai.mit.edu.
It is supported by Cygnus (contact tiemann@cygnus.com).
* Borland C++ (BC++) and Turbo C++ (TC++) are available from Borland Int'l.
It is available for DOS; an OS/2 2.0 product has been announced.
* Zortech C++ (ZTC++) is available from Zortech Int'l. DOS and OS/2.
* Glockenspiel C++ is a DOS port of cfront; also runs on some Un*x platforms.
* Saber C++ is a Un*x based interpreter/compiler programmer's workbench.
* ObjectCenter is a Un*x based interpreter/compiler programmer's workbench
distributed by CenterLine (formerly Saber Software). 617/498-3000
* Saber C++ is the former name for ObjectCenter (`Saber' became `CenterLine').
* Oregon C++; native-code compiler and source-level debugger; TauMetric Corp;
800-874-8501; Sun4, DECstation, Sun3, HP9000/300 & 400, i386/i486SV, VAX/VMS
* Green Hills C++ (sorry, no further information)
* Symantec's Think-C for Macintosh (5.0 supports many of the features of C++)
800-228-4122 or 408-253-9600.
* Intek (sorry, no further information)
* MPW C++ is a cfront 2.1 port for Apple from APDA=Apple Progmr's/Developer's
Assoc: USA:800-282-2732, Canada:800-637-0029, International:408-562-3910
* ObjectWorks\C++; ParcPlace; Un*x based interpreter/compiler programmers w.b.
* Comeau Computing has a cfront 2.1-based compiler for Amiga, DOS, and Unix.
* SAS Institute (was Lattice, Inc) has a cfront 1.2-based compiler for Amiga.
This list is not exhaustive.
Q6: Is there a translator that turns C++ code into C code?
A: Yes, there are many. USL produces such a compiler called `cfront' (if you
think of C as an assembly language, then it's a `compiler'; if you think of C
as a high level language, then it's a `translator'; technically cfront is a
`compiler front end'). Many companies port and resell this product.
Q7: Are there any C++ standardization efforts underway?
A: Yes; ANSI (American) and ISO (International) groups are working closely with
each other.
`X3J16' is the name of the ANSI-C++ committee.
`WG21' is the name of ISO's C++ standards group.
They are using the `Annotated C++ Reference Manual' (`ARM' for short) as a base
document. See below under `Books' for how to get the ARM.
The major players in the ANSI/ISO C++ standards process includes just about
everyone:
AT&T, IBM, DEC, HP, Sun, MS, Borland, Zortech, Apple, OSF, , ... and a lot of users and smaller companies. About 70 people attend
each ANSI C++ meeting. People come from USA, UK, Japan, Germany, Sweden,
Denmark, France, ... (all have `local' committees sending official
representatives and conducting `local' meetings).
Optimistically the standard might be finished by 1994 time frame (this is fast
for a proper standards process).
Q8: Where can I ftp a copy of the latest ANSI-C++ draft standard?
A: You can't. ANSI standards and/or drafts are NOT available in machine
readable form.
You can get a paper copy by sending a request to:
Standards Secretariat
CBEMA
311 First St NW, Suite 500
Washington, DC 20001
Ask for the latest version of `Working Paper for Draft Proposed American
National Standard for Information Systems -- Programming Language C++'.
Q9: Is C++ backward compatible with ANSI-C?
A: Almost. C++ is as close as possible to compatible with ANSI-C but no closer.
In practice, the major difference is that C++ requires prototypes, and that
`f()' declares a function that takes no parameters, while ANSI-C rules state
that `f()' declares a function that takes any number of parameters of any type.
There are some very subtle differences as well, like the sizeof a char literal
being equal to the sizeof a char (in ANSI-C, sizeof('x') is the sizeof an int).
Structure `tags' are in the same namespace as other names in C++, but C++ has
some warts to take care of backward compatibility here.
Q10: What books are available for C++?
A: Lots, with more just about every other week. Here are a few in no
particular order (comments are my own):
`The C++ Programming Language, second edition', Stroustrup, Addison/Wesley
A rich, in-depth intro text; covers rudiments of OOD as well as OOP
ISBN 0-201-53992-6
`A C++ Primer, 2nd edition', Lippman, Addison/Wesley
1st ed. considered std intro-C++ text; does not assume C; has some OOD
ISBN 0-201-54848-8
`Annotated C++ Reference Manual', Ellis and Stroustrup, Addison/Wesley
Heavy reading; definitely not for beginners; gives *ALL* the details.
ISBN 0-201-51459-1
`Advanced C++ Programming Styles and Idioms', Coplien, Addison-Wesley, 1992
ref-counting, wrappers, functionoids, `Self'/`Smalltalk' styles, etc
ISBN 0-201-54855-0
`A C++ Toolkit', Shapiro, Prentice Hall
Provides many small stand-alone classes; code is publically usable
ISBN 0-13-127663-8
`Mastering C++', Horstmann, Wiley
Wiley hasn't sent me one to review yet, but I hear it's great
`Teach Yourself C++', Stevens, MIS Press
An easy-to-read short book for C++ beginners
ISBN 1-558-28027-8
`A C++ Primer, first edition', Lippman, Addison/Wesley
Slightly out-of-date; solidly reference quality wrt the language proper
ISBN 0-201-16487-6
`Programming in C++', Dewhurst and Stark, Prentice Hall
How-to-use C++, shows many idioms of the language
`Using C++', Eckel, McGraw-Hill
Shows some of the ways C++ can be used as a better C; MS-DOS
`Data Abstraction and OO Programming in C++', Gorlen/Orlow/Plexico, Wiley
Describes how to use NIHCL (see question on `NIHCL')
ISBN 0-471-92346-X
`An Intro to OO Programming', Tim Budd, Addison-Wesley, 1991
Covers OOP in general; compares/contrasts several OOPLs including C++
ISBN 0-201-54709-0
`Object-Oriented Design with Applications', Grady Booch, Benjamin/Cummings,1991
Excellent 1st book on OO design; read on Classification and Abstraction
ISBN 0-8053-0091-0
`Object-Orientation: Concepts, Languages, Databases, User interfaces',
Khoshafian and Abnous, J.Wiley, 1990
ISBN 0-471-51801-8
`The Waite Group's C++ Programming', Berry
`An Introduction to Object-Oriented Programming and C++', Weiner & Pinson, A/W
`Object-Oriented Program Design with Examples in C++', Mullin, Addison-Wesley
`Hands-on C++ Programming', Isaac and Miller, Addison-Wesley
`C++ for C Programmers', Pohl, Benjamin/Cummings
`The C++ Programming Language, first edition', Stroustrup, Addison/Wesley
Out of date but a classic; get it to find out where the language `was'
ISBN 0-201-12078-X
`The C++ Answer Book', Hansen, Addison/Wesley
Answers to the exercises in Stroustrup's first ed; solid `how-to' text
ISBN 0-201-11497-6
`Turbo C++ DiskTutor', Greg Voss and Paul Chui, McGraw-Hill
ISBN 0-07-881526-6
`Object-Oriented Software Construction', Meyer, Prentice Hall
Chaps 1-4 are about OOP in general; the rest is about Eiffel language
ISBN 0-13-629049-3
Q11: How long does it take to learn C++?
A: I and others teach standard industry `short courses' (for those not familiar
with these, you pack a university semester course into one 40hr work-week), and
have found them successful. However mastery takes experience, and there's no
substitute for time. Laboratory time is essential for any OOP course, since it
allows concepts to `gel'.
Generally people start out wondering why the company has devoted a full 5 days
to something as trivial as another programming language. Then about half way
through, they realize they're not being taught just a new syntax, but an
entirely different way of thinking and programming and designing and . . . .
Then they begin to feel dumb, since they can't quite grasp what is being said.
Then they get mad and wonder why the course isn't taught in two or three weeks
instead. Finally about Wednesday afternoon the lights go `clink', and their
faces brighten, and they `get it'. By Friday, they've had numerous laboratory
`experiments' and they've seen both sides of reusable components (both how to
code *from* reuse, and how to code *for* reuse). It's different in every time
I teach, but the `reuse' aspect is generally the most rewarding, since it has
the greatest potential to improve software production's overall economics.
Full semester courses have the same overall contact hours (14wks * 3hrs/wk is
around 40hrs), but the slower rate allows students to retain more as well as to
go through more material. For example, I taught the equivalent of my `C++ as
an OOPL' course, and portions of my `OO Design Methodology' course, in a single
semester graduate course. Both courses take roughly a week when taught in the
condensed style.
It takes 6 months to `master' C++/OOP. Less if there is already a body of
experts and code that programmers have regular access to, more if there isn't a
`good' general purpose C++ class library available.