Map
Index
Random
Help
th

QuoteRef: stroB_1994

topics > all references > ThesaHelp: references sa-sz



ThesaHelp:
references sa-sz
Group:
object-oriented programming
Group:
operating system
Topic:
object-oriented classes
Topic:
structural equivalence vs. name equivalence of data types
Topic:
type conversion
Topic:
unique names
Topic:
initialization of data
Group:
goals for a programming system
Group:
type checking
Topic:
software portability
Topic:
initialized constants
Topic:
no need for replacement
Topic:
expression language
Topic:
notation for declarations
Topic:
dynamic vs. static data type
Topic:
abstraction in programming
Topic:
declarative vs. procedural representation
Group:
programming notation
Topic:
deployable module or assembly
Topic:
software components
Topic:
efficiency
Topic:
names as abbreviations for descriptions
Topic:
pronoun reference
Topic:
abbreviated input
Group:
parameters
Topic:
parameter passing by keyword or position
Topic:
vector processing
Topic:
arrays
Topic:
aliasing
Topic:
preventing accidental errors
Topic:
notations for brackets
Topic:
updating information with locking
Topic:
concurrency
Topic:
machine code and assembly language
Topic:
incremental compilation
Topic:
programming environment
Topic:
source-rich system
Group:
memory management
Topic:
type hierarchy
Topic:
pointers to data
Topic:
interface type
Topic:
dynamic type checking
Topic:
type reflection and introspection
Topic:
exceptions and undesired events
Topic:
exception handling by try..catch
Topic:
exception handling with resumption
Topic:
exception handling by termination
Group:
exception handling
Topic:
asynchronous processing
Topic:
interrupts
Topic:
information as a hint
Topic:
hardware for interprocess communication
Group:
type declaration
Topic:
namespace
Topic:
global declarations and variables

Reference

Stroustrup, B., The Design and Evolution of C++, Reading, Massachusetts, Addison-Wesley, 1994. Google

Quotations
22 ;;Quote: operating system research influenced C++: protection from access rights, initialization from capabilities, const from read/write access protection, exception handling from fault-tolerant systems
30 ;;Quote: a C++ class defines the type of members that represent an object, operations that manipulate objects, and access rights
36 ;;Quote: the C++ type system uses name equivalence instead of structural equivalence because it is safer and cleaner; everything has exactly one definition
36+;;Quote: C++ defines layout compatibility rules for structurally equivalent objects; allows explicit conversions for low-level services
37 ;;Quote: it is hard for a program to guarantee uniqueness, data type consistency, and initialization
37 ;;Quote: C++ is just one language in a system; it must work with program fragments written in other languages
41 ;;Quote: automatic conversion to smaller objects widely used; e.g., from 'int' to 'char'; could not remove from C++
57 ;;Quote: 'new' creates an object from raw memory by allocating the memory and calling a constructor to initialize that memory
59 ;;Quote: C++ has copy constructors because it is inefficient to first initialize an object to a default value and then assigning an object
80 ;;Quote: need implicit conversions for mixed-mode operations; otherwise get a quadratic explosion of functions
99 ;;Quote: allow declarations were needed. Used for initialize-only/single-assignment programming, references, initialized constants, and efficiency.
100 ;;Quote: every statement and declaration should be an expression that yields a value
100+;;Quote: should disallow uninitialized variables and multiple names per declaration
107 ;;Quote: static type checking avoids dynamic type errors and encourages a well-thought-out design
111 ;;Quote: a programming language must be useful to the average programmer using an average computer
111+;;Quote: most programming is mundane; done on low-powered computers with dated operating systems and tools
115 ;;Quote: a programming language should bridge the gap between ideas and computational primitives
115+;;Quote: to make a programming language more expressive, use declarative structures and explicit notation
116 ;;Quote: need to compose large and complex applications from separately developed parts without modification
121 ;;Quote: C++ follows the zero-overhead rule: a new feature can not decrease the efficiency of programs without the feature
155 ;;Quote: can use long, informative argument names in header files and short, convenient names in definitions; e.g., 'length_of_element_array' and 'n'
155 ;;Quote: with object-oriented programming, long argument lists and global variables become local state
155+;;Quote: keyword arguments are most useful in poorly written code; functions should have at most two arguments
157 ;;Quote: Fortran guarantees that multiple array arguments do not overlap; allows spectacular savings on vector hardware
158 ;;Quote: C++ lacks a 'no-alias' property because it can't be guaranteed, it may lead to accidental errors, and it is targeted to vectorizing computers
159 ;;Quote: the characters [, ], {, }, |, \, and ! are missing from widely used character sets; need to provide equivalent representations
190 ;;Quote: for concurrency, locking data is more fundamental than multi-tasking
190+;;Quote: use destructors to release a lock for exclusive access to data; simpler, more reliable, handles exceptions
201 ;;Quote: even though C and C++ are excellent languages for low-level systems work, assembly code can be significantly smaller and faster, and expensive to maintain
207 ;;Quote: want automatic, incremental compilation for minor changes
207+;;Quote: want easy access to program information that is derived by compilers
214 ;;Quote: 'new' needs memory placement arguments for hardware-specific addresses, custom memory allocation, and general resource management
225 ;;Quote: 'void*' is the root of the tree of class conversions; it is used if no other function matches a "more derived" class
304 ;;Quote: use pointers to data members to express the layout of a C++ class in an implementation-independent manner
307 ;;Quote: C++ run-time type mechanism: 'dynamic_cast' from a base class, an explicit 'typeid', and implementation 'type_info'
386 ;;Quote: need to define groups of exceptions; e.g., to catch any I/O library exception
388 ;;Quote: resource acquisition is initialization: resources released in reverse order of acquisition, and exceptions release allocated resources
391 ;;Quote: use termination instead of resumption for exception handling: simpler, discourages resource allocation attempts, resumption is not necessary
391+;;Quote: on resource exhaustion, do not attempt to allocate needed resources and resume. It leads to complicated interactions between a library and its users
392 ;;Quote: despite having resumption in Cedar/Mesa, every use of resumption become a problem and a better design replaced it
394 ;;Quote: need to map asynchronous events such as interrupts and exceptions to a process model as quickly as possible
394+;;Quote: nested, asynchronous exception handling is a prescription for chaos
397 ;;Quote: implement exception handling with a table of code address ranges, destructors, and exception handlers
404 ;;Quote: replace global declarations with a namespace; define a local synonym for the namespace and allow use of common namespaces without explicit name qualification


