Back to index
I have steered away from using templates and nested classes despite there being a few places where normal c++ practice would mandate their use. This is to avoid problems with compilers that lack or poorly implement these features.
I've tried to finish the protocols of all the classes and include skeleton methods. Look for the string NOT YET IMPLEMENTED in comments.
internal classes are prefixed by OOF_
external classes are prefixed by db
static members start with an 's' followed by an uppercase letter
all other members start with an 'm' followed by an uppercase letter
constants start with 'k' followed by an uppercase letter
local variables start with a lowercase word
parameters in header files are only named where the name adds to the readability
eg: dbQuery(dbQuery&) - not needed in copy constructor
dbfieldSeg(dbField&, unsigned int len) - len is needed
public functions start with a lowercase letter, private & protected functions start with an Uppercase
User database CONVENTIONS
dbField members start with an uppercase letter, eg dbChar LastName;
Where a dynamically allocated member is "owned" by a class, meaning the class is responsible for it's allocation & deallocation, the member has
// owned
next to its declaration.
There are rare cases where a method transfers ownership of a member, or exposes a pointer. The names of these methods will have "adopt" or "expose" in them, or in a comment next to the name (eg: an operator char*).
There are a lot of pointer members in OOFILE which are purely references to related classes. Marking relevant pointers with //owned makes it easy to see which ones should be cleaned up in destructors.
This section tries to summarise some of the c++ techniques I've used. I urge you to purchase "Effective C++" (see Resources at end) but the following may help if you are fairly new to C++ and a little confused by some of OOFILE's code.
In any library for general re-use, globals have the potential to cause conflicts and "pollute the namespace". They also suffer from uncontrolled access - anyone can fiddle with them. I use Static Class Members instead, which are global variables belonging to a specific class (eg: dbConnect::currentlyConstructing). They have to be explicitly qualified by the class name and you can restrict who has access using either Friend Classes or Friend Functions.
OOFILE_Dictionary and OOFILE_DictRep form a pair, where the outer class forwards nearly all its function to the inner (except for iteration).
This allows multiple copies of OOFILE_Dictionary to point to a single copy of the actual data, in OOFILE_DictRep, at the cost of some extra forwarding logic. Note that any copy constructors or assignments that create a new OOFILE_Dictionary must update the reference count of the DictRep.
The forwarding is not as onerous as it may appear - use of inlines reduces it to little more than one pointer derefence over the normal use of virtual object.
I've overloaded operator[] (the array index) in three ways for the OOFILE_Dictionary. Notice that I've provided both unsigned int and signed int, as well as the named access.
There is a minor problem in providing a native unsigned int, without a signed int version, in that the literal constant 0 is typed as a signed int. By the c++ conversion rules, the literal constant 0 is one trivial conversion away from either a null pointer to char, or an unsigned int.
Thus, the ambiguity cannot be resolved. Providing an operator[] with a signed int (inlined for performance), gives an operator that can be called with no trivial conversions. Being a slightly better choice, therefore the compiler is happy that literal 0 will invoke the [signed int] version.
I've made OOFILE_DictRep a "lazy" array in that the default constructor doesn't declare any space and there is no requirement for users of the class to explicitly tell it to expand. If you look into the operator[] you'll notice it performs a range check and does an expansion. The expansion provides a null pointer in the target cell, so use of an out of range value on the rhs is legal and detectable:
myField = mFields[outOfRangeIndex];
if (myField)...
My recommended technique, validated by several others, is to start with Meyers' "Effective C++" and refer back to a primer or the ARM when you don't understand something. This forces you to confront the most jarring and dangerous c++ issues early and helps prevent learning bad habits. As in learning any new language, it helps immensely to be working on a realistic project.
Gamma, Helm, Johnson & Vlissides, "Design Patterns" ISBN 0-201-63361-2
The infamous "Gang of Four" book. The patterns movement is the latest, best hope for getting some engineering into Software Engineering by documenting portions of designs in a usable format. EVERBODY should read this book!
Lakoff, "Women, Fire and Dangerous Things" ISBN 0-226-46804-6
Subtitled - What Categories Reveal about the Mind - it is a slightly academic work on cognitive models, attacking the "objectivist" viewpoint and providing firm evidence that we categorize things in different ways. The implications for OO designers are serious - this book helps explain why sometimes we can't find the "right" objects, or why people differ in their choice of objects.
Meyers, "Effective C++" ISBN 0-201-56364-9
very readable, full of simple recipes for adapting from C to c++ or avoiding common mistakes in c++. I think any serious c++ programmer should be capable of understanding this book.
ARM - Ellis & Stroustrup, "The Annotated C++ Reference Manual" ISBN 0-201-51459-1
(My copy has April 1994 revision date inside the cover). *the* reference manual that describes every quirk of the language - the sort of thing you must quote if you want to pick an argument with compiler writers
Lippman, "C++ Primer 2nd ed." ISBN 0-201-54848-8
A rather long-winded primer. If you like succint explanations avoid this and just buy the ARM, but have a look in at it the bookstore first. It's a very good introductory book and worth dropping back to if you find the others heavy going.
Coplien, "Advanced C++ Programming Styles and Idioms" ISBN 0-201-54855-0
You need to be very competent in c++ to understand this book but it presents some interesting techniques, particularly if you're into more dynamic designs that normally associated with c++. I found it a great thought-provoker while designing the framework.
Barton & Nackman, "Scientific & Engineering C++" ISBN 0-201-53393-6
The examples are definitely SciEng oriented but the descriptions of advanced c++ techniques are superb, more readable than Coplien and well-illustrated with diagrams. The emphasis on templates is probably due to the difference between Coplien as a 1992 book and this in 1994. A great starting point for ex FORTRAN and C programmers.
Spuler, "C++ and C Debugging, Testing and Reliability" ISBN 0-13-308172-9
A successor to Koenig's "C Traps and Pitfalls" this book combines a list and set of debugging resources with a very clear list of common c++ errors. Some overlap with Meyers' 50 rules occurs, but generally the errors listed are lower level simple bugs.
Teale, "C++ IOStreams Handbook" ISBN 0-201-59641-5
The only detailed and clear explanation of IOStreams that I've seen or seen mentioned. The book documents the older AT&T streams library so there have been a few minor changes but it is still largely applicable and makes a clear case for moving to streams.
"Taligent's Guide to Designing Programs" ISBN 0-201-40888-0
an internal style guide that grew. Very good advice on structuring libraries to minimize impact of change
Robert Martin, "Designing Object-Oriented C++ Applications Using the Booch Method" ISBN 0-13-203837-4
A great book that teaches OOA & OOD by example, including the thought processes, backtracking and refinement of real examples. It discusses the trade-offs in c++ designs and includes metrics for design quality.
Walden & Nerson, "Seamless Object-Oriented Software Architecture" ISBN 0-13-031303-3
Describes the BON method, which grew out of attempts to formalise Eiffel into a design language. BON offers hope for complex and large projects with compression of diagrams without loss of readability. The visual notation is paralleled by a textual form. Martin's book rescues the Booch method from some of the smoke-and-mirrors that goes into identifying objects, but BON has different approaches that are worth investigating.
Cattell (ed) "The Object Database Standard: ODMG-93" ISBN 1-55860-302-6
Clearly written standards document (amazing!). Interesting to note how much OOFILE resembles their ideas for the "future" c++ binding - this is entirely parallel evolution of ideas (comfortingly).
Loomis, "Object Databases The Essentials" ISBN 0-201-56341-X
Great overview of products and forces in the development of ODBMS technology to the current state (publication date is 1995). The book covers a lot of issues succintly.
"Designing Visual Interfaces", Kevin Mullet and Darrell Sano ISBN 0-13-303389-9
This is a BEAUTIFUL little book which "approaches interface design from the perspective of communication-oriented graphic design, industrial design, and architecture."
It is full of examples of good and bad interface, discussion of layout (including grids). eg: the 10 pages on grids has 9 illustrations including 4 screen shots.
The book includes screens and discussions of standards from Mac, MS Windows, Open Look and Motif. Nobody is spared bouquets or brickbats.
This is now my number-one "must buy" for anyone in interface design. It is so clearly written you can use it to explain almost any point of discussion that comes up in trying to explain why a design is good/bad.
The Comp.Object FAQ is a fantastic compilation of Object oriented development references, definitions and product information. It is available as described below, and regularly posted to the comp.object news group:
Version: 1.0.8
Date: 2/Jun/95
Author:
Bob Hathaway
Geodesic Systems, Inc.
Cyberdyne Systems Corporation
rjh@geodesic.com
Anonymous FTP Sites and Hypertext Server:
anonymous@zaphod.uchicago.edu:/pub/CompObj6.faq(.Z) (128.135.72.61)
anonymous@rtfm.mit.edu:/pub/usenet/comp.object/*_Part_*
http://cui_www.unige.ch/OSG/FAQ/OO-FAQ/index.htm
Mail Server: (See also section 1.24)
mail mail-server@rtfm.mit.edu
Subject:
send usenet/comp.object/*
Zaphod is preferred over rtfm for anonymous ftp retrieval, as it provides a single file. Rtfm contains the FAQ as posted.
The c++ FAQ is specific to c++ although it obviously includes some OOP theory questions. Read it before you ask beginner's questions in comp.lang.c++.
AUTHOR: Marshall P. Cline, Ph.D.
Paradigm Shift, Inc.
One Park St. / Norwood, NY 13668
voice: 315-353-6100
fax: 315-353-6110
email: cline@parashift.com
AVAILABILITY: This is available via anonymous ftp
from: sun.soe.clarkson.edu [128.153.12.3]
in the file: pub/c++/FAQ
URL: ftp://sun.soe.clarkson.edu/pub/c++/FAQ
and posted regularly in comp.lang.c++
Back to index