Term
|
Definition
| a procedure that emits all members of a set one at a time |
|
|
Term
|
Definition
| when presented with one of its members eventually stops running and prints, and when presented with a string that is not a member does something else |
|
|
Term
| Software Construction's Three Main Steps |
|
Definition
Planning
Implementation, testing, and documenting
Deployment and maintenance |
|
|
Term
|
Definition
| the degree to which program modules rely on other modules. can be low (also loose or weak) or high (also tight or strong) |
|
|
Term
|
Definition
| when one module modifies or relies on the internal workings of another module |
|
|
Term
|
Definition
| when multiple modules share the same global variable |
|
|
Term
|
Definition
| when multiple modules share the same externally imposed data format, communication protocol, or device interface |
|
|
Term
|
Definition
| when one modules controls the flow of another by passing it some information |
|
|
Term
|
Definition
| when multiple modules share the same composite data structure, and use only part of it, possibly different parts. This can change the way a module reads or records because an unused field has been changed |
|
|
Term
|
Definition
| when modules share data (through a parameter for example) |
|
|
Term
|
Definition
| modules use public interfaces to share parameter-less data |
|
|
Term
|
Definition
Ignoring details of the specific application often makes things easier
The higher the degree of abstraction of a program, the more situations it can cover |
|
|
Term
|
Definition
| Order of Implementation, Design for Debugability, Avoid Cleverness like the Plague |
|
|
Term
|
Definition
Use assertions
When to turn off assertions: turn them off when your ready to release, but errors should be handled depending on the situation of the program
Switchable diagnostics: sometimes it helps to put in multiple debugs that can be switched using flags |
|
|
Term
|
Definition
Output first: write the output parts of the program first so you have something to test
Incrementally refine
Get it running and keep adding features |
|
|
Term
| Hierarchy of Bugs (declining order of severity) |
|
Definition
Plausible Erroneous Results
Inplausible Erroneous Results
Runtime crash or Incorrect mode
Runtime abort
Runtime diagnostics (possibly with abort)
Linker diagnostics
Compile warning
Compiler diagnostics |
|
|
Term
|
Definition
Test code for deviations
Formulate hypothesis about bug
Design a test for the bug
Test again |
|
|
Term
|
Definition
| Only the first error is useful, as most additional errors occur because of that first error. |
|
|
Term
|
Definition
| This works by checking if a statement is true or false. If it is true, the program continues. If it is false, It will outputs an error message and makes a call to abort(). Agnes describes this as a special mechanism used to make programs fail with an error message in C and C++. |
|
|
Term
| Derived Data Types ( Indirected ) |
|
Definition
|
|
Term
| Derived Data Types ( Record ) |
|
Definition
|
|
Term
| Derived Data Types ( Fundamental ) |
|
Definition
| character, integer, floating point, void |
|
|
Term
|
Definition
Ex:
float f() { return 3.1416; } //#1
float x = 3.1416; //#2
float& g() { return x; } //#3
float& r = x; //#4
int& h() { return *new int; } //#5
#1 declares f() to return a float, namely 3.1415. It does nto "return the IEEE 754 representation of 3.1416," nor does it "return 3.1416 by IEEE 754 representation" -- data representations are an implementation issue.
#2 declares x to refer to (i.e., to be a reference to) a float, initially 3.1416
#3 declares g() to return x, which is a reference to a float. It does not "return a reference to x," nor does it "return x by reference."
#4 declares r to refer to x, which is a reference to a float.
#5 declares the function h() to return an int&. But, that newly construced integer location (C++ object) has neither "names" nor "aliases" and is, therefore, a counterexample to the general claim that a reference is "an alternative name for an object or a function," i.e., an "alias." |
|
|
Term
|
Definition
| any value of the type widget |
|
|
Term
|
Definition
| anything that has state capable of representing a widget |
|
|
Term
|
Definition
| the data type whose values are all of the widget references |
|
|
Term
| Referent (or value or content) of a widget reference |
|
Definition
| the widget value, if any, that the reference's current state represents |
|
|
Term
| Reference-to-referent conversion |
|
Definition
| a compile time conversion that replaces a reference by its referent |
|
|
Term
|
Definition
|
|
Term
| Instance of the type widget |
|
Definition
|
|
Term
|
Definition
| any instance of a class type |
|
|
Term
|
Definition
| any widget-valued expression (an expression that denotes a value) |
|
|
Term
|
Definition
| any widget&-valued expression (an expression that denotes a variable) |
|
|
Term
| lvalue-to-rvalue conversion |
|
Definition
| the effect on an lvalue when its denotation (the reference it denotes) undergoes reference-to-referent conversion |
|
|
Term
|
Definition
| a reference whos referent is of a nonreference type (an instance of a class) |
|
|
Term
|
Definition
| a reference whos referent is a C++ object (any variable used to describe an instance of a class) |
|
|
Term
|
Definition
identity
handle
address
id
id number
name (if the identity is a string) |
|
|
Term
|
Definition
reference
memory location
contiguous memory segment
object
cell
registry (usually a special case)
variable (if the reference is named) |
|
|
Term
|
Definition
|
|
Term
|
Definition
bind (reference to reference's identity to referent)
assign
write to
mutate
modify
update
initialize (first time only)
rebind (non-first time only) |
|
|
Term
|
Definition
|
|
Term
|
Definition
const variables
literal constants (i.e., 12, 3.14, "Hello", etc.)
macro-defined constants (i.e., #define PI 3.14159)
values of an enum types (i.e., enum colors {red, green, blue} ) |
|
|
Term
|
Definition
| varibles should be created as late as possible, and into the innermost scope as possible |
|
|
Term
| Lifetimes of Variables regular definitions |
|
Definition
| variable lasts as long as the scope (aka from { to } ) |
|
|
Term
| Lifetimes of Variables static definitions |
|
Definition
| lasts from its definition till the program exits |
|
|
Term
| Lifetimes of Variables automatic definitions |
|
Definition
| lasts from its definition until its scope is exited |
|
|
Term
| Lifetimes of Variables dynamic definitions |
|
Definition
| lasts from the execution of the new-expression that creates it until the end of hte program or the execution of a delete-expression that deletes it |
|
|
Term
|
Definition
Note that...
int const * p;
declares p to be a pointer to an int const. But...
int* const p = &x;
declares p to be a pointer constant that points to the non-const int variable x.
int const* const x = &x;
declares x to be a pointer constant that points to an int constant. |
|
|
Term
|
Definition
const lvalues (expressions that denote variable) shall not be used to initialize non-const references, not may they appear on the left-hand side of an assignment expression
Applying the address-of operator (&) to a const lvalue yields a const address
Dereferencing a const address creates a const lvalue
The value of a const pointer is a consts address. Non-const addresses may be assigned to (stored into) const pointer variables, but the values retrieved from them will be const. On the other hand, const addresses shall nt be stored into non-const pointer variables, because when that value is retrieved it would be non-const
const member functions treat *this as a const-reference parameter |
|
|
Term
|
Definition
| x is non-const even when it is a member of a const instance of the surrounding class |
|
|
Term
|
Definition
| instances and pointers and references to instances of a derived class are implicitly converted to pointers and references (respectively) to public base classes. |
|
|
Term
|
Definition
| if B is a base class and p points to the base object of an instance of a class D derived from B, then dynamic_cast p - yields a pointer ot that instance and otherwise the null pointer. The same goes for references, except that a special exception gets thrown in the otherwise case. |
|
|
Term
|
Definition
A concept that consists of Overloading, Abstract Data Types (method overloading, Object-Oriented Programming (method overriding)
Note that overloading is performed by the compiler, while overriding happens at run time as a result of vtable mechanisms put in place by the compiler |
|
|
Term
|
Definition
| multiple functions can have the same name provided that they have distinct signatures (sequences of argument types) |
|
|
Term
| Abstract Data Types (method overloading) |
|
Definition
| multiple functions can have the same name provided that they are members of distinct classs |
|
|
Term
| Object-Oriented Programming (method overriding) |
|
Definition
| member functions (aka methods) of a derived class are invoked instead of their virtual namesakes in the base-class, even if hte object is accessed via a pointer to or reference to its base object |
|
|
Term
|
Definition
if we directly assign an object of a derived class to an object of a base class, we will get a compiler error
if we indirectly assign an object of a derived class to an object of a base class, the parts specific to the derived class will be sliced off, leaving only the parts that exist in the base class |
|
|
Term
|
Definition
| The term "generic programming" refers to the use of templates |
|
|
Term
|
Definition
Advantage to adding attributes to data typeis that you dont need access to the classes definitions.
Disadvantage to adding attributes to data types is that there is overhead in speed or space. |
|
|
