%%% ====================================================================
%%% BibTeX-file{
%%% author = "Nelson H. F. Beebe",
%%% version = "1.05",
%%% date = "23 April 1998",
%%% time = "16:58:44 MST",
%%% filename = "cppreport.bib",
%%% address = "Center for Scientific Computing
%%% University of Utah
%%% Department of Mathematics, 322 INSCC
%%% 155 S 1400 E RM 233
%%% Salt Lake City, UT 84112-0090
%%% USA",
%%% telephone = "+1 801 581 5254",
%%% FAX = "+1 801 581 4148",
%%% URL = "http://www.math.utah.edu/~beebe",
%%% checksum = "03135 8519 42421 409023",
%%% email = "beebe at math.utah.edu, beebe at acm.org,
%%% beebe at ieee.org (Internet)",
%%% codetable = "ISO/ASCII",
%%% keywords = "BibTeX, bibliography, C++ Report",
%%% supported = "yes",
%%% docstring = "This is a bibliography of publications in the
%%% magazine C++ Report (CODEN CRPTE7, ISSN
%%% 1040-6042), published by SIGS Publications.
%%%
%%% At version 1.05, the year coverage looked
%%% like this:
%%%
%%% 1991 ( 21) 1994 ( 21) 1997 ( 25)
%%% 1992 ( 34) 1995 ( 26)
%%% 1993 ( 26) 1996 ( 81)
%%%
%%% Article: 234
%%%
%%% Total entries: 234
%%%
%%% The journal has a World-Wide Web site at
%%% http://www.sigs.com/publications/docs/cppr/.
%%%
%%% This bibliography has been collected from
%%% bibliographies in the author's personal
%%% files, from the journal's Web site contents
%%% files, and from the IEEE INSPEC database
%%% (1991--1995).
%%%
%%% Numerous errors in the sources noted above
%%% have been corrected. Spelling has been
%%% verified with the UNIX spell and GNU ispell
%%% programs using the exception dictionary
%%% stored in the companion file with extension
%%% .sok.
%%%
%%% BibTeX citation tags are uniformly chosen
%%% as name:year:abbrev, where name is the
%%% family name of the first author or editor,
%%% year is a 4-digit number, and abbrev is a
%%% 3-letter condensation of important title
%%% words. Citation tags were automatically
%%% generated by software developed for the
%%% BibNet Project.
%%%
%%% In this bibliography, entries are sorted in
%%% publication order, using bibsort -byvolume.
%%%
%%% The checksum field above contains a CRC-16
%%% checksum as the first value, followed by the
%%% equivalent of the standard UNIX wc (word
%%% count) utility output of lines, words, and
%%% characters. This is produced by Robert
%%% Solovay's checksum utility.",
%%% }
%%% ====================================================================
@Preamble{"\input path.sty" #
"\hyphenation{
para-digm
para-digms
Call-eens
Dasch-bach
Thor-sten
}"}
%%----------------------------------------------------------------------
%% Acknowledgement abbreviations:
@String{ack-nhfb = "Nelson H. F. Beebe,
Center for Scientific Computing,
University of Utah,
Department of Mathematics, 322 INSCC,
155 S 1400 E RM 233,
Salt Lake City, UT 84112-0090, USA,
Tel: +1 801 581 5254,
FAX: +1 801 581 4148,
e-mail: \path|beebe@math.utah.edu|,
\path|beebe@acm.org|,
\path|beebe@ieee.org| (Internet),
URL: \path|http://www.math.utah.edu/~beebe/|"}
@String{ack-rc = "Roman Czyborra,
e-mail: \path=|czyborra@dds.nl|"}
%%----------------------------------------------------------------------
%% Journal abbreviations:
@String{j-C-PLUS-PLUS-REPORT = "C++ Report"}
%%----------------------------------------------------------------------
%% Bibliography entries:
@Article{Booch:1991:CLD,
author = "G. Booch and M. Vilot",
title = "{C++} library design",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "6",
pages = "10--14",
month = jun,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The authors examine some design issues involved in
providing class libraries in C++. Library design is a
natural consequence of object-oriented design (OOD),
where we model the key abstractions of the problem
domain. Over time, the library components become the
reuseable elements of new applications. The authors
take a look at four aspects of C++ library design: the
separation of interface from implementation;
architectures other than the Smalltalk single-tree
approach; the increasing scale of libraries; and
performance concerns and steps toward resolving them.",
acknowledgement = ack-nhfb,
classcodes = "C6110B (Software engineering techniques); C6140D (High
level languages)",
classification = "C6110B (Software engineering techniques); C6140D
(High level languages)",
keywords = "abstractions; C language; C++ library design; Class
libraries; class libraries; Design issues; design
issues; elements; Interface; interface; key; Key
abstractions; Library components; library components;
Object-oriented design; object-oriented design;
object-oriented programming; Performance concerns;
performance concerns; Problem domain; problem domain;
reusability; reuseable; Reuseable elements; Smalltalk
single-; Smalltalk single-tree approach; software;
subroutines; tree approach",
thesaurus = "C language; Object-oriented programming; Software
reusability; Subroutines",
treatment = "P Practical",
}
@Article{Horstmann:1991:FLA,
author = "C. S. Horstmann",
title = "A first look at programming {Windows} with {C++\slash
Views} and {Borland C++}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "6",
pages = "15--18, 24",
month = jun,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "A discussion is given on the author's experiences with
a C++ class library for programming under Microsoft
Windows: C++/Views Version 1.1, CNS Inc. The author
used the class library in conjunction with the Borland
C++ compiler (Version 2.0). His background makes him
the perfect guinea pig to find out whether someone who
knows C++ but essentially nothing about Windows can
become a productive Windows programmer with a toolkit
like C++/Views. He concludes that the answer is a
definite `yes'.",
acknowledgement = ack-nhfb,
affiliation = "Dept. of Math. and Comput. Sci., San Jose State Univ.,
CA, USA",
classcodes = "C6110 (Systems analysis and programming); C6140D (High
level languages); C6180 (User interfaces)",
classification = "C6110 (Systems analysis and programming); C6140D
(High level languages); C6180 (User interfaces)",
corpsource = "Dept. of Math. and Comput. Sci., San Jose State Univ.,
CA, USA",
keywords = "Borland C++; Borland C++ compiler; C language; C++
class library; C++/Views; compiler; graphical user
interfaces; Microsoft Windows; packages; programming;
software; Windows programmer",
thesaurus = "C language; Graphical user interfaces; Programming;
Software packages",
treatment = "A Application; P Practical; R Product Review",
}
@Article{Druker:1991:WCD,
author = "S. Druker",
title = "`What's that compiler doing, anyway?' --- virtual
function overhead",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "6",
pages = "19--20",
month = jun,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "A programmer's best friend in C++ is a virtual
function. This is the primary vehicle for extending a
program, library, or other package of software. With
the appropriate design in mind, a clever programmer can
design years of value into a package written today. The
author presents a view of what goes on behind the
scenes of the Zortech C++ compiler for DOS in
implementing virtual functions and pointers to member
functions. This particular scheme has several
attractive features. The space required in the objects
themselves does not grow in the presence of multiple
inheritance in the language, unless the object
concerned inherits multiply somewhere. It lends a
natural and efficient implementation for pointers to
member functions. The technique uses an old idea called
thunks to implement these things. In the examples, a
notation is used to represent conceptual ideas. This
notation looks a lot like the programming language C
even though the compiler may not go through a C
translation phase.",
acknowledgement = ack-nhfb,
classcodes = "C6150C (Compilers, interpreters and other processors);
C6140D (High level languages); C6120 (File
organisation); C6110 (Systems analysis and
programming)",
classification = "C6110 (Systems analysis and programming); C6120
(File organisation); C6140D (High level languages);
C6150C (Compilers, interpreters and other processors)",
keywords = "C language; C++; conceptual; Conceptual ideas; data
structures; DOS; ideas; Member functions; member
functions; Multiple inheritance; multiple inheritance;
Pointers; pointers; program compilers; programming;
Programming language C; programming language C; Thunks;
thunks; Virtual function; virtual function; virtual
storage; Zortech C++ compiler",
thesaurus = "C language; Data structures; Program compilers;
Programming; Virtual storage",
treatment = "P Practical",
}
@Article{Coggins:1991:WDP,
author = "J. M. Coggins",
title = "Why does this program run so long?",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "6",
pages = "21--24",
month = jun,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Conventional wisdom suggests that C++ code tends to be
somewhat slower than corresponding C code. Some real
data supports the opposite position: that C++ code can
be faster than corresponding C code. The author shows
that C++ can be competitive with C in execution speed,
but the programmer must exercise some caution in
developing elegant C++ expressions or be ready to pay
the price in performance. The trade-off between
elegance and pragmatics is a familiar one. The one
examined is a particularly dramatic instance involving
the operator+() function.",
acknowledgement = ack-nhfb,
affiliation = "Dept. of Comput. Sci., North Carolina Univ., Chapel
Hill, NC, USA",
classcodes = "C6140D (High level languages); C6110 (Systems analysis
and programming)",
classification = "C6110 (Systems analysis and programming); C6140D
(High level languages)",
corpsource = "Dept. of Comput. Sci., North Carolina Univ., Chapel
Hill, NC, USA",
keywords = "C code; C language; C++ code; elegant C++; Elegant C++
expressions; Execution speed; execution speed;
expressions; Performance; performance; Pragmatics;
pragmatics; Programmer; programmer; programming",
thesaurus = "C language; Programming",
treatment = "P Practical",
}
@Article{Steinhoff:1991:SV,
author = "D. Steinhoff",
title = "{Saber-C++} version 1.0",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "6",
pages = "26--27, 30",
month = jun,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Saber Software has been shipping Saber-C++, their new
C++ programming environment, since 1990. This
second-generation tool builds upon the obvious success
of their earlier programming environment, Saber-C. Many
of the incremental programming and dynamic debugging
techniques they brought to UNIX with that earlier
product are present and expanded. Saber-C++
incorporates class, data, and file browsing, debugging,
incremental linking and a C++ interpreter into an
integrated environment. The product includes a slightly
modified (though `bug-compatible') version of cfront
2.0. In short, this is a tool for serious programming.
Programmers limping along with dbx and dbxtool or
similar tools should sit up and take note that this is
an order of magnitude improvement over what they are
used to.",
acknowledgement = ack-nhfb,
affiliation = "Appl. Dynamic Int., Ann Arbor, MI, USA",
classcodes = "C6115 (Programming support); C6110 (Systems analysis
and programming); C6140D (High level languages)",
classification = "C6110 (Systems analysis and programming); C6115
(Programming support); C6140D (High level languages)",
corpsource = "Appl. Dynamic Int., Ann Arbor, MI, USA",
keywords = "C language; C++; C++ interpreter; C++ programming
environment; dynamic debugging; Dynamic debugging
techniques; File browsing; file browsing; Incremental
linking; incremental linking; Incremental programming;
incremental programming; Integrated environment;
integrated environment; interpreter; programming
environments; Saber-C; Saber-C++; second-generation;
Second-generation tool; software packages; techniques;
tool",
thesaurus = "C language; Programming environments; Software
packages",
treatment = "P Practical; R Product Review",
}
@Article{Booch:1991:ODC,
author = "G. Booch and M. Vilot",
title = "Object-oriented {design-C++} class categories",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "7",
pages = "6--10",
month = jul # "-" # aug,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Looks at the design issues involved in defining the
contents of class libraries. A library designer has to
make many design decisions and many C++ language
features can support these decisions. They describe
some design idioms, or styles of use, of C++ features
employed in building libraries. They discuss some kinds
of C++ classes and how they can be used in libraries or
applications. Note that none of these styles of class
design are directly enforced by the language; they are
merely design conventions. They give each of the kinds
of classes a name to encourage a consistent use of
terms among C++ library designers.",
acknowledgement = ack-nhfb,
classcodes = "C6110 (Systems analysis and programming)",
classification = "C6110 (Systems analysis and programming)",
keywords = "C language; C listings; C++ classes; C++ language; C++
language features; class design; Class design; Class
libraries; class libraries; features; object-oriented
design; Object-oriented design; object-oriented
programming",
thesaurus = "C language; C listings; Object-oriented programming",
treatment = "P Practical",
}
@Article{Eckel:1991:CIC,
author = "B. Eckel",
title = "Containers and iterators in {C++}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "7",
pages = "12--13",
month = jul # "-" # aug,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The C++ language is all about creating and using
types. One of the important features of types in C++ is
the level of safety that can be built into them. The
author discusses two concepts in object-oriented
programming that allows one to take the raw forms shown
(the array and the index) and convert them into safe,
general-purpose abstractions for all types, not just
built-in types. These abstractions are called
containers and iterators and they will make code easier
to write and more robust.",
acknowledgement = ack-nhfb,
classcodes = "C6110 (Systems analysis and programming); C6140D (High
level languages)",
classification = "C6110 (Systems analysis and programming); C6140D
(High level languages)",
keywords = "Array; array; C language; C listings; C++ language;
Containers; containers; General-purpose abstractions;
general-purpose abstractions; Index; index; Iterators;
iterators; Object-oriented programming; object-oriented
programming; Types; types",
thesaurus = "C language; C listings; Object-oriented programming",
treatment = "P Practical",
}
@Article{Lane:1991:DCA,
author = "A. Lane",
title = "{DOS\slash C++} --- application frameworks",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "7",
pages = "14--15",
month = jul # "-" # aug,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Application frameworks are object-oriented class
libraries that integrate user-interface building
blocks, fundamental data structures and support for
object-oriented input and output. Major components of
an application's interface, such as windows, pull-down
menus, dialog boxes, scroll bars and even a generic
application are modeled as classes in the hierarchy.
This gives programmers the ability to inherit a large
body of functional interface code and frees them to
concentrate on implementing specifics. The author looks
at a couple of simple examples from the forthcoming
Turbo Vision application framework.",
acknowledgement = ack-nhfb,
classcodes = "C6115 (Programming support); C6110 (Systems analysis
and programming)",
classification = "C6110 (Systems analysis and programming); C6115
(Programming support)",
keywords = "application frameworks; Application frameworks; C
language; C listings; data structures; Data structures;
dialog boxes; Dialog boxes; functional; Functional
interface code; interface code; object-oriented;
object-oriented class libraries; Object-oriented class
libraries; programming; pull-down menus; Pull-down
menus; scroll bars; Scroll bars; software tools; Turbo
Vision application framework; user interfaces;
user-interface building blocks; User-interface building
blocks; windows; Windows",
thesaurus = "C language; C listings; Data structures;
Object-oriented programming; Software tools; User
interfaces",
treatment = "P Practical",
}
@Article{Brazille:1991:OIL,
author = "R. Brazille and B. Leggett",
title = "The {Object Interface Library}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "7",
pages = "18--20, 22, 24",
month = jul # "-" # aug,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "It is well know that object-oriented design can
profitably be applied to the creation of graphical user
interfaces. The author reviews the Object Interface
Library (OI), a collection of C++ classes for the X
Window System that offers C++ objects for common X
`widgets' such as scroll bars, drop-down menus, radio
buttons, icons, text entry fields, etc. The classes are
not related to the Xt widgets in any way, although they
do emulate some of the Intrinsics' mechanism to provide
better compatibility with other X tools. The most
interesting aspect of OI is that programs developed
with it are able to switch their look and feel between
OPEN LOOK and Motif at runtime.",
acknowledgement = ack-nhfb,
classcodes = "C6115 (Programming support); C6180 (User interfaces)",
classification = "C6115 (Programming support); C6180 (User
interfaces)",
keywords = "Application development; application development;
application generators; C language; C++ classes;
Drop-down menus; drop-down menus; graphical; Graphical
user interfaces; Icons; icons; Motif; Object Interface
Library; object-oriented; Object-oriented design;
object-oriented design; OI; OPEN LOOK; programming;
Radio buttons; radio buttons; Scroll bars; scroll bars;
software tools; Text entry fields; text entry fields;
user interfaces; Window System; X; X Window System",
thesaurus = "Application generators; C language; Object-oriented
programming; Software tools",
treatment = "P Practical; R Product Review",
}
@Article{Coplien:1991:ECC,
author = "J. Coplien",
title = "Experience with {CRC} cards in {AT\&T}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "8",
pages = "1, 4--6",
month = sep,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The object paradigm is an increasingly popular way for
digital system developers to think about problem
solving. Experience has shown that the success of an
object-oriented design depends heavily on three
factors: designers' understanding of the technology,
creating a suitable project sociology and having people
with appropriate problem domain expertise. CRC cards
have been used in a number of AT and T software
projects and their use has played a role in each of
these factors. The author looks at each of these
factors in turn and the role CRC cards play to help
shape and enable an object-oriented development. A CRC
card is a 3*5 index card representing an application
abstraction. It lists the abstraction's class,
responsibilities, and collaborators. CRC cards are used
in interactive design sessions to flesh out the
identity and nature of classes when using
object-oriented analysis techniques. These cards are
filled in at meetings between key system architects,
designers, and customers. The cards become the
documentation for the initial project structure. The
cards may be transferred to a hypertext system for use
by the project at large to document system interfaces
and system functionality in general.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C0310F (Software
development management)",
classification = "C0310F (Software development management); C6110J
(Object-oriented programming)",
keywords = "Application abstraction; application abstraction; AT
and T software projects; AT\&T software;
Class-responsibility-collaboration;
class-responsibility-collaboration; CRC card;
Customers; customers; digital; Digital system
developers; Documentation; documentation; human
factors; Index card; index card; initial project;
Initial project structure; Interactive design sessions;
interactive design sessions; key; Key system
architects; Object paradigm; object paradigm;
Object-oriented design; object-oriented design;
Object-oriented development; object-oriented
development; object-oriented programming; personnel;
Problem domain expertise; problem domain expertise;
Problem solving; problem solving; project engineering;
Project sociology; project sociology; projects;
structure; system architects; system developers; system
documentation; System functionality; system
functionality; systems analysis",
thesaurus = "Human factors; Object-oriented programming; Personnel;
Project engineering; System documentation; Systems
analysis",
treatment = "A Application; P Practical",
}
@Article{Booch:1991:OAD,
author = "G. Booch and M. Vilot",
title = "Object-oriented analysis and design",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "8",
pages = "7--10",
month = sep,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "There exist various kinds of classes useful for
implementing class libraries in C++, as described by B.
Straustrup (1991). These kinds of classes are purely a
design convention: nothing in the language enforces
their `correct' definition and use. However, settling
on a few standard styles can make a given library
clearer and more understandable. Having a common
vocabulary makes it easier to discuss library designs.
The authors look at another important vocabulary-the
vocabulary of the problem domain. They discuss the
difference between analysis and design and the role of
key abstractions and mechanisms in an object-oriented
design.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6140D (High
level languages)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages)",
keywords = "abstractions; C language; C++; Class libraries; class
libraries; common; Common vocabulary; key; Key
abstractions; Library; library; Library designs;
library designs; Object-oriented design;
object-oriented design; object-oriented programming;
Problem domain; problem domain; reusability; software;
Standard styles; standard styles; vocabulary",
thesaurus = "C language; Object-oriented programming; Software
reusability",
treatment = "P Practical",
}
@Article{Cargill:1991:CCO,
author = "T. Cargill",
title = "{CRC} cards ({OO} programming)",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "8",
pages = "11--13",
month = sep,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Many newcomers to object-oriented programming have
difficulty `finding the objects', that is, finding
appropriate abstractions and capturing them as classes.
A low-tech, paper-and-pencil analysis and design
technique, known as `CRC cards', can help in the search
for the right classes. K. Beck, W. Cunningham (1989)
created CRC cards as a device for teaching
object-oriented programming and R. Wirfs-Brock et al.
(1990), have incorporated the cards into their
`responsibility-driven' design methodology. CRC stands
for class, responsibility, collaboration. The technique
focuses on identifying classes, assigning
responsibilities to classes and recording
collaborations between classes. Responsibilities are
the services that a class provides, as a server, to the
rest of a system. Collaboration is the interaction
between a client and a server-a client collaborates
with a server to obtain services. CRC cards encourage
simultaneous searches for individual classes and
interactions between classes.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C0310F (Software
development management); C6120 (File organisation)",
classification = "C0310F (Software development management); C6110J
(Object-oriented programming); C6120 (File
organisation)",
keywords = "analysis; Class; class;
Class-responsibility-collaboration;
class-responsibility-collaboration; Client; client;
Collaboration; collaboration; CRC cards; data
structures; Design methodology; design methodology;
human factors; object-oriented programming;
paper-and-pencil; Paper-and-pencil analysis;
Responsibility-driven; responsibility-driven; Server;
server; Simultaneous searches; simultaneous searches;
systems analysis; Teaching object-oriented programming;
teaching object-oriented programming",
thesaurus = "Data structures; Human factors; Object-oriented
programming; Systems analysis",
treatment = "P Practical",
}
@Article{Booch:1991:ODP,
author = "G. Booch and M. Vilot",
title = "The object-oriented development process",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "9",
pages = "8--11",
month = oct,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Considers an important aspect of getting organized and
started on a project using the object-oriented
development approach, discussing part of the software
development process model. With an appropriate choice
of tangible design artifacts and review points, we can
represent the incremental and iterative OOD process in
linear form. The authors examine some of the software
project management aspects of object-oriented design.
They discuss some tangible design artifacts and review
points we can use to make the design process more
visible from a project planning perspective. They find
this helps fit a round-trip gestalt design approach
into management systems accustomed to a more linear
perspective.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C0310F (Software
development management)",
classification = "C0310F (Software development management); C6110J
(Object-oriented programming)",
keywords = "analysis; Gestalt design approach; gestalt design
approach; Linear form; linear form; Management systems;
management systems; model; object-; Object-oriented
design; Object-oriented development; object-oriented
development; object-oriented programming; OOD; oriented
design; software development process; Software
development process model; software engineering;
Software project management; software project
management; systems",
thesaurus = "Object-oriented programming; Software engineering;
Systems analysis",
treatment = "P Practical",
}
@Article{Huneke:1991:LCC,
author = "I. Huneke",
title = "Linking {C} with {C++}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "9",
pages = "12, 16",
month = oct,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "When developing applications in C++, the need
sometimes arises to call C++ functions from sections of
C code. This article suggests a method for providing
such linkage. The basic facility has been tried out
with Release 2.1 of cfront and with Zortech C++, so it
should be portable across all compilers.",
acknowledgement = ack-nhfb,
classcodes = "C6110 (Systems analysis and programming)",
classification = "C6110 (Systems analysis and programming)",
keywords = "C code; C language; C listings; C++; Cfront Release
2.1, software portability; cfront Release 2.1, software
portability; Compilers; compilers; object-oriented;
Object-oriented programming; object-oriented
programming; programming; software portability; Zortech
C++",
thesaurus = "C language; C listings; Object-oriented programming;
Software portability",
treatment = "P Practical",
}
@Article{VanWyk:1991:SEY,
author = "C. J. {Van Wyk}",
title = "Simultaneous equations are your friends",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "9",
pages = "14--16",
month = oct,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Discusses how one can build a class library that
allows C++ programmers to express simultaneous
equations directly in their code. The author considers
nonlinear equations and complex numbers.",
acknowledgement = ack-nhfb,
classcodes = "C6110 (Systems analysis and programming); C7310
(Mathematics)",
classification = "C6110 (Systems analysis and programming); C7310
(Mathematics)",
keywords = "C language; C listings; C++; Class library; class
library; complex numbers; Complex numbers; equations;
mathematics computing; nonlinear; Nonlinear equations;
simultaneous equations; Simultaneous equations",
thesaurus = "C language; C listings; Equations; Mathematics
computing",
treatment = "P Practical",
}
@Article{Coggins:1991:NCC,
author = "J. M. Coggins",
title = "Naming conventions in {C++} libraries",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "9",
pages = "17--21",
month = oct,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Follows a few threads of a long conservation about
naming conventions for C++, especially conventions that
could become part of any standard libraries
accompanying an ANSI/ISO standard C++ language. The
author's suggestions is that, in spite of being almost
impossible to agree on, naming conventions need to be
agreed upon in order to have standardized software and
that the exact names chosen for standard libraries and
classes are important to their reusability.",
acknowledgement = ack-nhfb,
classcodes = "C6110 (Systems analysis and programming)",
classification = "C6110 (Systems analysis and programming)",
keywords = "ANSI/ISO standard; ANSI/ISO standard C++ language; C
language; C listings; C++ language; Naming conventions;
naming conventions; Software reusability; software
reusability; Standardized software; standardized
software",
thesaurus = "C language; C listings; Software reusability",
treatment = "P Practical",
}
@Article{LeJacq:1991:ECY,
author = "J. P. LeJacq",
title = "Education can you do better than {C++}?",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "10",
pages = "1, 4--6",
month = nov # "-" # dec,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Once an organization has made the decision to migrate
to C++, the obvious question arises of how to get from
here to there. The answer entails decisions regarding
languages, compilers, libraries and organization
changes. Certainly one of the most significant factors
is educating the current development team in
object-oriented technology. This article summarizes the
author's experience teaching general object-oriented
design courses and C++-specific courses in industrial
settings. He presents what seems to be an effective
approach and flags some potential problems.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C0220 (Education
and training)",
classification = "C0220 (Education and training); C6110J
(Object-oriented programming)",
keywords = "C language; C++; Compilers; compilers; computer
science education; Libraries; libraries;
object-oriented; Object-oriented design courses;
object-oriented design courses; Object-oriented
technology; object-oriented technology; programming;
Teaching; teaching; training",
thesaurus = "C language; Computer science education;
Object-oriented programming; Training",
treatment = "P Practical",
}
@Article{Booch:1991:ODD,
author = "G. Booch and M. Vilot",
title = "Object-oriented design documents",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "10",
pages = "8, 10--12",
month = nov # "-" # dec,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Describes a possible documentation structure for a
project using object-oriented design. These documents
can be used to make the structure and status of the
development process more visible to the project team.
Of course, each project will have its own
considerations for recording design descriptions.
Project team and size and tolerance for documentation
are particularly influential when structuring design
documents.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming)",
classification = "C6110J (Object-oriented programming)",
keywords = "analysis; Documentation structure; documentation
structure; Object-oriented design documents;
object-oriented design documents; object-oriented
programming; process; Project team size; project team
size; software development; Software development
process; software engineering; systems",
thesaurus = "Object-oriented programming; Software engineering;
Systems analysis",
treatment = "P Practical",
}
@Article{Saks:1991:ACU,
author = "D. Saks",
title = "{ANSI C++} update: works in progress",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "10",
pages = "13--14, 16",
month = nov # "-" # dec,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The ANSI C++ Standards Committee X3J16 meets only
three times a year. Much of the Committee's work is
done between these meetings by small working groups
that clarify and evaluate issues and make proposals for
action by the entire committee. The active working
groups are C Compatibility, Core Language,
Environments, Extensions, Libraries, and Syntax. The
author discusses the work of these groups.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming)",
classification = "C6110J (Object-oriented programming)",
keywords = "ANSI; ANSI C++ Standards Committee; C Compatibility; C
environments; C extensions; C language; C libraries; C
syntax; C++ Standards Committee; Core Language;
object-oriented programming; standards",
thesaurus = "C language; Object-oriented programming; Standards",
treatment = "P Practical",
}
@Article{Horstmann:1991:ILB,
author = "C. Horstmann",
title = "An in-depth look as {Borland C++}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "10",
pages = "17--20",
month = nov # "-" # dec,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The Borland C++ compiler is a product with many
components and features. The author looks at some of
the more interesting ones in greater detail. He
considers the support for 80*86 modes, compiler quirks,
the debugger, precompiled headers, VROOM overlay link
technique, online help and documentation, amongst other
features.",
acknowledgement = ack-nhfb,
classcodes = "C6150C (Compilers, interpreters and other processors);
C6110J (Object-oriented programming)",
classification = "C6110J (Object-oriented programming); C6150C
(Compilers, interpreters and other processors)",
keywords = "80*86 Modes; 80*86 modes; Borland C++ compiler; C
language; Debugger; debugger; Documentation;
documentation; headers; object-oriented programming;
Online help; online help; Overlay link technique;
overlay link technique; precompiled; Precompiled
headers; program compilers; program debugging; software
packages",
thesaurus = "C language; Object-oriented programming; Program
compilers; Program debugging; Software packages",
treatment = "P Practical; R Product Review",
}
@Article{Coggins:1991:BCA,
author = "J. M. Coggins",
title = "Best of {\path|comp.lang.C++|} --- much ado about
null",
journal = j-C-PLUS-PLUS-REPORT,
volume = "3",
number = "10",
pages = "21--24",
month = nov # "-" # dec,
year = "1991",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Examines the different ways to represent Nothing in
C++. This is worthy of discussion because the
representation of Nothing must have a type. This
question eventually reaches into areas such as
automatic type conversion rules interactions of
preprocessor symbols with the type system,
compatibility problems among C++ implementations,
standardization concerns, and the interaction of
classes with basic types.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming)",
classification = "C6110J (Object-oriented programming)",
keywords = "Automatic type conversion rules; automatic type
conversion rules; C language; C listings; C++;
object-oriented programming; Standardization;
standardization",
thesaurus = "C language; C listings; Object-oriented programming",
treatment = "P Practical",
}
@Article{Soukup:1992:SCL,
author = "J. Soukup",
title = "Selecting a {C++} library",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "1",
pages = "1, 4--6",
month = jan,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "There is a major difference in both the construction
and use of libraries in C and C++. Unless special tools
are available, it is difficult to code a general
library in C for structures such as linked lists,
trees, graphs, or hash tables. However, in C++, whole
organizations can be treated as objects, which helps in
library design and simplifies its use. The availability
of such a library speeds up development, improves code
quality, and greatly enhances the maintainability of
the software. This paper concentrates mainly on
general-purpose libraries that manage basic data
structures such as linked lists, trees, graphs, or
entity-relationship models. These organizations
typically combine several different object types
connected by pointers. It lists the good and bad things
for which one has to watch when selecting a library. It
also suggests a benchmark that measures both ease of
use and library performance.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C0310H
(Equipment and software evaluation methods)",
classification = "C0310H (Equipment and software evaluation methods);
C6110J (Object-oriented programming)",
keywords = "Benchmark; benchmark; C language; C++; C++ library;
Code quality; code quality; Data structures; data
structures; Entity-relationship models;
entity-relationship models; Graphs; graphs; library;
Linked lists; linked lists; maintenance; Object types;
object types; Object-oriented programming;
object-oriented programming; Pointers; pointers;
software; Software maintenance; software maintenance;
software selection; Trees; trees",
thesaurus = "C language; Object-oriented programming; Software
maintenance; Software selection",
treatment = "P Practical",
}
@Article{Booch:1992:ODP,
author = "G. Booch and M. Vilot",
title = "Object-oriented design: physical design: storage
management",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "1",
pages = "7--10",
month = jan,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Considers the design of storage management for the
objects in designs. In OOD, the authors separate the
logical view of the classes and objects in the design
from the physical view of how they are packaged and
allocated. C++ allows us to precisely control the
storage management details when necessary. They
concentrate on one facet of physical design. Storage
management is an issue that faces most C++ developers.
One can use the features of C++ to provide convenient
access to the necessary details.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming)",
classification = "C6110J (Object-oriented programming)",
keywords = "C++; Classes; classes; management; Object-oriented
design; object-oriented design; Object-oriented
programming; object-oriented programming; Objects;
objects; storage; Storage management; systems
analysis",
thesaurus = "Object-oriented programming; Systems analysis",
treatment = "P Practical",
}
@Article{Saks:1992:ACU,
author = "D. Saks",
title = "{ANSI C++} update: works in progress",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "1",
pages = "11--14",
month = jan,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The ANSI C++ standards committee, X3J16, held its
sixth meeting in Lund, Sweden during June 1991. By
careful prior arrangement, the meeting coincided with
the first meeting for the ISO C++ working group, WG21.
The committees met both separately and in joint
session. Although much of the meeting time was spent
deciding how it would be best for the committees to
work together, there was still time for productive
technical discussion and a few significant decisions.
The author discusses the development of an
international standard and European representation for
C++.",
acknowledgement = ack-nhfb,
classcodes = "C6140D (High level languages)",
classification = "C6140D (High level languages)",
keywords = "ANSI C++ standards committee; C language; C listings;
ISO C++ working group; standards",
thesaurus = "C language; C listings; Standards",
treatment = "P Practical",
}
@Article{Horstmann:1992:OCL,
author = "C. Horstmann",
title = "The object-based class library in {Borland C++}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "1",
pages = "15--18",
month = jan,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Borland C++ Version 3.0 includes two class libraries,
principally implementing containers. The first one, the
so-called object-based library, is discussed. It has
been supplied with Borland C++ Version 2.0 and slightly
enhanced in the newest release. The second library is
new to Borland C++ 3.0 and is template based. Both
libraries are included in the professional version of
the compiler. All objects in the object-based library
are derived from an abstract base class Object. The
containers are heterogeneous and can hold any
collection of instances of classes derived from Object.
This setup is commonly known as the Smalltalk approach
and is used in many C++ class libraries. To test how
easy it is to use the library, the author modified a
project from a C++ training course: a simulation of
customers entering a bank and being serviced by an
array of tellers. This simulation program has a queue
holding customers, an array holding tellers, and a
priority queue holding events sorted by a time stamp.
Thus, there are naturally three containers in this
program.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming)",
classification = "C6110J (Object-oriented programming)",
keywords = "Abstract base class; abstract base class; approach;
Array; array; Borland C++ Version 3.0; C language; C
listings; Compiler; compiler; Containers; containers;
Events; events; Object-based class library;
object-based class library; object-oriented
programming; Priority queue; priority queue; Queue;
queue; Simulation; simulation; Smalltalk; Smalltalk
approach; Sorted; sorted; Time stamp; time stamp",
thesaurus = "C language; C listings; Object-oriented programming",
treatment = "P Practical",
}
@Article{Coggins:1992:HFC,
author = "J. M. Coggins",
title = "Handling failed constructors gracefully",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "1",
pages = "20--22",
month = jan,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "A constructor is a member function that is invoked
when an object is created. Its objective is to
initialize the new object to a valid state before any
processing occurs using the object. Some very useful
classes involve creating linkages with the external
environment-files, network connections, user
interfaces, processing accelerators-and the
construction of the object depends on certain states or
properties existing in that external environment. For
example, when we create a file object for reading, we
require the file name to exist. The author discusses
what happens if something goes wrong during
construction C++.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6140D (High
level languages)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages)",
keywords = "C language; C listings; C++; Classes; classes;
Constructor; constructor; File name; file name; File
object; file object; Object; object; Object-oriented
programming; object-oriented programming",
thesaurus = "C language; C listings; Object-oriented programming",
treatment = "P Practical",
}
@Article{McCluskey:1992:ETI,
author = "G. McCluskey",
title = "An environment for template instantiation",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "2",
pages = "1, 4--7",
month = feb,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The parametrized type or template feature has been
part of C++ for several years. Implementations of the
feature have started to appear in C++ compilers. An
interesting issue is how to handle what is known as
instantiation, the combining of a template with
arguments. The author reviews template basics, briefly
presents existing methods of instantiation, and then
describes the approach taken by one implementation (the
UNIX Systems Laboratories 3.0 compiler) to solve the
instantiation problem. What is described is an
environment for C++ compilation rather than part of the
language itself. Environment implementations are not
subject to standardization the way the language is and,
therefore, vendors are free to make different
implementation choices.",
acknowledgement = ack-nhfb,
classcodes = "C6140D (High level languages); C6150C (Compilers,
interpreters and other processors); C6120 (File
organisation)",
classification = "C6120 (File organisation); C6140D (High level
languages); C6150C (Compilers, interpreters and other
processors)",
keywords = "C language; C++ compilation; C++ compilers; data
structures; Parametrized type; parametrized type;
program compilers; Template feature; template feature;
Template instantiation; template instantiation; UNIX
Systems Laboratories; Vendors; vendors",
thesaurus = "C language; Data structures; Program compilers",
treatment = "P Practical",
}
@Article{Booch:1992:PDS,
author = "G. Booch and M. Vilot",
title = "Physical design: storage and management libraries
({OOP})",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "2",
pages = "8--10",
month = feb,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "An examination is given of C++ storage management
design issues. The authors examine some common designs
for optimizing storage management performance and how
the variety of storage options influences the design of
class libraries. Library design is an interesting case.
The design of storage management in a library must
operate efficiently in the face of unpredictable usage
patterns and a variety of usage contexts. As B.
Stroustrup (1991) observes, `Designing a general
library is much harder than designing an ordinary
program. A program is a solution to a particular
problem in a particular context, but a library must be
the solution to a set of problems encountered in a
number of projects. An ordinary program can make strong
assumptions about its environment, but a good library
has to operate successfully in the contexts provided by
a number of programs'.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6140D (High
level languages); C6120 (File organisation)",
classification = "C6110J (Object-oriented programming); C6120 (File
organisation); C6140D (High level languages)",
keywords = "C language; C++ storage management design issues;
Class libraries; class libraries; general; General
library; library; management performance;
object-oriented programming; OOP; storage; storage
management; Storage management performance; Storage
options; storage options; subroutines; Unpredictable
usage patterns; unpredictable usage patterns; Usage
contexts; usage contexts",
thesaurus = "C language; Object-oriented programming; Storage
management; Subroutines",
treatment = "P Practical",
}
@Article{Soukup:1992:MD,
author = "J. Soukup",
title = "Memory-resident databases",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "2",
pages = "11--15",
month = feb,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "A discussion is given on the use of memory-resident
databases developed in object-oriented C++. The method
was originally used by CAD designers for VLSI data. The
main concept is the use of memory-resident data which
is treated as a database. Two examples are given to
demonstrate the method: connectivity record for an
electric circuit and music collection catalogue. The
author explains how to implement such a database and
presents benchmarks to show performance.",
acknowledgement = ack-nhfb,
classcodes = "C6160 (Database management systems (DBMS)); C6140D
(High level languages); C6120 (File organisation);
C7410D (Electronic engineering); C7820 (Humanities)",
classification = "C6120 (File organisation); C6140D (High level
languages); C6160 (Database management systems (DBMS));
C7410D (Electronic engineering); C7820 (Humanities)",
keywords = "Benchmarks; benchmarks; C language; CAD; CAD
designers; circuit CAD; connectivity; Connectivity
record; database management systems; designers;
Electric circuit; electric circuit; Memory-resident
data; memory-resident data; Memory-resident databases;
memory-resident databases; music; Music collection
catalogue; music collection catalogue; Object-oriented
C++; object-oriented C++; record; storage management;
VLSI data",
thesaurus = "C language; Circuit CAD; Database management systems;
Music; Storage management",
treatment = "P Practical",
}
@Article{Skelly:1992:GHN,
author = "C. Skelly",
title = "Getting a handle on the new-handler",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "2",
pages = "16--18",
month = feb,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "A problem in moving from a C development environment
to a C++ environment is that C++ constructors don't
return anything. How can we know whether a constructor
has succeeded or failed if constructors never return an
indicating value? Is there a way to determine if the
memory allocation has occurred successfully despite the
silence of tight-lipped C++ constructors? In fact, such
a method does exist. It is built into the language to
handle just such an exigency. A predefined function
pointer, called the -new-handler, can be set by users
to point to a user-defined routine, which will be
executed if ever the new operator should have the
temerity or ill fortune to fail. This user-defined
routine can perform any action it pleases, including
setting an error flag, attempting to recover memory,
exiting, aborting, or, in state-of-the-art C++
environments, throwing an exception. In fact, the
-new-handler is a built-in exception handler packaged
for ease of use.",
acknowledgement = ack-nhfb,
classcodes = "C6140D (High level languages); C6110J (Object-oriented
programming); C6120 (File organisation); C6150J
(Operating systems)",
classification = "C6110J (Object-oriented programming); C6120 (File
organisation); C6140D (High level languages); C6150J
(Operating systems)",
keywords = "C development environment; C language; C++; C++
constructors; C++ environment; constructors; data
structures; Error flag; error flag; Exception;
exception; Exception handler; exception handler; Memory
allocation; memory allocation; object-oriented
programming; pointer; predefined function; Predefined
function pointer; storage allocation; User-defined
routine; user-defined routine",
thesaurus = "C language; Data structures; Object-oriented
programming; Storage allocation",
treatment = "P Practical",
}
@Article{Coggins:1992:AQA,
author = "J. M. Coggins",
title = "An array of questions about arrays",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "2",
pages = "19--22",
month = feb,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Arrays of objects in C++ raise important issues for
language designers and users alike. The issues include
how to initialize the array elements, how to ensure
that the array is properly deallocated, how to return
an array as the result of a function, how to pass
arrays as arguments without copying the array, how to
make sure that an array passed as an argument will not
be changed by the called procedure, how to define
operator=() for a class containing an array, and so on.
Several of these issues have arisen in net
conversation, and a few of them are summarized.",
acknowledgement = ack-nhfb,
affiliation = "Dept. of Comput. Sci., North Carolina Univ., Chapel
Hill, NC, USA",
classcodes = "C6140D (High level languages); C6110J (Object-oriented
programming); C6120 (File organisation)",
classification = "C6110J (Object-oriented programming); C6120 (File
organisation); C6140D (High level languages)",
corpsource = "Dept. of Comput. Sci., North Carolina Univ., Chapel
Hill, NC, USA",
keywords = "Arguments; arguments; Array elements; array elements;
C language; data structures; Deallocated; deallocated;
Function; function; Language designers; language
designers; object-oriented programming; Users; users",
thesaurus = "C language; Data structures; Object-oriented
programming",
treatment = "P Practical",
}
@Article{Hamsath:1992:ZCD,
author = "N. Hamsath",
title = "{Zortech C++ Developers Edition}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "2",
pages = "23--25",
month = feb,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The Developers Edition of Zortech's product, as
reviewed, is an upgrade of the first PC-based AT and T
V2.0 compliant C++ compiler. It requires an IBM PC, XT,
AT, 3/486, or compatible computer, MS-DOS/PC-DOS v3.0
or above, and at least 640 Kb of RAM. As installed, the
total size of the eight-disk DOS version with all
options is about 18 Mb. The disks are in archive form
and can be installed as a unit or installed separately,
as needed. Also, the disks can be read in any order.
Although it does not take long to reload files (if
necessary after the first installation) from the disk,
it is still a chore. Zortech C++V3.0el (ztc) is a C++
and a C compiler (source-level compatible with
Microsoft) with a completely integrated development
environment that supports almost any monitor.",
acknowledgement = ack-nhfb,
affiliation = "Nat. Inst. of Health, Bethesda, MD, USA",
classcodes = "C6150C (Compilers, interpreters and other processors);
C6140D (High level languages)",
classification = "C6140D (High level languages); C6150C (Compilers,
interpreters and other processors)",
corpsource = "Nat. Inst. of Health, Bethesda, MD, USA",
keywords = "640 Kbytes; C compiler; C language; C++ compiler;
Developers Edition; DOS/PC-DOS; IBM computers; IBM PC;
Integrated development environment; integrated
development environment; microcomputer applications;
Microsoft; MS-; MS-DOS/PC-DOS; PC-based AT and T;
PC-based AT\&T; program compilers; software packages;
Source-level compatible; source-level compatible",
numericalindex = "Memory size 6.6E+05 Byte",
thesaurus = "C language; IBM computers; Microcomputer applications;
Program compilers; Software packages",
treatment = "P Practical; R Product Review",
}
@Article{Stroustrup:1992:RTI,
author = "B. Stroustrup and D. Lenkov",
title = "Runtime type identification for {C++}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "3",
pages = "32--42",
month = mar # "-" # apr,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "A proposal is described for a mechanism for runtime
type identification and checked type casts, which is
simple to use, easy to implement, and extensible. This
proposal evolved through a series of earlier proposals
and ideas, and experimental implementations exist.
However this proposal and the features described may
never be accepted into C++.",
acknowledgement = ack-nhfb,
classcodes = "C6140D (High level languages); C6120 (File
organisation)",
classification = "C6120 (File organisation); C6140D (High level
languages)",
keywords = "C language; C++; Checked type casts; checked type
casts; data structures; Experimental implementations;
experimental implementations; Runtime type
identification; runtime type identification",
thesaurus = "C language; Data structures",
treatment = "P Practical",
}
@Article{Dewhurst:1992:DAI,
author = "S. C. Dewhurst",
title = "Distributed abstract interfaces",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "3",
pages = "44--50",
month = mar # "-" # apr,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "In C++, an abstract data type (ADT) and its class
implementation are often viewed as equivalent. This is
a useful simplification for many ADTs in those cases
where the abstract operations of the type can be
represented cleanly in the public (or public and
protected) regions of a single class declaration.
However, not all ADTs are so simple. The author shows
why it is often convenient to distribute the abstract
interface of an ADT among a set of C++ classes. The
usual one-to-one mapping of ADT to class can be viewed
as a degenerate form of this more general case. The
discussion is motivated largely by the problems
associated with performing (abstract) traversals of
ADTs that have (abstract) structure. An extended
discussion of the techniques of control abstraction is
given.",
acknowledgement = ack-nhfb,
classcodes = "C6140D (High level languages); C6110J (Object-oriented
programming); C6120 (File organisation)",
classification = "C6110J (Object-oriented programming); C6120 (File
organisation); C6140D (High level languages)",
keywords = "Abstract data type; abstract data type; Abstract
operations; abstract operations; abstraction; ADT; C
language; C++ classes; class; Class implementation;
control; Control abstraction; data structures;
declaration; Distributed abstract interfaces;
distributed abstract interfaces; implementation;
object-oriented programming; One-to-one mapping;
one-to-one mapping; single class; Single class
declaration",
thesaurus = "C language; Data structures; Object-oriented
programming",
treatment = "P Practical",
}
@Article{Musser:1992:ESC,
author = "J. Musser",
title = "Extending streambufs: class logstrbuf ({OOP})",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "3",
pages = "51--55",
month = mar # "-" # apr,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "It is often desirable to encapsulate a set of existing
operating system services in an object-oriented fashion
to streamline their use within an application. C++
provides the necessary tools for developers, including
those not involved in creating operating systems, to
encapsulate and possibly extend a variety of operating
system services. A solid foundation for many such
services is provided by the iostream library. The
author describes the design of the logstrbuf class,
which was developed to encapsulate the Berkeley Unix
syslog facility. This class is derived from streambuf,
the underlying buffering layer of the iostreams
library. The techniques used can similarly be applied
to other I/O and IPC operations, including sockets,
shared memory, window system IPC and the like. This
example shows how the streambuf class can be used to
achieve powerful results when applied to specific
problem domains.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6140D (High
level languages); C6120 (File organisation); C6150J
(Operating systems)",
classification = "C6110J (Object-oriented programming); C6120 (File
organisation); C6140D (High level languages); C6150J
(Operating systems)",
keywords = "Berkeley Unix syslog; Berkeley Unix syslog facility; C
language; C++; data structures; facility; I/O;
input-output programs; Iostream library; iostream
library; IPC; IPC operations; Logstrbuf class;
logstrbuf class; object-; Object-oriented fashion;
object-oriented fashion; Operating system services;
operating system services; operations; oriented
programming; Shared memory; shared memory; Sockets;
sockets; Streambuf; streambuf; Underlying buffering
layer; underlying buffering layer; Window system IPC;
window system IPC",
thesaurus = "C language; Data structures; Input-output programs;
Object-oriented programming",
treatment = "P Practical",
}
@Article{Buroff:1992:CO,
author = "S. Buroff and R. Murray",
title = "The {C++} Oracle",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "4",
pages = "9--10",
month = may,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The authors are concerned with the following
questions: If they use a template class and only call
for a few of its member functions, are all member
functions instantiated or only those they call? The
first thing to understand about this question is that
its answer is not part of the definition of C++.
Instead, this is left as a quality of implementation
issue. A C++ compiler is free to instantiate all member
functions or only those referenced without being in
violation of the standard. They term the instantiation
of only the referenced member functions selective
instantiation.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6140D (High
level languages)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages)",
keywords = "C language; C listings; C++; Compiler; compiler;
functions; member; Member functions; Object-oriented
programming; object-oriented programming; Selective
instantiation; selective instantiation; Template class;
template class",
thesaurus = "C language; C listings; Object-oriented programming",
treatment = "P Practical",
}
@Article{Eckel:1992:VC,
author = "B. Eckel",
title = "Virtual constructors. 2",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "4",
pages = "13--16",
month = may,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "For pt.1, see ibid., vol.4, no.3, p.13-18 (1992). This
paper concludes the presentation of the concept of
virtual constructors. It talks about destructors and
virtual destructor operation when using virtual
constructors and then goes on to discuss code
formatting.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6140D (High
level languages)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages)",
keywords = "C language; C listings; C++ language; Code formatting;
code formatting; constructors; Destructors;
destructors; Object-oriented programming;
object-oriented programming; virtual; Virtual
constructors; Virtual destructor operation; virtual
destructor operation",
thesaurus = "C language; C listings; Object-oriented programming",
treatment = "P Practical",
}
@Article{Booch:1992:LDS,
author = "G. Booch and M. Vilot",
title = "Logical design: software component libraries",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "4",
pages = "18, 20--22",
month = may,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Considers some of the issues in designing a library of
reusable software components. Such libraries can be
used to help improve productivity in software
development by providing prefabricated, pretested
parts. One can build applications by assembling and
customizing these elements, rather than redeveloping
them for each application. When one models the key
abstractions of a problem domain, the resulting classes
tend to be reusable across the set of applications
built for that domain. One could organize these classes
into a library of reusable components. Existing C++
libraries each focus on specific domains.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6110B (Software
engineering techniques)",
classification = "C6110B (Software engineering techniques); C6110J
(Object-oriented programming)",
keywords = "C language; C++; Key abstractions; key abstractions;
Object-oriented design; object-oriented design;
object-oriented programming; reusability; Reusable
software; reusable software; software; Software
component libraries; software component libraries;
Software development; software development",
thesaurus = "C language; Object-oriented programming; Software
reusability",
treatment = "P Practical",
}
@Article{Skelly:1992:LO,
author = "C. Skelly",
title = "In the land of {OOP}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "4",
pages = "23--26",
month = may,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The author begins an ongoing adventure into some of
the wilder forest regions, along some of the lesser
known paths, that run through the land of
object-oriented programming and C++. He imagines a
generic situation in which a datastream, composed of
packets of information, is being received by a
processing component of some sort. One option for
handling such a stream in C++ is to instantiate a
`handling object' for every data packet received.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming)",
classification = "C6110J (Object-oriented programming)",
keywords = "C language; C++; Data packet; data packet;
Object-oriented programming; object-oriented
programming",
thesaurus = "C language; Object-oriented programming",
treatment = "P Practical",
}
@Article{Soukup:1992:BTC,
author = "J. Soukup",
title = "Beyond templates. 1. ({C++})",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "4",
pages = "27--31",
month = may,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The good news is that C++ compilers are beginning to
support templates. The bad news is that templates do
not do what they were invented for very well. The main
purpose of templates is to provide a mechanism for
building general data structures such as linked lists,
trees, and graphs without giving up the protection of
full static typing. Data structures involve pointer
relations between different types of objects and are,
in the realm of object-oriented programming, often
referred to as associations and aggregations. The
author looks at the following approaches to building
data structures: templates and indirect links;
templates combined with multiple inheritance; templates
inheritance, and a code generator; and class generator
only. He particularly covers the first approach in this
issue. He stretches the use of templates to its limits
and uses new ideas and nonstandard approaches.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6150C
(Compilers, interpreters and other processors)",
classification = "C6110J (Object-oriented programming); C6150C
(Compilers, interpreters and other processors)",
keywords = "Aggregations; aggregations; Associations;
associations; C language; C++ compilers; Class
generator; class generator; Code generator; code
generator; Data structures; data structures; Full
static typing; full static typing; Graphs; graphs;
indirect; Indirect links; Inheritance; inheritance;
Linked lists; linked lists; links; object-;
Object-oriented programming; object-oriented
programming; oriented programming; Pointer relations;
pointer relations; program compilers; Templates;
templates; Trees; trees",
thesaurus = "C language; Data structures; Object-oriented
programming; Program compilers",
treatment = "P Practical",
}
@Article{Horstmann:1992:MCC,
author = "G. Horstmann",
title = "The {Microsoft C\slash C++ Version 7} compiler: {A}
first impression",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "4",
pages = "53--57",
month = may,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The author discusses the Microsoft C/C++ Version 7
compiler. In terms of sales, Borland is clearly the
biggest player in this market. The Microsoft press kit
contains a large number of feature comparisons with
Borland, without mentioning any other vendors at all.
He discusses some of the Microsoft sales arguments, as
well as some other comparisons that the Microsoft
marketing staff wisely omitted from the press kit.",
acknowledgement = ack-nhfb,
classcodes = "C6150C (Compilers, interpreters and other
processors)",
classification = "C6150C (Compilers, interpreters and other
processors)",
keywords = "Borland; C language; Compiler; compiler; Marketing;
marketing; Microsoft C/C++ Version 7; program
compilers",
thesaurus = "C language; Program compilers",
treatment = "P Practical; R Product Review",
}
@Article{Coggins:1992:QCW,
author = "J. M. Coggins",
title = "Questioning conventional `wisdom' about {C++} code
size and execution speed",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "4",
pages = "58--61",
month = may,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Object-oriented design and programming affect how
people think about computer programming and how people
think through computer programming problems.
Eventually, however, it is necessary to get down to
pragmatic concerns such as lines of code and speed of
program development and execution. This column surveys
a few of the more enlightening network postings
concerned with evaluations of the pragmatics of C++.
Such evaluations cannot be conducted effectively
without care for definitions of terms and experimental
controls that is rarely exercised in informal
conversations on the network. First, it considers the
pragmatic concern of source program length.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6140D (High
level languages)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages)",
keywords = "C language; C++; C++ code size; code size; Execution
speed; execution speed; Object-oriented design;
object-oriented design; Object-oriented programming;
object-oriented programming; Program development;
program development",
thesaurus = "C language; Object-oriented programming",
treatment = "P Practical",
}
@Article{Wilkinson:1992:SCO,
author = "N. M. Wilkinson",
title = "Subtleties of {C++} operator overloading",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "5",
pages = "36--41",
month = jun,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "In C++, a programmer uses the class construct to
create data types that mimic, to a great extent, the
look and behavior of built-in types. As with a built-in
type, the representation of the class can be hidden
from the user and accessed only through operations
defined on the type. Also, the construction and
destruction of objects of the user-defined data type
are handled automatically. Conversions, which are often
invisibly applied, can be defined by the class to and
from other types. Additionally, the C++ class author
may define functions for the class that represent
operators to be applied to that type. Many C++ users
think that these forms are equivalent, but they are
not. And the subtlety of the difference can take an
unsuspecting programmer by surprise. This article
examines a number of the subtle points in declaring and
using overloaded operators in C++. These points will
also illustrate exactly what the compiler will do, and
will not do, to resolve an operator expression.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6140D (High
level languages); C6150C (Compilers, interpreters and
other processors)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages); C6150C (Compilers, interpreters and
other processors)",
keywords = "built-in; Built-in types; C language; C++; Compiler;
compiler; Data types; data types; Object-oriented
programming; object-oriented programming; Overloaded
operators; overloaded operators; program compilers;
types",
thesaurus = "C language; Object-oriented programming; Program
compilers",
treatment = "P Practical",
}
@Article{Strickland:1992:ODD,
author = "H. Strickland",
title = "Object databases: a deep look at transparency",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "5",
pages = "42--46",
month = jun,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "When some people speak of transparency, they mean
`surface transparency', or `automaticness'. Surface
transparency measures how well something automatically
happens when compiled, unaltered, by a certain product,
or how much you have to do to make something
automatically happen. As a start, surface transparency
is a good measure and a respectable goal, and it may
help to get a demo running in a weekend. For a serious
software development project, deeper measures of
transparency are far more important. This article will
point out some of the issues that need to be addressed
in evaluating `deep transparency'. It presents some
sample interfaces to discuss transparency with
examples. These examples will address several important
concepts that object databases bring to C++. Three of
these are extended object lifetime, expanded object
identity, and automatic maintenance bidirectional
(inverse) relationships.",
acknowledgement = ack-nhfb,
classcodes = "C6160J (Object-oriented databases); C6110J
(Object-oriented programming)",
classification = "C6110J (Object-oriented programming); C6160J
(Object-oriented databases)",
keywords = "Automatic maintenance bidirectional relationships;
automatic maintenance bidirectional relationships; C
language; C++; expanded; Expanded object identity;
Extended object lifetime; extended object lifetime;
Interfaces; interfaces; Object databases; object
databases; object identity; object-oriented;
object-oriented databases; programming; Software
development project; software development project;
Transparency; transparency",
thesaurus = "C language; Object-oriented databases; Object-oriented
programming",
treatment = "P Practical",
}
@Article{Cargill:1992:DVH,
author = "T. Cargill",
title = "A dynamic vector is harder than it looks",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "5",
pages = "47--50",
month = jun,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "There is a subtle bug in the vector template in Glen
McCluskey's article on template instantiation that
should be brought to the attention of programmers who
are considering building a similar class template, see
ibid., vol.4, no.2, p.1-7 (1992). The bug arises from
dangling references, which may appear in a variety of
circumstances. Exactly which expressions in client code
will produce dangling references depends upon the order
of expression evaluation, which, in general, is not
well defined.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming)",
classification = "C6110J (Object-oriented programming)",
keywords = "C language; C++; Dangling references; dangling
references; Dynamic vector; dynamic vector;
instantiation; object-oriented programming; programming
theory; template; Template instantiation; Vector
template; vector template",
thesaurus = "C language; Object-oriented programming; Programming
theory",
treatment = "P Practical",
}
@Article{Leggett:1992:UCS,
author = "B. Leggett",
title = "The {USL C++} Standard Components release 2 (end
user package)",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "5",
pages = "69--73",
month = jun,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Release 2 of the UNIX System Laboratories (USL),
Standard Components (SC) is the end product in a
continuing development of C++ class libraries that has
been going on inside AT and T Bell Labs and USL for
several years. These classes have evolved with the C++
language and its capabilities. They present a robust,
well-tested set of collection, array, and string
classes that are useful in almost any C++ program or
application of any complexity.",
acknowledgement = ack-nhfb,
classcodes = "C6110J (Object-oriented programming); C6140D (High
level languages)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages)",
keywords = "Array classes; array classes; AT and T Bell Labs;
AT\&T Bell Labs; C language; C++ class; C++ class
libraries; Collection classes; collection classes; End
user package; end user package; libraries;
object-oriented programming; software tools; Standard
Components release 2; String classes; string classes;
UNIX System Laboratories",
thesaurus = "C language; Object-oriented programming; Software
tools",
treatment = "P Practical; R Product Review",
}
@Article{Meyers:1992:UCE,
author = "S. Meyers",
title = "Using {C++} effectively. Approaches to effectiveness",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "6",
pages = "34--39",
month = jul # "-" # aug,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "As the community of C++ programmers matures, there is
a natural shift from interest in what the language
features are to how to effectively use them. Guidelines
for class interfaces serve as useful starting points
for discussion, but they are hampered by the rich
variety of settings in which C++ is employed.
Constraint-checking programs modeled on lint offer the
advantage of automated detection of constraint
violations, but still suffer from the difficulty in
coming up with constraints that are universally
applicable. Natural language guidelines such as those
found in EFFECTIVE C++ are a good way to initiate C++
programmers into the subtleties of the language, but
such guidelines are rarely amenable to automatic
enforcement. Finally, a constraint language like CCEL
vastly expands the expressiveness and flexibility of an
automatic constraint-checking program, but it cannot
overcome the fact that many useful heuristics for C++
software development are impossible to formalize. The
search for better ways to summarize how to use C++
effectively will continue, of course, but for the
foreseeable future, the best approach is a combination
of informal guidelines with well-defined areas of
applicability, increasingly sophisticated automated
tools, and the insights that can only be gleaned from
bitter experience.",
acknowledgement = ack-nhfb,
affiliation = "Dept. of Comput. Sci., Brown Univ., Providence, RI,
USA",
classcodes = "C6140D (High level languages)",
classification = "C6140D (High level languages)",
corpsource = "Dept. of Comput. Sci., Brown Univ., Providence, RI,
USA",
keywords = "Automated tools; automated tools; C language; C++;
CCEL; class; Class interfaces; Constraint checking
programs; constraint checking programs; Constraint
language; constraint language; Constraint violations;
constraint violations; Expressiveness; expressiveness;
interfaces; Programmers; programmers",
thesaurus = "C language",
treatment = "P Practical",
}
@Article{Tavakkolian:1992:CPP,
author = "S. Tavakkolian",
title = "Crossing paradigms. {A} pilgrim's journey from {C} to
{C++}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "6",
pages = "40--45",
month = jul # "-" # aug,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Changing from C and procedural programming to C++ and
object-oriented (O-O) programming can be a hard
proposition. The author looks at the problem, it is not
just a matter of learning rules for spelling and
syntax, it is learning a completely new way of
expressing thoughts.",
acknowledgement = ack-nhfb,
affiliation = "Claircom, Seattle, WA, USA",
classcodes = "C6110J (Object-oriented programming); C6140D (High
level languages)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages)",
corpsource = "Claircom, Seattle, WA, USA",
keywords = "C; C language; C++; object-oriented programming; OO
programming; Procedural programming; procedural
programming",
thesaurus = "C language; Object-oriented programming",
treatment = "P Practical",
}
@Article{Martin:1992:ACP,
author = "R. Martin",
title = "Abstract classes and pure virtual functions",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "6",
pages = "46--52",
month = jul # "-" # aug,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "Abstract classes provide a powerful design technique
which promotes code reuse and polymorphism. Abstract
classes are produced by factoring out the common
features of the concrete classes of the application.
Although such factorings are sometimes hard to find,
the effort put into finding them is usually well worth
the benefits of the extra maintainability and
reusability. In general, common features should be
factored out and moved as high as possible in the
inheritance structure. In C++, pure virtual functions
are used to specify the pure interfaces of abstract
classes. An abstract class in C++ must have at least
one pure virtual function. Although pure virtual
functions typically have no implementation, C++ allows
implementations to be given to them. The user must take
care not to invoke pure virtual functions in the
constructors or destructors of an abstract class.",
acknowledgement = ack-nhfb,
classcodes = "C6140D (High level languages); C6110J (Object-oriented
programming)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages)",
keywords = "Abstract classes; abstract classes; C language; C++;
Maintainability; maintainability; object-oriented
programming; Pure virtual functions; pure virtual
functions; Reusability; reusability",
thesaurus = "C language; Object-oriented programming",
treatment = "P Practical",
}
@Article{Ball:1992:ITI,
author = "M. Ball",
title = "Inside templates: implementing {C++} strategies",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "7",
pages = "36--40",
month = sep,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The authors outline the framework of their mythical
C++ compiler. They then consider some embellishments
that can be added and describe the construction of
token streams. The token stream is a good example of a
tool that can be used in several (sometimes unexpected)
places in a C++ compiler. In fact, the entire token
stream mechanism was developed for use in parsing, and
has proved to have further application when
implementing inline functions, class definitions and
now, templates. It's also a good example of code that
developed from an ad hoc technique for handling a
difficult problem (parser lookahead and backtracking)
into a clean and powerful technique with general
applicability.",
acknowledgement = ack-nhfb,
classcodes = "C6150C (Compilers, interpreters and other processors);
C6140D (High level languages); C6110J (Object-oriented
programming)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages); C6150C (Compilers, interpreters and
other processors)",
keywords = "Ad hoc technique; ad hoc technique; Backtracking;
backtracking; C language; C++ compiler; Class
definitions; class definitions; functions; inline;
Inline functions; lookahead; object-oriented
programming; parser; Parser lookahead; Parsing;
parsing; program compilers; program processors;
Templates; templates; Token stream; token stream",
thesaurus = "C language; Object-oriented programming; Program
compilers; Program processors",
treatment = "P Practical",
}
@Article{Becker:1992:MCS,
author = "P. Becker",
title = "A msgstream class for smart formatting: Easing the
translator's job",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "7",
pages = "42--48",
month = sep,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The author briefly summarizes the problems that come
up during translation of program into a different
national language, and describes a variation of the
class ostream that solves one of the biggest ones. The
author discusses text translation, collating sequences;
character sets; and string lengths. He introduces the
msgstream class and the msgbuf class. He provides a C
listing for msgbuf. National language support must be
designed into programs. Put all your text strings into
resources or at least a separate source file. Use
strcoll(), not strcmp(). Use wide chars. Don't
hard-code buffer sizes, and be sure that all buffers
are big enough to allow for growth during translation.
Use flexible formatting techniques. In short, think
about the problems of translating the program for use
with a different language before starting to write the
code. This will make the translator's job much
easier.",
acknowledgement = ack-nhfb,
classcodes = "C6110 (Systems analysis and programming); C6110J
(Object-oriented programming)",
classification = "C6110 (Systems analysis and programming); C6110J
(Object-oriented programming)",
keywords = "C listing; C listings; Character sets; character sets;
collating; Collating sequences; data structures;
flexible; Flexible formatting techniques; formatting
techniques; input-output programs; National language;
national language; object-; oriented programming;
Ostream; ostream; programming; sequences; Strcmp();
strcmp(); Strcoll(); strcoll(); String lengths; string
lengths; strings; system documentation; text; Text
strings; Text translation; text translation; Wide
chars; wide chars",
thesaurus = "C listings; Data structures; Input-output programs;
Object-oriented programming; Programming; System
documentation",
treatment = "P Practical",
}
@Article{Bartels:1992:POO,
author = "D. Bartels and J. Robie",
title = "Persistent objects and object-oriented databases for
{C++}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "7",
pages = "49--50, 52--56",
month = sep,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "To store data in a conventional database, it must be
dissected into a series of two-dimensional tables. Only
predeclared data types are supported. Object-oriented
programming languages have a rich set of features for
creating data types and representing the relationships
among data that are not supported in such databases.
The authors discuss features that an object-oriented
database must support. To illustrate these features we
examine POET, a commercial object-oriented database
system with which the authors are connected.",
acknowledgement = ack-nhfb,
classcodes = "C6160J (Object-oriented databases); C6120 (File
organisation)C6110J (Object-oriented programming)",
classification = "C6110J (Object-oriented programming); C6120 (File
organisation); C6160J (Object-oriented databases)",
keywords = "C language; C listings; Data types; data types;
Object-oriented database; object-oriented database;
object-oriented databases; POET",
thesaurus = "C language; C listings; Object-oriented databases",
treatment = "P Practical",
}
@Article{Carroll:1992:IIM,
author = "M. Carroll",
title = "Invasive inheritance: modifying a base class to enable
inheritance",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "8",
pages = "34--42",
month = oct,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The author calls the act of modifying the intended
base class, then inheriting from it invasive
inheritance. He shows an example of invasive
inheritance in C++. The intended base class represents
the set of binary search trees; the intended derived
class represents the set of red-black trees. A
red-black tree IS-A binary search tree. He shows a
typical implementation of a binary search tree class.
Then he shows that attempting to derive a red-black
tree class from the binary search tree class fails, and
what invasions into the base class one must make to
permit the derivation to work. The invasive inheritance
problem is not unique to C++. He explains what
properties programming languages in general have that
cause the need for such an invasion. Most of the causes
of invasive inheritance could theoretically be removed
from programming languages, but only at the cost of
introducing other problems.",
acknowledgement = ack-nhfb,
affiliation = "AT and T Bell Labs., Murray Hill, NJ, USA",
classcodes = "C6140D (High level languages); C6110J (Object-oriented
programming)",
classification = "C6110J (Object-oriented programming); C6140D (High
level languages)",
corpsource = "AT\&T Bell Labs., Murray Hill, NJ, USA",
keywords = "Binary search tree; binary search tree; C language;
C++; Inheritance; inheritance; Intended base class;
intended base class; Invasive inheritance; invasive
inheritance; object-oriented programming; Red-black
trees; red-black trees",
thesaurus = "C language; Object-oriented programming",
treatment = "P Practical",
}
@Article{Banahan:1992:CTM,
author = "M. Banahan",
title = "Cross-over training: making the transition from {C} to
{C++}",
journal = j-C-PLUS-PLUS-REPORT,
volume = "4",
number = "8",
pages = "44--48",
month = oct,
year = "1992",
CODEN = "CRPTE7",
ISSN = "1040-6042",
bibdate = "Tue Mar 25 13:34:48 MST 1997",
abstract = "The author has been teaching C programmers to make the
transition to C++ for nearly seven years. Mere