Map
Index
Random
Help
Topics
th

QuoteRef: strob_1991

topics > all references > ThesaHelp: references sa-sz



ThesaHelp:
references sa-sz
Group:
goals for a programming system
Group:
object-oriented programming
Topic:
programming language design
Topic:
extensible languages
Topic:
software portability
Group:
data type
Topic:
abstraction in programming language
Topic:
object-oriented classes
Topic:
efficiency
Topic:
object-oriented data types
Topic:
preventing accidental errors
Topic:
information hiding
Topic:
abstraction in programming
Topic:
handling complexity
Topic:
abstraction
Topic:
object-oriented templates and containers
Topic:
object-oriented design
Topic:
restricted use of global variables
Group:
function
Group:
parameters
Topic:
parameters as argument place holders
Topic:
safe use of pointers
Topic:
variable as reference to a value
Topic:
alias names
Topic:
named constants and expressions
Topic:
local declaration of data
Topic:
local vs. global
Topic:
global declarations and variables
Topic:
primitive data type as memory
Topic:
primitive data types of a language
Topic:
pointers to data
Topic:
arrays
Topic:
comments
Topic:
source-rich system
Topic:
unique names
Topic:
localized understanding
Topic:
parameter passing by reference
Topic:
initialized constants
Topic:
generic operations and polymorphism
Topic:
type conversion
Topic:
language extension via macros
Topic:
macros
Topic:
abstract data type
Topic:
metaphysics and epistemology
Topic:
separate a module's interface specification from its implementation
Topic:
security by access functions
Topic:
object-oriented methods
Topic:
pronoun reference
Topic:
immutable files and data
Topic:
object modification
Topic:
initialization of data
Group:
type declaration
Topic:
object-oriented fields
Topic:
data type as a set of operations
Topic:
hierarchical structures
Topic:
type hierarchy
Topic:
types of object-oriented classes
Group:
data structures
Group:
derived data types
Topic:
abstract functions
Topic:
dynamic vs. static data type
Group:
type checking
Topic:
union data type
Topic:
problems with type inheritance
Topic:
opaque and partially-opaque data types
Topic:
finalization of data
Topic:
replacement as a procedure call
Topic:
optimization of object-oriented programs
Topic:
memory management by garbage collection
Topic:
replacement as setting a reference to a value
Topic:
collection class
Topic:
type parameter
Topic:
system builds
Topic:
iterator
Topic:
exception handling by try..catch
Group:
exception handling
Topic:
exception handling by unique value

Reference

Stroustrup, B., The C++ Programming Language, Reading Massachusetts, Addison-Wesley Publishing, 1991 (2nd edition). Google

Other Reference

pages 300-500 in (QuoteRef: strob_1991x)

Notes

restore quoted titles from pages: 26 47 104 140 143 237 281 316 318 363 364 370 371 375 375 380 382 383 384 394 450

