(original) (raw)

%%% -*-BibTeX-*- %%% ==================================================================== %%% BibTeX-file{ %%% author = "Nelson H. F. Beebe", %%% version = "1.06", %%% date = "19 September 2010", %%% time = "10:40:45 MDT", %%% filename = "cppreport.bib", %%% address = "University of Utah %%% Department of Mathematics, 110 LCB %%% 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 = "32588 8519 42420 409034", %%% email = "beebe at math.utah.edu, beebe at acm.org, %%% beebe at computer.org (Internet)", %%% codetable = "ISO/ASCII", %%% keywords = "BibTeX, bibliography, C++ Report", %%% license = "public domain", %%% 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, University of Utah, Department of Mathematics, 110 LCB, 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@computer.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. Merely teaching syntax is not enough. Doing so leaves students knowing how, but not why. Managers are often unhappy at the end of the process because nobody told them that they were changing to a very different style of programming, let alone to a language that is at least as complex as Ada. The article describes ways found to produce happiness in the first group, while allaying fears of the second (to some extent).", acknowledgement = ack-nhfb, classcodes = "C0220 (Education and training); C6110J (Object-oriented programming); C6140D (High level languages)", classification = "C0220 (Education and training); C6110J (Object-oriented programming); C6140D (High level languages)", keywords = "C language; computer science education; object-oriented; programming; Training; training", thesaurus = "C language; Computer science education; Object-oriented programming; Training", treatment = "A Application; P Practical", } @Article{Schmidt:1992:SPC, author = "D. Schmidt", title = "Systems programming with {C++} wrappers: encapsulating {IPC} services with object-oriented interfaces", journal = j-C-PLUS-PLUS-REPORT, volume = "4", number = "8", pages = "50--54", month = oct, year = "1992", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The article describes a technique for encapsulating existing operating system interprocess communication (IPC) services within object-oriented C++ wrappers. These services include mechanisms for local IPC (such as shared memory; semaphores; message queues; memory-mapped files; named, unnamed, and stream pipes; and BSD UNIX-domain sockets) and network IPC (such as remote procedure calls (RPC), BSD Internet-domain sockets, and System V Transport Layer Interface (TLI)).", acknowledgement = ack-nhfb, classcodes = "C6150N (Distributed systems); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6150N (Distributed systems)", keywords = "BSD; BSD Internet-domain sockets; BSD UNIX-domain sockets; C++ wrappers; Interface; interprocess communication; IPC services; Local IPC; local IPC; memory; Memory-mapped files; memory-mapped files; Message queues; message queues; Network IPC; network IPC; network operating systems; Object-oriented interfaces; object-oriented interfaces; object-oriented programming; operating system; Operating system interprocess communication; Remote procedure calls; remote procedure calls; Semaphores; semaphores; shared; Shared memory; System V Transport Layer; System V Transport Layer Interface; Unix; UNIX-domain sockets", thesaurus = "Network operating systems; Object-oriented programming; Unix", treatment = "P Practical", } @Article{Meyers:1993:UCE, author = "S. Meyers", title = "Using {C++} effectively. Examining development tools", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "1", pages = "30, 32--35", month = jan, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Discusses some questions you might want to direct at vendors of debuggers, class browsers, and development environments. Choosing effective tools for C++ software development is not as easy as it should be, although the situation is substantially better than it was. Arm yourself with as much information about your programming needs as you possibly can, because until high-quality tools for C++ development become widely available on all platforms, the best advice remains unchanged from that of centuries ago: caveat emptor (let the buyer beware).", acknowledgement = ack-nhfb, affiliation = "Dept. of Comput. Sci., Brown Univ., Providence, RI, USA", classcodes = "C6115 (Programming support); C0310H (Equipment and software evaluation methods); C6150G (Diagnostic, testing, debugging and evaluating systems); C6110J (Object-oriented programming)", classification = "C0310H (Equipment and software evaluation methods); C6110J (Object-oriented programming); C6115 (Programming support); C6150G (Diagnostic, testing, debugging and evaluating systems)", corpsource = "Dept. of Comput. Sci., Brown Univ., Providence, RI, USA", keywords = "browsers; C language; C++ software development tool selection; class; Class browsers; Debuggers; debuggers; Development environments; development environments; object-oriented languages; program debugging; programming environments; Programming needs; programming needs; software selection; software tools", thesaurus = "C language; Object-oriented languages; Program debugging; Programming environments; Software selection; Software tools", treatment = "P Practical", } @Article{Reed:1993:ETC, author = "D. Reed", title = "Engineering the transition to {C++}: a manager's perspective on realizing the benefits of {OOP}", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "1", pages = "36, 38--42", month = jan, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Managing the transition from C to C++ necessitates good engineering. As with any engineering task, the trade-offs must be understood and evaluated. This article provides a realistic view of the trade-offs associated with moving to C++ and object-oriented programming (OOP). Moving to the language is definitely a good idea, and it can be done incrementally. If the incremental approach is taken, the benefits are received incrementally as well.", acknowledgement = ack-nhfb, classcodes = "C0310F (Software development management); C6140D (High level languages); C6110J (Object-oriented programming)", classification = "C0310F (Software development management); C6110J (Object-oriented programming); C6140D (High level languages)", keywords = "C language; C++; DP management; Incremental approach; incremental approach; Language migration; language migration; Manager's perspective; manager's perspective; object-; object-oriented languages; Object-oriented programming; object-oriented programming; oriented programming; Trade-offs; trade-offs", thesaurus = "C language; DP management; Object-oriented languages; Object-oriented programming", treatment = "P Practical", } @Article{Vines:1993:SRT, author = "D. Vines and Z. Kishimoto", title = "{Smalltalk}'s runtime type support for {C++}", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "1", pages = "44--52", month = jan, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The Object Management Group (OMG) is establishing specifications for a common framework for integrating distributed applications using an object technology approach. One of these specifications is the Common Object Request Broker Architecture (CORBA). It defines the mechanisms required to transparently apply requests to objects and receive responses over a network. These mechanisms are implemented by an object request broker (ORB) and enable different applications running on different machine to `inter-operate' with each other. All of ORB's functions require access to type information at runtime. To support these features, runtime type information needs to include: type of object, methods of type, inheritance of types, identity of object and type, and instances of type. Smalltalk supports all these features as part of the language system, except for the passing of objects across address spaces. Therefore, instead of developing a new method, the authors decided to emulate Smalltalk typing with C++ and to do it in such a way as not to require any changes to the language itself or existing compilers.", acknowledgement = ack-nhfb, affiliation = "NEC C and C Software Technol. Center, Irvine, TX, USA", classcodes = "C6140D (High level languages); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6140D (High level languages)", corpsource = "NEC C and C Software Technol. Center, Irvine, TX, USA", keywords = "abstract data types; Architecture; C language; C++; Common Object Request Broker; Common Object Request Broker Architecture; CORBA; Interoperating applications; interoperating applications; Network; network; Object Management Group; Runtime type support; runtime type support; Smalltalk", thesaurus = "Abstract data types; C language; Smalltalk", treatment = "P Practical", } @Article{Coggins:1993:PPL, author = "J. M. Coggins", title = "Practical principles for library design. {I}. Selecting the right abstractions is the key", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "2", pages = "38--42", month = feb, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Image processing and analysis presents several design and programming challenges that exercise the nuances of both object-oriented design and C++. The article is the first in a series that discusses how these challenges have been addressed in IGLOO, the authors object-oriented image and graphics research library, which is written in C++. The article describes the design principles underlying IGLOO and explains some important trade-offs in tuning IGLOO for its application domain and user community.", acknowledgement = ack-nhfb, affiliation = "North Carolina Univ., Chapel Hill, NC, USA", classcodes = "C6110J (Object-oriented programming); C6140D (High level languages)", classification = "C6110J (Object-oriented programming); C6140D (High level languages)", corpsource = "North Carolina Univ., Chapel Hill, NC, USA", keywords = "C language; C++; computer graphics; IGLOO; image processing; object-; Object-oriented design; object-oriented design; oriented programming; software reusability; subroutines", thesaurus = "C language; Computer graphics; Image processing; Object-oriented programming; Software reusability; Subroutines", treatment = "P Practical", } @Article{Schmidt:1993:EOS, author = "D. C. Schmidt", title = "Encapsulating operating system {IPC}s. An object-oriented interface for event-driven {UNIX I/O} multiplexing", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "2", pages = "43--50", month = feb, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "For previous part see ibid. vol.4, no.8, p.50-4, 1992. The article describes a technique for encapsulating existing operating system (OS) interprocess communication (IPC) services within object-oriented (O-O) C++ wrappers. It presents an O-O wrapper for the I/O multiplexing facilities provided by the BSD select() and System V UNIX poll() system calls. Multiplexing is particularly useful for event-driven network servers that perform I/O on many connections simultaneously. The article describes a distributed logging facility that motivates the need for efficient I/O multiplexing, examines several alternative solution approaches, evaluates the advantages and disadvantages of these approaches, and compares them with the Reactor. Reactor is an extensible O-O class library written in C++ to provide a higher-level programming abstraction that simplifies the design and implementation of event-driven network applications.", acknowledgement = ack-nhfb, affiliation = "California Univ., Irvine, CA, USA", classcodes = "C6150N (Distributed systems); C6110J (Object-oriented programming); C6155 (Computer communications software)", classification = "C6110J (Object-oriented programming); C6150N (Distributed systems); C6155 (Computer communications software)", corpsource = "California Univ., Irvine, CA, USA", keywords = "BSD select(); computer communications software; data encapsulation; Distributed logging facility; distributed logging facility; event-driven network; Event-driven network servers; event-driven UNIX I/O; Event-driven UNIX I/O multiplexing; Higher-level programming abstraction; higher-level programming abstraction; input-; Interprocess communication; interprocess communication; multiplexing; network operating systems; O-O class library; Object-oriented interface; object-oriented interface; object-oriented programming; output programs; servers; System calls; system calls; System V UNIX poll(); Unix", thesaurus = "Computer communications software; Data encapsulation; Input-output programs; Multiplexing; Network operating systems; Object-oriented programming; Unix", treatment = "P Practical", } @Article{Becker:1993:IPR, author = "P. Becker", title = "Iterators, portability, and reuse", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "2", pages = "51--54", month = feb, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "One very common programming task is to perform some operation on each element in a set of objects. The set of objects may be a group of files, and the operation may be displaying the name of each of the files. This task shares a common structure with other such tasks, namely iteration over a set of elements. The author explores that common structure, illustrate how it can be encapsulated in several different forms of iterators, and how those iterators help improve portability and reusability of code. The author begins with a simple iterator that runs into serious problems when he tries to reuse it. By separating the underlying concept of iteration from the particular application, he creates an explicit iterator that is much more reusable. By encapsulating the bookkeeping involved in performing the iteration, he comes up with a callback iterator. And by replacing the function pointer in the callback iterator with a virtual function, he creates an inherited iterator that is much safer to use than the callback iterator.", acknowledgement = ack-nhfb, classcodes = "C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming)", keywords = "Bookkeeping; bookkeeping; C listings; Callback iterator; callback iterator; Encapsulating; encapsulating; Function pointer; function pointer; Inherited iterator; inherited iterator; object-oriented programming; Portability; portability; Reusability; reusability; software; software reusability; Virtual function; virtual function", thesaurus = "C listings; Object-oriented programming; Software portability; Software reusability", treatment = "P Practical", } @Article{Atwood:1993:GPC, author = "W. Atwood and A. Breakstone and D. Britton and T. Burnett and D. Myers and G. Word", title = "The {GISMO} project ({C++})", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "3", pages = "38--43", month = mar # "--" # apr, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The GISMO (Graphical Interface for Simulation and Monte Carlo with Objects) project began as a prototype to test the applicability of object-oriented techniques to detector simulation and event reconstruction. It was written using the Objective-C language with a graphical user interface (GUI) designed using the NeXT Interface Builder. GISMO will serve both as a tool to design new generations of high energy physics detectors and as a tool with which present-day detectors may be more easily understood.", acknowledgement = ack-nhfb, affiliation = "SLAC, Stanford Univ., CA, USA", classcodes = "C7320 (Physics and Chemistry); C6180G (Graphical user interfaces); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6180G (Graphical user interfaces); C7320 (Physics and Chemistry)", corpsource = "SLAC, Stanford Univ., CA, USA", keywords = "C language; C++; CAD; Detector simulation; detector simulation; Event reconstruction; event reconstruction; GISMO; Graphical user interface; graphical user interface; graphical user interfaces; High energy physics detectors; high energy physics detectors; Interface Builder; language; Monte Carlo; NeXT; object-oriented; Object-oriented techniques; object-oriented techniques; Objective-C; Objective-C language; physics computing; programming; simulation", thesaurus = "C language; CAD; Graphical user interfaces; Object-oriented programming; Physics computing; Simulation", treatment = "A Application; P Practical", } @Article{Sakkinen:1993:HSV, author = "M. Sakkinen", title = "How should virtual bases be initialized (and finalized)?", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "3", pages = "44--50", month = mar # "--" # apr, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The author argues that fork-join inheritance should not be able to break the integrity of the base class subobject: two paths should either share the same subobject or have completely disjoint subobjects. Multiple inheritance (MI) in C++ appeared to work like this, in contrast to many other object-oriented languages. He discusses some more subtle problems caused by the C++ approach including problems with virtual bases and requirements for initialization.", acknowledgement = ack-nhfb, affiliation = "Jyvaskyla Univ., Finland", classcodes = "C6110J (Object-oriented programming); C6140D (High level languages)", classification = "C6110J (Object-oriented programming); C6140D (High level languages)", corpsource = "Jyvaskyla Univ., Finland", keywords = "C language; C++; fork-join; Fork-join inheritance; inheritance; Initialization; initialization; Object oriented programming; object oriented programming; object-; Object-oriented languages; object-oriented languages; oriented programming; Virtual bases; virtual bases", thesaurus = "C language; Inheritance; Object-oriented languages; Object-oriented programming", treatment = "P Practical", } @Article{Dewhurst:1993:SM, author = "S. C. Dewhurst", title = "Subobject members", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "3", pages = "51--53", month = mar # "--" # apr, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "How does a base class differ from a member? This article examines some techniques that allows one to employ members as the functional equivalent of base classes, to simplify an implementation, change a synthetic relationship into a natural one, or to allow source code to be tailored without altering abstract type relationships or modifying the C++ source code.", acknowledgement = ack-nhfb, classcodes = "C6110J (Object-oriented programming); C6140D (High level languages)", classification = "C6110J (Object-oriented programming); C6140D (High level languages)", keywords = "Abstract type relationships; abstract type relationships; Base class; base class; C language; C++; Members; members; object-oriented; object-oriented languages; programming", thesaurus = "C language; Object-oriented languages; Object-oriented programming", treatment = "P Practical", } @Article{Webster:1993:CE, author = "J. Webster and F. Douglas", title = "{C++} is everywhere", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "4", pages = "36--39", month = may, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The authors evaluate the state of C++ applications. How far has the language come since the definitions of object-oriented terms and concepts were introduced into the professional journals \ldots{} since C++ was introduced as a leading-edge research tool for scientific applications? Current applications range from complex network control to the simplest screen presentations, and include everything from satellites, rockets, submarines, robots, stock market options and accounts payable line items. The language has come a long way in the past five years, and they have asked users at all ends of the spectrum-developers, programmers end users-for their experiences in using C++.", acknowledgement = ack-nhfb, classcodes = "C6140D (High level languages); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6140D (High level languages)", keywords = "accounts payable; Accounts payable line items; C language; C++ applications; complex network; Complex network control; control; line items; object-oriented languages; Object-oriented terms; object-oriented terms; Robots; robots; Rockets; rockets; Satellites; satellites; Screen presentations; screen presentations; Stock market options; stock market options; Submarines; submarines", thesaurus = "C language; Object-oriented languages", treatment = "G General Review", } @Article{Reid:1993:CFP, author = "R. J. Reid", title = "{C++} as a first programming language", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "4", pages = "41--44", month = may, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The Computer Science Department at Michigan State University has started using C++ as the primary language for programming instruction in its courses. The author discusses why C++ was chosen. He explains the course content, assesses results to date and explores future directions.", acknowledgement = ack-nhfb, affiliation = "Dept. of Comput. Sci., Michigan State Univ., East Lansing, MI, USA", classcodes = "C0220 (Education and training); C6140D (High level languages)C6110J (Object-oriented programming)", classification = "C0220 (Education and training); C6110J (Object-oriented programming); C6140D (High level languages)", corpsource = "Dept. of Comput. Sci., Michigan State Univ., East Lansing, MI, USA", keywords = "C language; C++; computer science education; Course content; course content; First programming language; first programming language; languages; object-oriented", thesaurus = "C language; Computer science education; Object-oriented languages", treatment = "A Application; G General Review", } @Article{Teale:1993:TTL, author = "S. Teale", title = "Transplanting a tree-recursive {LISP} algorithm to {C++}", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "4", pages = "45--48", month = may, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The author takes a small program, illustrating a typical tree-recursive process, written in the Scheme dialect of LISP and writes a version of it in C++. A tree-recursive process typically uses a function that calls itself more than once, thus generating an exponentially increasing number of nested invocations.", acknowledgement = ack-nhfb, classcodes = "C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming)", keywords = "C listings; C++; object-oriented; object-oriented languages; programming; recursive functions; Scheme; software portability; Tree-recursive LISP algorithm; tree-recursive LISP algorithm", thesaurus = "C listings; Object-oriented languages; Object-oriented programming; Recursive functions; Software portability", treatment = "P Practical", } @Article{Stroustrup:1993:LDU, author = "B. Stroustrup", title = "Library design using {C++}", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "5", pages = "14--22", month = jun, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The designer of a C++ library has several choices for the basic structure of a library and can even provide more than one interface style for a single library. C++ evolved to enable this diversity of library architectures and some of the newer C++ features are designed to ease the coexistence of libraries. The author focuses on generalities and language support for library building.", acknowledgement = ack-nhfb, affiliation = "Dept. of Comput. Structures Res., 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 = "Dept. of Comput. Structures Res., AT\&T Bell Labs., Murray Hill, NJ, USA", keywords = "C language; C listings; C++ library; Library architectures; library architectures; object-; object-oriented languages; oriented programming; software reusability", thesaurus = "C language; C listings; Object-oriented languages; Object-oriented programming; Software reusability", treatment = "P Practical", } @Article{Lea:1993:GCL, author = "D. Lea", title = "The {GNU C++} library", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "5", pages = "24--27", month = jun, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The GNU C++ library (libg++) was one of the first widely available general-purpose C++ class libraries. Libg++ is mainly an `abstract data structure library'. Most libg++ classes are somewhat different in design philosophy, design, and implementation than the classes ordinarily constructed for specific application. This article focuses mainly on these differences without otherwise going into much detail about particular components.", acknowledgement = ack-nhfb, affiliation = "Dept. of Comput. Sci., State Univ. of New York, NY, USA", classcodes = "C6140D (High level languages); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6140D (High level languages)", corpsource = "Dept. of Comput. Sci., State Univ. of New York, NY, USA", keywords = "Abstract data structure library; abstract data structure library; abstract data types; C language; General-purpose C++ class libraries; general-purpose C++ class libraries; GNU C++ library; Libg++; object-oriented languages; object-oriented programming; software reusability", thesaurus = "Abstract data types; C language; Object-oriented languages; Object-oriented programming; Software reusability", treatment = "P Practical", } @Article{Keffer:1993:DAT, author = "T. Keffer", title = "The design and architecture of {Tools.h}++", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "5", pages = "28--33", month = jun, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Rogue Wave Software's Tools.h++ has its roots in the Data Analysis and Interactive Modeling Software (DAIMS) project at the University of Washington. The objective of the project was to develop reusable mathematical modeling tools for use in fluid dynamics. The library includes a set of abstract data types (ADTs), and corresponding specializing classes, that provides a framework for persistence, localization, and other issues, although this is not the central focus of the library. The author discusses the various concrete classes offered by Tools.h++, then its various abstraction facilities. This is followed by a look at various implementation issues including implementation conventions, error handling, and dynamic link libraries.", acknowledgement = ack-nhfb, affiliation = "Rogue Wave Software, Corvallis, OR, USA", classcodes = "C6140D (High level languages); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6140D (High level languages)", corpsource = "Rogue Wave Software, Corvallis, OR, USA", keywords = "Abstract data types; abstract data types; Abstraction; abstraction; and Interactive Modeling Software; C language; C++ library; Data Analysis; Data Analysis and Interactive Modeling Software; Dynamic link libraries; dynamic link libraries; Error handling; error handling; Fluid dynamics; fluid dynamics; modeling tools; object-oriented languages; object-oriented programming; reusable mathematical; Reusable mathematical modeling tools; Rogue Wave Software; software reusability; Tools.h++", thesaurus = "Abstract data types; C language; Object-oriented languages; Object-oriented programming; Software reusability", treatment = "P Practical", } @Article{Carroll:1993:DUS, author = "M. Carroll", title = "Design of the {USL Standard Components}", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "5", pages = "34--39, 53", month = jun, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "USL C++ Standard Components (SC) is a general-purpose library. The principal design goals of SC are wide utility and efficiency. SC contains a collection of C++ classes that are both useful and efficient in a broad range of C++ programs. SC also contains tools intended to make programming in C++ easier. For example. it contains a tool that can produce an ASCII, T/sub E/X, or Postcript representation of the class inheritance hierarchy contained in a given collection of C++ source files. The author restricts his attention to the classes.", acknowledgement = ack-nhfb, classcodes = "C6140D (High level languages); C6110J (Object-oriented programming); C6110B (Software engineering techniques)", classification = "C6110B (Software engineering techniques); C6110J (Object-oriented programming); C6140D (High level languages)", keywords = "ASCII; C language; C++ programs; Class inheritance hierarchy; class inheritance hierarchy; object-oriented; object-oriented languages; Postcript; programming; software reusability; TEX; USL C++ Standard Components", thesaurus = "C language; Object-oriented languages; Object-oriented programming; Software reusability", treatment = "P Practical", } @Article{Booch:1993:SBC, author = "G. Booch and M. Vilot", title = "Simplifying the {Booch} Components", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "5", pages = "41--52", month = jun, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "What factors contributed to making the C++ Booch Components into `the incredible shrinking library?' This article examines, how the concepts of OOD and the features of C++ helped to organize and simplify the library. First, it provides a brief overview of the library showing its contents and organization. Then, it explores how inheritance and parameterization helped to streamline and simplify the library. The article concludes with a summary of how much each design change contributed to the overall size reduction.", acknowledgement = ack-nhfb, classcodes = "C6140D (High level languages); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6140D (High level languages)", keywords = "C language; C++ Booch Components; Inheritance; inheritance; object oriented; Object oriented design; object oriented design; Object oriented programming; object-oriented; object-oriented languages; Parameterization; parameterization; programming; Software library; software library; software reusability", thesaurus = "C language; Object-oriented languages; Object-oriented programming; Software reusability", treatment = "P Practical", } @Article{Hansen:1993:EMA, author = "T. L. Hansen", title = "Enhancing memory allocation. An array reallocation\slash renew function for {C++}", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "6", pages = "20--22, 24, 26--30", month = jul # "--" # aug, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "In J. Object-Oriented Program., vol.4, no.6, p.54-9 (1991). A. Koenig analysed a renew operator that relates to operator new and operator delete the same way the realloc() function relates to the malloc() and free() functions. He presented a template function renew() that implements the desired reallocation without requiring any changes to the C++ language. However, there are a couple of problems with the particular implementation Koenig shows. This article starts with a recap of Koenig's implementation, discusses the problems with the implementation, reexamines the requirements being renew(), shows the results of attempting to implement it on several existing C++ platforms that support templates, and discusses some changes that would be necessary to those compilers in order to implement such a template function.", acknowledgement = ack-nhfb, classcodes = "C6120 (File organisation); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6120 (File organisation)", keywords = "array reallocation/renew; Array reallocation/renew function; C listings; C++ language; Compilers; compilers; function; Memory allocation enhancement; memory allocation enhancement; object-oriented programming; Operator delete; operator delete; Operator new; operator new; Renew operator; renew operator; Renew(); renew(); storage allocation; Template function; template function", thesaurus = "C listings; Object-oriented programming; Storage allocation", treatment = "P Practical", } @Article{Vinoski:1993:DOC, author = "S. Vinoski", title = "Distributed object computing with {CORBA}", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "6", pages = "32--38", month = jul # "--" # aug, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The Object Management Group's Object Management Architecture (OMA) attempts to define, at a high level of abstraction, the various facilities necessary for distributed O-O computing. The core of the OMA is the Object Request Broker (ORB), a mechanism that provides transparency of object location, activation, and communication. In 1991 the OMG published revision 1.1 of the Common Object Request Broker Architecture (CORBA) specification, a concrete description of the interfaces and services that must be provided by compliant ORBs. Since then, many OMG member companies have either started shipping or have announced plans to ship products based on the CORBA specification. The CORBA is composed of five major components: ORB core; interface definition language; dynamic invocation interface; interface repository; and object adapters. This article describes each of these components and shows how they provide the flexibility required to support a variety of distributed O-O systems, emphasizing those developed in C++.", acknowledgement = ack-nhfb, affiliation = "Hewlett Packard, Chelmsford, MA, USA", classcodes = "C6110J (Object-oriented programming); C6150N (Distributed systems)", classification = "C6110J (Object-oriented programming); C6150N (Distributed systems)", corpsource = "Hewlett Packard, Chelmford, MA, USA", keywords = "Abstraction; abstraction; C language; C++; Common; Common Object Request Broker Architecture; CORBA; Distributed object oriented computing; distributed object oriented computing; distributed processing; Dynamic invocation interface; dynamic invocation interface; Group; Interface definition language; interface definition language; Interface repository; interface repository; Object adapters; object adapters; Object Management; Object Management Architecture; Object Management Group; Object Request Broker Architecture; object-oriented; ORB core; programming", thesaurus = "C language; Distributed processing; Object-oriented programming", treatment = "G General Review", } @Article{Myers:1993:MMC, author = "N. C. Myers", title = "Memory management in {C++}. {I}. Fine-tuning your programs", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "6", pages = "39--41, 43", month = jul # "--" # aug, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Because C++ code is naturally organized by class, a common response to this failure is to overload member operator new for individual classes. In addition to being tedious to implement and maintain, however, this piecemeal approach can actually hurt performance in large systems. Furthermore, it tends to fragment memory by keeping large, mostly empty blocks dedicated to each class. The result can be a quick new/delete cycle that accidentally causes virtual memory thrashing. At best, the approach interferes with system-wide tuning efforts. Thus, while detailed knowledge of the memory usage patterns of individual classes can be helpful, it is best applied by tuning memory usage for a whole program or major subsystem. This article describes an interface that can ease such tuning in C++ programs. Before tuning a particular program, however, it pays to improve performance for all programs by improving the global memory manager.", acknowledgement = ack-nhfb, classcodes = "C6110J (Object-oriented programming); C6120 (File organisation)", classification = "C6110J (Object-oriented programming); C6120 (File organisation)", keywords = "C language; C++ programs; Global memory manager; global memory manager; Memory usage patterns; memory usage patterns; object-oriented programming; Performance; performance; Program fine tuning; program fine tuning; storage management; system-wide; System-wide tuning efforts; tuning efforts; Virtual memory thrashing; virtual memory thrashing", thesaurus = "C language; Object-oriented programming; Storage management", treatment = "P Practical", } @Article{Barton:1993:SEP, author = "J. J. Barton and L. R. Nackman", title = "Scientific and engineering programming in {C++}: grafting onto our roots", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "7", pages = "26--31", month = sep, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Scientists and engineers typically do more numerical processing than other programmers, and they tend to structure their programs around mathematical models. Rapid improvements in numerical processing speed and the increasingly sophisticated mathematical models used to formulate technical programming projects have led science and engineering programmers to use C++ to tackle the thorny non-numerical parts of their programs. The authors discuss techniques for exploiting existing FORTRAN-callable numerical libraries.", acknowledgement = ack-nhfb, affiliation = "IBM Thomas J. Watson Res. Center, Hawthorne, NY, USA", classcodes = "C7300 (Natural sciences); C7400 (Engineering); C6110J (Object-oriented programming); C4100 (Numerical analysis)", classification = "C4100 (Numerical analysis); C6110J (Object-oriented programming); C7300 (Natural sciences); C7400 (Engineering)", corpsource = "IBM Thomas J. Watson Res. Center, Hawthorne, NY, USA", keywords = "C listings; C++; computing; engineering computing; Engineering programming; engineering programming; FORTRAN-callable numerical libraries; Mathematical models; mathematical models; natural sciences; Nonnumerical programming; nonnumerical programming; numerical analysis; Numerical processing; numerical processing; object-oriented programming; Scientific programming; scientific programming; subroutines", thesaurus = "C listings; Engineering computing; Natural sciences computing; Numerical analysis; Object-oriented programming; Subroutines", treatment = "P Practical", } @Article{Schmidt:1993:CWU, author = "D. C. Schmidt", title = "A {C++} wrapper for {UNIX I/O} multiplexing: the object-oriented design and implementation of the {Reactor}", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "7", pages = "32--43", month = sep, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Describes techniques for encapsulating existing operating system interprocess communication services using object-oriented C++ wrappers. I/O multiplexing is useful for developing event-driven network servers that receive and process data arriving from multiple clients simultaneously. This article focuses on the design and implementation of a C++ wrapper called the Reactor. The Reactor provides a portable interface to an object-oriented library of extensible, reusable, and type-secure C++ classes that encapsulate and enhance the select() and poll() UNIX I/O multiplexing facilities. To help simplify network programming, the Reactor integrates the multiplexing of synchronous and asynchronous I/O-based events together with timer-based events. When these events occur, the Reactor automatically dispatches previously registered application-defined member functions to handle the events. In addition to describing the Reactor, this article also presents a distributed logging facility that demonstrates how the Reactor simplifies the development of concurrent, event-driven network applications.", acknowledgement = ack-nhfb, classcodes = "C6150N (Distributed systems); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6150N (Distributed systems)", keywords = "application-defined; Application-defined member functions; Asynchronous events; asynchronous events; C listings; C++ wrapper; Concurrent applications development; concurrent applications development; Distributed logging facility; distributed logging facility; distributed processing; Encapsulation; encapsulation; event-driven; Event-driven network servers; input-; member functions; multiplexing; network servers; object-; Object-oriented design; object-oriented design; operating; Operating system interprocess communication services; oriented programming; output programs; Portable interface; portable interface; Reactor; software portability; subroutines; Synchronous events; synchronous events; system interprocess communication services; Unix; UNIX I/O; UNIX I/O multiplexing", thesaurus = "C listings; Distributed processing; Encapsulation; Input-output programs; Multiplexing; Network servers; Object-oriented programming; Software portability; Subroutines; Unix", treatment = "P Practical", } @Article{Stroustrup:1993:WCL, author = "B. P. Stroustrup", title = "Why consider language extensions? Maintaining a delicate balance", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "7", pages = "44--51", month = sep, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Formal standardization of C++ started in December 1989 when the ANSI C++ committee, X3J16, was formed. The initiative came from IBM, DEC, and HP and was supported by AT and T. In June 1991 the effort became officially international with the creation of the ISO SC22-WG21. Thus, a single US national and international C++ standard will emerge. Every living programming language faces a conflict between stability vs. the need to grow to meet new challenges and reflect new insights. This problem will not go away and must be handled delicately and with common sense. As usual, one person's common sense is another's lunacy, but no simple and absolute rule can adequately express a policy on this matter. The particular example of a proposed extension discussed in this article, namespaces, is simple, easily comprehended, and almost completely compatible. It solves a serious problem, transition from older styles to use of namespaces is easy, and it has been implemented. The problem it addresses cannot be adequately handled with existing language features or through a library. It is an example of a proposed extension that deserves to be accepted.", acknowledgement = ack-nhfb, affiliation = "Dept. of Comput. Structures Res., AT and T Bell Labs., Murray Hill, NJ, USA", classcodes = "C6140D (High level languages)", classification = "C6140D (High level languages)", corpsource = "Dept. of Comput. Structures Res., AT\&T Bell Labs., Murray Hill, NJ, USA", keywords = "ANSI C++ committee; C language; Compatibility; compatibility; International C++ standard; international C++ standard; ISO SC22-WG21; Language extensions; language extensions; Namespaces; namespaces; Policy; policy; programming languages; Stability; stability; standardisation; X3J16", thesaurus = "C language; Programming languages; Standardisation", treatment = "G General Review; P Practical", } @Article{Stal:1993:GDA, author = "M. Stal and U. Steinmuller", title = "Generic dynamic arrays: integrating dynamic arrays into {C++} templates", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "8", pages = "30--35, 38", month = oct, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Dynamic arrays should be helpful in many situations where scaffolding techniques once had to be applied. They also provide some advantages in programmers who are developing C++ libraries. The article focuses on how to integrate dynamic arrays into C++ using templates. An array is always an ordered collection of elements. There is a distinction between homogeneous arrays, where all array elements belong to the same datatype, and heterogeneous arrays, where the elements may have different types. The authors confine themselves to homogeneous arrays, which turns out to be no real limitation, since heterogeneous arrays can always be modeled in C++ by using a common base class for the elements (e.g. array of Object*). Additionally they do not cover associative arrays or sparse arrays. The arrays discussed use integral index values starting with 0 to some limit without having any holes.", 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 = "abstract data types; C language; C++; C++ libraries; C++ templates; Generic dynamic arrays; generic dynamic arrays; Homogeneous arrays; homogeneous arrays; Integral index values; integral index values; libraries; Object*; object-oriented languages; object-oriented programming; Scaffolding; scaffolding", thesaurus = "Abstract data types; C language; Object-oriented languages; Object-oriented programming", treatment = "P Practical", } @Article{Reed:1993:EPI, author = "D. R. Reed", title = "Exceptions: pragmatic issues with a new language feature", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "8", pages = "39--44", month = oct, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Deciding whether to use a new C++ feature is never easy. Like all engineering decisions, there are trade-offs to be made, and only you can decide which ones you can afford. From his research, the author found exception handling to be quite usable and looks forward to using it in future projects. Currently, however, the use of such a feature must be viewed as an engineering trade-off. If cross-platform portability of your source code is an important consideration, you may want to wait a bit to use C++ exception handling. As far as performance goes, it is not an issue for most types of software development.", acknowledgement = ack-nhfb, classcodes = "C6140D (High level languages); C6110J (Object-oriented programming); C6130 (Data handling techniques)", classification = "C6110J (Object-oriented programming); C6130 (Data handling techniques); C6140D (High level languages)", keywords = "C language; C++ feature; Cross-platform portability; cross-platform portability; Exception handling; exception handling; object-oriented languages; object-oriented programming; Software development; software development; Source code; source code", thesaurus = "C language; Exception handling; Object-oriented languages; Object-oriented programming", treatment = "P Practical", } @Article{Strickland:1993:OOD, author = "H. Strickland", title = "{ODMG}-93: the object database standard for {C++}", journal = j-C-PLUS-PLUS-REPORT, volume = "5", number = "8", pages = "45--48", month = oct, year = "1993", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The ODMG standard describes a C++ binding to an object database that not only defines some C++ interface classes but outlines an approach for defining database classes and manipulating persistent objects. The article introduces the part of the ODMG standard that defines a C++ binding to an object database. This C++ binding not only defines some C++ interface classes, but it also describes an approach for using C++ to define database classes and manipulate persistent objects. The author creates an abbreviation ODMG/C++ to refer to this base-line subset, and concentrates on only that part of the standard. The interface in this subset is largely based on the common subset of existing products, so it is a `codify existing practice' standard.", acknowledgement = ack-nhfb, classcodes = "C6160J (Object-oriented databases); C6140D (High level languages)", classification = "C6140D (High level languages); C6160J (Object-oriented databases)", keywords = "binding; C language; C++; C++ binding; C++ interface classes; Database classes; database classes; languages; Object database standard; object database standard; object-oriented; object-oriented databases; ODMG-93; ODMG/C++; Persistent objects; persistent objects; standards", thesaurus = "C language; Object-oriented databases; Object-oriented languages; Standards", treatment = "G General Review; P Practical", } @Article{Tichy:1994:GGA, author = "W. F. Tichy and J. Heilig and F. {Newbery Paulisch}", title = "A generative and generic approach to persistence", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "1", pages = "22--33", month = jan, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "A persistence facility saves a program's volatile data objects on permanent store for later use. In this article, we propose a method that takes the drudgery out of the load-process-save model. We demonstrate that the persistence facility can be produced automatically by a program generator. The generated routines are split into type-initialization routines that are used to record the information about the types used in the application and generic load and save routines which rely on this type information. This allows for a flexible and efficient implementation of persistence as well as a convenient user interface. To demonstrate the feasibility of this approach, the persistence facility described has been incorporated into PGen, a persistence generator tool for C++. PGen has been tested on several real-world applications to demonstrate that the generated routines are comparable in efficiency to manually written ones (in both time and space).", acknowledgement = ack-nhfb, affiliation = "Karlsruhe Univ., Germany", classcodes = "C6110J (Object-oriented programming); C6115 (Programming support)", classification = "C6110J (Object-oriented programming); C6115 (Programming support)", corpsource = "Karlsruhe Univ., Germany", keywords = "automatic programming; C language; C++; Generative approach; generative approach; generic routines; Generic routines; interface; languages; Load-process-save model; load-process-save model; object-oriented; object-oriented programming; objects; Persistence facility; persistence facility; Persistence generator tool; persistence generator tool; PGen; Program generator; program generator; Type-initialization routines; type-initialization routines; user; User interface; volatile data; Volatile data objects", thesaurus = "Automatic programming; C language; Object-oriented languages; Object-oriented programming", treatment = "P Practical", } @Article{Churchill:1994:ERS, author = "S. Churchill", title = "Exception recovery with smart pointers", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "1", pages = "34--35, 38--42", month = jan, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The C++ exception handling feature is designed to eliminate the time-consuming process of passing return codes up the call stack when lower-level errors occur. This article describes smart pointer mechanisms that can be used to provide a number of valuable services. Among these is the ability to recover dynamically allocated memory after an exception occurs. The author starts by taking a look at a common strategy for reference counting dynamically allocated objects and explains how this `ref counting' can be automated using smart pointers. Then he looks at how the use of smart pointers provides for the recovery of dynamically allocated memory when an exception occurs.", acknowledgement = ack-nhfb, affiliation = "Fijitsu, Tokyo, Japan", classcodes = "C6120 (File organisation); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6120 (File organisation)", corpsource = "Fijitsu, Tokyo, Japan", keywords = "C language; C++ exception handling feature; Call stack; call stack; coding errors; collection; data structures; dynamically allocated; Dynamically allocated memory; Exception recovery; exception recovery; garbage; Garbage collection; Lower-level errors; lower-level errors; memory; Object oriented programming; object oriented programming; object-oriented; programming; recovery; Reference counting; reference counting; Return codes; return codes; Smart pointers; smart pointers; storage allocation; storage management; system", thesaurus = "C language; Coding errors; Data structures; Object-oriented programming; Storage allocation; Storage management; System recovery", treatment = "P Practical", } @Article{Arjomandi:1994:CSC, author = "E. Arjomandi and W. O'Farrell and I. Kalas", title = "Concurrency support for {C++}: an overview", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "1", pages = "44--50", month = jan, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "How do you handle concurrency? Whether through language support or the use of libraries, the paradigms of OOP and concurrent programming must work together. In this article, we review and analyze some of the C++ based concurrent systems. Issues characterizing concurrent object-oriented systems and techniques used in adding concurrency to C++ are presented. We compare concurrent extensions to C++, and concurrent libraries for C++ where concurrency is kept outside of the language.", acknowledgement = ack-nhfb, affiliation = "York Univ., North York, Ont., Canada", classcodes = "C6150N (Distributed systems); C6140D (High level languages); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6140D (High level languages); C6150N (Distributed systems)", corpsource = "York Univ., North York, Ont., Canada", keywords = "C language; C++ based concurrent systems; concurrency control; concurrent; Concurrent extensions; concurrent extensions; Concurrent libraries; Concurrent object-oriented systems; Language support; language support; libraries; object-oriented languages; object-oriented systems; subroutines", thesaurus = "C language; Concurrency control; Object-oriented languages; Subroutines", treatment = "G General Review", } @Article{Martin:1994:PEO, author = "R. Martin", title = "A practical example of object-oriented analysis and design", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "2", pages = "18--23", month = feb, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Provides a case study which explores the topic of object-oriented analysis and design. Although the subjects of OOA and OOD are steeped in theory and current controversy, the author bypasses this and presents them from a pragmatic, how-to point of view. There seems to be a great deal of discussion about the merits of various object oriented languages. Some of the participants in these discussions favor C++ as an OOPL based on its nearness to C and its pragmatic outlook. Others berate C++ as an ugly and incomplete language because of its nearness to C and its pragmatic outlook. The author makes a different point altogether: the quality of an object-oriented application is determined far more by the quality of its analysis and design than by the features of the implementation language. In his opinion, C++ offers features in sufficient quantity to implement any 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 = "C; C language; C++; Incomplete language; incomplete language; methods; object; Object oriented languages; object-; object-oriented; Object-oriented analysis; object-oriented analysis; Object-oriented application quality; Object-oriented design; object-oriented design; object-oriented languages; object-oriented programming; oriented application quality; oriented languages", thesaurus = "C language; Object-oriented languages; Object-oriented methods; Object-oriented programming", treatment = "P Practical", } @Article{Silva-Lepe:1994:RDC, author = "I. Silva-Lepe and W. Hursch and G. Sullivan", title = "A report on {Demeter C++}", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "2", pages = "24--30", month = feb, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Reports on Demeter/C++, an object-oriented software development method featuring graphical description of class structures and a high level language for the definition of object behaviour. C++ programs developed with Demeter become less dependent on the details of a specific class structure and thus more adaptive to change. The Demeter method is supported by a suite of tools including a graphical user interface, a consistency checker, C++ code generators, and a run-time library of generic software. To alleviate the problem of writing large amounts of mundane code, Demeter/C++ provides tools for automatically generating class declarations and member function definitions. Automatic code generation is based on Demeter's graphical notation. The author shows how to develop a sample application using Demeter/C++ and how to adapt the application to new requirements.", acknowledgement = ack-nhfb, affiliation = "Coll. of Comput. Sci., Northeastern Univ., Boston, MA, USA", classcodes = "C6110J (Object-oriented programming); C6140D (High level languages); C6180G (Graphical user interfaces); C6115 (Programming support)", classification = "C6110J (Object-oriented programming); C6115 (Programming support); C6140D (High level languages); C6180G (Graphical user interfaces)", corpsource = "Coll. of Comput. Sci., Northeastern Univ., Boston, MA, USA", keywords = "Automatic code generation; automatic code generation; automatic programming; C language; C++; checker; Class declarations; class declarations; Class structures; class structures; Code generators; code generators; consistency; Consistency checker; Demeter C++; Demeter method; Demeter/C++; development method; generic; Generic software; Graphical description; graphical description; Graphical notation; graphical notation; graphical user; Graphical user interface; graphical user interface; High level language; high level language; interfaces; Member function definitions; member function definitions; Object behaviour definition; object behaviour definition; Object oriented programming; object oriented programming; object-oriented; object-oriented languages; object-oriented software; Object-oriented software development method; programming; Run-time library; run-time library; software; software tools", thesaurus = "Automatic programming; C language; Graphical user interfaces; Object-oriented languages; Object-oriented programming; Software tools", treatment = "P Practical", } @Article{Havener:1994:CAS, author = "C. L. Havener", title = "A {C++} application story", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "2", pages = "31--33", month = feb, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "C++ has been used at Epsilon Data Management for the development of a general data warehouse system on the Thinking Machines CM5 Connection Machine. Epsilon creates data-based marketing solutions which often rely on using large databases for decision support. This type of database is often called a data warehouse. Decision support queries require a pass over the entire database because they take the form of finding all customers who meet some requirement. We provide an application story that describes our experiences, both good and bad, with using C++.", acknowledgement = ack-nhfb, affiliation = "Epsilon Data Management Inc., Burlington, MA, USA", classcodes = "C6110J (Object-oriented programming); C7170 (Marketing); C6140D (High level languages); C6160Z (Other DBMS); C7102 (Decision support systems)", classification = "C6110J (Object-oriented programming); C6140D (High level languages); C6160Z (Other DBMS); C7102 (Decision support systems); C7170 (Marketing)", corpsource = "Epsilon Data Management Inc., Burlington, MA, USA", keywords = "C language; C++; CM5; Connection Machine; Customers; customers; Data warehouse; data warehouse; Data warehouse system; data warehouse system; data-based; Data-based marketing solutions; decision support; Decision support queries; Decision support systems; decision support systems; Epsilon Data Management; Large databases; large databases; marketing data; marketing solutions; Object oriented programming; object oriented programming; object-oriented; object-oriented languages; processing; programming; query processing; systems; Thinking Machines; very large databases", thesaurus = "C language; Decision support systems; Marketing data processing; Object-oriented languages; Object-oriented programming; Query processing; Very large databases", treatment = "A Application; P Practical", } @Article{Lajoie:1994:EHSa, author = "J. Lajoie", title = "Exception handling: supporting the runtime mechanism", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "3", pages = "36--39, 42--43", month = mar # "--" # apr, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The C++ exception handling mechanism can be used to communicate between two unrelated portions of a C++ application-one portion of the application can detect an exceptional situation and communicate it to the portion of the application that controls or synchronizes the work underway. The author reviews some of the language features provided in C++ to support exception handling and the underlying mechanisms an implementation must provide to support these features. One understands better the behavior of the C++ exception handling features if one understands the work happening behind the scenes-the work performed by the compiler and during runtime to support C++ exception handling.", acknowledgement = ack-nhfb, classcodes = "C6110J (Object-oriented programming); C6140D (High level languages); C6150C (Compilers, interpreters and other processors); C6150J (Operating systems); C6120 (File organisation); C6130 (Data handling techniques)", classification = "C6110J (Object-oriented programming); C6120 (File organisation); C6130 (Data handling techniques); C6140D (High level languages); C6150C (Compilers, interpreters and other processors); C6150J (Operating systems)", keywords = "application; C++; C++ application; C++ exception handling mechanism; Compiler; compiler; data structures; exception handling; Exceptional situation; exceptional situation; Language features; language features; languages; object-oriented; program compilers; Runtime mechanism; runtime mechanism; Underlying mechanisms; underlying mechanisms", thesaurus = "Data structures; Exception handling; Object-oriented languages; Program compilers", treatment = "P Practical", } @Article{vanLoon:1994:IXW, author = "R. {van Loon}", title = "Introducing the {X Window System}", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "3", pages = "45--47", month = mar # "--" # apr, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "A discussion is given on the X Window System, version II and programming X in C++. The author looks at the history of the X Window System or X and XII for short, as well as its various components. No knowledge about X or any other window system is assumed. The area of graphics and window systems has always been the playground of object-oriented programmers. A large number of authors have used some sort of geometric object-hierarchy in order to demonstrate object-oriented concepts. Some of the topics presented, such as the Xt/Intrinsics and Mota are only covered briefly.", acknowledgement = ack-nhfb, classcodes = "C6180 (User interfaces); C6110J (Object-oriented programming)C6140D (High level languages)", classification = "C6110J (Object-oriented programming); C6140D (High level languages); C6180 (User interfaces)", keywords = "C++; concepts; geometric object-hierarchy; Geometric object-hierarchy; Graphics; graphics; Mota; object-oriented; Object-oriented concepts; object-oriented languages; Object-oriented programmers; object-oriented programming; programmers; software packages; user interfaces; X Window System; XII; Xt/Intrinsics", thesaurus = "Object-oriented languages; Object-oriented programming; Software packages; User interfaces", treatment = "P Practical; R Product Review", } @Article{Schmidt:1994:DAN, author = "D. Schmidt", title = "A domain analysis of network daemon design dimensions", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "3", pages = "50--59", month = mar # "--" # apr, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Server daemons commonly provide clients with communication-related services that resolve queries, access file systems, manage routing tables, perform local system services and integrate multiple remote services. This article is part of a continuing series that describes object oriented techniques that may be used to simplify the development of reliable, robust and extensible distributed applications. It presents an object oriented domain analysis of key design decisions for network server daemons.", acknowledgement = ack-nhfb, classcodes = "C6150N (Distributed systems); C6110J (Object-oriented programming); C6150J (Operating systems); C5630 (Networking equipment)", classification = "C5630 (Networking equipment); C6110J (Object-oriented programming); C6150J (Operating systems); C6150N (Distributed systems)", keywords = "Clients; clients; Communication-related services; communication-related services; distributed applications; distributed processing; extensible; Extensible distributed applications; File systems; file systems; Local system services; local system services; Multiple remote services; multiple remote services; network; Network daemon design dimensions; network daemon design dimensions; network operating systems; Network server daemons; network server daemons; Object oriented domain analysis; object oriented domain analysis; Object oriented techniques; object oriented techniques; object-oriented programming; Query resolution; query resolution; Reliable applications; reliable applications; Robust applications; robust applications; Routing tables; routing tables; servers; software reliability", thesaurus = "Distributed processing; Network operating systems; Network servers; Object-oriented programming; Software reliability", treatment = "P Practical", } @Article{Horstmann:1994:EIL, author = "C. S. Horstmann", title = "Extending the iostream library", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "4", pages = "22--29", month = may, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "The first release of C++ gave two libraries, complex.h and stream.h, but many C programmers still use stdio.h for input and output. Streams, however, are superior to stdio because they are typesafe, and their extensibility goes far beyond just adding new types to the formatting layer. I show that the extensibility goes far beyond the addition of new types to the formatting layer. I added a manipulator to convert printf formatting commands to their stream equivalents, and I added a new stream class that displays output in a debug window under Microsoft Windows, fully supporting all features of the ostream class (including the new format manipulator). Both additions require very little code, but the programmer must know where to hook into the streams framework. This is, of course, characteristic of programming with frameworks.", acknowledgement = ack-nhfb, classcodes = "C6140D (High level languages); C6150G (Diagnostic, testing, debugging and evaluating systems); C6115 (Programming support); C6110J (Object-oriented programming)", classification = "C6110J (Object-oriented programming); C6115 (Programming support); C6140D (High level languages); C6150G (Diagnostic, testing, debugging and evaluating systems)", keywords = "Buffering; buffering; C language; C++; Complex.h; complex.h; Debug window; debug window; Frameworks; frameworks; Input; input; Iostream library; iostream library; Manipulator; manipulator; Microsoft Windows; object-oriented languages; Ostream class; ostream class; Output; output; Printf formatting command conversion; printf formatting command conversion; program debugging; Stdio.h; stdio.h; Stream.h; stream.h; subroutines", thesaurus = "C language; Object-oriented languages; Program debugging; Subroutines", treatment = "P Practical", } @Article{Moudgill:1994:RM, author = "M. Moudgill", title = "Reverse-engineering manipulators", journal = j-C-PLUS-PLUS-REPORT, volume = "6", number = "4", pages = "30--33", month = may, year = "1994", CODEN = "CRPTE7", ISSN = "1040-6042", bibdate = "Tue Mar 25 13:34:48 MST 1997", abstract = "Normally, our interaction (as C++ programmers) with the iostream library is confined to using the built-in extraction (>>operator) and insertion (<