SG20 (ISO C++ Study Group on Education)
The most recent version of this document is available as an online HTML document at: https://cplusplus.github.io/SG20/latest/.
The version of the document that you are currently reading is available in the following formats:
online (HTML) format as a single large HTML document: https://cplusplus.github.io/SG20/PR_0.0.20/html
EPUB format: https://cplusplus.github.io/SG20/PR_0.0.20/guidelines.epub
online (HTML) format, split across multiple HTML documents: https://cplusplus.github.io/SG20/PR_0.0.20/html_split/ [Note: The support for this format needs more work (in order to beautify and fix linking issues).]
Older versions of this document are also available. In general version ver is available at https://cplusplus.github.io/SG20/ver/html. For example, version 0.1.0 (assuming that this version exists) would be available at https://cplusplus.github.io/SG20/0.1.0/html.
This document is intended to serve as a resource for instructors to assist in the preparation of courses on C++ in a variety of settings, including university, college, and industry environments. The main objectives of this document are as follows:
This document does not itself provide a curriculum for a single specific course, but is rather a set of guidelines that can be used to prepare curricula for a wide variety of courses that differ in focus and level of sophistication. (This said, however, some links to other documents with examples of curricula for specific courses may be included herein.) This document only intends to target the teaching of the most recently ratified version of the C++ standard. (This said, however, since older versions of this document are also available, these older versions may be of some use to those who need guidance in older versions of the standard, at least versions that do not predate C++20.)
[NOTE: This document follows the same license model as the C++ Core Guidelines. The LICENSE document is taken verbatim from the C++ Core Guidelines.] This document is made available under a MIT-style license. In simple terms, this license permits copying, use, modification, and creation of derivative works. A copy of the license is included in the section LICENSE.
Contributions to this document are welcome. If you would like to help with this project as a contributor, please read the section How to Contribute.
The various concepts (i.e., ideas) to potentially be covered are partitioned into modules. A module is very broad in scope and consists of numerous topics.
For each module, topics related to the module are identified. Then, for each topic, learning outcomes are specified. In order to address a wide variety of courses on C++, each topic is addressed at three proficiency levels. These proficiency levels allow each topic to be covered at more than one level of detail. This allows target audiences with different background and learning objectives to be accommodated. The three proficiency levels are as follows:
foundational: This level gives the learner the idea that a facility exists, what benefits it offers, and the basic ways of using it.
main: This level shows mainstream uses and techniques. For abstraction and organizational mechanisms it also demonstrates how to build them. This level should also give the learner a basic (but not detailed) understanding of how a facility might be implemented so that the learner can have a first-order understanding of any costs involved.
advanced: This level gives information suitable for an expert. For most topics there is an expert level of knowledge that most programmers rarely need and techniques that require detailed understanding of language rules or library implementation.
The remainder of this document is organized as follows. The various topics are listed grouped by module. In cases where a topic might be classified into more than one module, the topic is listed under the module of most direct relevance. This is done in order to avoid duplication of content. (In the case that a topic is equally relevant to multiple modules, the decision of which to select is made by a proverbial coin toss.) The order in which modules and topics are presented is not meant to imply any order of coverage in a course. The order in which items are listed is essentially arbitrary.
In the sections that follow, the various modules and topics are presented. There is one section per module. For each module, a table listing the various topics in that module is provided. The ID for a topic is linked to the detailed coverage of that topic that comes later in the document. If a topic has any learning outcomes at a given proficiency level, this is indicated by a checkmark (“✔️”). If a topic has no learning outcomes (simply because there are not any, not because the information is missing), this is indicated by an em dash (“—”). In the case that the information for a topic is completely missing, a question mark (“?”) symbol is used.
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Translation Units | ? | ? | ? |
[?] | Headers | ? | ? | ? |
[?] | Modules | ? | ? | ? |
[?] | Name Mangling | ? | ? | ? |
[?] | Phases of Translation | ? | ? | ? |
[?] | Separate Compilation | ? | ? | ? |
[?] | Linkage | ? | ? | ? |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Preprocessor Metaprogramming | ? | ? | ? |
[?] | Inclusion | ? | ? | ? |
[?] | Macros | ? | ? | ? |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Constant Objects | ? | ? | ? |
[?] | Declarations | ? | ? | ? |
[def] | Definitions | ✔️ | ✔️ | ✔️ |
[?] | Selection Constructs (e.g., if, ternary) | ? | ? | ? |
[?] | Looping Constructs (e.g., for, while, etc.) | ? | ? | ? |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Calling Functions | ? | ? | ? |
[?] | Parameter Passing (e.g., Passing By Value and Reference) | ? | ? | ? |
[func-args] | Default Arguments | ✔️ | — | — |
[?] | Returning Multiple Values | ? | ? | ? |
[?] | Overloading | ? | ? | ? |
[udl] | User-Defined Literals | ✔️ | ✔️ | — |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Special Member Functions | ? | ? | ? |
[?] | Types | ? | ? | ? |
[?] | Conversions | ? | ? | ? |
[?] | Constructors and Destructors | ? | ? | ? |
[?] | Move/Copy Constructors and Assignment Operators | ? | ? | ? |
[?] | Member Functions | ? | ? | ? |
[?] | Sum Types | ? | ? | ? |
[?] | User-Defined Literals | ? | ? | ? |
[?] | Special Member Functions | ? | ? | ? |
[?] | Guidelines for Special Member Functions (e.g., Rule of Five, Rule of Zero) | ? | ? | ? |
[copy] | Copy Semantics | ✔️ | ✔️ | — |
[?] | Moving and Copying | ? | ? | ? |
[?] | Lambdas | ? | ? | ? |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Virtual Functions | ? | ? | ? |
[?] | Run-Time Type Information | ? | ? | ? |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Constant Expressions and Constant Evaluation | ? | ? | ? |
[static-assert] | static_assert |
✔️ | ✔️ | — |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Concepts | ? | ? | ? |
[?] | SFINAE | ? | ? | ? |
[?] | Template Metaprogramming | ? | ? | ? |
[?] | Function Templates | ? | ? | ? |
[?] | Requires Clauses | ? | ? | ? |
[req-expr] | Requires Expressions | ✔️ | ✔️ | — |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[coe] | Categories of Errors | ✔️ | ✔️ | — |
[?] | errno | ? | ? | ? |
[?] | Error Codes | ? | ? | ? |
[eh] | Exception Handling | ✔️ | ✔️ | ✔️ |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Input/Output (I/O) | ? | ? | ? |
[?] | Containers, Iterators, and Algorithms | ? | ? | ? |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Graphical User Interfaces | ? | ? | ? |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Software Build Tools | ? | ? | ? |
[?] | Strategies for Handling Build Problems | ? | ? | ? |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Source-Level Debuggers | ? | ? | ? |
[?] | Code Sanitizers | ? | ? | ? |
[?] | Test Frameworks | ? | ? | ? |
[?] | Debugging Strategies | ? | ? | ? |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Compiler Toolchains | ? | ? | ? |
[?] | IDEs | ? | ? | ? |
ID | Unit | Foundational | Main | Advanced |
---|---|---|---|---|
[?] | Design by Contract | ? | ? | ? |
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objective |
---|---|
Foundational | Handling error codes with std::error_code |
Main | Designing APIs around std::error_code |
Advanced | — |
Why is this important? Why do we want to learn/teach this topic?
C++ offers a type safe way of passing around errors, contrary to the C-style of error handling, by this, we prevent bugs when passing error codes. Furthermore, error handling with error codes is more commonly used than exception handling, which only should be used in exceptional situations and in some environments is not feasible at all, e.g., in embedded or performance critical software.
Very brief introduction to the topic.
C++ offers std::error_code
, which encapsulates error codes in a type safe way. This topic describes how to use these error codes.
std::error_code
A student:
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
std::error_code
, e.g., obtain the message of the error code or check if an error occurred.This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
std::error_code
and how to use itstd::error_code
A student should be able to:
error_code
and design API that work with std:error_code
std::error_category
std::error_code
std::error_code
std::error_code
)std::error_code
and it’s APIsstd::error_category
(explorative)These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
error_category
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objective |
---|---|
Foundational | Standards exception hierarchy |
Main | Exception guarantees |
Advanced | — |
Why is this important? Why do we want to learn/teach this topic?
Exception handling is used to be able to continue the program in case of exceptional situations (like requesting a ridiculous amount of memory: bad_alloc
).
Very brief introduction to the topic.
There are other forms of handling difficult situations, but here we concentrate on exception handling and the peculiarities/characteristics of it. Because there are different forms, we should know when to use which type of handling special situations.
A student:
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
std::
calls may cause an exceptionThis section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
A student should be able to:
These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objective |
---|---|
Foundational | Categories of errors |
Main | Handling different categories of errors |
Advanced | — |
Why is this important? Why do we want to learn/teach this topic?
Programs can run in a normal state or erroneous state. Students should be able to identify different types of erroneous state and how to best handle them.
Very brief introduction to the topic.
This topic is an umbrella topic that refers to the different topics for types of errors and error handling.
A student:
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
No caveats at present.
This section lists important details for each point.
Errors can happen at different times during software lifetime.
There are different types of errors
A student should be able to:
These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objectives |
---|---|
Foundational | using and understanding UDLs |
Main | implementing your own UDLs |
Advanced | Advanced use ("{}, {}!"_fmt("Hello", "World") ) |
Why is this important? Why do we want to learn/teach this topic?
std::string
: "Hello, world!"s
std::chrono
: 3h + 10min + 5s
Very brief introduction to the topic.
12min + 17s
is terse, expressive and type safe.A student: * knows how to form numeric literals, e.g., 1.5f
means a float
of value 1.5
. * is familiar with the major C++ types: * bool
(Boolean type) * int
(Integer type) * double
(Floating-point type) * std::string
(Text type) * std::vector
(Collection type) * knows that namespaces exist, and namespace std
. * knows what using-declarations and using-directives are. [C++ object model: declarations]
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
using namespace std::string_literals
[1]."blah"s
as well as with std::string{"blah"}
.std::literals
.[1]: explain that it’s okay to use a using-directive to “activate” UDLs.
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
No caveats at present. #### Points to cover
This section lists important details for each point.
No caveats at present. ### Advanced {#udl-advanced}
These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Functions in C++ may be overloaded with different numbers and types of parameters. It may be of value to specify default arguments for some number of parameters, to allow a caller to avoid specifying arguments that rarely change, or to enable expanding the set of parameters while maintaining backward compatibility with existing callers.
Level | Objective |
---|---|
Foundational | Define and use functions with default arguments |
Main | — |
Advanced | refinement of default arguments through multiple declarations |
Why is this important? Why do we want to learn/teach this topic?
Default arguments allow the omission of arguments with obvious or common values. Also may be utilized to extend an existing function signature without forcing changes to existing calling code.
Very brief introduction to the topic.
Explain how default arguments work and how to define them.
A student is able to:
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
Subsequent redeclarations of the same function may add default argument values, which are then usable by callers. Though a single parameter cannot be given a default argument twice in the same translation unit, it is legal, though ill-advised, to give the same function different default arguments in different translation units.
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objectives |
---|---|
Foundational | Defining and calling functions with values |
Main | |
Advanced |
Why is this important? Why do we want to learn/teach this topic?
The fundamental element for code-reuse is a function. For functions to be useful, we need to parameterize them. Understanding how to do such is thus fundamental to programming in any language.
Very brief introduction to the topic.
Explain how to define functions with parameters and call them with values.
A student is able to:
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objectives |
---|---|
Foundational | Avoiding copies using const-reference modifiers |
Main | Using references to modify external data |
Advanced |
Why is this important? Why do we want to learn/teach this topic?
Very brief introduction to the topic.
Explain what a reference type is and how it constrasts with a value type.
A student is able to:
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
A student should be able to:
These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objectives |
---|---|
Foundational | Define and use requires-expressions to check satisfaction of expressions by given parameters |
Main | Define and use requires-expressions to check properties of expressions |
Advanced | — |
Why is this important? Why do we want to learn/teach this topic?
Requires-expressions allow a developer to perform compile-time evaluation on the validity of other expressions. These are fundamental to the ability to write concepts. [Compile-time programming: concepts]
Very brief introduction to the topic.
Requires-expressions are compile-time predicates which evaluate to true when their specified set of expressions are all valid for a given set of inputs.
A student is able to:
It is helpful if:
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
if constexpr
conditionThis section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
To require that expressions, which evaluate to a boolean value like sizeof(t) == 4
, evaluate to true
a nested-requirement is needed (e.g., requires sizeof(t) == 4;
). Omitting the requires
results in a simple-requirement, which is satisfied based purely on syntactic validity, not on the result of the operation.
This section lists important details for each point.
requires
and primarily used to check the result of an expression computable by the compiler, including concepts or other requires-expressions.typename
and used to verify the existence of a type with a particular identifier.requires requires
and show how to ever avoid writing it by using a concept. [Compile-time programming: concepts]noexcept
A student is able to:
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
noexcept
ness of an expression.This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
noexcept
, by using a trailing noexcept
keyword.struct S
{void foo() noexcept {}
void bar() {}
};
static_assert(requires(S s) { { s.foo() } noexcept; } ); // Succeeds. s.foo() is noexcept
static_assert(requires(S s) { { s.bar() } noexcept; } ); // Fails. s.bar() is not noexcept
{ ++x } -> C<int>
would substitute C<decltype((++x)), int>
and check that concept C is satisfied for those parameters.static_assert
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objectives |
---|---|
Foundational | Calling static_assert with a constant expression |
Main | Using static_assert to detect contract violations and improve error messages |
Advanced | — |
Why is this important? Why do we want to learn/teach this topic?
static_assert
allows the developer to enforce that conditions which can be checked during compilation will force build errors when violated. Additionally, they are the best mechanism by which a developer can pass useful information to other developers regarding what violation occurred or what must be done, instead.
Very brief introduction to the topic.
static_assert
is a compile-time evaluated function that asserts the truth of a supplied predicate, issuing an optional user-supplied error message if the predicate is false
.
static_assert
with a constant expressionA student:
sizeof(T)
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
static_assert
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
static_assert
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
static_assert
to verify preconditions of a meta-functionstatic_assert
to verify the results of meta-functions for known valuesThis section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
static_assert
to test the resultsstatic_assert
calls at the scope of the code they are guardingtemplate<typename T>
struct container {
std::map<int, T> vals;
// Test location #1
static_assert(
std::is_default_constructible_v<T>,
"container type T must be default constructible");i
void add(int key, T const& t) {
// Test location #2
static_assert(
std::is_default_constructible_v<T>,
"container type T must be default constructible");
// std::map::operator[] requires default constructible type for
// the value. This will cause a build failure deep in the
// implementation of std::map, when T is not default constructible
vals[key] = t;
}
};
struct NoDefCtor {
delete;
NoDefCtor() = double d) {}
NoDefCtor(
};
// If Test #1 was omitted, this would succeed
container<NoDefCtor> c; // This is ill-formed. Test #2 would catch this and provide a better
// error message for the user
42, NoDefCtor(1.0)); c.add(
These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objective |
---|---|
Foundational | Declaring variables |
Main | Declaring for programs |
Advanced | Special cases and peculiarities |
Why is this important? Why do we want to learn/teach this topic?
int baz;
void bar();
class Foo;
Very brief introduction to the topic.
Introduce names and their associated type in a scope.
A student:
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
No caveats at present.
This section lists important details for each point.
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objective |
---|---|
Foundational | Defining variables and ODR |
Main | Defining for programs |
Advanced | Special cases and peculiarities |
Why is this important? Why do we want to learn/teach this topic?
int baz = 42;
void bar() { /* implementation */ }
class Foo { /* class body */ };
Very brief introduction to the topic.
A definition extends a declaration, providing all that is needed for a complete entity, e.g., allocate memory for variables, provide the implementation for functions, complete definitions of data and function members of a class.
A student:
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
int baz = 42;
void bar() {}
class Foo {};
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
No caveats at present.
This section lists important details for each point.
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
This section lists important details for each point.
These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
Skeleton descriptions are typeset in italic text, so please don’t remove these descriptions when editing the topic.
Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.
Level | Objectives |
---|---|
Foundational | understanding how and when are copies made |
Main | implementing user-defined copy operations |
Advanced | special cases: copy elision |
Why is this important? Why do we want to learn/teach this topic?
Copy semantics allows the user to define how objects of a class get replicated and interact on a value level.
Very brief introduction to the topic.
Explains when and how objects are copied.
A student is able to: * explain what a C++ type is? [C++ object model: types] * explain what an object is? [C++ object model: objects], [C++ object model: constant objects] * define and understand class invariants?
It helps when a student is able to: * use move semantics [C++ object model: move semantics] * explain special member functions [C++ object model: special member functions]
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to:
* In other languages these differences are sometimes referred to as shallow and deep copy.
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
char*
). These ownership problems can generally be solved by using types whose copy operations have the appropriate semantics, e.g., std::string
instead of char*
to hold string values.This section lists important details for each point.
std::unique_ptr
(has no copy)A student is able to: * identify special member functions [C++ object model: special member functions]
It helps when a student is able to: * use move semantics [C++ object model: move semantics] * explain the rule of zero [C++ object model: rule-of-zero] * explain the rule of five [C++ object model: rule-of-five]
A list of things “a student should be able to” after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.
A student should be able to: * explain when they have to implement the copy operations for their own type * Copy constructor * Copy assignment operator * implement copy operations for their own types * Optional: explain when copying with basic and strong exception guarantees is useful
This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.
std::auto_ptr
)This section lists important details for each point.
These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.
When can copies be elided and when does the standard guarantee copy elision. References: * Abseil tip of the Week #166 * cppreference - Copy elision
See concepts.
[NOTE: This license is copied verbatim from the C++ Core Guidelines.]
Copyright (c) Standard C++ Foundation and its contributors
Standard C++ Foundation grants you a worldwide, nonexclusive, royalty-free,
perpetual license to copy, use, modify, and create derivative works from this
project for your personal or internal business use only. The above copyright
notice and this permission notice shall be included in all copies or
substantial portions of the project. This license does not grant permission
to use the trade names, trademarks, service marks, or product names of the
licensor, except as required for reasonable and customary use in describing
the origin of the project.
Standard C++ Foundation reserves the right to accept contributions to the
project at its discretion.
By contributing material to this project, you grant Standard C++ Foundation,
and those who receive the material directly or indirectly from Standard C++
Foundation, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable,
transferrable license to reproduce, prepare derivative works of, publicly
display, publicly perform, and distribute your contributed material and such
derivative works, and to sublicense any or all of the foregoing rights to third
parties for commercial or non-commercial use. You also grant Standard C++
Foundation, and those who receive the material directly or indirectly from
Standard C++ Foundation, a perpetual, worldwide, non-exclusive, royalty-free,
irrevocable license under your patent claims that directly read on your
contributed material to make, have made, use, offer to sell, sell and import
or otherwise dispose of the material. You warrant that your material is your
original work, or that you have the right to grant the above licenses.
THE PROJECT IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE PROJECT OR THE USE OR OTHER DEALINGS IN THE
PROJECT.
If you believe that anything in the project infringes your copyright, please
contact us at admin@isocpp.org with your contact information and a detailed
description of your intellectual property, including a specific URL where you
believe your intellectual property is being infringed.
Christopher Di Bella
Florian Sattler
Michael Adams
rwdougla
Before attempting to contribute any content for consideration for inclusion in this document, please read the information below and and the referenced documents as appropriate.
All contributions to this project must be made in accordance with the license in section License. This teaching-guidelines document only offers guidance on teaching C++ as it is specified in the current version of the C++ standard. So, content should be presented relative to the most-recently ratified version of the standard. A detailed explanation of how to present the material for a topic is given in:
Any potential contributors should ensure that they read this document. The following document may also be helpful in providing some general background on the modular approach to teaching followed herein:
In order to prepare content, it is important to understand what learning outcomes are, and how to prepare good ones. Some information on learning outcomes can be found in the References section. The following document offers a concise introduction to learning outcomes:
Some possible terms to include in the glossary:
D. Kennedy, A. Hyland, and N. Ryan. Writing and Using Learning Outcomes: A Practical Guide, 2007. https://www.researchgate.net/publication/238495834_Writing_and_Using_Learning_Outcomes_A_Practical_Guide.
B. S. Bloom, M. D. Engelhart, E. J. Furst, W. H. Hill, and D. R. Krathwohl. Taxonomy of educational objectives: The classification of educational goals. Handbook I: Cognitive domain. New York: David McKay Company, 1956.
Bloom’s Taxonomy. https://en.wikipedia.org/wiki/Bloom%27s_taxonomy.
Effective Use of Performance Objectives for Learning and Assessment (For Use With Fink’s and Bloom’s Taxonomies), University of New Mexico, School of Medicine, Teaching and Educational Development, http://ccoe.rbhs.rutgers.edu/forms/pdf/EffectiveUseofLearningObjectives.pdf.
Christopher Di Bella, Simon Brand, and Michael Adams. P1389R0 — Standing Document for SG20: Guidelines for Teaching C++ to Beginners. https://wg21.link/p1389.
Christopher Di Bella. P1725R0 — Modular Topic Design. https://wg21.link/p1725.
JC van Winkel, Bjarne Stroustrup, and Florian Sattler. P2193 — How to structure a teaching topic. https://wg21.link/p2193.
JC van Winkel and Christopher Di Bella. P1231 — Proposal for Study Group: C++ Education. https://wg21.link/p1231.
H. Hinnant, R. Orr, B. Stroustrup, D. Vandevoorde, and M. Wong. P2000 — Direction for ISO C++, Section 5.1. https://wg21.link/p2000r0.