Quotations
v ;;Quote: C++ is a general purpose programming language for enjoyable programming by serious programmers
v+;;Quote: C++ is a superset of C
v ;;Quote: use data abstraction to construct modular programs; i.e., define new types that match the application's concepts, e.g., C++
v ;;Quote: object-based programs use objects that contain type information
v ;;Quote: a C++ class is a user-defined type; it provides data hiding, initialization, type conversion, dynamic typing, memory management, and overloaded operations
v ;;Quote: user-defined types in C++ can deal efficiently with fundamental hardware objects such as bits, bytes, words, and addresses
3 ;;Quote: defining general-purpose or application-specific types is the most fundamental programming activity in C++
3+;;Quote: a well designed user-defined type in C++ is used the same as a built-in type
3 ;;Quote: C++ types and data-hiding efficiently prevent accidental corruption of data. They do not provide secrecy and security
8 ;;Quote: a programming language specifies actions to be executed, and supplies concepts that help with programming
8+;;Quote: a programming language should be close to the machine, like C, and close to the problem, like C++
8 ;;Quote: a class is a type: it specifies how objects behave and how they are created, used, and destroyed. A class also specifies a representation
9 ;;Quote: a manageable program is organized as a tree or a directed acyclic graph with localized dependencies
10 ;;Quote: a program is a concrete representation of the ideas in a problem solution. Its structure should match the ideas
10+;;Quote: represent a separate idea as a class; a separate entity as an object; commonality between classes as a base class; and a container of objects as a template
10 ;;Quote: except for low-level types or math entities, avoid global data, global functions, public data, friends, direct access, type fields, inline functions, void*, pointer arithmetic, C arrays, and casts
11 ;;Quote: think of a program as a set of interacting classes and objects; not as a bunch of data structures manipulated by functions
26 ;;Quote: a function is a named part of a program that can be invoked as needed
26 ;;Quote: in C++, argument passing and returned values are identical to initialization of variables
28 ;;Quote: a C++ reference to a type is a synonym for the variable it is initialized to; used for overloaded operators, functions, and both sides of assignments
45 ;;Quote: an overloaded or hidden name can cause difficult errors; minimize by avoiding names like 'i' for globals or variables in large functions
47 ;;Quote: create a C++ object at its definition and destroy it at the end of scope
47+;;Quote: global and static data are initialized once and not destroyed
50 ;;Quote: the size of a C++ object is some multiple of the size of a 'char'
50+;;Quote: a 'char' is a signed or an unsigned integer; an 'unsigned char' may be significantly less efficient than a 'char'
50 ;;Quote: in C++, 'unsigned int' is seldom a good idea; e.g., 'unsigned surprise= -1' is legal
57 ;;Quote: in C++, pointer arithmetic is defined only within an array; the difference of two pointers is the number of array elements between them
62 ;;Quote: a 'const' reference can be the address of an initialized temporary; allows flexible initialization; useful for function arguments
104 ;;Quote: if possible, use the programming language instead of writing a comment
105 ;;Quote: a comment should be used for each file, class, template, nontrivial function, global variable, exceptional code, and very little else
110 ;;Quote: except for local names, a name should refer to only one type, value, function, or object in a program
125 ;;Quote: try to avoid functions that modify call-by-reference arguments. They make a program harder to read
125+;;Quote: reference arguments should use 'const' if the argument is not modified; allows literal and expression arguments; improves readability
130 ;;Quote: argument matching rules for C++: exact match, integral promotions, standard conversions, user-defined conversions, parameter ellipsis; must be unique at a level
140 ;;Quote: if you design a private language with macros, it will be incomprehensible to others
140+;;Quote: use 'const', 'inline', and 'template' in place of macros and C's preprocessor constructs
143 ;;Quote: a data type is a concrete representation of an idea or concept; e.g., 'float'
144 ;;Quote: a type separates the incidental details about the implementation of an object from the essential properties for using an object
146 ;;Quote: if restrict access to a data structure then only member functions can modify the data, cause illegal values, and define how to use the data
147 ;;Quote: use 'this' in C++ to refer to the object that invoked a member function; primarily used for pointer manipulation
148 ;;Quote: a 'const' member function can read but not write its object
148+;;Quote: a member function can "cast away const" if the object is modified but it appears constant to its users; e.g., caching values, maintaining statistics, updating use counts
150 ;;Quote: use a constructor to initialize an object instead of using a function; less error prone
150+;;Quote: a C++ constructor has the same name as the class itself
156 ;;Quote: to allocate an object, need to know its size
156+;;Quote: C++ requires recompilation if the size of a class object is changed; for efficiency
157 ;;Quote: to define a class need to define a complete set of operations. This is an important shift of emphasis from defining a data structure; lots of benefits
181 ;;Quote: a concept is not isolated; it derives its power from its relationships to related concepts
181+;;Quote: use derived classes to express hierarchical relationships; i.e., commonality between classes
187 ;;Quote: need to determine the actual type to use a derived class. Ensure a homogeneous set, use a type field, or use virtual functions
187+;;Quote: a base class is commonly used for container classes such as set, vector, and list; the container may be homogeneous or heterogeneous
187+;;Quote: virtual functions identify the type of an object in a type-secure way
188 ;;Quote: a type field leads to two kinds of errors in large programs: failure to test the type field and missed cases in a switch
188+;;Quote: virtual functions avoid the need for type tests and case switches. They take nearly the same space as a type field
209 ;;Quote: with single inheritance, shared information tends to move towards the root of the tree; root classes become a global name space and a muddle
211 ;;Quote: a class member can be 'private', 'protected',or 'public'. Private members implement a class and protected members implement derived classes
216 ;;Quote: delete objects of a derived class with a virtual destructor in the base class; it will know the size of the object
217 ;;Quote: a constructor is not an ordinary function: not virtual, special access to memory management, no 'this' object, no pointer to function
217+;;Quote: can turn a constructor into an ordinary function that calls the constructor and returns a constructed object
225 ;;Quote: C++ operator overloading can overload function calls, array indexing, pointer dereference, assignment and initialization. May define type conversions and restrict copies and deletions
226 ;;Quote: to prevent ambiguities, C++ operator overloading can not change precedence, change expression syntax, or define operator tokens
227 ;;Quote: the name of an overloaded C++ operator is 'operator' followed by the operator, e.g., 'operator<<'.
227+;;Quote: calling an overloaded C++ operator is the same as an explicit call to the operator function
231 ;;Quote: implement binary operators of complicated types with assignment operators; e.g., implement matrix addition in terms of '+='
233 ;;Quote: use explicit conversion operators to avoid ambiguities; use implicit conversions for frequently used conversions
233 ;;Note: a conversion is a form of typing; e.g., 'a(x)' can be interpreted as 'x is an a -- here's how'
237 ;;Quote: it may be cheaper and simpler to copy a return value than to allocate and deallocate an object on free store
238 ;;Quote: a copy constructor initializes an object by copying another object; used for initialization, argument passing, and function return
238+;;Quote: assignment and initialization are different operations; assignment only applies to properly constructed objects
238+;;Quote: classes with nontrivial destructors need to define an assignment operator and copy constructor
255 ;;Quote: a container class holds objects of another type (e.g., lists, arrays, sets); the type is irrelevant to the definer and crucial to the user
255+;;Quote: define a container class with a type parameter; e.g., a C++ template
257 ;;Quote: a C++ template is like a macro that obeys the scope, naming, and type rules of C++; the generated code is like separately compiled code
259 ;;Quote: templates should not depend on global information; they will be used for unknown types in unknown contexts
269 ;;Quote: an iterator class and its container class need to cooperate when elements are added or removed while the iterator is active
269+;;Quote: iterated containers usually support the notions of a current element and resetting an iteration to the beginning
279 ;;Quote: multiple template arguments for arithmetic types can lead to an explosion of generated functions and code; should use explicit type conversion instead
281 ;;Quote: a template with type arguments expresses a commonality across types
281+;;Quote: templates and type inheritance need each other. Without templates, derivation of similar class is tedious; without inheritance, templates lead to massive replication
293 ;;Quote: the author of a library can detect run-time errors but does not know what to do about them; use throw and catch
293+;;Quote: throw and catch separates error handling code from ordinary code; error handling is more regular than with error values or error call-backs

