| ■ | General | |||||
|
|
||||||
| ● | Date: 02/19/2025 |
|||||
| ● | Duration: 1 hour 20 minutes. | |||||
| ● | Questions can be on anything covered from the beginning up to and including the 02/17/2025. | |||||
| ● | Questions may specifically refer to the ourStr class (both versions) discussed during lectures and the IntSet classes of Assignments 1 and 2. | |||||
| ► | You may also be asked questions related to concepts/features discussed (and to be exercised in Assignment 3); e.g.: iterator, namespace, typedef and size_t. | |||||
| ● | Test will be closed books / notes / online-resources / discussions. | |||||
| ► | All allowed reference material will be provided as part of the exam or during the exam. | |||||
| ► | All electronics off during the exam. | |||||
|
|
||||||
| ■ | Recap of some of the topics: | |||||
|
|
||||||
| ● | 3 parts a (non-trivial) C++ program is typically organized into: interface, implementation, client/application. | |||||
| ► | What items commonly go into each part (and what don't logically belong). | |||||
| ● | User-defined data type development using C++ in object-based fashion (use of class in particular). | |||||
| ► | Information hiding: separating the interface (what) from the implementation (how). | |||||
| ○ | Header and source files and separate compilation. | |||||
| ○ | Key benefit: maintainability (modifiability, updatability, upgradability, . . .). | |||||
| ♯ | Interface has lower tendency to change (with time) than implementation. | |||||
| ► | Modular programming: building application with components (notably containers) that are organized as modules (interface-implementation pairs). | |||||
| ○ | Header-source file pairs and separate compilation. | |||||
| ○ | Key benefit: reusability. | |||||
| ► | Indigeneous versus exogeneous data type. | |||||
| ○ | ourStr Version 1 vs ourStr Version 2. | |||||
| ○ | IntSet of Assignment 1 vs IntSet of Assignment 2. | |||||
| ► | The "Big Four". | |||||
| ○ | Which is automatically invoked when. | |||||
| ○ | Automatic (compiler-supplied) versions, their shortcomings, and impacts of the shortcomings. | |||||
| ♯ | In particular: deep copying versus shallow copying. | |||||
| ○ | When and how to write custom (overriding) ones. | |||||
| ► | Operators. | |||||
| ○ | Which ones "come-for-free" (and what shortcomings if any). | |||||
| ○ | How to use operator overloading to override compiler-supplied assignment operator and to support additional operators. | |||||
| ► | Some key C++ (especially class-related) features, the roles they play and how to use them (both as a client/user and a developer/supplier). | |||||
| ○ | include directive (macro/inclusion guard). | |||||
| ○ | Instance-level variable and class-level variable. | |||||
| ○ | The invoking object and the this pointer. | |||||
| ○ | Accessors and mutators. | |||||
| ○ | Non-public helpers. | |||||
| ○ | Member functions (methods), non-member (free, ordinary) functions, and friend functions. | |||||
| ♯ | How-to's associated with each within the interface, implementation and client/application components. | |||||
| ♯ | (CAUTION: When writing code, there's no situation in the exam that warrants the use of the friend feature.) | |||||
| ○ | Initializer (or initialization)
list. (for use in constructors only) |
|||||
| ○ | Function with default arguments. | |||||
| ♯ | Its particular usefulness in covering constructors -> "multi-role" constructor. | |||||
| ○ | const keyword: three of the contexts (situations) and their semantics (meanings) of its use. | |||||
| ♯ | Declaring symbolic constant. | |||||
| ♯ | Specifying pass-by-const-reference. | |||||
| ♯ | Specifying accessor (protecting invoking object). | |||||
| ○ | Some specific items prone to misconceptions. | |||||
| ♯ | Whose data can an accessor not cause any side effect on. | |||||
| ♯ | Whose data can a member function
(method) directly access. (access meaning read for accessors and read/write for mutators) |
|||||
| ♯ | When does "=" mean assignment and when does it not (but mean what instead). | |||||
| ► | Object lifetime: construction -> utilization -> destruction. | |||||
| ○ | Who is/are the role player(s) in which of the phases. | |||||
| ● | Contract-based design methodology. | |||||
| ► | What the 3 key ingredients and the 3 key action
verbs are. (precondition, postcondition and class invariant; expect, guarantee and maintain) |
|||||
| ► | How the key ingredients interrelate. | |||||
| ► | How the key action verbs apply (relative to the key ingredients). | |||||
| ► | Who are the stakeholders (i.e., contract between which parties). | |||||
| ► | How the functions of a class are bound ("contractually") by invariants. | |||||
| ○ | Constructors <--> invariants. | |||||
| ○ | Destructors <--> invariants. | |||||
| ○ | Other mutators <--> invariants. | |||||
| ● | Good practices. | |||||
| ► | Program defensively. | |||||
| ○ | Principle of least privilege. | |||||
| ♯ | Reveal/enable only what is necessary and no more. | |||||
| ♯ | E.g.: don't use global variables. | |||||
| ♯ | E.g.: use appropriate parameter passing mechanism (by value, reference and const reference) in functions. | |||||
| ○ | Use friend functions
sparingly and only where warranted. (CAUTION - mentioned in class and/or above - repeated for emphasis: There shouldn't be situation in CS3358 assignments/exams to warrant its use - just have to know about the feature.) |
|||||
| ○ | Where possible, trap/address precondition violations and other "surprise" situations. | |||||
| ► | Client-oriented design. | |||||
| ○ | E.g.: specify position rather than index. | |||||
| ○ | E.g.: don't baffle client with implementation details. | |||||
| ► | "Don't make soup too salty". | |||||
| ○ | E.g.: not good to have using directive in header file. | |||||
| ● | Computer-based problem solving concepts. | |||||
| ► | Central role of data -> storage and access techniques for data -> data structures and algorithms. | |||||
| ○ | Classic ("tried-and-proven-to-be-commonly-useful") containers. | |||||
| ♯ | At "lower-level": array, linked list, etc. | |||||
| ♯ | At "higher-level": stack, queue, etc. | |||||
| ○ | Key motivating factors for studying data structures (and corresponding algorithms). | |||||
| ♯ | Solve the right problem right. | |||||
| ♯ | Use the right tool for the right problem. | |||||
| ♯ | Don't re-invent the wheel. | |||||
| ► | Abstraction. | |||||
| ○ | What it is and how it helps us in solving problems. | |||||
| ♯ | Underpinnings of just about all aspects of CS. | |||||
| ○ | Procedural abstraction: top-down progressive/stepwise refinement/specialization, modularization, divide and conquer. | |||||
| ♯ | Procedural (action-centered) paradigm. | |||||
| ○ | Data abstraction: bottom-up generalization. | |||||
| ♯ | Object (data-centered) paradigm. | |||||
| ► | Abstract data types (ADTs). | |||||
| ○ | Focusing on the interface (what), abstracting away (ignoring) the implementation (how). | |||||
| ♯ | One-to-many (in general) relationship between interface and implementation. | |||||
| ○ | C++ support: header and source files and separate compilation. | |||||
| ○ | Container ADTs. | |||||
| ♯ | What they are and what the "3 categories of operations (besides construction and destruction) typically supported by each" are . | |||||
| ♯ | Why so many different types of containers. | |||||
| ○ | Starter ADTs: set, multiset (bag), sequence (list) and sorted sequence (sorted list). | |||||
| ● | Specifying/implementing/utilizing container ADTs in C++ - some aspects: | |||||
| ► | Iterators. | |||||
| ○ | What are and why. | |||||
| ► | Enhanced scoping (name-conflict prevention) using custom namespace. | |||||
| ► | Symbolic representation of data type using typedef. | |||||
| ► | Use of size_t for sizing/counting/iterating. | |||||
| ○ | Pitfalls of using size_t. | |||||
| ( and whatever templating items below we get to cover up to and including the 02/17/24 |
||||||
| ● | Templating. | |||||
| ► | What it essentially enables one to do. | |||||
| ○ | What must hold true to make it possible. | |||||
| ► | Template function and template class. | |||||
| ○ | Provision data types must meet for successful use with templates. | |||||
| ► | Relatively simple example illustrating C++ templating mechanics/quirks. | |||||
| ○ | How to specify, implement, and use. | |||||
| ○ | How to organize (including work-around used to effect separation of interface from implementation). | |||||
| ► | Aspects of STL. | |||||
| ○ | What the 3 key components are. | |||||
| ♯ | containers (template classes), iterators, algorithms. | |||||
|
| ○ | What left-inclusive metaphor is. | ||||
|
|
||||||
| ■ | Others | |||||
|
|
||||||
| ● | Reference material. | |||||
| ► | Lecture Notes prefixed 301 through 308 and 311Templating. | |||||
| ► | Examples etc. (posted on class website). | |||||
| ● | You may want to check out sample past exam questions posted on the class homepage (under Other Resources). | |||||
| ► | You should not however, expect the questions to be identical in number, kind, topic coverage, etc. | |||||
| ► | Notion very ill-advised to harbor: I take it I will do well in current exams if I can do the sample past exam questions well. |
|||||
| ► | You should not have to worry about questions being written on topics we have not (or not yet) covered; some such questions may appear as sample past questions because the associated topics were appropriate at that time. | |||||
| ● | Do the following if you are eligible and intend to use extended time accommodation: | |||||
| ► | Follow proper procedure to request taking the exam at the ATSD. | |||||
| ○ | You typically need to do the request at least a certain number of (non-weekend?) hours in advance. | |||||
| ○ | The exam date of your request should be the same as the (regularly) scheduled date of the exam. | |||||
| ○ | The exam start time of your request should be closest to the (regularly) scheduled start time of the exam. | |||||