Embracing Modern C Plus Plus Safely Glossary Word List (CloudMonk.io)
Embracing Modern C++ Safely Glossary Word List
Return to Programming Glossary, Glossaries, Embracing Modern C Plus Plus Safely | Embracing Modern C++ Safely, C Plus Plus | C++
See also:
* Embracing Modern C Plus Plus Safely Glossary | Embracing Modern C++ Safely Glossary
* Embracing Modern C Plus Plus Safely Table of Contents
* Embracing Modern C Plus Plus Safely Preface
* Embracing Modern C Plus Plus Safely Topics
* Embracing Modern C Plus Plus Safely Bibliography
* Embracing Modern C Plus Plus Safely Index
A
# ABI
# abstract class
# abstract interface
# abstract machine
# access level
# access specifier
# accessible (from a context)
# active member
# address space
# ADL
# aggregate
# aggregate class
# aggregate initialization
# aggregate type
# algebra
# algorithm selection
# alias template
# aliasing
# alignment (of an address)
# alignment requirement (of a type)
# allocating object
# allocator aware
# amortized constant time (of a repeated operation)
# API
# application binary interface (ABI)
# application programming interface (API)
# architectural insulation
# argument
# argument-dependent lookup (ADL)
# arithmetic type
# array-to-pointer decay
# as-if
# assignable (type)
# assignment operator
# atomic
# automatic storage duration
# automatic variable
B
# backward compatibility
# barrier
# base name (of a component)
# base specifier-list
# basic exception-safety guarantee
# basic guarantee
# basic source character set
# benchmark test
# binary search
# bit field
# block scope
# boilerplate code
# brace elision
# brace initialization
# braced-initializer list
# byte
C
# C linkage
# C++03 POD type
# C++11 memory allocator
# C++11 POD type
# C++17 pmr allocator
# cache associativity
# cache hit
# cache line
# cache miss
# call operator
# callable entity
# callable object
# callback function
# capture default
# captured by copy
# captured by reference
# captured by value
# captured variable
# carry dependency
# cast
# char-like object
# character literal
# CI
# CIMS
# class key
# class-specific memory management
# class template
# class template argument deduction
# class type
# closure
# closure object
# closure type
# code bloat
# code elision
# code motion
# code point
# code unit
# cold path
# Collatz conjecture
# Collatz function
# Collatz length
# Collatz sequence
# comma operator
# common initial member sequence (CIMS)
# common type
# compile-time constant
# compile-time coupling
# compile-time dispatch
# compile-time introspection
# complete-class context
# complete type
# component - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa physical unit of design consisting of two files: a header (or .h) file and a source (or .cpp) file, often accompanied by an associated test driver (or .t.cpp) file. extern template (359), Opaque enums (665), friend ’11 (1035), inline namespace (1068)" (EMCppSfe 2021)
# component local - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given (logical) entity (class, function, template, typedef, macro, etc.), that — even though it is programmatically accessible — it is not intended (often indicated by naming convention) for consumption outside of the component in which it is defined or otherwise provided. Opaque enums (664)" (EMCppSfe 2021)
# composite pattern - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa recursive design pattern that allows a single object or a group of objects to be treated uniformly for a common subset of operations via a common supertype; this pattern is useful for implementing part-whole hierarchies, such as a file system in which an object of the abstract Inode supertype is either a concrete composite Directory object, containing zero or more Inode objects, or else a concrete leaf File object. final (1020)" (EMCppSfe 2021)
# concepts – a C++20 feature that provides direct support for compile-time constraints on template parameters (limiting which potential template arguments match) to appropriately narrow the applicability of a template. Additionally, concepts can be used to add ordering between constrained templates — i.e., more constrained and less constrained templates can be implemented differently, and the most constrained one that is applicable for a particular invocation will be preferred for instantiation. Moreover, concepts afford advantages with respect to compile-time error detection and especially diagnostics. Prior to C++20, much of the same functionality was available using SFINAE and other advanced template metaprogramming techniques, but, among other things, concepts make expressing the requirements on template parameters simpler and clearer and allow constraining nontemplate constructors of class templates. static_assert (122), auto Variables (208), Generalized PODs ’11 (480), initializer_list (571), auto Return (1201)" (EMCppSfe 2021)
# concrete class - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone from which objects can be instantiated; see also abstract class. Inheriting Ctors (540), final (1008)" (EMCppSfe 2021)
# conditional compilation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe selective compilation of contiguous lines of source code, controllable from the command line (e.g., using the -D switch with gcc and clang), by employing standard C and C++ preprocessor directives such as #if, #ifdef, #ifndef, #else, #elif, and #endif. Generalized PODs ’11 (469)" (EMCppSfe 2021)
# conditional expression - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that (1) consists of an application of the ternary operator (?:) or (2) is contextually convertible to bool and used to determine the code path taken in control-flow constructs such as if, while, and for, or as the first argument to a short-circuit logical or ternary operator (&&, ]] | | , or ?:). [[noexcept Operator (615)" (EMCppSfe 2021)
# conditional noexcept specification - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone having the form noexcept (<expr>) where <expr> is both a conditional expression and a constant expression, used to determine at compile time whether that function is to be declared noexcept(true). noexcept Operator (639)" (EMCppSfe 2021)
# conditionally compile - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe act of performing conditional compilation. Generalized PODs ’11 (469)" (EMCppSfe 2021)
# conditionally supported – implies, for a particular feature, that a conforming implementation may choose to either support that feature as specified or not support it at all; if it is not supported, however, the implementation is required to issue at least one error diagnostic. Attribute Syntax (13), Generalized PODs ’11 (425)" (EMCppSfe 2021)
# conforming implementation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone (e.g., a compiler) that satisfies all of the requirements of the version of the C++ Standard it attempts to implement." (EMCppSfe 2021)
# constant expression - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that can be evaluated at compile time. Deleted Functions (59), static_assert (115), Braced Init (224), constexpr Functions (257), constexpr Variables (302), Generalized PODs ’11 (431), initializer_list (554), User-Defined Literals (836), constexpr Functions ’14 (960), noexcept Specifier (1091)" (EMCppSfe 2021)
# constant initialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXinitialization of an object (e.g., one having static or thread storage duration) with values and operations that are evaluable at compile time. Function static ’11 (75)" (EMCppSfe 2021)
# constant time - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa bound on the runtime complexity of a given operation such that execution completes within a constant time interval, regardless of the size of the input; see also amortized constant time." (EMCppSfe 2021)
# contextual convertibility to bool - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given expression E, that the definition of a local variable b, such as bool b(E), would be well-formed; see also conditional expression. See also contextually convertible to bool. explicit Operators (63)" (EMCppSfe 2021)
# contextual keyword - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan identifier, such as override (see Section 1.1.“override” on page 104) or final (see Section 3.1.“final” on page 1007), that has special meaning in certain specific contexts but can otherwise be used like any other identifier, e.g., to name a variable or function. override (104), final (1007)" (EMCppSfe 2021)
# contextually convertible to bool - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given expression E, that E may be used to direct-initialize — e.g., bool b(E); — a bool variable, where even an explicit conversion operator (see Section 1.1.“explicit Operators” on page 61) to bool may be used, in contrast to implicit conversion, for which converting constructors and conversion operators that are declared as explicit are always excluded. Contextual conversion occurs when the core language must test an expression as bool, such as is required by an if or while statement, the condition of a ternary operator (?:), or a conditional noexcept specifier (see Section 3.1.“noexcept Specifier” on page 1085). See also contextual convertibility to bool. noexcept Specifier (1129)" (EMCppSfe 2021)
# continuous integration (CI) – the (typically automated) practice of continually recompiling all source code and running all tests as changes are made to a code base." (EMCppSfe 2021)
# continuous refactoring - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe practice of making broad incremental changes to a legacy code base, often involving the consolidation of duplicative components at a lower level in the physical hierarchy. deprecated (147)" (EMCppSfe 2021)
# contract - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa bilateral agreement between the human user of a function and its implementer such that, provided all preconditions are met, all postconditions (along with any other promised essential behavior) are guaranteed; see also contracts. Generalized PODs ’11 (485), noexcept Operator (616), Rvalue References (714)" (EMCppSfe 2021)
# contract violation – the failure on the part of the caller of a function to satisfy all of its preconditions or, having satisfied all preconditions, the failure of that function to satisfy all of its postconditions and/or live up to its promised essential behavior. Generalized PODs ’11 (485)" (EMCppSfe 2021)
# contracts – a highly anticipated feature in a future version of C++ that will provide for optional runtime checking of preconditions and postconditions as well as invaluable input to static analysis tools and perhaps, some day, even optimizers; see amini21." (EMCppSfe 2021)
# controlling constant expression - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa compile-time constant expression used in a conditional-compilation preprocessor directive such as #if or #elif. constexpr Functions (285)" (EMCppSfe 2021)
# conventional string literal - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa token consisting of a sequence of characters delimited on each end by double-quote (") characters, creating a null-terminated sequence of objects of type const char. The string literal is of type const char[N], where N is exactly one more than the integral (possibly zero) number of chars in the string. Note that prefixing a conventional string-literal token (e.g., “foo”) with an L (e.g., L"foo") creates a null-terminated sequence of four const wchar_t objects instead. See also raw string literal. Also note that the type of a string literal in C++ has always been const; however, C++03 had a deprecated implicit conversion to (nonconst) char* for compatibility with C, rendering string literals themselves dubiously mutable. Raw String Literals (113)" (EMCppSfe 2021)
# conversion operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXfor a given class S and type T, a possibly explicit member operator of the form operator T() used to convert expressions from type S to type T; see Section 1.1. “explicit Operators” on page 61. explicit Operators (61)" (EMCppSfe 2021)
# converting constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXany nonexplicit constructor, other than a copy or move constructor, invocable with a single argument. explicit Operators (61), noexcept Specifier (1131)" (EMCppSfe 2021)
# cooked UDL operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa user-defined literal operator that is passed the information obtained from an already-parsed string in the form of an unsigned long long, long double, or null-terminated const char*. User-Defined Literals (841)" (EMCppSfe 2021)
# cookie – an opaque value produced by an object or subsystem intended to be held by the client and potentially passed as an argument in some subsequent call into that same object or subsystem. Opaque enums (669)" (EMCppSfe 2021)
# copy assignable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXproperty of a type where assignment from an lvalue of the same type is valid. Generalized PODs ’11 (485)" (EMCppSfe 2021)
# copy assignment - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe process of invoking the assignment operator with two arguments of the same type (modulo cv-qualifiers) where the right-hand side of the argument is an lvalue. Generalized PODs ’11 (485), Rvalue References (752)" (EMCppSfe 2021)
# copy-assignment operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa special member function of a class X named operator= and taking a single argument whose type is X or, more commonly, lvalue reference to possibly cv-qualified X, where common practice is for it to have a return type of X& and to return *this. Deleted Functions (54), Generalized PODs ’11 (451), Rvalue References (714)" (EMCppSfe 2021)
# copy constructible - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXproperty of a type where construction from an lvalue of the same type is valid." (EMCppSfe 2021)
# copy construction - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXconstruction of an object from an lvalue of the same type (modulo cv-qualifiers). Rvalue References (764)" (EMCppSfe 2021)
# copy constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that, for a given type X, takes, as its first argument, a possibly cv-qualified lvalue reference to X; any subsequent parameters must have default arguments. Deleted Functions (54), Generalized PODs ’11 (437), Rvalue References (714)" (EMCppSfe 2021)
# copy elision - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan optimization in which copies (and moves) are permitted to be elided under some circumstances, even if the elided operation would have had an observable side effect. The compiler may treat the source and the destination object of such a notional copy or move as referring to the same object, even across function call boundaries; see also return-value optimization. Forwarding References (390), Rvalue References (734)" (EMCppSfe 2021)
# copy initialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe initialization that occurs when using the = form of initialization, as well as when passing arguments to a function, returning by value from a function, throwing and handling exceptions, and in aggregate member initialization. auto Variables (211), Braced Init (215), Default Member Init (318), Generalized PODs ’11 (506)" (EMCppSfe 2021)
# copy initialized - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given object, that copy initialization has been employed. Braced Init (221)" (EMCppSfe 2021)
# copy list initialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXcopy initialization from a braced-initializer list. Braced Init (226), Default Member Init (318), initializer_list (555)" (EMCppSfe 2021)
# copy operation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXeither copy construction or copy assignment. Deleted Functions (53), Generalized PODs ’11 (522), noexcept Operator (627), Rvalue References (715)" (EMCppSfe 2021)
# copy semantics – implies, for an operation on two objects (a destination and a source), that once an operation completes, the destination and source objects have the same value and the value of the source object remains unchanged. Deleted Functions (54), noexcept Operator (627), Rvalue References (742), User-Defined Literals (852)" (EMCppSfe 2021)
# copy/swap idiom - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone, commonly used (perhaps overused) to achieve the strong exception-safety guarantee when propagating the value of an object having potentially throwing copy operations, in which a local copy of the source value is made and, if that operation does not fail via an exception, a nonthrowing swap operation is then used to exchange the value of the destination object with that of the local copy. Note that using this idiom with a throwing swap still offers the basic guarantee. noexcept Operator (636), noexcept Specifier (1097)" (EMCppSfe 2021)
# copyable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given object, that one or more copy operations can be applied." (EMCppSfe 2021)
# core language specification - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe part of the C++ Standard that does not describe the Standard Library: clauses 1–16 in C++11 and C++14, clauses 1–19 in C++17, and clauses 1–15 in C++20. Generalized PODs ’11 (482)" (EMCppSfe 2021)
# core trait - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa standard trait (e.g., std::is_trivially_copyable) that corresponds to a term (e.g., trivially copyable) used in the core language specification and whose implementation typically requires a compiler intrinsic; see also interface trait. Generalized PODs ’11 (482)" (EMCppSfe 2021)
# critical section - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa region of code that must be guarded to prevent race conditions (a.k.a. data races) resulting from concurrent execution by multiple threads. Function static ’11 (71)" (EMCppSfe 2021)
# CRTP - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for curiously recurring template pattern." (EMCppSfe 2021)
# curiously recurring template pattern (CRTP) – one in which a class template, B, parameterized by a single type, D, is intended also to be a base class of D — e.g., template <typename T> class Crtp; class Derived : public Crtp<Derived> { /*...*/ } — so named because it was allegedly discovered independently and used repeatedly throughout the 1990s; see Section 3.1.“friend ’11” on page 1031. friend ’11 (1041)" (EMCppSfe 2021)
# currying – transforming a function that accepts multiple arguments into a sequence of functions that each takes a single argument, such that invoking each returned function with the same respective argument as presented in the original function will return the same value as did the original one — i.e., if f(a,b,c) == curry(f)(a)(b)(c) — presumably named after the logician Haskell Curry. Lambdas (598)" (EMCppSfe 2021)
# cv-qualification – the (possibly empty) set of cv-qualifiers of a given type. Rvalue References (726)" (EMCppSfe 2021)
# cv-qualifier - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone of two keywords, const or volatile, used to qualify variables, types, and nonstatic member functions. Forwarding References (379), Rvalue References (724), Ref-Qualifiers (1153)" (EMCppSfe 2021)
# cyclic physical dependency - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa dependency among two or more physical entities that implies all involved entities are directly or indirectly physically dependent on each other. extern template (374)" (EMCppSfe 2021)
# cyclically dependent - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a set of entities, that there exists a direct or indirect (often physical) dependency among them; see also cyclic physical dependency. Function static ’11 (75)" (EMCppSfe 2021)
D
# dangling reference - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone to an object whose lifetime has ended. Ref-Qualifiers (1171), decltype(auto) (1212)" (EMCppSfe 2021)
# data dependency - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone in which the evaluation of an operation requires the result of another to have already been computed. carries_dependency (999)" (EMCppSfe 2021)
# data-dependency chain – a chain of evaluations that has a data dependency between each consecutive evaluation in the chain. carries_dependency (998)" (EMCppSfe 2021)
# data member - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa member variable of a class, struct, or union; if declared static, the variable will be shared among all objects of the type. alignas (168)" (EMCppSfe 2021)
# data race - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa defect in a multithreaded program or system in which the ordering of events among threads or processes, respectively, is insufficiently constrained to guarantee correct operation. Function static ’11 (68)" (EMCppSfe 2021)
# death test - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of unit test that verifies program termination occurs when expected (and thus involves termination of the test driver itself); implementing such tests typically requires a test driver that forks and then performs the death test in the child process, observing (from the parent process) that the expected output and exit status were produced." (EMCppSfe 2021)
# debug build - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa mode in which code can be compiled that favors the ability to detect and diagnose bugs, often including the enabling of assertions via <cassert> or other assertion libraries. Generalized PODs ’11 (468)" (EMCppSfe 2021)
# decay (of a type) – a colloquial term for implicit trivial conversions such as array to pointer, function to pointer, and lvalue to rvalue. Rvalue References (815)" (EMCppSfe 2021)
# decimal floating-point (DFP) – a representation of floating-point numbers that involves storing the mantissa as a power of 10, as opposed to the classical (binary) floating-point representation in C and C++, which stores the mantissa as a power of 2. User-Defined Literals (862)" (EMCppSfe 2021)
# declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa statement that declares an entity, such as a variable, function, or type; a declaration might be part of a definition; see also nondefining declaration and opaque declaration. static_assert (121), constexpr Variables (315), Variadic Templates (879), noexcept Specifier (1105)" (EMCppSfe 2021)
# declarator operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXeither *, &, &&, ::*, [], or (), any of which can be applied to form a compound type, respectively a pointer, an lvalue reference, an rvalue reference, a pointer to member, an array, or a function. Variadic Templates (889)" (EMCppSfe 2021)
# declare - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXto introduce into a scope the existence (and perhaps properties) of a (typically) named entity such as a variable, function, type, template, or type alias (such as a typedef). Deleted Functions (54), Forwarding References (390), Rvalue References (762)" (EMCppSfe 2021)
# declared type (of an object) – the type with which a (typically) named entity was declared. decltype (25)" (EMCppSfe 2021)
# deduced return type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa type that, for a given function whose return type is represented using the auto keyword, is deduced from (possibly implicit) return statements within the function definition (see Section 1.1.“Trailing Return” on page 124); note that auto at the start of a function declaration might instead be used to introduce a trailing, but nonetheless explicit, return type (see Section 1.1.“Trailing Return” on page 124). Lambdas (593)" (EMCppSfe 2021)
# deduction guide - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan implicit or user-defined rule that tells the compiler how to deduce template arguments for a class template from a provided initializer — available as of C++17." (EMCppSfe 2021)
# default constructed – implies, for a given object, that it has been created without an initializing expression. Generalized PODs ’11 (478), Rvalue References (752)" (EMCppSfe 2021)
# default constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that can be invoked without arguments. Generalized PODs ’11 (437), Rvalue References (754), noexcept Specifier (1136)" (EMCppSfe 2021)
# default initialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXinitialization that (1) for a class type, invokes the constructor that would be invoked if the initializer were empty parentheses (i.e., () ), (2) for an array type, default initializes each of its elements, and (3) in all other cases, performs no initialization. Note that default initialization can occur either because no initializer is supplied or as the result of value initialization. Braced Init (216), constexpr Functions (273), Rvalue References (765)" (EMCppSfe 2021)
# default initialized - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given object, that it was initialized via default initialization. Defaulted Functions (36), Braced Init (221), Default Member Init (322), Generalized PODs ’11 (493), Rvalue References (752)" (EMCppSfe 2021)
# default member initializer - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is associated with the declaration of a nonstatic data member of a class type that may be used during construction when no other initializer is provided (e.g., from a constructor’s member initializer list). constexpr Functions (270), Default Member Init (318), Generalized PODs ’11 (426)" (EMCppSfe 2021)
# defaulted (function) – implies a defaulted special member function. Generalized PODs ’11 (483), noexcept Operator (649), Rvalue References (757), noexcept Specifier (1086)" (EMCppSfe 2021)
# defaulted special member function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa (user-declared) special member function specified (see Section 1.1.“Defaulted Functions” on page 33) to be implemented using its default (i.e., compiler-generated) definition. Note that, in some situations (e.g., see Section 3.1.“union ’11” on page 1174), the compiler may choose to delete an implicitly or explicitly declared and defaulted function." (EMCppSfe 2021)
# defect report (DR) – an acknowledgment by the C++ Standards Committee of a defect in the current C++ Standard that is considered by ISO to apply to the currently active C++ Standard and is generally taken by implementers to apply to all previous versions of the C++ Standard where the change would be both applicable and practicable. Braced Init (218), constexpr Functions (280), Generalized PODs ’11 (432), Inheriting Ctors (551), initializer_list (561), Lambdas (594), noexcept Operator (615), Range for (681), Rvalue References (722), noexcept Specifier (1086)" (EMCppSfe 2021)
# defensive check - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone typically performed at runtime (e.g., using a C-style assert macro) to verify some condition that is impossible to occur in a correct program. A common use case is to verify, for a given function, that there has not been a contract violation — i.e., a precondition or postcondition violation — yet is entirely superfluous in a correctly implemented program. Generalized PODs ’11 (468), Rvalue References (744)" (EMCppSfe 2021)
# defensive programming - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa term, sometimes (mis)used, to suggest generally good programming practice implies the use of defensive checks to, for example, detect client misuse of a given function, by violating its preconditions when invoking it. final (1024)" (EMCppSfe 2021)
# define - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXto provide, for a given entity, any additional details, e.g., size, layout, address, etc., beyond just its declaration, needed to use that entity in a running process. Deleted Functions (58), Forwarding References (390), Rvalue References (762), Variadic Templates (880)" (EMCppSfe 2021)
# defined behavior – (1) behavior that is unambiguously codified in terms of C++’s abstract machine or (2) the full set of behaviors defined for a given component or library. Note that invoking a component or library out of contract is library undefined behavior (a.k.a. soft UB), which might lead to language undefined behavior (a.k.a. hard UB). noexcept Specifier (1112)" (EMCppSfe 2021)
# defining declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone — such as class Foo { }; — that provides a complete definition of the entity being declared. Note that a typedef or using declaration (see Section 1.1.“using Aliases” on page 133) would not be considered defining because, according to the C++ Standard, neither is a definition. Also note that an opaque enumeration declaration does not provide the enumerators corresponding to the complete definition and, although sufficient to instantiate opaque objects of the enumerated type, does not allow for interpretation of their values; hence, it too would not be considered defining; see also nondefining declaration. Rvalue References (729)" (EMCppSfe 2021)
# definition - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa statement that fully characterizes an entity (e.g., type, object, or function); note that all definitions are subject to the one-definition rule. Function static ’11 (68), constexpr Variables (315), Variadic Templates (879), noexcept Specifier (1105)" (EMCppSfe 2021)
# delegating constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that, rather than fully initializing data members and base-class objects itself, invokes another constructor after which it might perform additional work in its own body (see Section 1.1.“Delegating Ctors” on page 46). Delegating Ctors (46)" (EMCppSfe 2021)
# deleted - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies (1) for a given function, that it has been rendered inaccessible from any access level — either explicitly, by being annotated using = delete (see Section 1.1.“Deleted Functions” on page 53) or implicitly (e.g., see Section 3.1.“union ’11” on page 1174); or (2) for a given pointer to a dynamically allocated object, that the (typically global) delete operator has been applied to it (and no new object has subsequently been reallocated at that same address). Deleted Functions (59), Generalized PODs ’11 (483), Rvalue References (757), noexcept Specifier (1086)" (EMCppSfe 2021)
# deleted function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is either declared explicitly to be deleted or else is implicitly deleted (e.g., an aggregate that comprises a subobject whose corresponding special member function is unavailable). Defaulted Functions (33), Generalized PODs ’11 (523)" (EMCppSfe 2021)
# dependent type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone referenced in a template whose identity cannot be determined without knowing one or more of the arguments to the template itself. Inheriting Ctors (538), Generic Lambdas (981)" (EMCppSfe 2021)
# design pattern - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan abstract unit of commonly recurring design (e.g., Singleton, Adapter, Iterator, Visitor) that comprises a fairly small number of entities having distinct roles and identified interrelationships, is more general than can be expressed directly (e.g., as a template) in reusable code, and is often language agnostic (e.g., C++, D, Java, Python, Smalltalk). Note that CRTP, despite having a P (for pattern), is so formulaic and nonportable that it might be considered a C++ idiom instead. See gamma95: Chapter 3, section “Singleton,” pp. 127–138; Chapter 4, section “Adapter,” pp. 139–150; and Chapter 5, section “Iterator,” pp. 257–271, and section “Visitor,” pp. 331–349. Opaque enums (669)" (EMCppSfe 2021)
# destructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa special member function of a class (e.g., S) declared using the same name as the class but preceded by a tilde character (e.g., ~S) that is invoked implicitly when the lifetime of an object of that type ends on leaving the block in which the object was defined (automatic storage duration), when the main function returns (static storage duration), when the thread for which it is defined ends (thread storage duration), when the delete operator is applied (dynamic storage duration), or when the destructor is invoked explicitly within the program. Note that a class’s destructor automatically invokes the destructors for each of its nonstatic data members and base-classs objects. Generalized PODs ’11 (450), Rvalue References (752), noexcept Specifier (1086)" (EMCppSfe 2021)
# detection idiom - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa pattern used with templates to detect whether certain expressions are valid or ill formed for a particular sequence of template arguments, frequently used for compile-time dispatch; see otsuka20." (EMCppSfe 2021)
# devirtualize – replace, as a pure optimization of a given virtual function call, the indirect invocation of that function, through the object’s virtual-function table, with a direct one, assuming that the tool chain can somehow determine the dynamic type of the object at either compile time or link time; in such cases, the viable body of a virtual function can be inlined. final (1011)" (EMCppSfe 2021)
# DFP – short for decimal floating point." (EMCppSfe 2021)
# diffusion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXsee memory diffusion. alignas (183)" (EMCppSfe 2021)
# dimensional unit type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa type used for representing distinct kinds and dimensions of physical units, often providing protection against mixing units where such mixing would be erroneous. User-Defined Literals (864)" (EMCppSfe 2021)
# direct braced initialized - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given object, that it has been initialized using a braced-initializer list in a direct initialization context. Generalized PODs ’11 (455)" (EMCppSfe 2021)
# direct initialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXinitialization of an object using a parenthesized initializer, a braced-initializer list that is not preceded by =, a static_cast, or a type conversion using functional notation. explicit Operators (62), auto Variables (211), Braced Init (215), Default Member Init (318)" (EMCppSfe 2021)
# direct initialized - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given object, that it has been initialized via direct initialization. Braced Init (230), Rvalue References (754)" (EMCppSfe 2021)
# direct list initialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe use of list initialization during direct initialization. Braced Init (229), Default Member Init (318), initializer_list (555)" (EMCppSfe 2021)
# direct mapped - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of cache associativity in which every region in main memory maps to exactly one cache line, resulting in evictions when a second region that maps to the same cache line is accessed. alignas (182)" (EMCppSfe 2021)
# disambiguator – something that can be used to distinguish between two otherwise identical entities. For example, an unused additional function parameter of varying type is used as a disambiguator in an overload set, where the type to use for the disambiguating parameter is determined through metaprogramming by the invoker. Disambiguators can also be found in the syntax of the C++ language itself, e.g., when template or typename are needed to facilitate a proper parse. decltype (29)" (EMCppSfe 2021)
# distinguishing sequence - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa sequence of salient operations that, when applied to two objects of the same type having initially distinct platonic values — whose observable salient attributes might not be distinguishable — will eventually produce objects whose respective observable salient attributes are not the same. In other words, two value semantic objects of a given type do not have the same value if there exists a distinguishing sequence for them. Note that this sequence might vary depending on the initial values of the respective objects, which differs from the classical definition in finite automata theory in which the distinguishing sequence must be the same for all pairs of FSM states." (EMCppSfe 2021)
# divide and conquer – an approach to problem-solving where a task (e.g., sorting a collection of values) is divided into roughly equal-sized smaller tasks whose individual solutions can be used to solve the original, larger problem (e.g., merge sort). constexpr Functions (297)" (EMCppSfe 2021)
# DR – short for defect report." (EMCppSfe 2021)
# duck typing - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXdetermining the properties of a type, often in a template when choosing what algorithms to use with objects of that type, based solely on the syntactic interface it supports. As this approach has no way to check for or enforce semantic requirements, it must rely on the aphorism, “If it looks like a duck and walks like a duck, it must be a duck.” friend ’11 (1052)" (EMCppSfe 2021)
# dumb data - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXvalues, typically integral, whose specific meaning is defined and usable only in a higher-level context; see lakos20, section 3.5.5, “Dumb Data,” pp. 629–633. Opaque enums (668)" (EMCppSfe 2021)
# dynamic binding - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXdetermining, for a given object, the appropriate (virtual member) function to call based on the dynamic type of the object, often implemented via virtual dispatch. final (1015)" (EMCppSfe 2021)
# dynamic dispatch - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXinvoking the appropriate (virtual member) function based on the dynamic type of the object used to invoke it; see also virtual dispatch. final (1011)" (EMCppSfe 2021)
# dynamic exception specification - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe classic approach to exception specification using throw on a function declaration to list all of the exception types that might be thrown by a function. Supplanted by noexcept (see Section 3.1.“noexcept Specifier” on page 1085), this feature was deprecated in C++11, removed except for throw() as an equivalent of noexcept in C++17, and removed completely in C++20. noexcept Operator (618), noexcept Specifier (1085)" (EMCppSfe 2021)
# dynamic type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe runtime type (e.g., Derived) of an object, which might differ from the static type (e.g., Base) of a pointer or reference to it — e.g., Base* p = new Derived(); — where class Derived publicly inherits from class Base. Generalized PODs ’11 (416)" (EMCppSfe 2021)
E
# EBO – see empty-base optimization." (EMCppSfe 2021)
# embedded development - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXwriting, documenting, testing, and deploying software for embedded systems. Binary Literals (145)" (EMCppSfe 2021)
# embedded system - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that runs either on resource-limited hardware or in restricted environments, ranging from pacemakers to set-top entertainment devices. long long (93), noexcept Specifier (1101)" (EMCppSfe 2021)
# emplacement – an often more efficient alternative to copy construction in which the arguments to some value constructor of an object, rather than a reference to a constructed object itself, are used to construct a new object directly in its final destination — e.g., template<typename T> push_back(const T&); versus template<typename... Args> void emplace_back(Args&&... args); for the std::vector container; see, e.g., hu20. Forwarding References (390)" (EMCppSfe 2021)
# empty-base optimization (EBO) – a compiler optimization in which a base-class subobject that introduces no nonstatic data members is assigned the same address as another subobject of the derived-class object, provided they do not have the same type, to avoid any size overhead that would otherwise be required. Since C++11, compilers are required to perform this optimization if the derived class is a standard-layout class; otherwise, this optimization is allowed but not required. Had the same empty base type been used instead to create a data member, at least one additional byte would have been required within the footprint of the outer class; hence, the preference for making empty types base classes rather than data members. Note that C++20 introduces an attribute to address the inefficiency of empty data members. alignof (185), Generalized PODs ’11 (499), Lambdas (607), Variadic Templates (933), final (1028)" (EMCppSfe 2021)
# encapsulation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe colocation of (typically private) data along with manipulator and accessory functions used to act upon and retrieve that data; ideally the representation of the data can change, perhaps necessitating client code be recompiled, but without forcing any clients to rework their code; see also insulation. Opaque enums (663)" (EMCppSfe 2021)
# encoding prefix - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone placed before a string or character literal used to indicate a literal having a character type other than char. C++03 supported L for wchar_t; C++11 added u for char16_t, U for char32_t, and u8 for char (with UTF-8 encoding). User-Defined Literals (844)" (EMCppSfe 2021)
# entity - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone of the primary logical building blocks of a C++ program: value, object, reference, function, enumerator, type, class member, bit-field, template, template specialization, name-space, parameter pack, or this. decltype (25), Local Types ’11 (84), deprecated (147)" (EMCppSfe 2021)
# equality comparable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given type, that the homogeneous equality-comparison operators, operator== and operator!=, are defined and publicly accessible for the purpose of determining whether two objects of that type have (represent) the same value; see value semantics. Note that equality comparable is independent of homogeneous relational operators (<, <=, >, >=)." (EMCppSfe 2021)
# escalation – a form of refactoring (a.k.a. escalation technique) whereby parts of a pair of components that are mutually dependent are moved to a separate, higher-level component, enabling the removal of a potential cyclic physical dependency; see lakos20, section 3.5.2, “Escalation,” pp. 604–614. extern template (374)" (EMCppSfe 2021)
# essential behavior - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa superset of postconditions that includes aspects of the computation beyond the final result, such as runtime complexity, thread safety, exception safety, etc." (EMCppSfe 2021)
# exception agnostic – a particular style of implementation in which no exception-related syntax (try, catch, or throw) is used and hence no exceptions are thrown directly; nonetheless the code remains entirely exception safe with respect to injected exceptions (e.g., from derived classes or template arguments) through judicious use of RAII. Importantly, a fully exception agnostic library will be buildable and behave correctly, irrespective of whether support for exceptions in the compiler is enabled; note that exception and nonexception builds might not necessarily be ABI compatible. noexcept Operator (644), noexcept Specifier (1126)" (EMCppSfe 2021)
# exception free path - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone in which the flow of control (e.g., leading up to an invocation of a function) does not involve the throwing (and potentially catching) of any exceptions. noexcept Specifier (1134)" (EMCppSfe 2021)
# exception safe - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given function, that no defects will manifest nor resources leak when an exception escapes the function, even when that exception is thrown by a different function. More generally, a class, template, component, or library is exception safe if no defects or resource leaks occur as the result of an exception thrown during the evaluation of any function they define. noexcept Operator (644), noexcept Specifier (1126)" (EMCppSfe 2021)
# exception specification - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone of two forms — dynamic exception specification (deprecated) or noexcept (as of C++11) — used for a given function to indicate which or just whether, respectively, exceptions may be thrown by that function. Lambdas (593), Rvalue References (733)" (EMCppSfe 2021)
# excess N notation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa representation of a (typically signed) value v stored instead as v + N in an unsigned integer or bit field; the range for v is –N through M – N, where M is the largest value representable in that storage. IEEE floating-point formats make use of a form of this notation in which N (a.k.a. the bias) is one less than half the range of the unsigned storage: excess 127 [-126 to +127] for float and excess 1023 [-511 to +512] for double. Note, however, that the smallest and largest values are reserved and have special meaning, thereby reducing the range of representable exponents by 2. Digit Separators (155)" (EMCppSfe 2021)
# executable image – the representation of the program in relocatable binary format, typically stored in a file, that is (at least partially) loaded by the operating system into memory prior to execution of that program. noexcept Specifier (1135)" (EMCppSfe 2021)
# execution character set - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthat comprising all characters that can be interpreted by a running program on a specific platform including, at minimum, all of the characters in the source character set; control characters representing alert, backspace, and carriage return; and a null character (or null wide character), whose value is 0. Each character in the execution character set has an implementation-defined non-negative integral value, typically specified by a standard such as ASCII or Unicode. User-Defined Literals (844)" (EMCppSfe 2021)
# expiring object - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given object, that it no longer needs to hold either its value or the resources used to represent that value beyond the expression in which it is used. An object can be explicitly marked as expiring (e.g., using std::move), and expressions that designate objects so marked are xvalues. An object may also be implicitly deemed by a compiler to be expiring (e.g., for a temporary). Rvalue References (713)" (EMCppSfe 2021)
# explicit instantiation declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa directive (see Section 2.1.“extern template” on page 353) that suppresses implicit instantiation of a function template for the specified template arguments in the local translation unit, instead relying on an explicit instantiation definition, provided in exactly one translation unit within the program, potentially reducing compilation time and object-code size (but having no effect on the linked program’s executable size or run time); see also explicit instantiation definition. extern template (353)" (EMCppSfe 2021)
# explicit instantiation definition - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa directive (see Section 2.1.“extern template” on page 353), for a given template and specific template arguments, to instantiate and emit, in the current translation unit, any associated object code for entities that the template defines. Note that at most one such directive per template specialization may appear in a program, no diagnostic required; see also explicit instantiation declaration and Ill Formed, No Diagnostic Required. extern template (353)" (EMCppSfe 2021)
# explicit instantiation directive - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXeither an explicit instantiation declaration or an explicit instantiation definition. extern template (353)" (EMCppSfe 2021)
# explicit specialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa declaration or complete definition of a template specialization, used instead of instantiating the corresponding primary template (or any partial specialization) that might be selected when supplied with those same arguments at the point of use; see primary class template declaration and partial ordering of class template specialization." (EMCppSfe 2021)
# explicit template-argument specification - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe specification, when invoking a function template — e.g., template <typename T, typename U> func() — with a sequence of template arguments (e.g., int, double) surrounded by < and >, e.g., func<int, double>(0, 0); such explicitly specified template arguments will be used as is and will not require template argument deduction. Variadic Templates (895)" (EMCppSfe 2021)
# explicitly captured - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given variable, that it is named in the capture list of a lambda. Lambdas (582)" (EMCppSfe 2021)
# expression - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa valid sequence of operators and operands that specifies a computation; the evaluation of an expression may produce a value or cause side effects. Unlike a statement, expressions may be nested; see also outermost expression." (EMCppSfe 2021)
# expression alias - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan often considered, potential future feature of C++ that would support a parameterized alias for an expression. Such a feature would substitute the expression in-place, much like a hygienic macro, behaving like a forced inline function having automatically deduced result type and exception specification (see Section 3.1.“noexcept Specifier” on page 1085), but without the possibility of separating declaration and definition. noexcept Specifier (1146)" (EMCppSfe 2021)
# expression SFINAE – the use of SFINAE to exclude a function template specialization from consideration during overload resolution or a (class) template partial specialization during template instantiation, based on the validity of a particular expression. This form of SFINAE enables programming patterns such as the detection idiom. decltype (29), static_assert (122), Trailing Return (126)" (EMCppSfe 2021)
# expression template - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa template metaprogramming pattern in which overloaded operators return compound types that capture, within their template parameters, an entire expression. When these complex types are converted to a desired result type, an optimized implementation of the entire expression will be evaluated, instead of a potentially much less efficient evaluation of each individual subexpression. This general technique has been used often in libraries such as Eigen (eigen) to optimize computations involving large matrices. auto Variables (202)" (EMCppSfe 2021)
# extended alignment - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan alignment larger than the alignment of std::max_align_t. alignas (168)" (EMCppSfe 2021)
# external linkage - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXlinkage that allows a name to refer to the same entity across translation units; see also internal linkage." (EMCppSfe 2021)
F
# factory function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone whose purpose is to construct, initialize, and return an object, often by value. Rvalue References (778), User-Defined Literals (836), Variadic Templates (929)" (EMCppSfe 2021)
# fallible – implies, for a given function, that it might fail to satisfy its postconditions even when its preconditions are met; see also fallible implementation. noexcept Specifier (1118)" (EMCppSfe 2021)
# fallible implementation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that might fail to meet its contract, i.e., one that is fallible. noexcept Specifier (1120)" (EMCppSfe 2021)
# false sharing - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa pessimizing storage phenomenon where unrelated objects that happen to wind up on the same cache line in memory result in potentially severe runtime performance degradation when multiple threads attempt to access those respective objects concurrently; note that cache line access on typical hardware is automatically synchronized to avoid concurrent access from execution threads. alignas (174)" (EMCppSfe 2021)
# fault tolerant – implies, for a given distributed system (but never a function, component, or program), that failures are reliably handled (e.g., through graceful degradation rather than catastrophic failure) and often approximated through significant redundancy of interconnected hardware, design, and implementation so as to avoid any single point of failure. noexcept Specifier (1123)" (EMCppSfe 2021)
# fence - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa memory barrier; see also memory-fence instruction. Function static ’11 (82)" (EMCppSfe 2021)
# file extension - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe part of a filename after a final ., commonly used in modern operating systems to identify distinct file types. For example, typical standard practice for C++ developers is to use .h or .hpp for header files and .cpp, .cxx, or .cc for implementation (a.k.a. source) files. Opaque enums (667)" (EMCppSfe 2021)
# floating-point literal - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa literal denoting a floating-point value — e.g., 5.0 (double), 5.0f (float), or 5.0L (long double). User-Defined Literals (837)" (EMCppSfe 2021)
# floating-point-to-integer conversion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan implicit (truncating) conversion defined from floating-point types to integral types. User-Defined Literals (843)" (EMCppSfe 2021)
# floating-point type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXeither float, double, or long double." (EMCppSfe 2021)
# flow of control - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe execution path (i.e., sequence of operations executed) within a program; e.g., a file-scope static variable is initialized the first time the flow-of-control passes through its definition. Function static ’11 (68)" (EMCppSfe 2021)
# footprint - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe contiguous block of sufficiently aligned memory, as quantified by the sizeof and alignof operators (see Section 2.1.“alignof” on page 184), in which any nonstatic data members, base-class objects, vtable pointers, virtual-base pointers, and padding bytes needed to achieve proper subobject alignment reside; note that an object’s footprint is independent of any dynamically allocated memory that it might hold or own. extern template (357), Generalized PODs ’11 (452), Rvalue References (734), noexcept Specifier (1114)" (EMCppSfe 2021)
# forward class declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa forward declaration of a class, struct, or union, often used in the header file of a component to increase insulation. Opaque enums (675)" (EMCppSfe 2021)
# forward declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa nondefining declaration that resides ahead of its definition in the same translation unit (TU); typical use is (1) as an opaque declaration in a header file to facilitate consistent use across TUs and (2) to accommodate mutually dependent entities (e.g., within a single TU); see also local declaration. Opaque enums (662)" (EMCppSfe 2021)
# forward declared - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given entity in a particular translation unit (TU), that a nondefining declaration of it precedes its definition in that TU; see also local declaration. Opaque enums (664)" (EMCppSfe 2021)
# forwarding reference - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa function template parameter whose type is an unqualified rvalue reference to a template parameter (T&&). The deduced template argument corresponding to the template parameter will have the same value category as the function argument; reference collapsing will cause the function parameter of the instantiated function to be an lvalue reference or rvalue reference as appropriate. Forwarding References (377), Range for (680), Rvalue References (732), Variadic Templates (918), Generic Lambdas (971), auto Return (1184)" (EMCppSfe 2021)
# fragmentation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe process by which initially densely packed blocks of allocated memory, due to repeated allocation and deallocation, spread out across the address space over time — e.g., even when the total memory utilization does not increase. As a consequence, an allocation request for a sizable block of (contiguous) memory, which might have succeeded if requested earlier in the process lifetime, cannot be honored, despite there being an ample quantity of (noncontiguous) free memory available; see also memory diffusion. alignas (183)" (EMCppSfe 2021)
# free function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is not a member function; see also hidden-friend idiom. Deleted Functions (58), Generalized PODs ’11 (442), initializer_list (558)" (EMCppSfe 2021)
# free operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa built-in or user-defined operator that is not implemented as a member of a class; see also member operator. User-Defined Literals (839)" (EMCppSfe 2021)
# freestanding – implies a subset of the C++ Standard Library and core language (due to missing pieces of the library) intended to be run on platforms (such as embedded systems) that might not have a fully functioning underlying operating system. initializer_list (570)" (EMCppSfe 2021)
# full expression - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is not a subexpression of another expression; see outermost expression. Range for (693)" (EMCppSfe 2021)
# full specialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa (colloquial) synonym for explicit specialization." (EMCppSfe 2021)
# fully associative - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of cache associativity where any cache line can reference any region in main memory, obviating evictions until every cache line has been populated. alignas (182)" (EMCppSfe 2021)
# fully constructed – implies, for a given object, that its initialization, if any, has been completed. In particular, if initialization requires invoking a nondelegating constructor, fully constructed implies that the constructor has finished running, whereas if initialization requires invoking a delegating constructor, fully constructed implies that the target constructor has finished running. Delegating Ctors (47)" (EMCppSfe 2021)
# function designator – a term in the C Standard used to describe an expression having function type. Rvalue References (815)" (EMCppSfe 2021)
# function object - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa callable object (a.k.a. functor); see also invocable object. constexpr Functions (292), Default Member Init (328), Lambdas (574), Lambda Captures (990)" (EMCppSfe 2021)
# function parameter list - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe parameter declarations that specify the arguments with which a function may be invoked and, along with the function’s name, contribute to its signature." (EMCppSfe 2021)
# function parameter pack - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa pack expansion within a function parameter list that defines a function parameter for each element of a named template parameter pack. Variadic Templates (879)" (EMCppSfe 2021)
# function prototype - XXXXXXXXXXXXXXXXXXXXXXXXXXXXX(the specification of) a nondefining declaration of a function, which includes its signature, return type, and any other features, such as a noexcept specification (see Section 3.1.“noexcept Specifier” on page 1085) that would distinguish it from other like-named functions. Rvalue References (733)" (EMCppSfe 2021)
# function scope - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXused (colloquially within this book) to mean block scope. Note that the C++ Standard as published (through C++20) has an entirely different definition of this term, applying only to labels; that definition was removed from the Standard via a DR (see herring20). Function static ’11 (68)" (EMCppSfe 2021)
# function template - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that defines a compile-time parameterized function." (EMCppSfe 2021)
# function-template-argument type deduction - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa process effected by the compiler during overload resolution whereby each function template in the overload set is matched to the specified arguments and, if a valid set of template parameters can be deduced from the argument types, that specialization for the function template remains in the overload set (to be compared with other functions remaining in the set to determine if a unique best match can be found); see also SFINAE. auto Variables (195)" (EMCppSfe 2021)
# function try block - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone, including its catch clause, that serves as a function body, primarily used to provide exception handling in a constructor — e.g., C::C(X x) : d_x(x) try { /*...*/ } catch (...) { /*...*/ } — as exceptions thrown from the member initializer list will also be caught and acted upon (but not swallowed) by the exception handler of the function try block. constexpr Functions (268)" (EMCppSfe 2021)
# functor – a callable object. Lambdas (573), Generic Lambdas (968)" (EMCppSfe 2021)
# functor class - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa class type that supports callable objects. Lambdas (574)" (EMCppSfe 2021)
# functor type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe type of a callable object. Lambdas (573)" (EMCppSfe 2021)
# fundamental alignment - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXany alignment that is not greater than std::max_align_t; note that an alignment is always an integral power of 2 (1, 2, 4, 8, ...). alignas (168)" (EMCppSfe 2021)
# fundamental integral type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa synonym for integral type. long long (89)" (EMCppSfe 2021)
# fundamental type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXeither an arithmetic type, void, or std::nullptr_t. noexcept Operator (622), Rvalue References (803), final (1014), union ’11 (1174)" (EMCppSfe 2021)
G
# general-purpose machine - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa kind of computer that is designed for general applications, used widely in a variety of organizations. long long (93)" (EMCppSfe 2021)
# generalized PODs – a superset of C++03 POD types that are characterized in modern C++ as the intersection of trivial types and standard-layout types; see Section 2.1.“Generalized PODs ’11” on page 401." (EMCppSfe 2021)
# generic - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given class, function, object, or code fragment, that properties intrinsic to its behavior will be specified (at compile time) at the point where it is used (e.g., the relevant template is instantiated); see also generic programming. Generalized PODs ’11 (474)" (EMCppSfe 2021)
# generic lambda - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone having function parameters specified using auto so as to create a closure having a templated function-call operator. Lambdas (592), Generic Lambdas (968)" (EMCppSfe 2021)
# generic programming - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXwriting and using software in which the types of the objects being manipulated are themselves parameterized (e.g., using C++ templates). noexcept Operator (615)" (EMCppSfe 2021)
# generic type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is itself parameterized to accept, at compile time, type (or even non-type) arguments at the point at which it is instantiated; generic types are typically implemented as class templates in C++. Variadic Templates (878)" (EMCppSfe 2021)
# glvalue - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa value category that characterizes an expression as one from which the identity of an object or function can be determined; a value that is not a glvalue is necessarily an rvalue. Rvalue References (717), decltype(auto) (1259)" (EMCppSfe 2021)
# golden file - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa file containing the expected output of a (regression) test program. The test program is run, creating an output file that is then compared to the golden file, and if the files match, the test passes. Raw String Literals (114)" (EMCppSfe 2021)
# grouping macro - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that expands all of its arguments using __VA_ARGS__; a grouping macro is useful for circumventing syntactic annoyances that occur when a conventional macro is supplied a multiparameter template and thus with macro arguments containing commas that are not themselves nested within parentheses; e.g., SOME_MACRO(SomeTemplateC>) results in a syntax error. Generalized PODs ’11 (520)" (EMCppSfe 2021)
# guaranteed copy elision - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of copy elision that became mandatory in C++17: when an object is initialized with a prvalue of the same type (e.g., when returning from a function by value), no temporary object is created, and the destination object is constructed directly from the initializing expression, thereby eliminating any need for (accessible) copy operations. Braced Init (216), noexcept Operator (648), Rvalue References (791), Ref-Qualifiers (1163)" (EMCppSfe 2021)
H
# handle type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that defines a (typically lightweight) proxy for a physically separate object or resource, often wrapping a lower-level API that interacts directly with a raw resource. Rvalue References (792)" (EMCppSfe 2021)
# hard UB - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for language undefined behavior (a.k.a. language UB). noexcept Specifier (1115)" (EMCppSfe 2021)
# has identity - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXstates, for a given entity, that there is a way (e.g., by name or address) of identifying it (e.g., a glvalue) other than just reiterating its value (e.g., a prvalue). For example, a variable or data member thereof has identity, whereas a (nonstring) literal does not. Rvalue References (711)" (EMCppSfe 2021)
# header-only library - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa library whose full implementation is contained in header files and all defined functions are template or inline, removing the need to link library-specific object files. inline namespace (1067)" (EMCppSfe 2021)
# heap memory - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa synonym for dynamically allocated memory." (EMCppSfe 2021)
# hidden-friend idiom - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe design technique of declaring and defining a free function or free operator as a friend of a type within the scope of a class definition. A function implemented in this way is not visible to ordinary name lookup or even qualified lookup and will be found only through argument-dependent lookup — i.e., only when the type declaring the hidden friend is participating in overload resolution. Generalized PODs ’11 (472)" (EMCppSfe 2021)
# hide - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXpreventing access, by one entity, to another entity of the same name due to name lookup rules. For example, function-name hiding occurs when a member function in a derived class has the same name as one in the base class, but it is not overriding it due to a difference in the function signature or because the member function in the base class is not virtual; the hidden member function is accessible only via a pointer or reference to the base class. Another example occurs when a type S is hidden by a variable — e.g., struct S { } S; S s; (Error, S is not a type.) — i.e., one having the same name in the same scope. Inheriting Ctors (536), Lambda Captures (987)" (EMCppSfe 2021)
# hierarchical reuse - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa central paradigm of effective large-scale software development in which reuse is not limited to client-facing components but instead extends downward recursively to apply to all of the parts comprised by every component; see also Software Capital. final (1012)" (EMCppSfe 2021)
# higher-order function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that operates on other functions — i.e., takes a function as an argument or returns a function as its return value. Trailing Return (125)" (EMCppSfe 2021)
# horizontal encoding - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa convention whereby the meaning of certain bits that occur throughout an encoding (e.g., the microcode of a computer) are independent of the values of bits that occur elsewhere in that encoding." (EMCppSfe 2021)
# hot path - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe part of a program (specifically, generated object code) that is executed under normal and frequently encountered conditions; see also cold path. noexcept Specifier (1103)" (EMCppSfe 2021)" (EMCppSfe 2021)
# Hyrum's law - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe observation attributed to Hyrum Wright of Google that, given a sufficient number of users of an API, all observable behavior — notably including those that are undocumented, unintentional, nonessential, or unstable — will be depended upon by the user base. final (1012), friend ’11 (1036)" (EMCppSfe 2021)
I
# id expression - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa qualified id or unqualified id that can be used to name an entity or a set of entities, such as variable names, function names, and (after a . or ->) class member names. decltype (25), Rvalue References (780)" (EMCppSfe 2021)
# identity - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa property of an expression that can be identified uniquely, e.g., by name or address, independently of its value; see also has identity." (EMCppSfe 2021)
# IFNDR – short for ill formed, no diagnostic required." (EMCppSfe 2021)
# ill formed - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given program, that it is not valid C++. A compiler is required to fail to compile such a program and issue an appropriate diagnostic (error) message unless the ill formed nature is explicitly identified as one where no diagnostic is required (a.k.a. IFNDR); see ill formed, no diagnostic required. static_assert (120), Braced Init (227), constexpr Variables (303), User-Defined Literals (839), inline namespace (1067), auto Return (1203)" (EMCppSfe 2021)
# ill formed, no diagnostic required (IFNDR)– implies, for a given program, that it is ill formed in a way where the compiler is not required to issue a diagnostic. Typical examples of IFNDR, such as violations of the ODR, do not require a diagnostic because identifying the problem would either drastically impact compile times or be otherwise impracticable (if not impossible) in general. Delegating Ctors (50), static_assert (117), alignas (177), constexpr Functions (262), enum class (350), Opaque enums (666), Underlying Type ’11 (832), User-Defined Literals (840), Variadic Templates (900), carries_dependency (1000), inline namespace (1067)" (EMCppSfe 2021)
# immutable type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa user-defined type for which objects instantiated from that type, once fully constructed, cannot be changed. Ref-Qualifiers (1167)" (EMCppSfe 2021)
# imperative programming - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given language or programming paradigm, the use of a sequence of statements describing the evaluations of expressions that progressively mutate existing state (e.g., variables, objects) within a program instead of always creating new objects of immutable types as is common in declarative or functional programming. constexpr Functions ’14 (959)" (EMCppSfe 2021)
# implementation defined - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given behavior, that it is not fully specified by the Standard but that an implementation must specify in its documentation. Attribute Syntax (12), nullptr (100), alignas (168), constexpr Functions (295), enum class (335), Generalized PODs ’11 (501), Opaque enums (660), Rvalue References (747), noexcept Specifier (1093)" (EMCppSfe 2021)
# implementation inheritance - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of inheritance in which the implementation of a non-virtual or nonpure virtual function defined in a base class is inherited along with its interface in a derived class; note that inheriting the definitions of nonvirtual functions is sometimes referred to more specifically as structural inheritance; see also interface inheritance. Inheriting Ctors (541)" (EMCppSfe 2021)
# implicitly captured - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for given a variable, that it is captured by a closure by dint of it being named in the body of the lambda. Lambdas (582)" (EMCppSfe 2021)
# implicitly declared - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a special member function, that it is declared (and defined) by the compiler, obviating, in certain cases, an explicit declaration within the class definition. Generalized PODs ’11 (522)" (EMCppSfe 2021)
# implicitly movable entity - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that, as of C++20, will be treated as an xvalue, e.g., a variable having automatic storage duration that is either a nonvolatile object or an rvalue reference to a nonvolatile object. Rvalue References (735)" (EMCppSfe 2021)
# in contract - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given function invocation, that none of the preconditions in the function’s contract are violated. noexcept Specifier (1122)" (EMCppSfe 2021)
# in place – implies, for a given object, its construction directly into a particular memory location, e.g., by emplacement, rather than being passed a constructed object and then copying or moving it into place. Rvalue References (734)" (EMCppSfe 2021)
# in-process - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given value (such as an object’s address), that it is meaningful only within the currently running process. friend ’11 (1034)" (EMCppSfe 2021)
# incomplete type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that has been declared but not defined. Note that a class type is considered to be incomplete within its own class definition unless it is within a complete-class context for that type." (EMCppSfe 2021)
# indeterminate value - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that cannot be relied upon in any way (e.g., not even to not change spontaneously); for example, any nonstatic object of scalar type, such as int, that is not explicitly initialized has an indeterminate value, as do any bits within the footprint of an object used to ensure alignment (a.k.a. padding) or to hold a virtual table (or base) pointer. Most uses of an indeterminate value have undefined behavior; see Section 2.1.“Generalized PODs ’11” on page 401. Generalized PODs ’11 (435)" (EMCppSfe 2021)
# infallible – implies, for a given function, that it will never fail to satisfy its contract (e.g., due to resource limitations); see infallible implementation. noexcept Specifier (1118)" (EMCppSfe 2021)
# infallible implementation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa function definition that can reasonably be expected to satisfy its contract on any relevant platform regardless of the availability of system resources (e.g., heap memory, stack memory, file handles, mutexes). noexcept Specifier (1118)" (EMCppSfe 2021)
# inheriting constructors – the C++11 feature (see Section 2.1.“Inheriting Ctors” on page 535) whereby constructors can be inherited from a base class via using directives; each inherited constructor has essentially the same signature in the derived class, invokes the relevant base class constructor, and initializes derived-class data members in the same way an implicit default constructor would initialize them. Inheriting Ctors (538)" (EMCppSfe 2021)
# init capture - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of capture in a lambda expression, since C++14 (see Section 2.2.“Lambda Captures” on page 986), that specifies an initializer expression, essentially adding a new data member of deduced type to the closure object; see captured by copy and captured by reference. Lambda Captures (986)" (EMCppSfe 2021)
# inline namespace - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa variant of namespace, since C++11 (see Section 3.1.“inline namespace” on page 1055), in which a namespace declared using the inline keyword enables name lookup in an enclosing namespace (e.g., via ADL) to find names declared within a nested inline name-space, similar to providing a using (namespace) directive after the close of a conventionally nested namespace. What’s more, an inline namespace enables templates to be specialized from within the enclosing namespace. Note that name conflicts that might arise with an enclosing name are addressed quite differently for an inline namespace compared to a conventional one. inline namespace (1055)" (EMCppSfe 2021)
# instantiation time - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for template-instantiation time. static_assert (120)" (EMCppSfe 2021)
# instruction selection - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of compiler optimization in which optimal (otherwise equivalent) sets of instructions are selected based on the target platform and other aspects of the context in which those instructions will execute — e.g., vectorized operations or operations that will exhibit superior pipelining on the target CPU. noexcept Specifier (1136)" (EMCppSfe 2021)
# insulate - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXreduce or eliminate compile-time coupling (e.g., an implementation detail); see insulation. noreturn (96), constexpr Functions (299), extern template (369), Opaque enums (665)" (EMCppSfe 2021)
# insulating - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given interface, that implementation details are insulated and can change without forcing clients to recompile, only relink." (EMCppSfe 2021)
# insulation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa strong form of encapsulation in which the representation of private implementation details can change without forcing clients to recompile their code, but simply to relink it; see lakos20, section 3.11.1, “Formal Definitions of Encapsulation vs. Insulation,” pp. 790–791. Opaque enums (663)" (EMCppSfe 2021)
# integer literal - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone specifying an integral value. This value can be expressed (1) in decimal, in which case the literal sequence of (decimal) digits is in the range [0-9] and does not begin with 0; (2) in octal, in which case the (octal) digit sequence is limited to the range [0-7] and begins with 0; (3) in hexadecimal, in which case the literal begins with a 0x or 0X and is followed by one or more (hexadecimal) digits in the case-insensitive range [0-9a-f]; or, as of C++14, (4) in binary, in which case the literal begins with a 0b or 0B and is followed by one or more (binary) digits, 0 or 1 (see Section 1.2.“Binary Literals” on page 142). An integer literal may have an optional suffix, which may contain a (case-insensitive) L or LL and may also contain a (case-insensitive) U, e.g., 1L, 0377uL, or 0xABCuL. As of C++14, digit separators (') (see Section 1.2.“Digit Separators” on page 152) may be used to visually group digits (e.g., 1'000'000) and are especially useful in C++14 with binary literals (see Section 1.2. “Binary Literals” on page 142), e.g., 0b1100'1011. Note that every integer literal has a nonnegative value; expressions such as -1, -02, and -0x3 apply the unary-minus (-) operator to the non-negative int value of that integer literal. Note that if the value is too large to fit in int, then unsigned int, long, unsigned long, long long, and unsigned long long may be tried (in that order); however, the set of possible types for an integer literal may be constrained by its suffix. In particular, a decimal literal without a suffix always has a signed type and overflows if the value cannot be represented as a signed long long. More generally, if the value of the integer literal is not representable in any type that is compatible with the prefix and suffix, it is ill formed. User-Defined Literals (837)" (EMCppSfe 2021)
# integer-to-floating-point conversion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan implicit conversion from an integral type to a floating-point type. User-Defined Literals (843)" (EMCppSfe 2021)
# integer type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa synonym for integral type." (EMCppSfe 2021)
# integral constant - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa constant expression of integral type such as an integer literal or constexpr" (EMCppSfe 2021)
# variable of integral type (see Section 2.1.“constexpr Variables” on page 302). Note that a const-qualified variable of integral type that is initialized with a constant expression can be an integral constant too. Braced Init (223), constexpr Variables (303)" (EMCppSfe 2021)
# integral constant expression - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan expression of integral or unscoped enumeration type that is a constant expression, i.e., one that can be evaluated at compile time. alignas (169), alignof (184)" (EMCppSfe 2021)
# integral promotion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe implicit conversion of the type of an integral expression to a larger integral type that preserves value. In expressions, an integral bit field of less than the number of bits in an int is, by default, promoted to an int. In integral expressions, if a (binary) operation is applied to two integral expressions of different sizes, the smaller one will be promoted to the larger size before the operation is performed; see also integral constant. " (EMCppSfe 2021)
# integral constant expression, and integral type. Deleted Functions (56), enum class (334), Rvalue References (726), Underlying Type ’11 (832)" (EMCppSfe 2021)
# integral type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa category of fundamental types, codified by the std::is_integral trait, denoting one of bool, char, signed char, unsigned char, char16_t, char32_t, wchar_t, and the familiar signed and unsigned variations on short, int, long, long long (see Section 1.1.“long long” on page 89), and any implementation-defined extended-integer type; C++20 adds char8_t to this list. long long (89), Underlying Type ’11 (829)" (EMCppSfe 2021)
# interface inheritance - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of inheritance in which the interface (only) of one or more pure virtual functions declared in a base class is inherited in a derived class; see also implementation inheritance. Inheriting Ctors (541)" (EMCppSfe 2021)
# interface trait - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa (typically standard) trait, such as std::is_trivially_destructible, that describes an aspect of the usable interface of a type but does not correspond to a property named in the core language specification; see also core trait. Generalized PODs ’11 (482)" (EMCppSfe 2021)
# internal linkage - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXlinkage that prevents an entity from being referenced by name from another translation unit. Multiple distinct entities having internal linkage may have the same name, provided each resides in a separate translation unit; see also external linkage. Function static ’11 (77), constexpr Variables (307)" (EMCppSfe 2021)
# intra-thread dependency - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa data dependency that exists between evaluations within a single thread. carries_dependency (998)" (EMCppSfe 2021)
# invocable – implies, for a given entity f and zero or more arguments t1, t2, ..., tN, that one of (t1.*f)(t2, ..., tN), ((*t1).*f)(t2, ..., tN), t1.*f, (*t1).*f, or f(t1, t2, ..., tN) is well formed at the point of invocation — i.e., f must be usable and either a (1) callable entity, (2) pointer-to-member function, or (3) pointer-to-data member. Generalized PODs ’11 (482), Lambda Captures (986)" (EMCppSfe 2021)
# invocable entity - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is invocable; see also callable entity." (EMCppSfe 2021)
J
# join (a thread) – the operation by which execution of the current thread is suspended until execution of one or more other threads completes." (EMCppSfe 2021)
L
# lambda body – the statements in a lambda expression that will form the body of a lambda closure’s call operator. Lambdas (581), Generic Lambdas (976)" (EMCppSfe 2021)
# lambda capture - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa syntax by which variables from a reaching scope are made available for use within the body of a lambda expression. See also captured by copy and captured by reference. Lambdas (577), Variadic Templates (919), Generic Lambdas (969)" (EMCppSfe 2021)
# lambda closure - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe object created by evaluating a lambda expression. Lambdas (584)" (EMCppSfe 2021)
# lambda declarator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe function parameter list, mutability, exception specification, and return type of a lambda expression, all of which are imbued on the call operator of the lambda closure. Lambdas (591)" (EMCppSfe 2021)
# lambda expression - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan anonymous callable type having unnamed data members used to store values that are, by default, captured by copy (=) or else captured by reference (&); see Section 2.1.“Lambdas” on page 573. Local Types ’11 (83), Lambdas (576), Generic Lambdas (968), Lambda Captures (995), auto Return (1182), decltype(auto) (1206)" (EMCppSfe 2021)
# lambda introducer – a possibly empty lambda capture list, surrounded by [], used to begin a lambda expression; e.g., [](){} is a lambda expression that captures nothing, takes no arguments, does nothing, and returns void. Lambdas (582), Lambda Captures (986)" (EMCppSfe 2021)
# language undefined behavior - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthat which is not defined by the C++ Standard’s specification of the abstract machine; such behavior can, in theory, be mapped onto any behavior that the target hardware supports and that the host operating system will allow (a.k.a. hard UB). To quote Marshall Clow, “Your cat can get pregnant — even if you don’t have a cat!” (clow14, time 02:00). noexcept Specifier (1115)" (EMCppSfe 2021)
# leak - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe phenomenon (often considered a defect) in which a limited system resource, most usually memory, is acquired but never released." (EMCppSfe 2021)
# levelization technique - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone of nine classic refactoring techniques — escalation, demotion, opaque pointers, dumb data, redundancy, callbacks, manager class, factoring, and escalating encapsulation — used to remove (or ideally avoid) cyclic physical dependencies within a code base; see lakos20, section 3.5, “Levelization Techniques,” pp. 602–704." (EMCppSfe 2021)
# library undefined behavior - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthat which is not specified (explicitly or otherwise) in the contract of a function. When library undefined behavior occurs, for example, by calling a function in a way that fails to satisfy one or more of its preconditions (e.g., passing a negative value to a square-root function), the behavior of the program, from a language perspective, might still be well defined; however, library undefined behavior often leads to language undefined behavior (e.g., attempting to use substantively, in the implementation of a function, a null pointer that was passed in erroneously by a client). noexcept Specifier (1115)" (EMCppSfe 2021)
# lifetime extension - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthat which may happen to a temporary object when it is used to initialize a reference having automatic storage duration; in such cases, the temporary’s lifetime will be extended beyond its largest enclosing expression and instead will end along with that of the reference bound to it. Range for (680), Rvalue References (720), Ref-Qualifiers (1162), decltype(auto) (1213)" (EMCppSfe 2021)
# link-time optimization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXoptimization that occurs during linking, as opposed to that which occurs during compilation of an individual translation unit (TU), and thus has available the definition of an entire program. Though capable of performing transformations beyond what can typically be achieved locally within a TU, such global optimizations come at the cost of scaling poorly (e.g., superlinearly) with the size of a program. noexcept Specifier (1094)" (EMCppSfe 2021)
# linkage - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa characterization that denotes whether and to what extent distinct declarations of the same name will refer to the same entity: (1) a name having external linkage, such as a global function or variable, can refer to an entity that is defined in a different translation unit (TU); (2) a name having internal linkage, such as a function declared in an unnamed namespace, can refer to an entity that is defined in the same TU only; (3) a name having no linkage, such as a variable at block scope, always refers to a distinct entity that cannot be defined elsewhere. Note that the notion of linkage does not apply to a nonentity such as a type alias. Local Types ’11 (83)" (EMCppSfe 2021)
# list initialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXinitialization using a braced-initializer list. Braced Init (215), constexpr Functions (260), Default Member Init (331)" (EMCppSfe 2021)
# literal - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa token that represents a value (typically a constant expression) — e.g., an integer literal, floating-point literal, string literal, or user-defined literal (see Section 2.1.“User-Defined Literals” on page 835). User-Defined Literals (835)" (EMCppSfe 2021)
# literal type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone whose objects can be constructed (and potentially manipulated and accessed) at compile time; see Section 2.1.“constexpr Functions” on page 257. Deleted Functions (59), constexpr Functions (260), constexpr Variables (302), Generalized PODs ’11 (431), initializer_list (556), constexpr Functions ’14 (960)" (EMCppSfe 2021)
# local class - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone defined within the body of a function (as opposed to at namespace or class scope)." (EMCppSfe 2021)
# local declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa nondefining declaration, at file or namespace scope, of an external-linkage entity — other than one supplied by the header of some other component — for which there is no corresponding definition within the same translation unit (TU). Hence, unlike a forward declaration — e.g., in a header file — there is never an opportunity for a conventional compiler to verify that this specific declaration matches its definition (in some other TU). Note that local declarations are especially problematic for global functions and variables, which can be used substantively via their nondefining declarations alone; see Section 2.1.“Opaque enums” on page 660. Also note that this book’s use of the term local declaration is in relation to physical design and distinct from the more common logical notion of local (e.g., local type or local variable), which pertains to an entity that is declared in block scope. Opaque enums (662)" (EMCppSfe 2021)
# local scope - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa synonym for block scope — i.e., the scope implied by a compound statement, such as the body of a function or lambda expression." (EMCppSfe 2021)
# locality of reference - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe phenomenon whereby data that resides in close proximity in the address space is typically more likely to be accessed together (i.e., within close temporal proximity). alignas (181), Rvalue References (742)" (EMCppSfe 2021)
# logical - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given aspect of software design, the classical notions exclusive to language constructs such as classes, functions, inheritance, using relationships, and control-flow, as opposed to physical ones, e.g., involving files and libraries, compile- and link-time dependencies, and executable size." (EMCppSfe 2021)
# logical design - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe identification of relationships between (logical) entities, such as types, functions, and variables, irrespective of the specific (physical) files, translation units, and libraries in which those entities will eventually reside. “Fortunately, there is a serendipitous synergy between good logical design and good physical design. Given time, these two design goals will come to reinforce one another.” See lakos96, section 5.11, “Summary,” pp. 324–325, specifically p. 325 (bottom)." (EMCppSfe 2021)
# long-distance friendship – that which is granted to an entity not defined within the current component. friend ’11 (1035)" (EMCppSfe 2021)
# lossy conversion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that loses information and thus is not reversible for the entire domain upon which it is defined — e.g., converting a double to an int. Braced Init (222)" (EMCppSfe 2021)
# lvalue - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe value category of an expression whose evaluation determines the identity of an entity (i.e., an object, bit field, or function) that is not expiring. For example, an lvalue might be the name of a variable, the result of operator . or -> applied to a (non-expiring) object to access a member, the result of dereferencing a pointer, a call to a function whose return type is an lvalue reference, or any expression of function type. The built-in address-of operator (&) requires an lvalue as its operand; however, an expression designating a bit field may not have its address taken, even if it is an lvalue. decltype (26), auto Variables (196), Braced Init (216), constexpr Functions (267), Forwarding References (377), Generalized PODs ’11 (501), Lambdas (590), noexcept Operator (617), Range for (680), Rvalue References (710), Variadic Templates (875), Generic Lambdas (971), Lambda Captures (992), friend ’11 (1047), noexcept Specifier (1133), Ref-Qualifiers (1153), auto Return (1184), decltype (auto) (1211)" (EMCppSfe 2021)
# lvalue reference - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone formed, for a type X, as X&. A nonconst reference of this kind can be bound to only an lvalue, while a const lvalue reference can be bound to any expression having a type that is implicitly convertible to X, possibly resulting in the creation of a temporary and the associated lifetime extension that would ensue. Range for (701), Rvalue References (710), Lambda Captures (993), noexcept Specifier (1118)" (EMCppSfe 2021)
# lvalue-to-rvalue conversion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe implicit conversion that occurs when a prvalue is needed from an expression whose value category is glvalue — effectively, the process of reading the value of an object. Generalized PODs ’11 (501), Rvalue References (814)" (EMCppSfe 2021)
M
# managed allocator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that keeps track of each active allocation made through it such that it is able to unilaterally release all outstanding memory at destruction or, perhaps, via a single (e.g., release) operation (a.k.a. winking out). As of C++17, the C++ Standard Library supports this sort of functionality via two concrete classes derived from std::pmr::memory_resource: (1) a (special-purpose) monotonic-allocator resource that treats each individual deallocation as a no-op and (2) a (general-purpose) multipool-allocator resource that is substitutable for the global allocator supplied by the C++ run time. final (1021)" (EMCppSfe 2021)
# mandatory RVO – a requirement, as of C++17, for functions returning objects by value (a form of guaranteed copy elision) that, when the value in a unique return statement is a prvalue, the object, instead of being copied or moved, is constructed in place in its final destination in the calling function’s context. Rvalue References (807)" (EMCppSfe 2021)
# mangled name - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone created by the compiler and potentially used by the linker to uniquely identify distinct entities having the same name but defined in different contexts, e.g., entities having the same name but declared in multiple scopes or an (overloaded) function having multiple signatures. This feature of the ABI also enables type-safe linkage, which helps to avoid mismatches across translation units — e.g., that a function defined to take an int cannot be bound to (the use of) a declaration of a function having the same name but taking a long. A function template, in addition to its parameters, necessarily incorporates the return type as part of the mangled name. The use of C linkage eliminates such mangling, thereby preventing the overloading of such functions and function templates. Note that a global variable, e.g., a double, declared at file or namespace scope might, but is not required to, use a mangled name to identify its type in the ABI; hence, type-safe linkage cannot be relied upon to detect such mismatches; see local declarations. inline namespace (1056), noexcept Specifier (1114)" (EMCppSfe 2021)
# manifestly constant evaluated - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given expression, that it is used in a context that requires it be evaluated at compile time, such as an array bound or as an argument for a non-type template parameter; see also constant expression. constexpr Functions (258)" (EMCppSfe 2021)
# mantissa – the part of a floating-point representation that contains the significant digits; note that, when represented in binary, the leading 1 can be omitted. Digit Separators (155)" (EMCppSfe 2021)
# materialize – the act of temporary materialization — i.e., that of the compiler creating a temporary object in the address space to represent a given prvalue. Rvalue References (717), Ref-Qualifiers (1163)" (EMCppSfe 2021)
# maximal fundamental alignment - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthat of std::max_align_t, which, for any given platform, is at least as strict as that of every scalar type. alignof (193)" (EMCppSfe 2021)
# mechanism – a term used to characterize a class type capable of instantiating objects and whose purpose it is to provide a service, such as scoped guard, lock, socket, etc. A mechanism does not attempt to represent a platonic value, such as does std::complex<double>, nor even an in-process one (e.g., one whose value incorporates a memory address as a salient attribute). Delegating Ctors (51), Opaque enums (663), Rvalue References (789)" (EMCppSfe 2021)
# member - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan entity other than a friend function — such as a data member, member function, user-defined type, or type alias — that is declared to reside within the scope of a class type; see also hidden-friend idiom. union ’11 (1174)" (EMCppSfe 2021)
# member function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is a member of a class, struct, or union; see also free function. Rvalue References (793), Variadic Templates (892)" (EMCppSfe 2021)
# member initializer list - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe syntax used in constructors to initialize direct base classes, virtual base classes, and nonstatic data members. Note that the initialization order is fixed by the relative order in which base classes and data members are declared (some compilers may warn if the relative orderings differ). Delegating Ctors (46), Braced Init (230), Default Member Init (318)" (EMCppSfe 2021)
# member operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa user-defined (overloaded) operator (e.g., copy assignment) that is implemented as a member of a class and, unless implicitly static (e.g., class-specific operators new and delete), has access to the object’s this pointer as an implicit argument." (EMCppSfe 2021)
# memory barrier - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of synchronization primitive that is used to enforce an observable modification order for one or more memory locations (a.k.a. a fence), facilitating the coordination of access to data from concurrent execution contexts; see also multithreading contexts. Function static ’11 (80)" (EMCppSfe 2021)
# memory diffusion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe process by which the size of the working set increases over time, despite constant memory utilization; see also memory fragmentation. noexcept Operator (628), Rvalue References (788)" (EMCppSfe 2021)
# memory-fence instruction - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa machine-level instruction enforcing an observable modification order for one or more memory locations; see also memory barrier. carries_dependency (999)" (EMCppSfe 2021)
# memory fragmentation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe process by which the maximum available contiguous chunk of dynamically allocatable memory decreases over time, despite consistent memory utilization; see also memory diffusion." (EMCppSfe 2021)
# memory leak - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa type of resource leak involving specifically a memory resource. Note that use of class-specific memory allocators (e.g., implemented in terms of class-specific new and delete) can create a pseudo memory leak that can be as problematic as a genuine one; see lakos96, section 10.3.4, “Class-Specific Memory Management,” pp. 698–711, in particular, Figure 10-30, p. 709. Function static ’11 (74)" (EMCppSfe 2021)
# metafunction - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa compile-time operation whose parameters and results are code subject to compilation, such as functions, types, and compile-time constants, rather than runtime values. C++ metafunctions, such as the standard type traits provided in <type_traits>, are implemented as class, variable, and alias templates that compute types and/or compile-time constants based on the values of their metaparameters, supplied as template arguments. Note that modern C++ introduced a related feature; see Section 2.1.“constexpr Functions” on page 257. Forwarding References (381), Generalized PODs ’11 (469), noexcept Operator (643), constexpr Functions ’14 (963)" (EMCppSfe 2021)
# metaparameter - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa parameter that controls (a priori) the generation or the workings of an entity that is itself parameterized; for example, in a neural network, the number of layers is a metaparameter. Specifically (in C++), a metaparameter is a template parameter used at compile time to configure a section of code (e.g., one that defines a type or implements an algorithm). The allocator parameter in a C++11/14 standard container is a metaparameter that controls how memory is to be allocated and deallocated by the container. Note that, as of C++17, PMR provides a more flexible, runtime-based alternative for memory allocation. Variadic Templates (948)" (EMCppSfe 2021)
# metaprogramming - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe act of writing code whose input and output is, itself, code; specifically (in C++), a programming paradigm in which class and function templates are defined in such a way as to generate on-demand highly configurable interfaces and implementations under the control of their template parameters (metaparameters). In this paradigm, the template programmer writes code that, in turn, controls a sophisticated code generator (the template-instantiation engine), which will generate source code when the template is instantiated. C++ template metaprogramming was ushered into classical C++ during the 2000s in large part by Andrei Alexandrescu (alexandrescu01). decltype (30), constexpr Functions (257), Variadic Templates (876)" (EMCppSfe 2021)
# Meyers' singleton - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is implemented as a static variable in function scope, popularized by Scott Meyers; see meyers96, “Techniques,” item 26, “Allowing Zero or One Objects,” pp. 130–138. Function static ’11 (72)" (EMCppSfe 2021)
# microbenchmark - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa benchmark that is characterized by itself being small and typically performing one or a few operations many times in a loop; such benchmarks are often used to model real-world programs but might not be reflective of behavior in larger, long-running ones — e.g., due to memory diffusion." (EMCppSfe 2021)
# mix-in - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa type intended to provide a (perhaps partial) implementation of the desired derived type, often via (perhaps private) structural inheritance, such as in the CRTP (to achieve the EBO, at least until C++20); see Section 3.1.“final” on page 1007. A derived (e.g., adapter) type might multiply inherit publicly from both a mix-in and an abstract-interface, which can then be used to access and manipulate the mix-in polymorphically; see lakos96, Appendix A, “The Protocol Hierarchy Design Pattern,” pp. 737–768, specifically item 6, pp. 754–755." (EMCppSfe 2021)
# mixed-mode build – one that comprises multiple translation units built using distinct but compatible build modes (compiler settings) — e.g., different levels of optimization. inline namespace (1073)" (EMCppSfe 2021)
# mock – an artificial, often highly configurable, implementation of an abstract interface, controllable by a higher-level agent, used for the testing technique known as mocking. A well-designed mock implementation will often (1) record its inputs from the client for analysis by the testing agent and (2) provide specific outputs to be consumed (e.g., in response to inputs) by the client; see also mocking." (EMCppSfe 2021)
# mocking - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa testing technique that involves spoofing a client of an abstract interface using an artificial implementation that acts at the will of a higher-level agent orchestrating the test of said client. This approach enables the testing agent to assess and evaluate the behavior of the client even under unusual, exceptional, or error conditions; see also mock. final (1017)" (EMCppSfe 2021)
# modules – a C++20 feature that introduces a new way to organize C++ code, which provides better encapsulation than do conventional headers. Note, however, that modules, as currently defined, do absolutely nothing new with respect to insulation. friend ’11 (1041)" (EMCppSfe 2021)
# monotonic allocator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa managed allocator that dispenses memory from one or more contiguous regions of memory in a sequential fashion, yielding both fast allocations and dense memory utilization. Memory is reclaimed only when the allocator object itself is destroyed or its release method is invoked; individual deallocations are no-ops. Note that imprudent use of such an allocator can result in a pseudo memory leak. The C++17 Standard Library provides monotonic allocator functionality via the std::pmr::monotonic_buffer_resource class. alignof (190), final (1021)" (EMCppSfe 2021)
# most vexing parse - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa subtle syntactic ambiguity in the grammar of the C++ language between (1) a function declaration and (2) a variable definition that is direct-initialized with, e.g., a result of a function-style cast or a default-constructed temporary object of a user-defined type. In cases where such an ambiguity arises, the compiler resolves it in favor of a function declaration. For example, the statement — S s(int(my_obj)); — declares a function named s having a single parameter, of type int, and not, as one might reasonably think, a local variable s, of type S, that is initialized with my_obj cast to an int via a function-style cast. Similarly, the statement — S s2(MyType()); — declares a function having the decayed function-pointer parameter MyType (*)() and returning an S. Uniform initialization, using braces instead of parentheses, is often touted as solving the most vexing parse problem in that, e.g., MyType{} is always interpreted as a value-initialized MyType object, but constructor arguments within braces sometimes have a different meaning than those within parentheses, such as when a constructor has an initializer_list parameter. Inheriting Ctors (536)" (EMCppSfe 2021)
# movable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given object, that one or more move operations can be applied. Rvalue References (728)" (EMCppSfe 2021)
# move assignable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given type, that assignment from an rvalue of that type is well formed. Note that all copy assignable types are also implicitly move assignable unless the move-assignment operator is explicitly deleted. Generalized PODs ’11 (524)" (EMCppSfe 2021)
# move assignment - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXassignment that potentially harvests resources from an expiring source object to populate the target object more expeditiously (e.g., by avoiding memory allocation). Rvalue References (750)" (EMCppSfe 2021)
# move-assignment operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan overload of operator= for a particular type, X, that takes a single argument that is a (potentially cv-qualified) rvalue reference to X. Common practice is to have a return type of X& and to return *this. Rvalue References (710)" (EMCppSfe 2021)
# move construction - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXconstruction of an object from an rvalue of the same type (modulo cv-qualifiers); resources allocated to the expiring source object may be harvested to expedite the transfer of value. Note that a class might not have a move constructor distinct from its copy constructor, in which case move construction is copy construction (if available). Rvalue References (750)" (EMCppSfe 2021)
# move constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa constructor for a particular type, X, that has, as a first parameter, a (potentially cv-qualified) rvalue reference to X; any subsequent parameters have default arguments. Generalized PODs ’11 (437), Rvalue References (710)" (EMCppSfe 2021)
# move only – implies, for a given type, that it is a move-only type; i.e., objects of that type cannot be copied, only moved. initializer_list (570), noexcept Operator (641), Rvalue References (790), Ref-Qualifiers (1165)" (EMCppSfe 2021)
# move-only type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that provides one or more move operations but no copy operations, such as std::unique_ptr. noexcept Operator (644), Rvalue References (716)" (EMCppSfe 2021)
# move operation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXeither a move constructor or a move-assignment operator. Defaulted Functions (43), Deleted Functions (53), alignas (183), noexcept Operator (627), Rvalue References (710), noexcept Specifier (1093)" (EMCppSfe 2021)
# move semantics – the conventional meaning associated with an object that exploits the framework afforded by C++ rvalue references and the two additional special member functions, move constructor and move-assignment operator, whereby the value of an expiring source object can be transferred to a target object, perhaps more runtime efficiently, by repurposing resources allocated to the source, such that the source object might no longer represent its original value. Note that copy semantics satisfy the requirements of move semantics, but not vice versa; consequently, any type that supports copy semantics naturally supports move semantics unless the move special member functions have been explicitly deleted; see also value semantics. Rvalue References (710)" (EMCppSfe 2021)
# moved-from object - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that has been the source argument of a move operation. Note that the state of such an object will by definition satisfy all of its intended object invariants but might be otherwise unspecified; see also moved-from state. Rvalue References (788)" (EMCppSfe 2021)
# moved-from state - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe state of an object after it has been the source for a move operation. Depending on the object’s type, this state can be (1) its pre-move state, (2) a well-documented (possibly unique) empty state, (3) the default-constructed state, (4) some finite number of designated post-move states, or (5) an unspecified state. Note that — by definition — a moved-from object satisfies all of its object invariants and, hence, remains a valid object; see Section 2.1.“Rvalue References” on page 710. Rvalue References (789)" (EMCppSfe 2021)
# multithreading context - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone in which there might be multiple threads of execution running concurrently in the same address space (e.g., a single process). Function static ’11 (68)" (EMCppSfe 2021)
N
# naked literal - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe initial sequence of characters comprising a user-defined literal token excluding the UDL suffix. Note that a naked literal is always a syntactically valid literal in its own right. User-Defined Literals (839)" (EMCppSfe 2021)
# name mangling – the creation of a mangled name by the compiler or other tooling such as a symbolic debugger. Mangled names, in addition to the name, may contain scope and type information, as well as other decorations that are specific to the ABI. inline namespace (1067), noexcept Specifier (1149)" (EMCppSfe 2021)
# named return-value optimization (NRVO)– a form of copy elision that can occur when the (entire) operand of a return statement is the name of a nonvolatile variable having automatic storage duration of the same type (ignoring cv-qualifiers) as the return type. In such a case, a compiler can often avoid creating a distinct local variable before either copying or moving it into the object representing it in the caller’s context. Note that there is active interest for future versions of C++ (post C++20) in increasing opportunities for this optimized behavior and also making it mandatory — e.g., to facilitate the implementation of factory functions returning objects by value that are neither copyable nor movable. Rvalue References (734)" (EMCppSfe 2021)
# NaN - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for Not a Number, characterizing one of a fixed set of bit patterns in the representation of a floating-point type that do not represent a numeric value. In particular, equality and relational comparisons involving floating-point variables in this state always return false — even when applied reflexively, e.g., x == x. Hence, floating-point values do not fully obey all notions implied by value semantics. Generalized PODs ’11 (530)" (EMCppSfe 2021)
# narrow contract - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa function contract that contains one or more preconditions on its arguments or ambient program state, including, for a member function, any preconditions on the state of its underlying object (e.g., std::vector::front() requires, as a precondition, that it not be empty); see also wide contract and library undefined behavior. Rvalue References (715), final (1021), noexcept Specifier (1112)" (EMCppSfe 2021)
# narrowing conversion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone between scalar types that is known to be lossy, such as from double to float, or any conversion from an integral type to a floating-point type (e.g., bool to long double) or vice versa (e.g., float to long long) — even if it is not lossy on the current platform. Braced Init (222), noexcept Specifier (1091)" (EMCppSfe 2021)
# narrowing the contract - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXevolving a function contract by strengthening or otherwise adding new (nonduplicative) preconditions, thereby reducing the domain of the function, which might impact backward compatibility for its users; see also widening the contract. Rvalue References (793)" (EMCppSfe 2021)
# natural alignment - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe minimum alignment for a given size that is sufficiently strict to accommodate any object of that size provided that neither it nor any of its subobjects has had its alignment requirements artificially strengthened via explicit use of an alignment specifier (see Section 2.1.“alignas” on page 168). Numerically, the naturalalignment for size N is gcd(N, sizeof(std::max_align_t)) — in other words, the largest power of 2, not larger than alignof(std::max_align_t), that evenly divides N, e.g., naturalalignment(4) = 4, naturalalignment(5) = 1, and naturalalignment(6) = 2. Note that natural alignment is typically used when the size of an object is known but not its type; for example, allocating 4 bytes with natural alignment will result in 4-byte aligned storage because the computation cannot distinguish between, e.g., a single int (having a required alignment of 4) and a struct containing two short data members (having a required alignment of only 2). alignas (179), alignof (184), Underlying Type ’11 (831)" (EMCppSfe 2021)
# negative testing - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe testing practice of deliberately violating a precondition when invoking a function having a narrow contract in a unit test. Such testing is important in practice to ensure that any defensive checks are implemented as intended (e.g., without all-too-common off-by-one errors) and requires that the test harness be compiled in a mode in which such defensive checks would be expected to detect those specific contract violations at runtime (see production build). These tests are often implemented by configuring a suitable defensive checking framework to throw a specific test exception on a contract violation or else via death tests, in which case a process must be started for each individual successful trial. Rvalue References (794)" (EMCppSfe 2021)
# new handler - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa callback function registered using the standard library function std::set_new_handler that will be invoked by standard allocation functions whenever a memory allocation attempt fails. Note that this callback function may try to free additional memory to allow for a retry of the allocation attempt. alignof (193)" (EMCppSfe 2021)
# nibble – half a byte, i.e., 4 bits. Digit Separators (153)" (EMCppSfe 2021)
# nofail – implies, for a given function or guarantee, that it is a nofail function or nofail guarantee, respectively. noexcept Specifier (1116)" (EMCppSfe 2021)
# nofail function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that provides no failure mode (i.e., has no out clause in the contract describing its interface) and has an infallible implementation, irrespective of whether it provides a nofail guarantee. noexcept Specifier (1117)" (EMCppSfe 2021)
# nofail guarantee - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that, for a given function, implies it is now and always will be a nofail function. noexcept Specifier (1117)" (EMCppSfe 2021)
# nondefining declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone — such as class Foo; — that does not provide all of the collateral information, such as function or class body, associated with a complete definition. Note that a typedef or using declaration (see Section 1.1.“using Aliases” on page 133) is nondefining as type aliases are declared, not defined. Also note that an opaque enumeration declaration provides only the underlying type for that enumeration, sufficient to instantiate opaque objects of the enumerated type yet not sufficient to interpret its values; hence, it too is not (fully) defining and therefore is nondefining. Note that a nondefining declaration may be repeated within a single translation unit (TU); see also defining declaration. Rvalue References (729)" (EMCppSfe 2021)
# nonprimitive functionality – implementable in terms of the publicly accessible functionality of a type or a set of types and, hence, does not require access to any of their encapsulated (private) implementation details. explicit Operators (67)" (EMCppSfe 2021)
# nonreporting contract - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa function contract that does not specify an out clause — i.e., the contract (e.g., for std::vector::push_back) makes no mention of what happens if the operation were to fail. noexcept Specifier (1120)" (EMCppSfe 2021)
# nonreporting function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa function whose contract offers no mechanism to report whether the principal action requested was performed. noexcept Specifier (1119)" (EMCppSfe 2021)
# nonstatic data member - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone declared without the static keyword, an instance of which appears in every object of the class. constexpr Variables (305)" (EMCppSfe 2021)
# non-trivial constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXnot a trivial constructor, such as a user-provided constructor (which is never trivial, even if the resulting generated code matches exactly what a trivial constructor would do). union ’11 (1174)" (EMCppSfe 2021)
# non-trivial destructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXnot a trivial destructor — e.g., a user-provided destructor or one whose implementation invokes some non-trivial destructor of a base-class or data-member subobject. noexcept Specifier (1118)" (EMCppSfe 2021)
# non-trivial special member function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is not trivial; see also special member function. union ’11 (1174)" (EMCppSfe 2021)
# non-type parameter - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for non-type template parameter. Variadic Templates (902)" (EMCppSfe 2021)
# non-type parameter pack - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa template parameter pack made up of non-type template parameters. Variadic Templates (902)" (EMCppSfe 2021)
# non-type template parameter - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone whose argument is a constant expression, rather than a type or template; the parameter must have integral type, enumeration type, pointer type, pointer-to-member type, or lvalue reference type. C++20 broadens slightly this category of types to structural types, which includes floating-point types and class types comprising other structural types. Variadic Templates (902)" (EMCppSfe 2021)
# normative wording – implies, for wording in the Standard, that it forms part of the definition of ISO C++, as opposed to (nonnormative) notes, which exist only to make the Standard easier to read. Rvalue References (808)" (EMCppSfe 2021)
# notionally trivially destructible - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given class type, that it could (and would) have a trivial destructor if not for a desire to have some entirely optional operations that do not change the semantics of a correct program — e.g., defensive checks to verify that object invariants have been maintained properly throughout the lifetime of the object. Note that such a type might be written using, e.g., conditional compilation to have a trivial destructor in some build modes but not in others. Generalized PODs ’11 (468)" (EMCppSfe 2021)
# NRVO – short for named return-value optimization. Rvalue References (736)" (EMCppSfe 2021)
# null address - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe value of a pointer variable that represents the absence of a memory address; the bit pattern representing such a value, however, is implementation defined. See also null pointer value. nullptr (99)" (EMCppSfe 2021)
# null pointer value - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa singular value in the domain of each pointer type that never represents the address of an object nor the address past the end of an object. Note that the object representation of a null pointer value is implementation defined and need not be all zero bits nor even the same between different pointer types. Rvalue References (743)" (EMCppSfe 2021)
# null statement - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan empty statement consisting of just a single semicolon (;). constexpr Functions (268)" (EMCppSfe 2021)
# null-terminated string - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa sequence of characters whose end is marked by a terminating character having the numeric value of 0. Rvalue References (743)" (EMCppSfe 2021)
O
# object invariant - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa property of an object that holds from the point at which it becomes fully constructed until its destructor begins to execute, except when the flow of control is within the body of a mutating public member (or friend) function of that object’s class; in other words, every object invariant is implicitly a postcondition of every public member and friend function of its class. Generalized PODs ’11 (472), Inheriting Ctors (539), Rvalue References (742)" (EMCppSfe 2021)
# object-orientation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan object-centric (as opposed to a function-centric) approach to programming in which data serves to aggregate functions rather than vice versa. In this mindset, programmers view objects as the fundamental building blocks of logical design, where raw data is encapsulated in objects along with the functions that access and manipulate it. In C++, objects are defined in terms of classes; see also object-oriented programming. Note that this now antiquated term was popularized in the late 1980s and has since fallen into disuse. final (1015)" (EMCppSfe 2021)
# object-oriented programming - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa paradigm of programming that extends object-orientation to provide dynamic binding along with subtyping as a means of factoring interfaces as well as implementations of related types; see also object-orientation. In C++, these object-oriented features are implemented via virtual functions and inheritance. Generalized PODs ’11 (440)" (EMCppSfe 2021)
# object representation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe bytes of data within an object’s footprint used to represent the object’s state. Generalized PODs ’11 (405)" (EMCppSfe 2021)
# ODR – short for one-definition rule. constexpr Variables (307)" (EMCppSfe 2021)
# ODR-used – implies, for a given entity, that it is referenced in a potentially evaluated expression; such entities are subject to the ODR and thus must have a definition for a program to be considered well formed. Lambdas (581), Lambda Captures (988), inline namespace (1081)" (EMCppSfe 2021)
# one-definition rule (ODR) – the C++ language constraint on a well-formed program that there must be exactly one definition for each entity that is ODR-used; otherwise, the program is IFNDR. Entities whose source-level definitions must appear in multiple translation units, such as inline functions, template definitions, and default arguments, may have multiple definitions, but all of those definitions must be generated from the same sequence of tokens. Note that, as of C++17, a definition need not exist for an entity that is ODR-used only within a discarded statement, i.e., a statement in the unused part of an if constexpr construct. constexpr Functions (263), extern template (374), inline namespace (1072), noexcept Specifier (1114), auto Return (1188)" (EMCppSfe 2021)
# opaque declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa nondefining declaration for a class type or enumeration. Note that such declarations expose minimal collateral information beyond the name of the type being declared, e.g., type aliases — such as typedef int size_type; — are not opaque; see also insulation. Opaque enums (660)" (EMCppSfe 2021)
# opaque enumeration declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa nondefining declaration of an enumeration, which does not specify its enumerators but fixes its underlying type so that its size and alignment can be determined and thus allows objects of that type to be created, copied, etc., opaquely. Note that such opaque enumeration declarations present a unique challenge with respect to physical design in that a component that defines an enumeration having a fixed underlying type might need to provide two header files — one containing the opaque enumeration declaration and a second (which may include the first) that provides the full definition; see Section 2.1. “Opaque enums” on page 660. Opaque enums (663)" (EMCppSfe 2021)
# operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa kind of function that has a non-function-like syntax known to the compiler and consisting of either a keyword or other token (typically comprising just punctuation characters) that can used as part of an expression alongside its operands — e.g., sizeof(a + b), where both + and sizeof are operators. Token-based operators include assignment (=), equality comparison (==), member access, subscripting ([]), sequencing (,), conditional (?:), function call (()), etc. Keyword-based operators include sizeof, new, delete, typeid, and, as of C++11, alignof, decltype, and noexcept. Many of the built-in token-based operators, along with new and delete, can be overloaded for class types; notable exceptions include dot (.) and conditional (?:). constexpr Functions (265)" (EMCppSfe 2021)
# ordinary character type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is char, signed char, or unsigned char. Note that char8_t (introduced in C++20) is not an ordinary character type. Generalized PODs ’11 (501)" (EMCppSfe 2021)
# out clause - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXin law, a clause that permits signatories to a contract to opt out of particular provisions or to terminate the contract early. In software contracts, it is a statement in a contract that (1) allows a function not to achieve its stated goal and (2) typically specifies a channel by which it will inform the caller of its failure to do so and perhaps also an explanation of what precipitated that failure. noexcept Specifier (1117)" (EMCppSfe 2021)
# out of contract - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given invocation of a function, that one or more of its preconditions (explicitly stated or otherwise) was not satisfied. Rvalue References (744), noexcept Specifier (1117)" (EMCppSfe 2021)
# outermost expression - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe expression E, for a given expression S, such that S is a subexpression of E and E is not a subexpression of any other expression; see also full expression. Rvalue References (820)" (EMCppSfe 2021)
# over-aligned – implies, for a given type, that its alignment requirement exceeds that of what would otherwise be its minimal required alignment; see also natural alignment. alignof (185)" (EMCppSfe 2021)
# overload - XXXXXXXXXXXXXXXXXXXXXXXXXXXXX(1) a member of a set of functions or operators that have the same name but different signatures or (2) the act of creating such a similarly named function or operator (see also overloading). Rvalue References (741)" (EMCppSfe 2021)
# overload resolution - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe process by which, after name lookup, the C++ compiler determines which, if any, function from the set of candidate functions is the unique best match for a given argument list. Deleted Functions (53), Rvalue References (710), User-Defined Literals (841)" (EMCppSfe 2021)
# overload set - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe set of (viable) candidates (overloads), for a given invocation of a function (or operator), that the compiler refines during overload resolution until it finds the best viable function, if one exists, for the supplied argument list." (EMCppSfe 2021)
# overloading - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe act of creating an overload." (EMCppSfe 2021)
# overriding - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXproviding, for a virtual function declared in a base type, a suitable implementation specific to a derived type. Inheriting Ctors (539)" (EMCppSfe 2021)
# owned resource - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone, such as dynamic memory, a socket, or a shared-memory handle, that is managed by an object (a.k.a. the owner), typically with the expectation that the owner will release the resource when it no longer needs it, e.g., in the owner’s destructor. Move operations typically transfer an owned resource from one owner to another. On occasion, a resource can have more than one owner — such as in the case of std::shared_ptr — in which case the last owner to be destroyed is typically responsible for releasing the resource. Rvalue References (741)" (EMCppSfe 2021)
P
# pack expansion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe process of expanding a syntactic pattern followed by an ellipsis (...) that contains the name of at least one parameter pack into a comma-separated list of instantiations of that pattern, appropriate for that pack-expansion context. Lambdas (590), Variadic Templates (882), constexpr Functions ’14 (964)" (EMCppSfe 2021)
# pack-expansion context - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe syntactic position at which a pack expansion occurs, which impacts both the kinds of parameter packs that can be expanded and the semantics of that expansion. Variadic Templates (883)" (EMCppSfe 2021)
# package prefix - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan organization-wide unique (ideally very short) identifier that denotes the smallest unit of physical design larger than a component (e.g., std, bsls, bslma, ball). This name is often used for the namespace containing a collection of related logical entities, such as classes and functions. This same name can be used as the initial part of the name of a physical entity, such as a directory, a component, or a library, to associate it with the namespace that comprises its logical content; see lakos20, section 2.4, “Logical and Physical Name Cohesion,” pp. 297–333, specifically section 2.4.10, “Package Prefixes Are Not Just Style,” pp. 322–326." (EMCppSfe 2021)
# padding byte - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone supplied by the compiler in the footprint of an object of class type, typically to satisfy alignment requirements of individual data members or for the object as a whole. Each padding byte is of indeterminate value and, like a vtable pointer or virtual base pointer, does not contribute to the value representation of the object. Generalized PODs ’11 (475)" (EMCppSfe 2021)
# parameter - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe (formal) name declared within the defining declaration of an entity, such as a function or template, used locally within its definition to refer to the corresponding (actual) argument supplied when called or instantiated, respectively." (EMCppSfe 2021)
# parameter declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXThe declaration of a parameter to a function within a function’s parameter list. Variadic Templates (888)" (EMCppSfe 2021)
# parameter list - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa sequence of formal parameter declarations, such as a function parameter list or a template parameter list." (EMCppSfe 2021)
# parameter pack - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa function parameter pack or a template parameter pack. Variable Templates (159), Variadic Templates (873), constexpr Functions ’14 (964)" (EMCppSfe 2021)
# partial application - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXtransforming an N-ary function into another of smaller arity, specifically by binding one or more parameters of the original function to fixed arguments, as commonly occurs in C++ when trailing parameters of a given function are declared to have default arguments or, more generally, when a higher-order function, e.g., h(F, v), is applied to some function, e.g., f(x, y, z), to yield another function, e.g., g(x, y) = h(f(x, y, z), k), such that, for all a and b, g(a, b) = f(a, b, k). Lambdas (597)" (EMCppSfe 2021)
# partial class-template specialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe partial specialization of a class template. constexpr Functions ’14 (963)" (EMCppSfe 2021)
# partial implementation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan abstract class that provides implementations for some (but not all) virtual functions of a protocol. Inheriting Ctors (540), final (1021) partial ordering of class template specialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe process by which the compiler selects the most specialized candidate when instantiating a class template that has partial specializations. Variadic Templates (886)" (EMCppSfe 2021)
# partial specialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa template specialization that is itself a template. Generalized PODs ’11 (529), Variadic Templates (884)" (EMCppSfe 2021)
# partially constructed – implies, for a given object, that its constructor has begun executing, but has not yet completed. Delegating Ctors (47)" (EMCppSfe 2021)
# perfect forwarding – the use of a combination of a forwarding reference and std::forward to enable a function f (e.g., a factory function) to call a different function (e.g., the constructor of a class) with one of f’s arguments, retaining both its type and its value category. Braced Init (240), Rvalue References (807), Variadic Templates (942), noexcept Specifier (1131), auto Return (1198)" (EMCppSfe 2021)
# perfectly forwarded – implies, for a given function argument, that it was passed into the function using perfect forwarding. Lambda Captures (992)" (EMCppSfe 2021)
# physical - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given aspect of design, that it involves files, libraries, or dependencies, in contrast to a purely logical one, e.g., that which pertains to classes, functions, variables, algorithms, or their relationships. Note that this term is also used to denote physical aspects of the program, tool chain, and supporting hardware, such as executable size, compilers, linkers, available memory, and so on." (EMCppSfe 2021)
# physical dependency - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for two distinct physical entities (e.g., files, components, libraries), that one requires the other in order to be compiled, linked, tested, or used. In well-designed component-based software, an envelope of physical dependencies among components can be gleaned quickly by examining their relative #include directives. Generalized PODs ’11 (443)" (EMCppSfe 2021)
# physical design - XXXXXXXXXXXXXXXXXXXXXXXXXXXXX(1) implies, during software development, the factoring and partitioning of logical content into source files and libraries and (2) the physical aspects that characterize the design and architecture of the resulting software. Opaque enums (663), friend ’11 (1042)" (EMCppSfe 2021)
# physical memory - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXstorage that provides the address space available to a running process. noexcept Specifier (1135)" (EMCppSfe 2021)
# pipelined – implies, for a given computation, that a step that comes earlier in the serial ordering of subcomputations is allowed to begin processing a new data item while later steps continue to work concurrently on previous data items, yielding better throughput and/or reduced latency. Optimizing compilers often reorder instructions to better exploit the ability of modern CPUs to pipeline their execution so as to improve performance. noexcept Specifier (1137)" (EMCppSfe 2021)
# placeholder – short for placeholder type. auto Return (1182)" (EMCppSfe 2021)
# placeholder type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone of auto or, in C++14, decltype(auto) that can be used in a declaration to represent a type that will be deduced from the relevant initialization. As of C++20, a placeholder can be constrained by a concept. auto Variables (195), Generic Lambdas (984), decltype(auto) (1205)" (EMCppSfe 2021)
# placement new - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan overload of the new operator, defined by the C++ Standard, that can be used to construct an object at a particular location in memory. Forwarding References (391), Generalized PODs ’11 (452), noexcept Operator (638), Variadic Templates (940), inline namespace (1072), union ’11 (1174)" (EMCppSfe 2021)
# plain old data (POD) – a now-deprecated term in the C++ Standard (replaced by the union of standard-layout type and trivial) used to describe C++ types that were C compatible, having the same layout and behavior in both languages." (EMCppSfe 2021)
# platonic value - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone whose unique meaning is understood outside of the current running process. Multiple variables in separate programs, processes, or databases — having different representations (e.g., 5u, 5.0, 'V', or "five") — might each identify such a value, but that value (i.e., the integer 5) is itself unique. Rvalue References (742)" (EMCppSfe 2021)
# PMR - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for polymorphic memory resource." (EMCppSfe 2021)
# POD - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for Plain Old Data, such as a C++03 POD type or C++11 POD type. Generalized PODs ’11 (401), union ’11 (1174)" (EMCppSfe 2021)
# point of instantiation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe source-code location where template arguments are supplied (either directly or via template argument deduction) to template parameters to form a template instantiation." (EMCppSfe 2021)
# pointer semantics – a proxy or handle type with in-core (a.k.a. in-process) value semantics that behaves similarly to a built-in pointer in that a value of the type provides access — typically via the dereference operators, * or -> — to some resource (e.g., a separately allocated object, as is the case for std::shared_ptr) or else has a null value. If an object of pointer-semantic type is copied, the original and the copy will refer to the same resource; any modifications made to the resource through one will be reflected in accesses through the other. Two pointer-semantic objects will not have the same value unless they refer to the same resource or both are null. Note that pointer-semantic objects are more independent of their referenced entity than are reference-semantic objects in that the former can be modified (e.g., assigned) independently, have a separate notion of equality, and be null, whereas the latter approximate fixed aliases to their referenced entity, analogous to the difference between built-in pointers and references; in particular, assigning from a pointer-semantic object, unlike a reference-semantic one, does not imply copying its referenced resource." (EMCppSfe 2021)
# pointer to member - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa type (or a value of that type) that is able to identify (by its value) a specific nonstatic member of a specific class type, such as an int data member of class X, or a possibly virtual, nonstatic member function having a specific signature and return value. A class member cannot be accessed using the value of a pointer-to-member type alone, but instead it must be combined with the address of a live object of the specified (or derived) type. explicit Operators (64), Generalized PODs ’11 (456)" (EMCppSfe 2021)
# polymorphic class - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone having a virtual function or a virtual base class. noexcept Operator (617)" (EMCppSfe 2021)
# polymorphic memory resource (PMR) – (1) a class derived from the standard abstract base class std::pmr::memory_resource, used to customize memory allocation and deallocation when using classes that obtain memory from an std::pmr::polymorphic_allocator object; (2) colloquially, the facilities in the C++ Standard Library within the std::pmr namespace, including memory_resource, polymorphic_allocator, monotonic_buffer_resource, and unsynchronized_pool_resource. alignof (190), Default Member Init (328)" (EMCppSfe 2021)
# polymorphic type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that, in C++, is implemented as a polymorphic class. noexcept Operator (616), final (1011)" (EMCppSfe 2021)
# positive semidefinite - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given matrix, that it is both Hermitian and all of its eigenvalues are non-negative; see vandenbos17. noexcept Operator (655)" (EMCppSfe 2021)
# POSIX epoch – 00:00:00 UTC on January 1, 1970, the reference time point against which POSIX time representations are typically based. constexpr Functions (291)" (EMCppSfe 2021)
# postcondition - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa promise made in the contract of a function stating what conditions will hold once the flow of control leaves a function, provided that all of that function’s (explicit or implicit) preconditions are met." (EMCppSfe 2021)
# potentially evaluated - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given expression, that it is not an unevaluated operand or part of one. noexcept Operator (615)" (EMCppSfe 2021)
# precondition - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa predicate, specified within a function’s contract, that must hold when the function is invoked; otherwise, the behavior is undefined. See also library undefined behavior. Attribute Syntax (18), Generalized PODs ’11 (472)" (EMCppSfe 2021)
# predicate - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa Boolean-valued expression, typically indicating whether some particular property holds; see also predicate function. Lambdas (575)" (EMCppSfe 2021)
# predicate function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that returns a Boolean value; see also predicate functor. Local Types ’11 (86)" (EMCppSfe 2021)
# predicate functor – a callable object that returns a Boolean value; see also predicate. Lambdas (575)" (EMCppSfe 2021)
# primary-class-template declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa declaration that introduces a class template into the current scope (and, hence, is neither a specialization nor a partial specialization). Variadic Templates (881)" (EMCppSfe 2021)
# primary declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for primary-class-template declaration. Variadic Templates (881)" (EMCppSfe 2021)
# private inheritance - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXderivation (e.g., using the private keyword) from a base class such that inheritance does not afford programmatic access to the base class to any further derived classes or public clients. final (1029)" (EMCppSfe 2021)
# procedural - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given imperative programming paradigm or language, that the basic building blocks are functions that operate on raw data rather than, say, objects that encapsulate raw data along with relevant functionality; see also object-orientation. Generalized PODs ’11 (448)" (EMCppSfe 2021)
# proctor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan object of a proctor class. noexcept Operator (646), noexcept Specifier (1139)" (EMCppSfe 2021)
# proctor class - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that, like a scoped guard, uses RAII to take temporary ownership of a resource and ensure that the held resource is released when the flow of control exits scope unexpectedly, e.g., via a thrown exception. Unlike a scoped guard, however, a proctor class necessarily has an explicit release operation that allows ownership of the resource to be adopted by another (longer-lived) entity before the proctor is destroyed. Proctor objects are used for writing exception-safe code in an exception-agnostic programming style. noexcept Operator (646)" (EMCppSfe 2021)
# production build - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that employs a compilation mode that prioritizes the performance required of a production system, perhaps sacrificing niceties such as defensive checks or debugging information. Generalized PODs ’11 (469)" (EMCppSfe 2021)
# programmatically accessible - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given (logical) entity (e.g., within some other entity), that it can be manipulated, accessed, or detected programmatically (i.e., using the C++ language) by clients. noexcept Specifier (1085)" (EMCppSfe 2021)
# protocol - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa class whose (user-declared) members — apart from an empty destructor, possibly defined out of line in a source (.cpp) file — consist of only pure virtual functions and that does not inherit (either directly or indirectly) from any other class that is not itself a protocol. Generalized PODs ’11 (440), Inheriting Ctors (540), final (1018)" (EMCppSfe 2021)
# protocol hierarchy - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan inheritance hierarchy consisting exclusively of protocols, whereby higher-level protocols serve only to widen and augment the functionality available to public clients; see lakos96, Appendix A, “The Protocol Hierarchy Design Pattern,” pp. 737–768. final (1020)" (EMCppSfe 2021)
# prvalue - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for pure rvalue; an expression of this value category — such as a function that returns by value or a numeric literal — has a value but no inherent identity; see also lvalue and xvalue. decltype (25), nullptr (99), auto Variables (206), constexpr Functions (282), enum class (346), Generalized PODs ’11 (513), Range for (692), Rvalue References (711), decltype(auto) (1206)" (EMCppSfe 2021)
# publicly accessible - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given member of a user-defined type, that its access level is public. Generalized PODs ’11 (489)" (EMCppSfe 2021)
# pun - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe act of type punning, i.e., accessing an object from other than a compatible type." (EMCppSfe 2021)
# pure abstract interface - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is a protocol, i.e., providing no implementation of any kind. Inheriting Ctors (540)" (EMCppSfe 2021)
# pure function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that (1) produces no side effects and (2) returns a consistent value for a given set of arguments. Such functions can, for example, have their results memoized (reused for specific input arguments without having to reevaluate the function) with no observable change in the behavior of the program. Attribute Syntax (16)" (EMCppSfe 2021)
# pure virtual function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is a virtual function declared with a pure specifier, =0. Such a function need be defined only if it is called with (or as if with) its qualified id; see also protocol. final (1008)" (EMCppSfe 2021)
Q
# qNaN - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for quiet NaN." (EMCppSfe 2021)
# QoI - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for quality of implementation." (EMCppSfe 2021)
# qualified id - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan unqualified id following a (possibly empty) sequence of namespace or class specifiers, each separated by :: — e.g., B::x, decltype(a)::d_b, or std::vector<int>." (EMCppSfe 2021)
# qualified name - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that contains the scope-resolution operator (::) — e.g., ::foo (global scope) or bar::baz (bar scope). inline namespace (1060)" (EMCppSfe 2021)
# qualifier - XXXXXXXXXXXXXXXXXXXXXXXXXXXXX(classically) short for cv-qualifier, one of const or volatile; see Section 3.1.“Ref-Qualifiers” on page 1153. Variadic Templates (889)" (EMCppSfe 2021)
# quality of implementation (QoI)– a characterization with respect to a range of (e.g., compiler or library) implementation behaviors that are allowed by the Standard along with the possibly subjective measure of how well those implementations meet the intent of the Standard and the needs of the users. constexpr Functions (277), Generalized PODs ’11 (529)" (EMCppSfe 2021)
# quiet NaN (qNaN) – a NaN value that is generated by certain computations (e.g., 0.0/0.0) and that, when used as an operand, yields a NaN result; e.g., 1.0 + NaN yields NaN. Contrast with signaling NaN. Generalized PODs ’11 (531)" (EMCppSfe 2021)
R
# RAII - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for resource acquisition is initialization. Deleted Functions (54), Forwarding References (388), noexcept Operator (644), Rvalue References (769), noexcept Specifier (1126)" (EMCppSfe 2021)
# range - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXany object (e.g., an std::vector) that exposes a sequence of elements suitable for iteration using a range-based for loop. Note that C++20 elaborates on this notion via the addition of the ranges library. decltype (29), Variadic Templates (877)" (EMCppSfe 2021)
# range-based for loop - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa variety of for loop, introduced in C++11 (see Section 2.1.“Range for” on page 679), that provides a simpler, more abstract syntax — for ( declaration : range-expression ) — used to iterate through the elements of a range. Range for (679)" (EMCppSfe 2021)
# range expression - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that produces a range — i.e., one suitable for use in a range-based for loop. Range for (680)" (EMCppSfe 2021)
# raw string literal - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa C++11 feature (see Section 1.1.“Raw String Literals” on page 108) that allows a string literal to be interpreted literally — i.e., without escape sequences (commonly called a “here doc” in scripting languages). Raw String Literals (113)" (EMCppSfe 2021)
# raw UDL operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa user-defined-literal operator that is passed the unparsed literal string as a null-terminated const char*. User-Defined Literals (841)" (EMCppSfe 2021)
# reachable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given expression, that its value has identity and that the address of its underlying object representation is accessible. To a good approximation, an object is reachable if it is a glvalue, that is, an lvalue or an xvalue but not a prvalue; there are, however, pathological prvalues that are nonetheless reachable. Consider, for example, a type S that holds an int and stores its this pointer as a global variable on construction — struct S; S* p; struct S { int v; S(int i) : v(i) { p = this; } }; int x = (S(3), 2 * p->v); — and sets the value of x to 6. See Section 2.1.“Rvalue References” on page 710. Rvalue References (712)" (EMCppSfe 2021)
# reaching scope - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe set of enclosing scopes containing a lambda, up to and including the innermost enclosing function and its parameters. This scope defines the set of automatic-storage-duration variables that a lambda can capture or to which it can refer; see captured by copy and captured by reference. Lambdas (587)" (EMCppSfe 2021)
# recursion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXX(1) invoking a function that is called (directly or indirectly) from that same function— e.g., int f(int n) { return n > 0 ? n * f(n-1) : 1; } — or (2) defining an entity in terms of itself, e.g., a type list (see Section 2.1.“Variadic Templates” on page 873). Variadic Templates (875)" (EMCppSfe 2021)" (EMCppSfe 2021)
# redundant check - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is superfluous in a defect-free program (a.k.a. defensive check). static_assert (115)" (EMCppSfe 2021)
# ref-qualifier - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone of & or && applied to a nonstatic member function declaration, thereby enabling overloading based on the value category of the object from which that member function is invoked. Forwarding References (380), Ref-Qualifiers (1154)" (EMCppSfe 2021)
# reference collapsing – the C++ language rule for applying & or && to a type alias or decltype expression that is itself a reference (T& or T&&), i.e., when there are two reference operators being applied to the same underlying type. The resulting reference will be an lvalue reference (T&) unless both operators are &&, in which case the result will be an rvalue reference (T&&). Forwarding References (380)" (EMCppSfe 2021)
# reference related – implies, for a given type T, that some other type U differs in only cv-qualification (at any level) or T is a direct or indirect base class of U. Rvalue References (726)" (EMCppSfe 2021)
# reference type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that denotes an alias to an object of the referenced type and can be either an lvalue reference or an rvalue reference. alignof (184), union ’11 (1174)" (EMCppSfe 2021)
# reflection - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa language feature allowing a program to inspect and modify its own structure and behavior. The C++ Standards Committee, and specifically its Study Group 7, is actively working toward incorporating static (compile-time) reflection capabilities into a future version of C++. Generalized PODs ’11 (520)" (EMCppSfe 2021)
# regression test - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone designed to detect the recurrence of some previously corrected undesired property (e.g., a bug) in the software." (EMCppSfe 2021)
# regular type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that emulates syntactically the operations (and corresponding behaviors) of built-in types such as an int, e.g., that they be copy constructible, copy assignable, destructible, and equality comparable; see stepanov09, section 1.5, “Regular Types,” pp. 6–8. Note that, due to being copyable, all such types are implicitly also movable. Though required by the definition of regular type, default construction is not typically needed in generic contexts. A type that does not provide equality-comparison operators but would otherwise be considered a regular type is called semiregular; see stepanov15, section 10.3, “Concepts,” pp. 181–184, specifically p. 184. alignof (187), Rvalue References (751)" (EMCppSfe 2021)
# release-acquire – a synchronization paradigm in which all reads and writes on memory locations that appear in the source code before a release operation will occur before all reads and writes that appear after a subsequent acquire operation. carries_dependency (998)" (EMCppSfe 2021)
# release-consume - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa synchronization paradigm within the release/acquire/consume memory model that guarantees that any modification to a memory location made visible by a release operation can be read after a consume operation on a (possibly different) memory location provided that there is a data-dependency chain from the modified location to the consumed location. carries_dependency (998)" (EMCppSfe 2021)
# reliable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given function having a reporting contract, that it has an infallible implementation and any failure to deliver fully on the outcome intended by the caller will always be reliably reported back to the caller in some well-defined way, e.g., via an error status. noexcept Specifier (1122)" (EMCppSfe 2021)
# reporting contract - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa function contract having an out clause that specifies a channel by which an error is reported back to the caller. noexcept Specifier (1120)" (EMCppSfe 2021)
# reserved identifier - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone commandeered for exclusive use by the C++ Standard Library and whose use by other code is ill formed, no diagnostic required — e.g., any identifier that contains (anywhere) double underscores (__), or any identifier having a leading _ in the global namespace. User-Defined Literals (840)" (EMCppSfe 2021)" (EMCppSfe 2021)
# resource acquisition is initialization (RAII) – a C++ programming idiom for managing the lifetime of any allocated resource — e.g., dynamic or shared memory, socket, file — by acquiring it in the constructor of an object and then relying on that object’s destructor to be responsible for releasing it, thereby tying proper management of the underlying resource to that of the lifetime of the object itself. This idiom is effective at avoiding common defects, compared with having to pair allocation and deallocations explicitly, especially with respect to early return statements and unexpectedly thrown exceptions." (EMCppSfe 2021)
# return-type deduction - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa feature by which the return type of a lambda expression (since C++11) or a function having a placeholder type (e.g., auto) as its return type (since C++14) is deduced from the possibly implicit return statement in the (necessarily visible) function body; see Section 2.1.“Lambdas” on page 573 and Section 3.2.“auto Return” on page 1182, respectively. decltype (28)" (EMCppSfe 2021)
# return-value optimization (RVO) – copy elision (guaranteed as of C++17) that can occur by constructing the return value of a function directly into the variable in the calling context that is initialized from said return value, rather than constructing a temporary; see also named return-value optimization (NRVO). Forwarding References (390), Rvalue References (734)" (EMCppSfe 2021)
# reuse - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXutilizing a piece of software designed for one application or context in a different one. final (1012)" (EMCppSfe 2021)
# RTTI – short for runtime type identification. noexcept Operator (617)" (EMCppSfe 2021)
# rule of zero - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa design guideline recommending to class authors that, when possible, the compiler be allowed to implicitly generate all five special member functions that are typically defined together (or not at all): destructor, copy constructor, copy-assignment operator, and where advantageous (e.g., for runtime performance), move constructor and move-assignment operator. Choosing data members of types, such as std::vector, std::shared_ptr, and std::unique_ptr, that properly manage their respective owned resources, obviates having to provide these functions explicitly, thereby automatically achieving the appropriate owned-resource lifetime management through effective use of RAII. Note, however, that having a data member of move-only type, such as std::unique_ptr, will result in a move-only class when adhering to this rule. noexcept Operator (631), Rvalue References (788)" (EMCppSfe 2021)
# runtime type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa synonym for dynamic type." (EMCppSfe 2021)
# runtime type identification (RTTI) – a C++ language feature whereby an object’s type, and thereby information associated with that type, can be determined at run time; this mechanism underlies type-safe casting using dynamic_cast and runtime querying of type information using typeid." (EMCppSfe 2021)
# rvalue - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXany expression that is not an lvalue (i.e., either an xvalue or a prvalue) and, hence, can be passed to a function via an rvalue reference. decltype (26), Defaulted Functions (42), nullptr (99), Variable Templates (167), auto Variables (196), Braced Init (216), Forwarding References (377), Generalized PODs ’11 (501), initializer_list (570), Lambdas (590), noexcept Operator (628), Range for (680), Rvalue References (710), Variadic Templates (890), Generic Lambdas (971), Lambda Captures (992), noexcept Specifier (1133), Ref-Qualifiers (1153), auto Return (1184), decltype(auto) (1206)" (EMCppSfe 2021)
# rvalue reference - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa reference, formed for a type X as X&&, that can be bound to an rvalue; see Section 2.1.“Rvalue References” on page 710. Forwarding References (400), Range for (701), Rvalue References (710)" (EMCppSfe 2021)
# RVO – short for return-value optimization." (EMCppSfe 2021)
S
# safe-bool idiom - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa technique in class design (e.g., using an unspecified-bool type) that suppresses unwanted comparisons made available by the presence of a nonexplicit conversion function to bool. explicit Operators (64)" (EMCppSfe 2021)
# salient attribute - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa (typically independently observable) property of an object (e.g., the year of a date or the real part of a complex number) that contributes to its overall semantic value, i.e., one that would be relevant in the result of a homogeneous equality-comparison operator (==) for its type." (EMCppSfe 2021)
# salient operation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone, for a given value-semantic type, that is relevant to the algebra governing the set of platonic values it aims to represent." (EMCppSfe 2021)
# salient value - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa particular value corresponding to the salient attribute of a type. noexcept Operator (634)" (EMCppSfe 2021)
# sanitizer – a family of tools (e.g., AddressSanitizer, ThreadSanitizer) provided along with the GCC and especially Clang tool chains that can be run with an instrumented build of an application to identify various sorts of defects, such as dangling pointers, memory leaks, race conditions, and various forms of undefined behavior. Rvalue References (802)" (EMCppSfe 2021)
# scalar type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is an arithmetic type, enumeration type, pointer type, pointer-to-member type, std::nullptr_t, or any cv-qualified version of these types. alignas (168), Braced Init (217), Generalized PODs ’11 (417), decltype(auto) (1207)" (EMCppSfe 2021)
# scoped allocator model - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone comprising stateful customizable memory allocators in which all of an object of allocator-aware type and all of its allocator-aware subobjects are constructed using the same allocator, i.e., the allocator used by (and optionally passed into) the outermost object’s constructor. Default Member Init (328)" (EMCppSfe 2021)
# scoped enumeration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone, declared using enum class or enum struct, for which the enumerator names are not automatically injected into the enclosing namespace. Opaque enums (660)" (EMCppSfe 2021)
# scoped guard - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan object that uses RAII to take ownership of a resource and ensures that it is released when the object goes out of scope, typically used as a local variable in block scope to prevent a resource (such as a mutex lock or file handle) from being leaked in the event of an early return statement or a thrown exception; see also proctor. noexcept Operator (645), Rvalue References (764), noexcept Specifier (1139)" (EMCppSfe 2021)
# section - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa segmented portion of an object file containing object-level code that can be incorporated by the linker into the final executable program, independently of any other such sections. extern template (361)" (EMCppSfe 2021)
# secure hash algorithms (SHA) – a family of cryptographic hash functions defined by the U.S. National Institute for Standards and Technology." (EMCppSfe 2021)
# sentinel – a marker, such as an out-of-band value, often used to represent the end of a sequence, e.g., a null terminator to represent the end of a string or a null pointer or empty node to represent the end of a list. Rvalue References (743), noexcept Specifier (1114)" (EMCppSfe 2021)
# sequencing operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa synonym for the comma operator. constexpr Functions (265)" (EMCppSfe 2021)
# serial date - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is represented as a single number, generally days since a well-known epoch, as opposed to one represented by year, month, and day individually. Generalized PODs ’11 (453)" (EMCppSfe 2021)
# set associative - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given hardware memory cache, that every address is directly mapped to exactly one set of (e.g., 2, 4, or 8) lines in the cache. The cache lines within each set are fully associative, obviating evictions from the set until all cache lines within it are full. A set-associative cache is a hybrid between a direct mapped cache and a fully associative cache, with a power-performance trade-off between the two. alignas (182)" (EMCppSfe 2021)
# SFINAE – short for substitution failure is not an error. decltype (28), static_assert (121), Forwarding References (397), Generalized PODs ’11 (474), Inheriting Ctors (539), noexcept Specifier (1089), auto Return (1190)" (EMCppSfe 2021)
# SHA – short for secure hash algorithms. inline namespace (1083)" (EMCppSfe 2021)
# side effect - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXany observable modification of program state that occurs as the result of evaluating an expression. Attribute Syntax (16)" (EMCppSfe 2021)
# signal - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa type of message that is sent to a process by the operating system, possibly indicating an error condition. The process may — depending on the type of signal — ignore it, have one of its threads interrupted so that it can execute a signal handler, or terminate. Note that signals first originated in Bell Labs UNIX (version 4) in 1973, are part of C, and are entirely independent of C++ exceptions. noexcept Specifier (1120)" (EMCppSfe 2021)
# signaling NaN (sNaN) – one of a subset of NaN values that, in theory, produces a signal (e.g., a floating-point exception) originating from the processor hardware when used as part of a computation. An sNaN is never generated from a computation (e.g., by 0.0/0.0) but must instead be explicitly set by the programmer. Theoretically, an sNaN could be injected into a computation to catch bugs such as use of freed memory, but examples of such use are rare in practice; moreover, many compilers implicitly convert sNaNs into qNaNs. Generalized PODs ’11 (531)" (EMCppSfe 2021)
# signature – the information needed at the ABI level to uniquely identify a function (including an instantiation of a function template) from any other one that might coexist (e.g., be overloaded) having the same name. A function’s signature comprises its fully qualified name (including enclosing namespace and class if any), function parameter list, and (for member functions) cv-qualifiers and ref-qualifiers; see Section 3.1.“Ref-Qualifiers” on page 1153. If the function is a specialization of a function template, its signature includes its template arguments, whether explicitly specified or deduced. Though this term is seldom used for templates except when referring to an instantiation or specialization, the signature of an (unspecialized) function template further includes its return type and template parameter list. Trailing Return (124), Inheriting Ctors (536), Rvalue References (729), friend ’11 (1052), noexcept Specifier (1089), Ref-Qualifiers (1153)" (EMCppSfe 2021)" (EMCppSfe 2021)
# signed integer overflow - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan evaluation (e.g., the result of a built-in operation on one or two signed integers) in which an expression or subexpression has signed integer type but its value is outside the range of values representable in that type. All overflow on signed integers has undefined behavior. In contrast, the same operations on unsigned integers, which follow modular arithmetic, do not have any cases where the result cannot be expressed in the same type; hence, most operations (other than division by 0) on unsigned integers are well defined. long long (90)" (EMCppSfe 2021)
# sink argument - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is supplied to a function — either by value or by rvalue reference — typically with the intent of transferring ownership of a managed resource. Note that passing by rvalue reference leaves open the option to read but not move, whereas passing by value does not. Rvalue References (775)" (EMCppSfe 2021)
# size constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone, available on certain standard containers (e.g., std::vector), that takes an integral size and initializes the container with that many value-initialized elements. Rvalue References (764)" (EMCppSfe 2021)
# slicing - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe outcome of copying or moving from a derived-class object, via a base-class reference to the original object, to a distinct base-class object. Note that the resulting object will be unable to hold any supplementary state that might exist in only the derived class; in the special case of a move operation, object invariants could be violated for either or both objects involved. Inheriting Ctors (539), final (1025)" (EMCppSfe 2021)
# smart pointer - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa user-defined type, typically with overloads of operator-> and operator*, intended to behave like a built-in pointer but with additional semantics or functionality, often to manage the lifetime of the referenced objects using RAII. The most commonly available examples are std::shared_ptr, which uses reference counting to manage ownership of shared objects, and std::unique_ptr, which is a move-only type that allows only one object at a time to own a given dynamically allocated object. Rvalue References (770), Variadic Templates (948)" (EMCppSfe 2021)
# sNaN - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for signaling NaN." (EMCppSfe 2021)
# soft UB - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for library undefined behavior. noexcept Specifier (1115)" (EMCppSfe 2021)
# Software Capital - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa proprietary suite of relevant, interoperable, reusable components that is an asset of an entire organization and does not belong to any one application or product; see lakos20, section 0.9, “Software Capital,” pp. 86–97." (EMCppSfe 2021)
# source character set - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for basic source character set." (EMCppSfe 2021)
# special member function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone of the six member functions that the compiler knows how to generate: default constructor, copy constructor, move constructor, copy-assignment operator, move-assignment operator, and destructor. Defaulted Functions (33), Deleted Functions (53), constexpr Functions (266), Generalized PODs ’11 (413), initializer_list (553), Rvalue References (710), noexcept Specifier (1086), union ’11 (1174)" (EMCppSfe 2021)
# specialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe class, function, or class member that results when supplying a template argument for every (nonoptional) template parameter of a template. The use of a specialization will trigger template instantiation of the primary template (or one of its partial specializations) unless there exists an explicit specialization for that template. Variadic Templates (884)" (EMCppSfe 2021)
# stack frame - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa contiguous segment of memory within a running program that is used to hold local variables — i.e., objects having automatic storage duration. noexcept Specifier (1101)" (EMCppSfe 2021)
# stack memory - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa synonym for automatically allocated memory." (EMCppSfe 2021)
# stack unwinding – the process by which the runtime library destroys automatic variables when traversing the call stack from the point an exception is thrown to the point it is caught. Note that, if a thrown exception encounters a function having a noexcept specification, it is implementation defined whether stack unwinding occurs before the runtime library calls std::terminate; see Section 3.1.“noexcept Specifier” on page 1085. noexcept Operator (621), noexcept Specifier (1135)" (EMCppSfe 2021)
# standard conversion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan implicit conversion, having built-in meaning, from one type to another, such as array to pointer decay or short to int promotion. Unlike a user-defined conversion, a standard conversion does not involve a converting constructor or conversion operator. Zero or more implicit conversions might be used when an expression is converted to a destination type, such as when direct initializing a variable, or when a function parameter is being initialized from a function argument. The Standard defines a partial ordering of conversions that is used, during overload resolution, to choose certain conversions over others, with sequences consisting entirely of standard conversions always preferred over those containing a user-defined conversion. Deleted Functions (56), enum class (334), Generalized PODs ’11 (509), User-Defined Literals (835)" (EMCppSfe 2021)
# standard-layout - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given class type, that its physical layout (a.k.a. footprint in memory) has properties that can be relied upon portably (e.g., that the address of the first data member coincides with the address of the object overall), as well as being suitable for integration with other languages, C in particular; see also standard-layout class and standard-layout type. Generalized PODs ’11 (420)" (EMCppSfe 2021)
# standard-layout class - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa class, struct, or union having all nonstatic data members at the same access level, no nonstatic data members of reference type or non-standard-layout type, no base classes that are not standard-layout classes, and no virtual functions or virtual base classes; furthermore, if such a class is not a union, no two subobjects — i.e., base classes, nonstatic data members, and subobjects thereof — of the same type will both have offset 0 within an object of the outermost type. Generalized PODs ’11 (422)" (EMCppSfe 2021)
# standard-layout class type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa synonym for standard-layout class. Generalized PODs ’11 (420)" (EMCppSfe 2021)
# standard-layout type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is a (possibly cv-qualified) scalar or standard-layout class type, or an array of such a type. alignas (178), alignof (186), Generalized PODs ’11 (401)" (EMCppSfe 2021)
# statement - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa unit of programming larger than an expression that typically governs the scope of temporaries created therein; unlike expressions, statements cannot be nested. An expression followed by a semicolon forms a statement (as does a semicolon alone). A label (within a function) is required to precede a statement. See also block scope." (EMCppSfe 2021)
# static assertion declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone using the static_assert keyword to evaluate a constant expression at compile time. If the expression is false, the program is ill formed and the compiler outputs a required (optional, as of C++17) user-supplied diagnostic string. Such declarations are invaluable for enforcing compile-time assumptions (e.g., maximum object size) and especially in conjunction with standard traits (e.g., std::is_trivially_copyable). static_assert (115)" (EMCppSfe 2021)
# static data space - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthat memory region of a running program holding objects having static storage duration. Variable Templates (165)" (EMCppSfe 2021)
# static storage duration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe lifetime of a variable defined in namespace scope or declared with the static storage class specifier, beginning sometime before its first use in the program and ending after the main function has completed. At program startup, such a variable is always zero-initialized, and if its initialization is a constant expression, such initialization is performed. If the variable is defined at block scope, any further initialization that it requires will be performed when control flow reaches its definition for the first time; otherwise, the implementation may complete such initialization at any time prior to its first use. Non-trivial destructors are run on normal program termination in (roughly) the reverse order of the corresponding constructor invocations. Function static ’11 (68), Generalized PODs ’11 (478)" (EMCppSfe 2021)
# storage class specifier - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone of static, thread_local, extern, or mutable, all of which control details of where and how an entity can be located. C++03 also allowed the (redundant) use of auto as a storage class specifier for variables with automatic storage duration, which was removed in C++11. Up to C++14, the specifier register was allowed as a hint to store an object in registers in lieu of memory, but this was removed in C++17. auto Variables (195)" (EMCppSfe 2021)
# strict aliasing - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa rule in C++ stating that accessing the value of an object of one type through a pointer or reference to a different type has undefined behavior unless that difference is limited to cv-qualifiers (at any level) and, for integral types only, signed versus unsigned; compilers may optimize based on this rule by assuming that any two pointers or references to objects of such dissimilar types do not refer to overlapping memory regions and, thus, modifications through one will not affect the state of the other. Note that accessing the individual bytes of the object representation of any object type through a pointer to char or unsigned char (and, as of C++20, std::byte) never violates the strict-aliasing rule; see Section 2.1.“Generalized PODs ’11” on page 401. Generalized PODs ’11 (401)" (EMCppSfe 2021)
# string literal - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa literal comprising a sequence of characters between quotation marks ("") that together form a null-terminated string. static_assert (115), deprecated (148), User-Defined Literals (837)" (EMCppSfe 2021)
# strong exception-safety guarantee - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone provided by certain Standard Library container operations, e.g., push_back on an std::vector, stipulating that if an exception is emitted by the operation, then no changes to the state of the operands will be observed. noexcept Operator (634), Rvalue References (750), noexcept Specifier (1097)" (EMCppSfe 2021)
# strong guarantee - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for strong exception-safety guarantee. noexcept Operator (634), Rvalue References (746)" (EMCppSfe 2021)
# strong typedef - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa user-defined type (UDT) implementing the strong typedef idiom, e.g., using inheriting constructors. Inheriting Ctors (542), User-Defined Literals (871)" (EMCppSfe 2021)
# strong typedef idiom - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that involves creating a user-defined type (UDT) wrapper having the same API as the type it wraps but which is not implicitly convertible from that type, thereby providing a greater degree of static type safety. In particular, this idiom is used for avoiding programming errors whereby one kind of value is passed where a different kind is expected when they are each represented by the same vocabulary type. A typical implementation of a strong typedef is in terms of a struct derived from the original type and then employing inheriting constructors (see Section 2.1.“Inheriting Ctors” on page 535) to avoid having to rewrite the derived-class constructors explicitly. For integer types, a classical enum having the original type as its underlying type (see Section 2.1.“Underlying Type ’11” on page 829) can serve the same purpose. Function static ’11 (74)" (EMCppSfe 2021)
# structural inheritance - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of inheritance in which non-virtual functions are inherited by a derived class; see also implementation inheritance. Deleted Functions (57), alignas (180), Inheriting Ctors (545), final (1025)" (EMCppSfe 2021)
# structural type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa category of type, introduced in C++20, used to characterize the extended set of allowable types for values supplied as non-type template parameters, which include integral type, enumeration type, pointer type, pointer-to-member type, lvalue reference type, as well as floating-point type and class types made up of other structural types." (EMCppSfe 2021)
# structured binding - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa C++17 feature that introduces new names bound to the subobjects of the object produced by the expression that initializes them, i.e., auto [a,b] = std::make_tuple(17,42); where a will be initialized to 17 and b will hold the value 42. Range for (685)" (EMCppSfe 2021)
# substitution failure is not an error (SFINAE) – a property of C++ template instantiation that enables the technique of supplying template arguments to a function template to determine if the resulting function will participate in overload resolution or supplying template arguments to a template partial specialization to determine whether it is eligible to be instantiated; errors that result from substituting certain (e.g., syntactically incompatible) arguments for the template parameters result merely in that particular template instantiation being dropped from the overload set, and is not (in and of itself) ill formed." (EMCppSfe 2021)
# sum type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan abstract data type allowing the representation of one of multiple possible alternative types. Each alternative has its own type (and state), and only one alternative can be active at any given point in time. Sum types keep track of which choice is active and properly implement (value-semantic) special member functions (even for non-trivial types). They can be implemented efficiently as a C++ class using a union and a separate (integral) discriminator. This sort of implementation is commonly referred to as a discriminating (or tagged) union and is available in C++17 as std::variant. union ’11 (1177)" (EMCppSfe 2021)
# synchronization paradigm - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe general approach used to coordinate memory reads and writes among two or more concurrent threads of execution. As used in this book, one of two approaches within the release-acquire/consume memory consistency model — release-acquire or release-consume. carries_dependency (998)" (EMCppSfe 2021)
# syntactic sugar - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXlanguage and library features that ease the use of the language by providing more ergonomic interfaces that obviate more verbose or difficult-to-use syntax but do not themselves provide new functionality." (EMCppSfe 2021)
T
# template argument - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe type, template, or value mapped to a template parameter in the instantiation of a template. Variadic Templates (899)" (EMCppSfe 2021)
# template argument deduction - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe process by which template arguments are determined from the types of the function arguments when calling a function template. Variadic Templates (894)" (EMCppSfe 2021)
# template argument list - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe sequence of arguments — types, templates, or values, depending on the corresponding parameters — that are used to specify explicit, nondeduced arguments to a template instantiation. Variadic Templates (882)" (EMCppSfe 2021)
# template head - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe keyword template and associated template parameter list used to introduce the declaration or definition of a template. Variable Templates (157)" (EMCppSfe 2021)
# template instantiation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXX(1) the process of substituting template arguments into the template parameters of a template declaration or definition to produce a concrete entity declaration or definition, respectively, and (2) the entity produced by this process. Forwarding References (382)" (EMCppSfe 2021)
# template-instantiation time - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe point at which, for a given template, the compiler performs template instantiation, triggered when encountering a point of instantiation for that template in the source code. Note that when a template definition is first encountered, certain semantic analysis and error detection — particularly those involving the template parameters — must be deferred until template-instantiation time. static_assert (116)" (EMCppSfe 2021)
# template parameter - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone, for a given template, that is associated with a template argument (i.e., a type, template, or value) when that template is instantiated; see also point of instantiation. Variadic Templates (896), friend ’11 (1031)" (EMCppSfe 2021)
# template parameter list - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe list of template parameters, surrounded by angle brackets (< and >), in the template head of a template declaration or definition. Variadic Templates (888)" (EMCppSfe 2021)
# template parameter pack - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa template parameter that accepts one or more template arguments, identified by an ellipsis (...) preceding the parameter name (if any) in the template head; the size of a parameter pack is determined by the number of template arguments supplied or deduced for the pack parameter at the point of instantiation for the template. Generalized PODs ’11 (437), Variadic Templates (879)" (EMCppSfe 2021)
# template template parameter - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa template parameter that expects a template argument that is itself a template: template <template <typename> class X> class Y; (declares a template template parameter, X, for a template class, Y). Variable Templates (165), Variadic Templates (902)" (EMCppSfe 2021)
# template template parameter pack - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa template parameter pack of template template parameters: template <template <typename> class X...> (X is a template template parameter pack). Variadic Templates (903)" (EMCppSfe 2021)
# temporary - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for temporary object; see also expiring object. initializer_list (555), Rvalue References (724)" (EMCppSfe 2021)
# temporary materialization – the act, by the compiler, of creating a temporary object when needed, e.g., when binding a reference to a prvalue. Rvalue References (717)" (EMCppSfe 2021)
# temporary object - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan unnamed object, created by evaluating an expression, whose lifetime generally extends until the end of the outermost enclosing expression in which the temporary is created. Rvalue References (711)" (EMCppSfe 2021)
# ternary operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan operator, formed with ? and :, taking three operands: (1) a conditional expression before the ?, (2) an expression between the ? and the : to be evaluated to produce the result if the first argument is true, and (3) an expression after the : to be evaluated to produce the result if the first argument is false. The type of the complete expression is the common type of the second and third operands. constexpr Functions (268), noexcept Operator (615)" (EMCppSfe 2021)
# test driver - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa program that, when invoked, will run unit tests for a component. Raw String Literals (114)" (EMCppSfe 2021)
# thrashing – profound performance degradation, resulting from excessive cache misses or page faults due to poor memory-access patterns. alignas (183)" (EMCppSfe 2021)
# thread storage duration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe lifetime of an object declared using the thread_local keyword; storage for these entities will be created when first used in a thread and will last for the duration of the thread in which it was allocated. Any reference to a variable of this type will be to one associated with the current thread. Note that, when declaring an object to have thread storage duration in function scope, providing the static keyword in addition avoids spurious warnings — e.g., “implicitly auto variable is declared __thread.”" (EMCppSfe 2021)
# top-level const - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa const cv-qualifier — such as for the variable p in int * const p; — that pertains to a type overall. By contrast, a non-top-level const — such as for the variable q in const int* q; — pertains to the type of object to which q points, rather than to q itself. Note that reference types and function types, including member-function types, can never have a top-level cv-qualifier, and the top-level cv-qualifier of an array — such as const int x[5]; — is the top-level cv-qualifier of the type of its elements. Rvalue References (729)" (EMCppSfe 2021)
# trailing return type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe return type for a function or a lambda expression specified after the parameter list, cv-qualifiers, and noexcept specification and preceded by the -> token; for a function, the auto placeholder resides where the return type would traditionally have been specified. An important benefit of a trailing return type is that it is permitted to refer to function parameters, e.g., by using decltype on an expression involving them; see Section 1.1. “Trailing Return” on page 124. Lambdas (593), noexcept Specifier (1145)" (EMCppSfe 2021)
# translation unit (TU) – the combined text resulting from a source file and all header files incorporated via #include directives that are translated (at once) into a single object file. Function static ’11 (71), Opaque enums (660), noexcept Specifier (1138)" (EMCppSfe 2021)
# trivial - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given entity, that it is especially simple in some manner that allows it to be treated specially; see also trivial class, trivial type, and trivial operation. Defaulted Functions (38), Deleted Functions (59), constexpr Functions (273), Generalized PODs ’11 (409), Rvalue References (733), final (1011), noexcept Specifier (1087), union ’11 (1181)" (EMCppSfe 2021)
# trivial class - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is trivially copyable, has at least one nondeleted trivial default constructor, and has no default constructors that are not trivial. Generalized PODs ’11 (521)" (EMCppSfe 2021)
# trivial constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa trivial default constructor, trivial copy constructor, or trivial move constructor. Generalized PODs ’11 (408)" (EMCppSfe 2021)
# trivial copy-assignment operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa copy-assignment operator that is not user provided, is for a nonpolymorphic type, and does not invoke any non-trivial copy-assignment operators for base classes or data members; it essentially performs a bitwise copy of the object representation. Generalized PODs ’11 (470)" (EMCppSfe 2021)
# trivial copy constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa copy constructor that is not user provided, is for a nonpolymorphic type, and does not invoke any non-trivial constructors for base classes or data members; it essentially performs a bitwise copy of the object representation. Generalized PODs ’11 (470)" (EMCppSfe 2021)
# trivial copy operation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is performed by directly calling a trivial copy constructor or trivial copy-assignment operator (or perhaps even a trivial move operation, if one should be chosen as a better fit during overload resolution). Rvalue References (733)" (EMCppSfe 2021)
# trivial default constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa default constructor that is not user provided, is for a nonpolymorphic type having no default member initializers, and does not invoke any non-trivial constructors for base classes or data members; when an object of class type having a trivial default constructor is default initialized, any of its scalar data members begin their lifetimes having indeterminate values. Generalized PODs ’11 (461)" (EMCppSfe 2021)
# trivial destructibility - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe quality, for a given type, as to whether it’s trivially destructible. Generalized PODs ’11 (468)" (EMCppSfe 2021)
# trivial destructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa destructor that is neither user provided nor virtual and that does not invoke any non-trivial destructors for base classes or data members. Generalized PODs ’11 (408), noexcept Specifier (1101)" (EMCppSfe 2021)
# trivial move-assignment operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa move-assignment operator that is not user provided, is for a nonpolymorphic type, and does not invoke any non-trivial move-assignment operators for base classes or members; it essentially performs a bitwise copy of the object representation." (EMCppSfe 2021)
# trivial move constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa move constructor that is not user provided, is for a nonpolymorphic type, and does not invoke any non-trivial constructors for base classes or data members; it essentially performs a bitwise copy of the object representation. Generalized PODs ’11 (528)" (EMCppSfe 2021)
# trivial move operation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is generated by the compiler and — just like a trivial copy operation — is essentially a bitwise copy of the underlying object representation. Rvalue References (733)" (EMCppSfe 2021)
# trivial operation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa special member function that is trivial — i.e., one having a compiler-provided implementation that conceptually does the absolute minimum amount of work: nothing (for a trivial default constructor or trivial destructor) or just a simple bitwise copy of the object representation (for a trivial copy constructor, trivial move constructor, trivial copy-assignment operator, or trivial move-assignment operator). Defaulted Functions (33)" (EMCppSfe 2021)
# trivial type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa scalar type, trivial class type, array of such a type, or cv-qualified version of such a type. Generalized PODs ’11 (401), union ’11 (1174)" (EMCppSfe 2021)
# triviality – the quality of an entity or operation being trivial or not. Rvalue References (733)" (EMCppSfe 2021)
# trivially constructible - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given type T and a (potentially empty) template parameter pack A, that the standard library type trait std::is_trivially_constructible::value is true — i.e., T is of scalar type, or both the destructor and constructor of T that would be called for arguments of the types specified by A... are trivial, public, nondeleted, and unambiguously invocable, or T is an array of such types. In common usage, the argument type is not specified, in which case the meaning is the same as trivially default constructible. Function static ’11 (80), Generalized PODs ’11 (431)" (EMCppSfe 2021)
# trivially copy assignable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given type T, that the standard library type trait std::is_trivially_copy_assignable::value is true — i.e., an lvalue of type T can be unambiguously assigned-to from a const lvalue of type T via a trivial, public, and nondeleted assignment operator. Note that a trivial or trivially copyable type is not required to have a public, unambiguous copy-assignment operator and is thus not necessarily trivially copy assignable. Generalized PODs ’11 (486)" (EMCppSfe 2021)
# trivially copy constructible - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given type T, that the standard library type trait std::is_trivially_constructibleconst T&>::value is true — i.e., T is of scalar type, both the copy constructor and destructor of T are trivial, public, nondeleted, and unambiguously invocable, or T is an array of such types. Note that a type that is trivially copy constructible might not be trivially copyable and vice versa. Generalized PODs ’11 (488)" (EMCppSfe 2021)
# trivially copyable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given type, that it is a trivially copyable type. Defaulted Functions (39), Generalized PODs ’11 (401), Rvalue References (765)" (EMCppSfe 2021)
# trivially copyable class - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone having a nondeleted trivial destructor and at least one of the four possible copy or move operations — i.e., one of copy constructor, move constructor, copy-assignment operator, or move-assignment operator — that is not deleted and none of which is non-trivial. Note that a trivially copyable class might not be trivially copy constructible and vice versa. Generalized PODs ’11 (521)" (EMCppSfe 2021)
# trivially copyable type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa scalar type, trivially copyable class, array of such a type, or cv-qualified version of such a type; such types are assignable by external bitwise copying, e.g., using std::memcpy. Generalized PODs ’11 (468)" (EMCppSfe 2021)
# trivially default constructible - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given type T, that the standard library type trait std::is_trivially_default_constructible::value is true. In other words, T is a scalar type, or both the default constructor and destructor of T are trivial and usable (i.e., public, nondeleted, and unambiguously invocable), or T is an array of such types. Note that a trivial type is not required to have a public or unambiguous default constructor or destructor and is thus not necessarily trivially default constructible. Generalized PODs ’11 (401)" (EMCppSfe 2021)
# trivially destructible - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given type, that it is a trivially destructible type, and, hence, failing to execute that destructor before deallocating or reusing an object's memory is typically of no practical consequence; see also notionally trivially destructible. constexpr Variables (305), Generalized PODs ’11 (402), noexcept Specifier (1102)" (EMCppSfe 2021)
# trivially destructible type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone for which the standard library type trait std::is_trivially_destructible::value is true — i.e., it is a class type with a trivial, public, and nondeleted destructor, a scalar type, an array of such types with known bound, or a reference type. Note that a trivial type is not required to have a public destructor and is thus not necessarily a trivially destructible type; see also usable. Generalized PODs ’11 (430)" (EMCppSfe 2021)
# trivially move assignable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given type T, that the standard library type trait std::is_trivially_move_assignable::value is true — i.e., an lvalue of type T can be unambiguously assigned-to from an rvalue of type T via a trivial, public, and nondeleted assignment operator. Note that a trivial or trivially copyable type is not required to have a public unambiguous move-assignment operator and is thus not necessarily trivially move assignable; see also usable." (EMCppSfe 2021)
# trivially move constructible - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given type T, that the standard library type trait std::is_trivially_move_constructible::value is true — i.e., T is trivially destructible and can be unambiguously constructed from an rvalue of type T via a trivial, public, and nondeleted constructor. Note that a trivial or trivially copyable type is not required to have a public, unambiguous move constructor or destructor and is thus not necessarily trivially move constructible." (EMCppSfe 2021)
# TU – short for translation unit." (EMCppSfe 2021)
# type alias - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan alternate name for a type, declared using a typedef or, as of C++11, a using declaration; see Section 1.1.“using Aliases” on page 133. friend ’11 (1031)" (EMCppSfe 2021)
# type deduction - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for function-template-argument type deduction. Forwarding References (380)" (EMCppSfe 2021)
# type erasure - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan idiom enabling dynamic polymorphism without requiring inheritance from a base class or overriding virtual functions. Type erasure in C++ involves creating a class C that defines an API via its (nonvirtual) public interface and supplies a constructor (or other member [or even friend function) template that adapts an object of its parameter type T to that API. This approach allows C to be used as a vocabulary type, supporting polymorphism across API boundaries without requiring T objects to have a common base class nor requiring clients to be templates. For example, in the C++ Standard Library, std::function uses type erasure to erase the type of an invocable object, and std::shared_ptr uses it to erase the type of its deleter. Lambdas (602)" (EMCppSfe 2021)
# type inference - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe feature whereby the compiler substitutes the type of an expression for an auto placeholder or decltype specifier. alignof (193) type list - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa library (i.e., reusable) class template that can capture a sequence of types and exposes basic list operations on those types for use in compile-time metaprogramming. constexpr Functions ’14 (963)" (EMCppSfe 2021)
# type parameter pack - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for type template parameter pack. Variadic Templates (903)" (EMCppSfe 2021)
# type punning - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXcircumventing the type system to enable access to an object of a given type as though it were an object of a different type. Generalized PODs ’11 (401)" (EMCppSfe 2021)
# type suffix - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXcharacters at the end of a literal token that affect its interpretation; a type suffix can be either a built-in suffix (e.g., f, u, L) or a UDL suffix; see Section 2.1.“User-Defined Literals” on page 835. User-Defined Literals (837)" (EMCppSfe 2021)
# type template parameter - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa template parameter that expects a type as its argument: in the declaration — template <typename T> class C; — T is a type parameter for class template C." (EMCppSfe 2021)
# type template parameter pack - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa template parameter pack that represents a sequence of template argument types: in the declaration — template <typename... T> class C; — T is a type template parameter pack for class template C. Variadic Templates (880)" (EMCppSfe 2021)
# type trait - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa metafunction for providing a Boolean predicate on the properties of a type (for compile-time introspection) or else a transformed version of a type (facilitating generic programming). A type trait is typically defined as (1) a class template taking one or more type template parameters and having a static constexpr bool data member named value that holds the evaluated predicate, (2) a class template having a type alias member named type that represents the transformed type, (3) a constexpr bool variable template that yields the value of the evaluated predicate, or (4) an alias template that yields the transformed type. static_assert (119), using Aliases (136), Variable Templates (161), Forwarding References (378), Generalized PODs ’11 (436), noexcept Operator (649)" (EMCppSfe 2021)
U
# UB - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for undefined behavior." (EMCppSfe 2021)
# UDL - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for user-defined literal." (EMCppSfe 2021)
# UDL operator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone having a name of the form operator""<identifier>, designating <identifier> as a UDL suffix. The UDL operator is invoked to produce the value of a user-defined literal having the specified <identifier> suffix. Declaring a UDL operator with an <identifier> that does not begin with _ is reserved for exclusive use by the Standard Library. User-Defined Literals (837)" (EMCppSfe 2021)
# UDL operator template - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa family of UDL operators that is declared as a variadic function template (see Section 2.1.“Variadic Templates” on page 873) having a single non-type template parameter pack of type char and taking no function arguments. Note that a distinct instantiation results for each unique string to which such an operator is applied, possibly resulting in code bloat. User-Defined Literals (841)" (EMCppSfe 2021)
# UDL suffix - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe identifier at the end of a user-defined literal, used to locate an appropriate UDL operator. User-Defined Literals (837)" (EMCppSfe 2021)
# UDL type category - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone characterizing the kind of naked literal that precedes the suffix part of a user-defined literal — i.e., one of (1) integer literal, (2) floating-point literal, (3) character literal, or (4) string literal. User-Defined Literals (837)" (EMCppSfe 2021)
# UDT - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for user-defined type. final (1007)" (EMCppSfe 2021)
# undefined behavior (UB) – that which results from executing a piece of C++ code for which no behavior is defined by the language or library and, in theory, could be anything. A well-formed construct in the language, e.g., dereferencing a pointer to access an object, can result in language undefined behavior (a.k.a. hard UB) under certain conditions (e.g., if the pointer is null). A function having a narrow contract makes no guarantees when invoked with one or more of its preconditions unsatisfied; doing so results in library undefined behavior (a.k.a. soft UB), which is not in and of itself language UB but might well lead to it; see also ill formed. Attribute Syntax (18), Delegating Ctors (50), Function static ’11 (70), long long (90), noreturn (97), alignof (190), Braced Init (218), Generalized PODs ’11 (401), initializer_list (556), Range for (692), Rvalue References (715), final (1024), friend ’11 (1049), inline namespace (1077), noexcept Specifier (1104), union ’11 (1175), auto Return (1187)" (EMCppSfe 2021)
# undefined symbol - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe name (possibly mangled) of an entity that has been odr-used but not defined. extern template (363)" (EMCppSfe 2021)
# underlying type (UT) – the integral type used to represent values of an enumeration. Uni-code Literals (131), alignas (171), constexpr Variables (308), enum class (333), Generalized PODs ’11 (501), Inheriting Ctors (542), Opaque enums (660), Underlying Type ’11 (829)" (EMCppSfe 2021)
# unevaluated context - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan unevaluated operand or subexpression thereof. Note that the expression (0 ? a : b) does not provide an unevaluated context for a, even though a will never be evaluated. decltype (31), noexcept Specifier (1132)" (EMCppSfe 2021)
# unevaluated operand - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan expression used as an argument to a compile-time operator — e.g., sizeof, typeid (except for expressions of polymorphic type), alignof, decltype, or noexcept — that does not evaluate the expression but merely introspects some aspect of that expression’s static type. An unevaluated operand is not ODR-used. As of C++20, either a requires expression or an expression used in a requires clause is also an unevaluated operand. noexcept Operator (615)" (EMCppSfe 2021)
# Unicode - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan international standard encoding used to represent most text characters found in the world’s various languages and writing systems, as well as special symbols and control characters. Unicode has a maximum of 1, 112, 064 code points, of which 144, 697 were assigned as of Unicode 14.0.0; see unicode." (EMCppSfe 2021)
# unification - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe algorithmic process in C++ of finding the appropriate template arguments that can make two parameterized symbolic types equivalent, e.g., when identifying a type for a template parameter during template argument deduction. Variadic Templates (901)" (EMCppSfe 2021)
# uniform initialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa colloquial term for a set of C++11 features, braced initialization in particular, that allow the use of braces ({ and }) as a consistent syntax for initializing an object, whether of scalar type, class type, or array type — e.g., int x{0}; S s{}; char a[]{'p', 'q'}; see also most vexing parse. Braced Init (215)" (EMCppSfe 2021)
# unique object address - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given object of a given type, that no other object of that type resides at that same address at the same time. In general, two non-bit-field objects having overlapping lifetimes must have distinct addresses unless one is nested within the other (e.g., a base class subobject and the enclosing derived-class object, or an object and its first nonstatic data member) or they are of different types and at least one is an empty base class (e.g., a base class and a nonstatic data member with a different type at offset 0). As of C++20, the requirement for an object to have a distinct address may be relaxed under certain circumstances (e.g., for an empty member object of class type) through use of the no_[[unique_address attribute. Generalized PODs ’11 (418)" (EMCppSfe 2021)
# unique ownership - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa resource-management model in which at most one object can claim ownership of a resource at any given time. The move operations for a type implementing this model (a.k.a. a move-only type) will typically transfer ownership of any allocated resource to the moved-to object, leaving the moved-from object resourceless. Destroying the current owner releases the resource entirely — e.g., std::unique_ptr. Rvalue References (768)" (EMCppSfe 2021)
# unit test - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa (sometimes standalone) test intended to verify the correctness of the implementation of a single software component along with any of its inherent physical dependencies." (EMCppSfe 2021)
# universal reference - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa synonym for forwarding reference proposed by Scott Meyers, favored by some, and discouraged by the C++ Standards Committee. Forwarding References (400)" (EMCppSfe 2021)
# unnamed namespace - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone introduced without a name (a.k.a. an anonymous namespace). Any entity that is declared within an unnamed namespace is unique to the translation unit in which it is defined, has internal linkage (which, for an object, is comparable to declaring it static at file scope), and can be used as if it were declared in the enclosing namespace without additional qualification (see Section 3.1.“inline namespace” on page 1055). Function static ’11 (77)" (EMCppSfe 2021)
# unqualified id - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXan identifier (e.g., x), operator name (e.g., operator=), or template id (e.g., TC::B>) that is not preceded by a scope-resolution operator (::) or class member access operator (. or ->)." (EMCppSfe 2021)
# unqualified name lookup - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe process by which an unqualified ID is matched to an entity by searching through enclosing class and namespace scopes, as well as associated namespaces nominated by argument-dependent lookup (ADL). User-Defined Literals (841)" (EMCppSfe 2021)
# unrelated types – types that are either (1) entirely unrelated by inheritance or (2) do not share a common polymorphic class as a base class (note that pointers and references to unrelated types are not interconvertible using dynamic_cast). Generalized PODs ’11 (507)" (EMCppSfe 2021)
# unsigned ordinary character type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXeither unsigned char or, on platforms where char is unsigned, char. Generalized PODs ’11 (515)" (EMCppSfe 2021)
# usable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given member function, that it is accessible, defined, and, in the context in which it is called, unambiguous, i.e., overload resolution will identify it as the best viable function." (EMCppSfe 2021)
# usable literal type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that provides a nonempty set of operations beyond merely those required of it to be a literal type, enabling meaningful use in a constant expression. constexpr Functions (282)" (EMCppSfe 2021)
# user declared - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given function, that its declaration appears in the source code irrespective of whether it is deleted or defaulted; see Section 1.1.“Deleted Functions” on page 53 and Section 1.1.“Defaulted Functions” on page 33, respectively. constexpr Functions (274), Generalized PODs ’11 (413), noexcept Specifier (1086)" (EMCppSfe 2021)
# user defined - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given special member function, that it is user provided. Note that such use of the term user defined is obsolete as of C++11, replaced by the more precise terms user declared and user provided. (Note also that user defined retains other valid meanings that are not obsolete.)" (EMCppSfe 2021)
# user-defined conversion - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe result of invoking either a converting constructor or a conversion operator, explicitly or implicitly." (EMCppSfe 2021)
# user-defined literal (UDL) – a string or numeric literal whose meaning is defined by either the user or the standard library. A UDL suffix at the end of the literal token identifies which UDL operator is used to interpret it and produce a value. Generalized PODs ’11 (462), User-Defined Literals (837)" (EMCppSfe 2021)
# user-defined type (UDT) – a (1) class, (2) struct, (3) union, or (4) enumeration type (enum or enum class; see Section 2.1.“enum class” on page 332). Delegating Ctors (46), alignas (168), Default Member Init (322), Generalized PODs ’11 (462), initializer_list (553), noexcept Operator (622), Rvalue References (742), User-Defined Literals (835), final (1012), friend ’11 (1031)" (EMCppSfe 2021)
# user provided - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given function, that it is user declared and is not explicitly defaulted or deleted on its first declaration. Function static ’11 (80), Braced Init (217), Generalized PODs ’11 (413), Rvalue References (742), noexcept Specifier (1087)" (EMCppSfe 2021)
# user-provided special member function - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa special member function that is user provided. Defaulted Functions (33)" (EMCppSfe 2021)
# using declaration - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that begins with using and introduces an existing declaration into the current scope and is sometimes used colloquially to refer to the declaration of a type alias or alias template; see Section 1.1.“using Aliases” on page 133. constexpr Functions (268), Inheriting Ctors (535)" (EMCppSfe 2021)
# using directive - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for using-namespace directive. constexpr Functions (268), User-Defined Literals (842), inline namespace (1056)" (EMCppSfe 2021)
# using-namespace directive - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone — of the form using namespace ns — that makes all names in a nominated namespace ns usable in the current scope without namespace qualifiers; see Section 3.1.“inline namespace” on page 1055." (EMCppSfe 2021)
# UT - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for underlying type." (EMCppSfe 2021)
# UTF-8 – a variable-width encoding for Unicode characters that uses one to four 8-bit code units for each code point and is designed to encode the first 128 Unicode code points using a 1-byte representation that is identical to that used by the ASCII character encoding. User-Defined Literals (844)" (EMCppSfe 2021)
# UTF-16 – a variable-width encoding for Unicode characters that uses one or two 16-bit code units for each code point. User-Defined Literals (844)" (EMCppSfe 2021)
# UTF-32 – a fixed-width encoding for Unicode characters that uses one 32-bit code unit for each code point. User-Defined Literals (844)" (EMCppSfe 2021)
V
# valid but unspecified– implies, for a given object, that it meets the C++ Standard Library’s minimum requirements for a moved-from object; such an object must, in principle, meet all of the requirements of the specific Standard Library template with which it is used, especially that it can be assigned-to (if the template requires assignability), swapped (if the template requires swappability), compared (if the template requires comparison), and destroyed (often required, even if not documented); see also moved-from state. Rvalue References (715)" (EMCppSfe 2021)
# value - XXXXXXXXXXXXXXXXXXXXXXXXXXXXX(1) the platonic value (or else the in-process value) represented by an object such as might affect the result of its associated homogeneous equality-comparison operator or (2) the bit pattern associated with its value representation. Delegating Ctors (51), noexcept Operator (625), Rvalue References (741), Lambda Captures (992), Ref-Qualifiers (1162)" (EMCppSfe 2021)
# value category - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa characterization of a compile-time property of a (typically runtime-evaluable) expression. Every expression has one of three disjoint leaf value categories: lvalue, xvalue, and prvalue. In addition, two compound value categories — glvalue (comprising lvalue and xvalue) and rvalue (comprising xvalue and prvalue) — serve to characterize values that (1) have identity and (2) are expiring, respectively; see Section 2.1.“Rvalue References” on page 710. decltype (25), Forwarding References (377), Lambdas (590), Range for (680), Rvalue References (710), Generic Lambdas (972), Lambda Captures (992), noexcept Specifier (1145), Ref-Qualifiers (1153), auto Return (1184), decltype (auto) (1205)" (EMCppSfe 2021)
# value constructor - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone designed to assemble (as opposed to copy or move) an overall value from one or more supplied arguments and that (absent defaulted arguments) is never also a default constructor, copy constructor, or move constructor. Defaulted Functions (37), Generalized PODs ’11 (450), Rvalue References (753), User-Defined Literals (836), Variadic Templates (942)" (EMCppSfe 2021)
# value initialization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of initialization, typically invoked by supplying an empty (rather than absent) initializer list, such as () or {}, that (1) performs zero initialization for scalar types as well as class types having a trivial default constructor, (2) invokes the default constructor for class types having a user-provided default constructor, or (3) performs zero initialization and then invokes the default constructor for all other class types, i.e., those that have a compiler-generated non-trivial default constructor. For an array type, each individual element is value initialized. Value initialization for a type having a deleted or ambiguous default constructor is ill formed — even if said initialization would not involve invoking the default constructor. Braced Init (216), constexpr Functions (273), Generalized PODs ’11 (493)" (EMCppSfe 2021)
# value initialized - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given object, that it has undergone value initialization. Braced Init (221), Generalized PODs ’11 (412), Rvalue References (764)" (EMCppSfe 2021)
# value representation - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe bits in an object’s footprint that represent its value, excluding, e.g., those used for padding or to represent a virtual-function-table pointer or virtual-base pointer. Generalized PODs ’11 (405)" (EMCppSfe 2021)
# value semantic (of a type)– implies, for a given type, that it has value semantics. Defaulted Functions (36), Delegating Ctors (48), alignof (187), Opaque enums (663), Rvalue References (743)" (EMCppSfe 2021)
# value-semantic type (VST) – one, specifically a class type, that has value semantics. Forwarding References (386), Generalized PODs ’11 (452), Rvalue References (742), Lambda Captures (992), friend ’11 (1034)" (EMCppSfe 2021)
# value semantics – the fundamental, language-independent, mathematical principles that must be satisfied by any type that properly represents a platonic value; see lakos15a. Importantly, two objects of a value-semantic type do not have the same value (as defined by their respective salient attributes) if there exists a sequence of salient operations (a.k.a. a distinguishing sequence) that, when applied to each object separately, mutates the respective objects such that they can be observed not to have (i.e., represent) the same value. Note that a well-written C++ value-semantic type will also be a regular type (see stepanov09, section 1.5, “Regular Types,” pp. 6–8) unless its (homogeneous) equality-comparison operator (==) would be too computationally complex; if it’s omitted, the type becomes semiregular (see stepanov15, section 10.3, “Concepts,” pp. 181–184, specifically p. 184); see also lakos15b. Also note, as of C++20, the Standard Library supports the concepts std::regular and std::semiregular. noexcept Operator (627), Rvalue References (811)" (EMCppSfe 2021)
# variable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa named object having automatic, static, or thread storage duration." (EMCppSfe 2021)
# variable template - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone — e.g., template <typename T> T var; — that can be instantiated to yield a family of like-named variables, each of distinct type, e.g., var<int>, var<double>; see Section 1.2.“Variable Templates” on page 157. constexpr Variables (302)" (EMCppSfe 2021)
# variadic class template - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that can be instantiated with a variable number of template arguments by virtue of having a parameter pack in its template parameter list. Variadic Templates (892)" (EMCppSfe 2021)
# variadic function template - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that can be instantiated with a variable number of template arguments by virtue of having a parameter pack in its template parameter list, typically callable with a variable number of function arguments, achieved by having a function parameter list that contains a function parameter pack. Lambdas (590), Variadic Templates (957), Generic Lambdas (978)" (EMCppSfe 2021)
# variadic macro - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that can be expanded with a variable number of macro arguments. Originally a C99 feature and incorporated into C++ as of C++11, a variadic macro is declared with an ellipsis (...) in its parameter list; within the macro, the special identifier __VA_ARGS__ expands to the macro arguments matching the ellipsis. Braced Init (249), Rvalue References (781), noexcept Specifier (1145)" (EMCppSfe 2021)
# variadic member function template - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa variadic function template declared as a member of a class. Variadic Templates (892)" (EMCppSfe 2021)
# vectorization - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe use, by the compiler, of special platform-specific CPU instructions that can perform (typically arithmetic) operations on multiple values at once. noexcept Specifier (1137)" (EMCppSfe 2021)
# vertical encoding - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa data layout whereby the values of certain bits indicate the intended interpretation of other bits within the same data structure. Generalized PODs ’11 (440)" (EMCppSfe 2021)
# virtual base pointer - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa common implementation of virtual base classes where a derived-class object contains internal pointers to its virtual base class subobjects, which may be at different locations relative to the object depending on its concrete type. An alternative to a virtual base pointer, used in the Itanium ABI, is to include offsets to virtual bases within the virtual-function table. Generalized PODs ’11 (409)" (EMCppSfe 2021)
# virtual dispatch - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of dynamic dispatch achieved in C++ via inheritance and virtual functions, which are invariably implemented using virtual-function tables. final (1015)" (EMCppSfe 2021)
# virtual-function table - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa compiler-generated data structure specific to each polymorphic class used to dispatch a virtual function call to the appropriate concrete function implementation at run time. The compiler assigns each member function that is declared virtual in a base class a distinct index that is used to look up a function pointer and an offset (typically zero in the case of non-virtual single inheritance) to be applied to the this pointer prior to invoking the function. The layout of a virtual function table is implementation-specific and might also store RTTI information and virtual-base class offsets. Note that each object of polymorphic type stores, within its footprint, an extra hidden pointer to its class’s virtual-function table. Generalized PODs ’11 (441)" (EMCppSfe 2021)
# vocabulary type - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone that is used widely in the interfaces of functions to represent a common (typically concrete) data type (e.g., int, double, std::string) or (typically abstract) service (e.g., std::pmr::memory_resource in C++17). long long (91), Unicode Literals (131), constexpr Functions (291)" (EMCppSfe 2021)
# VST - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for value-semantic type." (EMCppSfe 2021)
# vtable - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXshort for virtual-function table. noexcept Operator (617)" (EMCppSfe 2021)
# vtable pointer - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa pointer, hidden in the footprint of each object of polymorphic type, used to access the virtual function table that will be employed during virtual dispatch and, for some implementations, to access a virtual base class. Generalized PODs ’11 (409), final (1011)" (EMCppSfe 2021)
W
# well formed - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given program or program fragment, that it meets the language requirements for proper translation, i.e., that no part of it is ill formed. Note that being well formed does not imply that a program is correct; a well-formed program might still compute results incorrectly or have undefined behavior at runtime; see also IFNDR. alignas (169)" (EMCppSfe 2021)
# wide contract - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXone without preconditions. Note that restrictions imposed by the C++ language itself — e.g., that an input not have indeterminate value — are not considered preconditions for the purpose of determining whether a contract is wide; see also narrow contract. Rvalue References (750), final (1021), noexcept Specifier (1112)" (EMCppSfe 2021)
# widening the contract - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe act of evolving the interface of a function having a narrow contract by weakening or removing preconditions to increase its domain in a way that will not invalidate any existing in contract call to the function. Note that a contract that has been widened is not necessarily a wide contract (i.e., some preconditions might still exist)." (EMCppSfe 2021)
# witness argument - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa specific value used as an argument in a test to prove that a function is callable or has some other hard-to-discover but easy-to-verify behavior. constexpr Functions (283)" (EMCppSfe 2021)
# working set - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXthe set of memory pages (or cache lines) currently needed by the program over some fixed time interval. If the working-set size is too large, the program will be subject to thrashing. alignas (182), noexcept Specifier (1139)" (EMCppSfe 2021)
X
# xvalue - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa glvalue that denotes an object whose resources can be reused. decltype (26), auto Variables (206), Forwarding References (380), Rvalue References (710), decltype (auto) (1206)" (EMCppSfe 2021)
Y
# Y combinator - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa function object that indirectly holds a reference to itself, providing one form of expressing recursive lambda expressions. Generic Lambdas (978)" (EMCppSfe 2021)
Z
# zero cost - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXimplies, for a given implementation choice (e.g., exception-handling model), that, if not used (e.g, no exception is thrown), it imposes exactly zero additional runtime cost. In particular, the zero-cost exception model was chosen in service of a fundamental design criteria of C++ that, for a language feature to be adopted, it impose no general (i.e., no program-wide) runtime overhead, “What you don’t use, you don’t pay for (zero-overhead rule)” (stroustrup94, section 4.5, “Low-Level Programming Support Rules,” pp. 120–121, specifically p. 121). Moreover, whenever such a feature is used, it (typically) couldn’t be hand coded any better. See also zero-cost exception model. noexcept Specifier (1136)" (EMCppSfe 2021)
# zero-cost exception model - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa technique for implementing C++ exception handling whereby no instructions related to possible exceptions are inserted into the nonexceptional code path (a.k.a. the hot path). This technique maximizes the speed of execution along the hot path by avoiding a test, on each function call return, to check whether the called function exited via an exception. Instead, the compiler generates tables that are used to lookup and jump to appropriate exception-handling code (a.k.a. the cold path) when an exception is thrown. Some compilers go so far as to put the cold path in entirely separate memory pages so that it is not loaded into memory unless and until an exception is thrown, at the cost of much lower runtime performance on the presumably rare occasions when the cold path code is taken. noexcept Specifier (1134)" (EMCppSfe 2021)
# zero initialized - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXa form of initialization in which (1) scalar objects are initialized as if from an integer literal 0, (2) all subobjects of array and class types are zero initialized, (3) the first data members of objects of union type are zero initialized, with any padding bits set to zero, and (4) reference types are not initialized. For example, objects having static storage duration or thread storage duration are zero initialized prior to any other initialization that might be performed. Function static ’11 (75), Braced Init (218)" (EMCppSfe 2021)
# zero-overhead exception model – a synonym for zero-cost exception model. noexcept Specifier (1101)" (EMCppSfe 2021)
Fair Use Sources
Fair Use Sources:
* B09HTFQB92 (EMCppSfe 2021)
C Plus Plus | C++: Effective CPP | Effective C++, C Plus Plus Best Practices | C++ Best Practices, CPP Core Guidelines (CG) by Bjarne Stroustrup and Herb Sutter | C++ Core Guidelines (CG) by Bjarne Stroustrup and Herb Sutter, C Plus Plus Fundamentals | C++ Fundamentals, C Plus Plus Inventor | C++ Inventor - C Plus Plus Language Designer | C++ Language Designer: Bjarne Stroustrup in 1985; C Plus Plus Keywords | C++ Keywords, CPP Built-In Data Types | C++ Built-In Data Types, C Plus Plus Data Structures | C++ Data Structures (CPP Containers) - C Plus Plus Algorithms | C++ Algorithms, C Plus Plus Syntax | C++ Syntax, C Plus Plus OOP | C++ OOP - C Plus Plus Design Patterns | C++ Design Patterns, Clean C Plus Plus | Clean C++ - C Plus Plus Style Guide | C++ Style Guide - C Plus Plus BDD | C++ BDD, C Plus Plus Standards | C++ Standards (C Plus Plus 23 | C++ 23, C Plus Plus 20 | C++ 20, C Plus Plus 17 | C++ 17, C Plus Plus 14 | C++ 14, C Plus Plus 11 | C++ 11, C Plus Plus 03 | C++ 03, C Plus Plus 98 | C++ 98), Bjarne Stroustrup's C Plus Plus Glossary | Bjarne Stroustrup's C++ Glossary - Glossaire de CCP - French, CppReference.com, CPlusPlus.com, ISOcpp.org, C Plus Plus Compilers | C++ Compilers (Compiler Explorer, MinGW), C Plus Plus IDEs | C++ IDEs, C Plus Plus Development Tools | C++ Development Tools, C Plus Plus Linter | C++ Linter, C Plus Plus Debugging | C++ Debugging, C Plus Plus Modules | C++ Modules (C Plus Plus 20 | C++20), C Plus Plus Packages | C++ Packages, C Plus Plus Package Manager | C++ Package Manager (Conan - the C/C Plus Plus Package Manager | Conan - the C/C++ Package Manager), C Plus Plus Standard Library | C++ Standard Library, C Plus Plus Libraries | C++ Libraries, C Plus Plus Frameworks | C++ Frameworks, C Plus Plus DevOps | C++ DevOps - C Plus Plus SRE | C++ SRE, C Plus Plus CI/CD | C++ CI/CD (C Plus Plus Build Pipeline | C++ Build Pipeline), C Plus Plus Data Science | C++ Data Science - C Plus Plus DataOps | C++ DataOps, C Plus Plus Machine Learning | C++ Machine Learning, C Plus Plus Deep Learning | C++ Deep Learning, Functional C Plus Plus | Functional C++, C Plus Plus Concurrency | C++ Concurrency, C Plus Plus History | C++ History, C Plus Plus Topics | C++ Topics, C Plus Plus Bibliography | C++ Bibliography, Manning CPP Series | Manning C++ Series, C Plus Plus Courses | C++ Courses, CppCon, C Plus Plus Research | C++ Research, C Plus Plus GitHub | C++ GitHub, Written in C Plus Plus | Written in C++, C Plus Plus Popularity | C++ Popularity, C Plus Plus Awesome | C++ Awesome , C Plus Plus Versions | C++ Versions. (navbar_cplusplus -- see also navbar_cpp_containers, navbar_cppcon, navbar_cpp_core_guidelines, navbar_cpp23, navbar_cpp20, navbar_cpp17, navbar_cpp14, navbar_cpp11)
----
Cloud Monk is Retired (impermanence | for now). Buddha with you. Copyright | © Beginningless Time - Present Moment - Three Times: The Buddhas or Fair Use. Disclaimers
SYI LU SENG E MU CHYWE YE. NAN. WEI LA YE. WEI LA YE. SA WA HE.
----