Related Topics up

ThesaHelp: references sa-sz (237 items)
Group: object-oriented programming   (26 topics, 822 quotes)
Group: operating system   (27 topics, 924 quotes)
Topic: object-oriented classes (67 items)
Topic: structural equivalence vs. name equivalence of data types (30 items)
Topic: type conversion (33 items)
Topic: unique names (58 items)
Topic: initialization of data (45 items)
Group: goals for a programming system   (21 topics, 983 quotes)
Group: type checking   (12 topics, 392 quotes)
Topic: software portability (43 items)
Topic: initialized constants (12 items)
Topic: no need for replacement (4 items)
Topic: expression language (14 items)
Topic: notation for declarations (20 items)
Topic: dynamic vs. static data type (24 items)
Topic: abstraction in programming (67 items)
Topic: declarative vs. procedural representation (54 items)
Group: programming notation   (14 topics, 221 quotes)
Topic: deployable module or assembly (12 items)
Topic: software components (11 items)
Topic: efficiency (96 items)
Topic: names as abbreviations for descriptions (35 items)
Topic: pronoun reference (23 items)
Topic: abbreviated input (10 items)
Group: parameters   (10 topics, 145 quotes)
Topic: parameter passing by keyword or position (13 items)
Topic: vector processing (15 items)
Topic: arrays (58 items)
Topic: aliasing (28 items)
Topic: preventing accidental errors (37 items)
Topic: notations for brackets (9 items)
Topic: updating information with locking (20 items)
Topic: concurrency (33 items)
Topic: machine code and assembly language (49 items)
Topic: incremental compilation (3 items)
Topic: programming environment (46 items)
Topic: source-rich system (27 items)
Group: memory management   (11 topics, 367 quotes)
Topic: type hierarchy (18 items)
Topic: pointers to data (55 items)
Topic: interface type (50 items)
Topic: dynamic type checking (43 items)
Topic: type reflection and introspection (28 items)
Topic: exceptions and undesired events (29 items)
Topic: exception handling by try..catch (53 items)
Topic: exception handling with resumption (31 items)
Topic: exception handling by termination (16 items)
Group: exception handling   (12 topics, 314 quotes)
Topic: asynchronous processing (30 items)
Topic: interrupts (25 items)
Topic: information as a hint (18 items)
Topic: hardware for interprocess communication (31 items)
Group: type declaration   (5 topics, 110 quotes)
Topic: namespace (19 items)
Topic: global declarations and variables (33 items)

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