typedef

Abstract: PART I. 1. The Prehistory of C++ . 2. C with Classes. 3. The Birth of C++. 4. C++ Language Design Rules. 5. Chronology 1985-1993. 6. Standardization. 7. Interest and Use. 8. Libraries. 9. Looking Ahead. PART II. 1. Memory Management. 2. Overloading. 3. Multiple Inheritance. 4. Class Concept Refinements. 5. Casting. 6. Templates. 7. Exception Handling. 8. Namespaces. 9. The C Preprocessor. Index. 0201543303T04062001

Abstract: Preface. 0. Introduction. From C to C++. Using C++ to Develop Large Projects. Reuse. Quality. Software Development Tools. Summary. I. BASICS. 1. Preliminaries. Multi-File C++ Programs. typedef Declarations. Assert Statements. A Few Matters of Style. Iterators. Logical Design Notation. Inheritance versus Layering. Minimality. Summary. 2. Ground Rules. Overview. Member Data Access. The Global Name Space. Include Guards. Redundant Include Guards. Documentation. Identifier-Naming Conventions. Summary. II. PHYSICAL DESIGN CONCEPTS. 3. Components. Components versus Classes. Physical Design Rules. The DependsOn Relation. Implied Dependency. Extracting Actual Dependencies. Friendship. Summary. 4. Physical Hierarchy. A Metaphor for Software Testing. A Complex Subsystem. The Difficulty in Testing "Good" Interfaces. Design for Testability. Testing in Isolation. Acyclic Physical Dependencies. Level Numbers. Hierarchical and Incremental Testing. Testing a Complex Subsystem. Testing versus Tested. Cyclic Physical Dependencies. Cumulative Component Dependency (CCD). Physical Design Quality. Summary. 5. Levelization. Some Causes of Cyclic Physical Dependencies. Escalation. Demotion. Opaque Pointers. Dumb Data. Redundancy. Callbacks. Manager Class. Factoring. Escalating Encapsulation. Summary. 6. Insulation. From Encapsulation to Insulation. C++ Constructs and Compile-Time Coupling. Partial Insulation Techniques. Total Insulation Techniques. The Procedural Interface. To Insulate or Not to Insulate. Summary. 7. Packages. From Components to Packages. Registered Package Prefixes. Package Levelization. Package Insulation. Package Groups. The Release Process. The main Program. Start-Up Time. Summary. III. LOGICAL DESIGN ISSUES. 8. Architecting a Component. Abstractions and Components. Component Interface Design. Degrees of Encapsulation. Auxiliary Implementation Classes. Summary. 9. Designing a Function. Function Specification. Fundamental Types Used in the Interface. Special Case Functions. Summary. 10. Implementing an Object. Member Data. Function Definitions. Memory Management. Using C++ Templates in Large Projects. Summary. Appendix A. Protocol Hierarchy. Appendix B. Implementing an ANSI C-Compatible C++ Interface. Appendix C. A Dependency Extractor/Analyzer Package. Appendix D. Quick Reference. Index. 0201633620T04062001

Abstract: Preface. 0. Introduction. From C to C++. Using C++ to Develop Large Projects. Reuse. Quality. Software Development Tools. Summary. I. BASICS. 1. Preliminaries. Multi-File C++ Programs. typedef Declarations. Assert Statements. A Few Matters of Style. Iterators. Logical Design Notation. Inheritance versus Layering. Minimality. Summary. 2. Ground Rules. Overview. Member Data Access. The Global Name Space. Include Guards. Redundant Include Guards. Documentation. Identifier-Naming Conventions. Summary. II. PHYSICAL DESIGN CONCEPTS. 3. Components. Components versus Classes. Physical Design Rules. The DependsOn Relation. Implied Dependency. Extracting Actual Dependencies. Friendship. Summary. 4. Physical Hierarchy. A Metaphor for Software Testing. A Complex Subsystem. The Difficulty in Testing "Good" Interfaces. Design for Testability. Testing in Isolation. Acyclic Physical Dependencies. Level Numbers. Hierarchical and Incremental Testing. Testing a Complex Subsystem. Testing versus Tested. Cyclic Physical Dependencies. Cumulative Component Dependency (CCD). Physical Design Quality. Summary. 5. Levelization. Some Causes of Cyclic Physical Dependencies. Escalation. Demotion. Opaque Pointers. Dumb Data. Redundancy. Callbacks. Manager Class. Factoring. Escalating Encapsulation. Summary. 6. Insulation. From Encapsulation to Insulation. C++ Constructs and Compile-Time Coupling. Partial Insulation Techniques. Total Insulation Techniques. The Procedural Interface. To Insulate or Not to Insulate. Summary. 7. Packages. From Components to Packages. Registered Package Prefixes. Package Levelization. Package Insulation. Package Groups. The Release Process. The main Program. Start-Up Time. Summary. III. LOGICAL DESIGN ISSUES. 8. Architecting a Component. Abstractions and Components. Component Interface Design. Degrees of Encapsulation. Auxiliary Implementation Classes. Summary. 9. Designing a Function. Function Specification. Fundamental Types Used in the Interface. Special Case Functions. Summary. 10. Implementing an Object. Member Data. Function Definitions. Memory Management. Using C++ Templates in Large Projects. Summary. Appendix A. Protocol Hierarchy. Appendix B. Implementing an ANSI C-Compatible C++ Interface. Appendix C. A Dependency Extractor/Analyzer Package. Appendix D. Quick Reference. Index. 0201633620T04062001

Abstract: There are numerous times when a C++ user could benefit from a pointer variant that has more functionality than is provided by the basic, language-defined pointer. For example, type-accurate garbage collection, reference counting, or transparent references to distributed or persistent objects, might be implemented with classes that provide pointer functionality. The C++ language directly supports one kind of pointer substitute, the smart pointer, in the form of overloadable indirection operators: -< and *. In this paper we evaluate how *seamlessly* smart pointers can replace raw pointers. The ideal is for client code not to care whether it is using raw pointers or smart pointers. For example, if a typedef selects whether raw or smart pointers are used throughout the program, changing the value of the typedef should not introduce syntax errors. Unfortunately, C++ does not support pointer substitutes well enough to permit seamless integration. This paper presents the desired behavior of smart pointers in terms of the semantics of raw pointers that the smart pointers try to emulate. Then, we describe several ways of implementing smart pointers. For each, we show cases in which the smart-pointers fail to behave like raw pointers. From among the choices, we explain which is the best for emulating the standard pointer conversions. *Accessors* are similar to smart pointers, but have certain advantages. This paper discusses the differences between accessors and smart pointers, and shows why our conclusions about type conversion behavior also apply to accessors. Whether a programmer prefers smart pointers or accessors, this paper shows the limitations and recommends an implementation.