Related Topics up

ThesaHelp: references sa-sz (237 items)
Group: goals for a programming system   (21 topics, 983 quotes)
Group: object-oriented programming   (26 topics, 822 quotes)
Topic: programming language design (53 items)
Topic: extensible languages (71 items)
Topic: software portability (43 items)
Group: data type   (34 topics, 730 quotes)
Topic: abstraction in programming language (47 items)
Topic: object-oriented classes (67 items)
Topic: efficiency (96 items)
Topic: object-oriented data types (29 items)
Topic: preventing accidental errors (37 items)
Topic: information hiding (50 items)
Topic: abstraction in programming (67 items)
Topic: handling complexity (60 items)
Topic: abstraction (62 items)
Topic: object-oriented templates and containers (27 items)
Topic: object-oriented design (30 items)
Topic: restricted use of global variables (22 items)
Group: function   (12 topics, 232 quotes)
Group: parameters   (10 topics, 145 quotes)
Topic: parameters as argument place holders (15 items)
Topic: safe use of pointers (102 items)
Topic: variable as reference to a value (21 items)
Topic: alias names (39 items)
Topic: named constants and expressions (21 items)
Topic: local declaration of data (11 items)
Topic: local vs. global (29 items)
Topic: global declarations and variables (33 items)
Topic: primitive data type as memory (29 items)
Topic: primitive data types of a language (31 items)
Topic: pointers to data (55 items)
Topic: arrays (58 items)
Topic: comments (23 items)
Topic: source-rich system (27 items)
Topic: unique names (58 items)
Topic: localized understanding (43 items)
Topic: parameter passing by reference (11 items)
Topic: initialized constants (12 items)
Topic: generic operations and polymorphism (67 items)
Topic: type conversion (33 items)
Topic: language extension via macros (23 items)
Topic: macros (22 items)
Topic: abstract data type (64 items)
Topic: metaphysics and epistemology (99 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: security by access functions (10 items)
Topic: object-oriented methods (42 items)
Topic: pronoun reference (23 items)
Topic: immutable files and data (59 items)
Topic: object modification (10 items)
Topic: initialization of data (45 items)
Group: type declaration   (5 topics, 110 quotes)
Topic: object-oriented fields (28 items)
Topic: data type as a set of operations (38 items)
Topic: hierarchical structures (46 items)
Topic: type hierarchy (18 items)
Topic: types of object-oriented classes (18 items)
Group: data structures   (12 topics, 278 quotes)
Group: derived data types   (9 topics, 119 quotes)
Topic: abstract functions (11 items)
Topic: dynamic vs. static data type (24 items)
Group: type checking   (12 topics, 392 quotes)
Topic: union data type (12 items)
Topic: problems with type inheritance (20 items)
Topic: opaque and partially-opaque data types (14 items)
Topic: finalization of data (11 items)
Topic: replacement as a procedure call (10 items)
Topic: optimization of object-oriented programs (16 items)
Topic: memory management by garbage collection (116 items)
Topic: replacement as setting a reference to a value (10 items)
Topic: collection class (11 items)
Topic: type parameter (34 items)
Topic: system builds (43 items)
Topic: iterator (13 items)
Topic: exception handling by try..catch (53 items)
Group: exception handling   (12 topics, 314 quotes)
Topic: exception handling by unique value (8 items)

Collected barberCB 8/97
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.