Embracing Modern C Plus Plus Safely Glossary (CloudMonk.io)

Embracing Modern C++ Safely Glossary



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 Word List | Embracing Modern C++ Safely Glossary Word List
* 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

(EMCppSfe 2021)



Note: In the blue text at the end of each definition, the number inside parentheses indicates the page on which the glossary term is first used in a given feature.


A



* "ABI - short for application binary interface. Generalized PODs ’11 (402), inline namespace (1056), noexcept Specifier (1089)" (EMCppSfe 2021)

* "abstract class - one from which objects cannot be instantiated. In C++, the term abstract class is typically used to imply one that has at least one pure virtual function. Note that an object that is not instantiable for some other reason, say, having no usable constructor (other than a copy constructor), might be said to be not concrete; see also concrete class. final (1008)" (EMCppSfe 2021)

* "abstract interface - a protocol." (EMCppSfe 2021)

* "abstract machine - a hypothetical nondeterministic computer defined by the C++ Standard to abstractly model real hardware and provide a basis for describing the semantics of the C++ language absent resource (e.g., memory) constraints. noexcept Specifier (1118)" (EMCppSfe 2021)

* "access level - a property, i.e., public, protected, or private, of member m of a class C as determined by the access level in effect in C where m was declared. Generalized PODs ’11 (489)" (EMCppSfe 2021)

* "access specifier - one of three keywords, private, protected, or public, used to specify the prevailing access level, governing the situations under which base classes and declared members are accessible: private base classes and members may be accessed only from within that class or by friends, protected base classes and members may also be accessed by derived classes, and public base classes and members may be accessed from anywhere. Defaulted Functions (35), Inheriting Ctors (537)" (EMCppSfe 2021)

* "accessible (from a context) – implies, for a given member m, that its name is not precluded from use in a given client context c due solely to the access level of m. For example, if m is declared protected within a class S and c is the body of a member function of a class derived from S, then m is accessible when used in c. Note that accessible doesn’t necessarily imply usable, as m might be, e.g., ambiguous, deleted, or an ill-formed template specialization. Note that this term is sometimes used informally (and imprecisely) to mean publicly accessible. Generalized PODs ’11 (410), noexcept Operator (641), Rvalue References (790)" (EMCppSfe 2021)

* "active member - a unique nonstatic data member of a union whose lifetime has begun and has not ended. Generalized PODs ’11 (406)" (EMCppSfe 2021)

* "address space - all of the typically sequential, often virtual, almost always byte-addressable computer memory in which objects can be referenced via pointers. Note that, on embedded systems and older computers, the size of the addressable memory can be severely constrained (e.g., by the width of the address bus)." (EMCppSfe 2021)

* "ADL - short for argument-dependent lookup." (EMCppSfe 2021)

* "aggregate - an aggregate type or an object thereof. Aggregate Init ’14 (138), Braced Init (230), Default Member Init (330), Generalized PODs ’11 (402), Rvalue References (750), Variadic Templates (877), noexcept Specifier (1087)" (EMCppSfe 2021)

* "aggregate class - one of aggregate type. Generalized PODs ’11 (415)" (EMCppSfe 2021)

* "aggregate initialization - the initialization of an aggregate from a braced-initializer list. Aggregate Init ’14 (138), Braced Init (221), constexpr Functions (273), Default Member Init (330), Generalized PODs ’11 (463), Rvalue References (752)" (EMCppSfe 2021)

* "aggregate type - (1) a class type having no user-provided or explicit constructors, no base classes, no private or protected nonstatic data members, and no virtual functions, or (2) any array type. As of C++14, aggregates can have default member initializers for nonstatic data members. As of C++17, public nonvirtual base classes are allowed, but inherited constructors are not; as of C++20, all user-declared constructors become disallowed. constexpr Functions (279), Generalized PODs ’11 (410), Rvalue References (742)" (EMCppSfe 2021)

* "algebra - a set of operations, often involving just a single type, that can be applied to object values, along with any rules governing those operations and how they interrelate; see also value semantics. constexpr Functions ’14 (961)" (EMCppSfe 2021)

* "algorithm selection - the process by which an algorithm is chosen from among a portfolio of potentially applicable algorithms, based on readily observable, especially compile-time, features of the input data set (see leyton-brown03). Variadic Templates (947)" (EMCppSfe 2021)

* "alias template - one that defines a family of type aliases parameterized by one or more template parameters. using Aliases (135), Variadic Templates (887)" (EMCppSfe 2021)

* "aliasing - having pointers or references to distinct objects (possibly of distinct type) whose footprints overlap in the address space. noexcept Operator (638)" (EMCppSfe 2021)

* "alignment (of an address) – the largest integral power of 2 that evenly divides the numerical value of a given address in the address space. alignas (168)" (EMCppSfe 2021)

* "alignment requirement (of a type) – the smallest alignment at which an object of a given type can reside in the address space; see also natural alignment. alignas (168), alignof (184)" (EMCppSfe 2021)

* "allocating object - one that might itself allocate and manage dynamically allocated memory outside of its own footprint using new, malloc, or some other allocation interface, such as std::allocator or, as of C++17, std::pmr::polymorphic_allocator. noexcept Operator (634)" (EMCppSfe 2021)

* "allocator aware - implies, for a given allocating object’s type, that its API supports the ability to supply an external resource to the class’s constructor, used by the object to obtain memory; see also scoped allocator model." (EMCppSfe 2021)

* "amortized constant time (of a repeated operation) – a bound on the runtime complexity of a given operation such that when it is repeated N times (where N is a sufficiently large number), the total time spent is proportional to N, leading to a constant average time spent per operation. Note that any single iteration might not have a fixed limit on its run time and thus not execute in constant time. The classic example involves populating a default-constructed std::vector with allocating objects via repeated calls to push_back (assuming dynamic memory allocation itself is slow but still considered a constant-time operation); see also constant time. noexcept Operator (636)" (EMCppSfe 2021)

* "API - short for application programming interface. Generalized PODs ’11 (402), Rvalue References (793), inline namespace (1056)" (EMCppSfe 2021)

* "application binary interface (ABI)– the object-code-level aspects of a given library that might be needed to link it into a client program, such as the layout of scalar and class objects, how function names are mangled (to produce type-safe linkage), as well as parameter-calling and return-value conventions; if two libraries (e.g., two versions of the same library) have the same ABI, then they are interchangeable (mutually substitutable), requiring a client application only to relink but specifically not recompile." (EMCppSfe 2021)

* "application programming interface (API) – the source-code-level aspects of a library that are programmatically accessible to client software such as type aliases, enumerations, class definitions, and so on; two libraries having the same API but different ABIs are interchangeable (mutually substitutable) provided that every translation unit directly or indirectly incorporating source code from the API — e.g., via a processor #include directive or, as of C++20, a module import statement — is recompiled before the library is relinked." (EMCppSfe 2021)

* "architectural insulation - an architectural-level form of insulation." (EMCppSfe 2021)

* "argument - a value or object that is supplied to a parameterized entity and subsequently referred to by the name of its corresponding (formal) parameter — e.g., a type argument supplied to a template, or an object argument supplied to a function." (EMCppSfe 2021)

* "argument-dependent lookup (ADL) – the process by which, when a function is invoked using its unqualified name, candidate functions that will form the overload set are mustered from all namespaces associated with the function arguments along with those accessible from the caller’s scope. Generalized PODs ’11 (472), initializer_list (572), noexcept Operator (638), Range for (681), User-Defined Literals (841), inline namespace (1056)" (EMCppSfe 2021)

* "arithmetic type - any integral type or floating-point type. enum class (334)" (EMCppSfe 2021)

* "array-to-pointer decay – the implicit conversion from an array (having either known or unknown bounds) to a pointer to its first element. Braced Init (222)" (EMCppSfe 2021)

* "as-if - a rule that grants latitude to a compiler to transform code in any way that maintains the same observable behavior for well-formed programs — i.e., the same latitude granted to the optimizer. Note that every C++ compiler is required to emulate only the behavior of the abstract machine (modulo physical limitations) and makes no other guarantees regarding the operation of the physical hardware on which the program is run. constexpr Variables (307), Rvalue References (717)" (EMCppSfe 2021)

* "assignable (type) – implies, for a given type, that it has a homogeneous assignment operator, which is either built-in or a usable public assignment special member function that may be implicitly declared, defaulted, or user provided. Common usage is to treat the term assignable as short for copy assignable and to call out move assignable explicitly where relevant, such as when an object supports move assignment but not copy assignment. Generalized PODs ’11 (486)" (EMCppSfe 2021)

* "assignment operator - (1) a member function named operator= taking exactly one argument or (2) the built-in assignment operator (=). Generalized PODs ’11 (522), Rvalue References (816)" (EMCppSfe 2021)

* "atomic - implies, for a given operation, that it is executed either completely or not at all — e.g., concurrent atomic reads and writes cannot be observed to be partially completed. Function static ’11 (80)" (EMCppSfe 2021)

* "automatic storage duration - the C++ storage class of a nonstatic, nonthread_local function-scope object; an object of this storage class is created when the thread of execution passes through its definition and is destroyed immediately when execution leaves the lexical (a.k.a. block) scope in which it was defined. Note that all unnamed temporaries generated by the compiler are of this storage class. Function static ’11 (68), Rvalue References (731)" (EMCppSfe 2021)

* "automatic variable - a variable having automatic storage duration, as in a nonstatic, non-thread_local local (i.e., function-scope) variable. Note that C++11 redefines the C++03 meaning of the keyword auto; see Section 2.1.“auto Variables” on page 195." (EMCppSfe 2021)



B



* "backward compatibility - the property of a newer version of released software (e.g., a component or library) with respect to some previous version such that any program that might have depended on that previous version of the software would have the same essential behavior when rebuilt (relinked and perhaps recompiled) against the newer version. noexcept Specifier (1113)" (EMCppSfe 2021)

* "barrier - a memory barrier a.k.a. fence. Function static ’11 (82)" (EMCppSfe 2021)

* "base name (of a component) – the root name of a component’s header file, excluding any package prefix or filename extensions (e.g., bdlt_date in bdl/bdlt/bdlt_date.h); see lakos20, section 2.4.7, “Proprietary Software Requires an Enterprise Namespace,” pp. 309–310, specifically the definition on p. 310. Opaque enums (667)" (EMCppSfe 2021)

* "base specifier-list - a list that specifies, in the definition of a struct or class, the sequence of base classes, along with their respective access levels, whether each is virtual, and, potentially, any associated attributes; see Section 1.1.“Attribute Syntax” on page 12. Variadic Templates (883)" (EMCppSfe 2021)

* "basic exception-safety guarantee - a (typically implicit) promise that, in the event an exception is somehow thrown during the execution of a given function, (1) each object involved in the computation remains in a valid state (i.e., with its object invariants preserved) and (2) no resources are leaked. noexcept Operator (644)" (EMCppSfe 2021)

* "basic guarantee - short for basic exception-safety guarantee. noexcept Operator (644)" (EMCppSfe 2021)

* "basic source character set - the abstract character set that must be available for expressing C++ source code, which consists of space, horizontal and vertical tab, form feed, newline, the uppercase and lowercase Latin alphabet [A...Z] and [a...z], the 10 digits [0...9], and the 29 essential punctuation marks, _, {, }, [, ], #, (, ), <, >, %, :, ;, ., ?, *, +, -, /, ^, &, ]] | , ~, !, =, ,, \, ", and '. [[Raw String Literals (110), Unicode Literals (130)" (EMCppSfe 2021)

* "benchmark test - a measure of quantifiable and ideally repeatable results, e.g., runtime performance, object-code size, or memory consumption, that serves as a point of reference for comparing components, libraries, programs, and so on; most typically, benchmark testing is used to compare aspects of a proposed future version of software with its current one; see also microbenchmark and regression test. Raw String Literals (114)" (EMCppSfe 2021)

* "binary search - one in which the data in a sorted random-access data structure (e.g., a built-in array or an std::vector) is repeatedly partitioned into a pair of subsets of approximately equal size (e.g., differing by at most a constant) until the value is found or determined to be absent in O(logN) time, where N is number of elements in the data structure. constexpr Functions (292)" (EMCppSfe 2021)

* "bit field - a contiguous sequence of bits of a specified length, declared within a class definition and having an underlying representation of integral or enum type; adjacent bit fields may share a memory location, and unnamed bit fields (which may be of zero length) may be declared to force what would otherwise be an adjacent bit field into the next addressable memory location. Generalized PODs ’11 (526)" (EMCppSfe 2021)

* "block scope - one created by a compound statement bounded by { and } that forms or resides within a function’s body; variables that are declared within block scope are found by name only after their declaration within the block. Lambdas (587)" (EMCppSfe 2021)

* "boilerplate code - significant sections of source code that occur (typically copied) in multiple places with little or no variation. using Aliases (136), Variable Templates (161), Default Member Init (322), enum class (333)" (EMCppSfe 2021)

* "brace elision - the act, by a programmer, of omitting braces around the initialization of nested members of aggregate type during aggregate initialization of a compound aggregate. Aggregate Init ’14 (140)" (EMCppSfe 2021)

* "brace initialization - the initialization of an object using a braced-initializer list. Generalized PODs ’11 (493), Range for (684), Rvalue References (752), Variadic Templates (926)" (EMCppSfe 2021)

* "braced-initializer list - a possibly empty, comma-separated sequence of values between braces ({ and }) used as an object initializer. initializer_list (554)" (EMCppSfe 2021)

* "byte - the fundamental storage unit in the C++ memory model, necessarily at least 8 bits and, on modern hardware, universally exactly 8 bits. Digit Separators (153)" (EMCppSfe 2021)



C



* "C linkage - a form of linkage that allows for declarations and definitions written in C++ to match with callers and callees written and compiled in the C language. Generalized PODs ’11 (403)" (EMCppSfe 2021)

* "C++03 POD type - (1) a scalar type, (2) an aggregate type or union having no nonstatic data members that are not themselves C++03 POD types, or (3) an array of such objects. Generalized PODs ’11 (414)" (EMCppSfe 2021)

* "C++11 memory allocator - a potentially stateful (as of C++11) object that provides operations for allocating and deallocating memory dynamically. An allocator type appears as an optional template parameter in many standard containers and can be used to control how memory is allocated, how elements are constructed, and how they are referenced; see also C++17 pmr allocator. Rvalue References (763)" (EMCppSfe 2021)

* "C++11 POD type - a type that is both a trivial type and a standard-layout type. C++20 removes the notion of a POD type as it is no longer deemed necessary. Generalized PODs ’11 (415)" (EMCppSfe 2021)

* "C++17 pmr allocator - a form of stateful memory allocator that supports allocating memory dynamically via the std::pmr::memory_resource abstract base class, thus providing a common vocabulary for enabling custom memory allocation, especially allocation from local arenas; see lakos16, lakos17a, lakos17b, lakos19. Rvalue References (763)" (EMCppSfe 2021)

* "cache associativity - the characterization of the mapping from cache lines to locations in physical memory, ranging in implementation from one-to-many (direct mapped) to many-to-many with no restrictions (fully associative)." (EMCppSfe 2021)

* "cache hit - successfully finding needed data resident in a given level of cache, obviating its retrieval from outside that cache. alignas (181)" (EMCppSfe 2021)

* "cache line - the smallest unit of memory read from or written to main memory by a cache in a single operation. alignas (174), Generalized PODs ’11 (459), noexcept Specifier (1142)" (EMCppSfe 2021)

* "cache miss – failing to find needed data resident in a given level of cache, thus requiring its retrieval from outside that cache. alignas (182)" (EMCppSfe 2021)

* "call operator - a nonstatic member function having the name operator() and taking zero or more arguments; see also callable object. Lambdas (574)" (EMCppSfe 2021)

* "callable entity - one for which the call operator may be applied — e.g., function, callable object, reference to either, and pointer to function; see also invocable entity." (EMCppSfe 2021)

* "callable object - one whose type has one or more call operators; such an object can be invoked as if it were a function. Function static ’11 (70), Lambda Captures (994)" (EMCppSfe 2021)

* "callback function - one whose address is supplied for the purpose of being invoked when some anticipated event occurs. Opaque enums (669)" (EMCppSfe 2021)

* "capture default - an optional specifier in a lambda-capture list that is either = or &, where = implies that variables captured implicitly are captured by copy, whereas & implies that they are captured by reference. Lambdas (582)" (EMCppSfe 2021)

* "captured by copy - the form of lambda capture whereby a variable named in the enclosing scope of a lambda expression is copied to a data member of the returned lambda closure; all uses of that name within the body of the lambda expression refer to that data member instead of the variable from the enclosing scope. Lambdas (582)" (EMCppSfe 2021)

* "captured by reference - the form of lambda capture whereby a variable named in the body of a lambda expression is treated as an alias to a variable of the same name in the enclosing scope. Lambdas (582)" (EMCppSfe 2021)

* "captured by value - a colloquial term meaning captured by copy." (EMCppSfe 2021)

* "captured variable - one captured by copy or captured by reference within a lambda expression. Lambdas (602)" (EMCppSfe 2021)

* "carry dependency - one in which some evaluation has a data dependency on the result of some other evaluation. carries_dependency (999)" (EMCppSfe 2021)

* "cast - an expression that performs an explicit type conversion to a named type, T: the C-style cast, (T)expr, the equivalent functional notation, T(expr), and the four C++-specific notations, const_cast(expr), static_cast(expr), reinterpret_cast(expr), and dynamic_cast(expr) each perform casts, but with varying limitations on the types and expressions to which they can be applied. enum class (345)" (EMCppSfe 2021)

* "char-like object - an object of nonarray POD (i.e., trivial standard-layout) type, suitable for use as the element type of an std::string | std::string. Generalized PODs ’11 (479)" (EMCppSfe 2021)

* "character literal - a token having exactly one character between single quotes, e.g., 'q', that is of type char. Such a token can also be preceded by u, U, or L, and it will be of type char16_t, char32_t, or wchar_t, respectively. Note that some platforms support multicharacter literals, e.g., 'jsl', in which case the type will be int, and have implementation-defined behavior. User-Defined Literals (837)" (EMCppSfe 2021)

* "CI - short for continuous integration. inline namespace (1083)" (EMCppSfe 2021)

* "CIMS - short for common initial member sequence." (EMCppSfe 2021)

* "class key - a keyword (one of class, struct, or union) used to declare (and perhaps define) a nonenum user-defined type. Generalized PODs ’11 (414)" (EMCppSfe 2021)

* "class-specific memory management - a seldom used strategy in which user-provided (implicitly static) member overloads of operator new and operator delete will be used for dynamic allocation and deallocation, respectively. noexcept Specifier (1088)" (EMCppSfe 2021)

* "class template - one that declares a parameterized class, struct, or union. Variadic Templates (892)" (EMCppSfe 2021)

* "class template argument deduction - a C++17 feature that enables the deduction of template arguments for a variable using its initializer combined with [[deduction guides and constructors that are part of the primary class template named by the variable’s definition." (EMCppSfe 2021)

* "class type - a kind of user-defined type (UDT) whose definition is introduced using a class key (one of class, struct, or union). alignas (168), Generalized PODs ’11 (405), friend ’11 (1031)" (EMCppSfe 2021)

* "closure - a (1) closure object or (2) closure type. Local Types ’11 (87), Lambdas (578), Generic Lambdas (982), Lambda Captures (986), auto Return (1197)" (EMCppSfe 2021)

* "closure object - a callable object created via a lambda expression. Lambdas (578), Generic Lambdas (968), auto Return (1197)" (EMCppSfe 2021)

* "closure type - the (unnamed) type of a closure object produced by a lambda expression. Lambdas (578), Generic Lambdas (968)" (EMCppSfe 2021)

* "code bloat - excessive object code as might result from (1) the inlining of a large function body invoked from numerous call sites or (2) many similar but not identical instantiations of a function template, say, when employing perfect forwarding of string literals (see Section 2.1. “Forwarding References” on page 377). extern template (353), friend ’11 (1054)" (EMCppSfe 2021)

* "code elision - a compiler optimization whereby code that provably can never execute is simply omitted from the generated object code. noexcept Specifier (1136)" (EMCppSfe 2021)

* "code motion - a general term for compiler optimizations that reorder provably independent evaluations to potentially improve performance, based on the capabilities of hardware on which the code will execute. noexcept Specifier (1136)" (EMCppSfe 2021)

* "code point - a single character (e.g., glyph, control character, or modifier) in a character set. Unicode comprises 1,114,112 code points. ASCII comprises 128 code points. Unicode Literals (129)" (EMCppSfe 2021)

* "code unit - the smallest subdivision of a code point for a specific encoding. In Unicode, for example, the UTF-8 encoding uses 8-bit code units (one to four code units to represent each code point), and the UTF-32 encoding uses 32-bit code units (one per code point). Generalized PODs ’11 (476)" (EMCppSfe 2021)

* "cold path - a segment of generated object code that is executed only rarely or in exceptional cases (e.g., code within a catch block); such exceptional code is sometimes relegated to physically separate locations in memory so as to eliminate any added runtime cost associated with its existence (e.g., zero-cost-exception model). noexcept Specifier (1103)" (EMCppSfe 2021)

* "Collatz conjecture - one that states that for all positive integers N, the Collatz sequence is finite. Note that the length, however, varies widely with successive values N." (EMCppSfe 2021)

* "Collatz function - one that, given an integer N, returns N/2 if N is even, and 3N + 1 if N is odd; see also Collatz conjecture. constexpr Variables (313)" (EMCppSfe 2021)

* "Collatz length - the cardinality of the shortest Collatz sequence starting with N that contains 1; note that the length varies widely with successive values of N. constexpr Variables (313)" (EMCppSfe 2021)

* "Collatz sequence - one in which each successive element is obtained by starting with N and repeatedly applying the Collatz function to obtain the next element in the sequence. constexpr Variables (313)" (EMCppSfe 2021)

* "comma operator - (1) the built-in sequencing operator that evaluates and discards the result of its left-hand side expression and then unconditionally evaluates its right-hand side expression, which becomes the result of evaluating the operator or (2) an overloaded operator, having the name operator,, that unconditionally evaluates both of its arguments and returns a result as determined by its user-provided definition. constexpr Functions (268)" (EMCppSfe 2021)

* "common initial member sequence (CIMS) – the longest initial sequence (in declaration order) of nonstatic data members and bit fields within a class type that is the same between two standard-layout types. Generalized PODs ’11 (406)" (EMCppSfe 2021)

* "common type - the one that, for two given types, results from applying the ternary operator (?:) to two expressions of those respective types. Note that, for arithmetic types, the common type is the same type that would result for binary arithmetic operators applied to those types; for class types, however, the common type, if one exists, must be one of the two given types (modulo cv-qualifications); i.e., either they are the same type or there exists an unambiguous implicit conversion sequence from one to the other but not vice versa. auto Return (1186)" (EMCppSfe 2021)

* "compile-time constant - (1) a (typically named) constant suitable for evaluation in a constant expression; (2) the value of any constant expression that is computed and available for use at compile time. enum class (346)" (EMCppSfe 2021)

* "compile-time coupling - a tight form of physical interdependency across components that necessitates the recompilation of one component when some aspect of another’s implementation changes. Opaque enums (663)" (EMCppSfe 2021)

* "compile-time dispatch - the implementation technique determining which operation to invoke, depending on operand types, based on compile-time operations, often accomplished using function overloading, SFINAE, and, as of C++20, concepts. static_assert (121)" (EMCppSfe 2021)

* "compile-time introspection - the implementation technique of altering program behavior and code generation based on compile-time observable properties of other entities, particularly using templates and type deduction, and also the primary motivation for ongoing research into reflection. Variadic Templates (947)" (EMCppSfe 2021)

* "complete-class context - a semantic region within the lexical scope of a class definition in which the class (as a whole) itself is considered to be a complete type — e.g., function bodies, default arguments, default member initializers (see Section 2.1.“Default Member Init” on page 318), and noexcept specifiers (see Section 3.1.“noexcept Specifier” on page 1085). Default Member Init (319), noexcept Specifier (1086)" (EMCppSfe 2021)

* "complete type - one whose complete definition has been seen, thereby allowing a compiler to know the layout and footprint of objects of that type. alignof (184), Default Member Init (319), enum class (350), Opaque enums (661), Rvalue References (720), Variadic Templates (891)" (EMCppSfe 2021)

* "component - a 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 - implies, 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 - a 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 - one from which objects can be instantiated; see also abstract class. Inheriting Ctors (540), final (1008)" (EMCppSfe 2021)

* "conditional compilation - the 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 - one 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 operator or ternary operator (&&, ]] | | , or ?:). [[noexcept Operator (615)" (EMCppSfe 2021)

* "conditional noexcept specification - one 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 - the 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 - one (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 - one 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 - initialization 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 - a 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 - implies, 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 - an 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 - implies, 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 - the 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 - a 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 - a compile-time constant expression used in a conditional-compilation preprocessor directive such as #if or #elif. constexpr Functions (285)" (EMCppSfe 2021)

* "conventional string literal - a 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 - for 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 - any 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]] - a 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 - property of a type where assignment from an lvalue of the same type is valid. Generalized PODs ’11 (485)" (EMCppSfe 2021)

* "copy assignment - the 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 - a 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 - property of a type where construction from an lvalue of the same type is valid." (EMCppSfe 2021)

* "copy construction - construction of an object from an lvalue of the same type (modulo cv-qualifiers). Rvalue References (764)" (EMCppSfe 2021)

* "copy constructor - one 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 - an 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 - the 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 - implies, for a given object, that copy initialization has been employed. Braced Init (221)" (EMCppSfe 2021)

* "copy list initialization - copy initialization from a braced-initializer list. Braced Init (226), Default Member Init (318), initializer_list (555)" (EMCppSfe 2021)

* "copy operation - either 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 - one, 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 - implies, for a given object, that one or more copy operations can be applied." (EMCppSfe 2021)

* "core language specification - the 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 - a 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 - a 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 - short 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 - one 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 - a 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 - implies, 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 - one to an object whose lifetime has ended. Ref-Qualifiers (1171), decltype(auto) (1212)" (EMCppSfe 2021)

* "data dependency - one 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 - a 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 - a 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 - a 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 - a 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 - a 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 - either *, &, &&, ::*, [], 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 - to 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 - a 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 - an 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 - one that can be invoked without arguments. Generalized PODs ’11 (437), Rvalue References (754), noexcept Specifier (1136)" (EMCppSfe 2021)

* "default initialization - initialization 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 - implies, 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 - one 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 - a (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 - one 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 - a 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 - to 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 - one — 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 - a 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 - one 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 - implies (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 - one 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 - one 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 - an 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 - a 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 - a 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 - see memory diffusion. alignas (183)" (EMCppSfe 2021)

* "dimensional unit type - a 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 - implies, 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 - initialization 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 - implies, for a given object, that it has been initialized via direct initialization. Braced Init (230), Rvalue References (754)" (EMCppSfe 2021)

* "direct list initialization - the use of list initialization during direct initialization. Braced Init (229), Default Member Init (318), initializer_list (555)" (EMCppSfe 2021)

* "direct mapped - a 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 - a 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 - determining 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 - values, 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 - determining, 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 - invoking 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 - the 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 - the 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 - writing, documenting, testing, and deploying software for embedded systems. Binary Literals (145)" (EMCppSfe 2021)

* "embedded system - one 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 - the 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 - one 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 - one 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 - implies, 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 - a 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 - one 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 - implies, 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 - one 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 - a 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 - that 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 - implies, 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 - a 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 - a 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 - either an explicit instantiation declaration or an explicit instantiation definition. extern template (353)" (EMCppSfe 2021)

* "explicit specialization - a 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 - the 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 - implies, for a given variable, that it is named in the capture list of a lambda. Lambdas (582)" (EMCppSfe 2021)

* "expression - a 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 - an 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 - a 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 - an alignment larger than the alignment of std::max_align_t. alignas (168)" (EMCppSfe 2021)

* "external linkage - linkage that allows a name to refer to the same entity across translation units; see also internal linkage." (EMCppSfe 2021)


F


* "factory function - one 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 - one that might fail to meet its contract, i.e., one that is fallible. noexcept Specifier (1120)" (EMCppSfe 2021)

* "false sharing - a 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 - a memory barrier; see also memory-fence instruction. Function static ’11 (82)" (EMCppSfe 2021)

* "file extension - the 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 - a 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 - an implicit (truncating) conversion defined from floating-point types to integral types. User-Defined Literals (843)" (EMCppSfe 2021)

* "floating-point type - either float, double, or long double." (EMCppSfe 2021)

* "flow of control - the 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 - the 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 - a 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 - a 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 - implies, 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 - a 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 - the 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 - one 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 - a 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 - one that is not a subexpression of another expression; see outermost expression. Range for (693)" (EMCppSfe 2021)

* "full specialization - a (colloquial) synonym for explicit specialization." (EMCppSfe 2021)

* "fully associative - a 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 - a 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 - the 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 - a 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 - (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 - used (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 - one that defines a compile-time parameterized function." (EMCppSfe 2021)

* "function-template-argument type deduction - a 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 - one, 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 - a class type that supports callable objects. Lambdas (574)" (EMCppSfe 2021)

* "functor type - the type of a callable object. Lambdas (573)" (EMCppSfe 2021)

* "fundamental alignment - any 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 - a synonym for integral type. long long (89)" (EMCppSfe 2021)

* "fundamental type - either 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 - a 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 - implies, 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 - one 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 - writing 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 - one 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 - a 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 - a 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 - one 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 - a 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 - one 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 - short for language undefined behavior (a.k.a. language UB). noexcept Specifier (1115)" (EMCppSfe 2021)

* "has identity - states, 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 - a 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 - a synonym for dynamically allocated memory." (EMCppSfe 2021)

* "hidden-friend idiom - the 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 - preventing 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 - a 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 - one 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 - a 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 - the 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 - the 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 - a 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 - a 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 - implies, 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 - a user-defined type for which objects instantiated from that type, once fully constructed, cannot be changed. Ref-Qualifiers (1167)" (EMCppSfe 2021)

* "imperative programming - implies, 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 - implies, 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 - a 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 - implies, 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 - implies, 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 - one 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 - implies, 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 - implies, 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 - one 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 - one 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 - a 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 - a 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 - a 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 - short for template-instantiation time. static_assert (120)" (EMCppSfe 2021)

* "instruction selection - a 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 - reduce 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 - implies, for a given interface, that implementation details are insulated and can change without forcing clients to recompile, only relink." (EMCppSfe 2021)

* "insulation - a 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 - one 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 - an implicit conversion from an integral type to a floating-point type. User-Defined Literals (843)" (EMCppSfe 2021)

* "integer type - a synonym for integral type." (EMCppSfe 2021)

* "integral constant - a 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 - an 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 - the 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 - a 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 - a 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 - a (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 - linkage 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 - a 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 - one 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 - a 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 - the object created by evaluating a lambda expression. Lambdas (584)" (EMCppSfe 2021)

* "lambda declarator - the 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 - an 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 - that 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 - the phenomenon (often considered a defect) in which a limited system resource, most usually memory, is acquired but never released." (EMCppSfe 2021)

* "levelization technique - one 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 - that 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 - that 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 - optimization 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 - a 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 - initialization using a braced-initializer list. Braced Init (215), constexpr Functions (260), Default Member Init (331)" (EMCppSfe 2021)

* "literal - a 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 - one 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 - one defined within the body of a function (as opposed to at namespace or class scope)." (EMCppSfe 2021)

* "local declaration - a 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 - a 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 - the 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 - implies, 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 - the 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 - one 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 - the 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 - one 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 - the 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 - one 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 - one 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 - implies, 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 - that 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 - an 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 - one 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 - the 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 - a 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 - a 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 - the 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 - a 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 - the 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 - a 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 - a 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 - a 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 - the 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 - one 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 - a 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 - a 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 - a 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 - a 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 - a 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 - implies, for a given object, that one or more move operations can be applied. Rvalue References (728)" (EMCppSfe 2021)

* "move assignable - implies, 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 - assignment 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 - an 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 - construction 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 - a 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 - one 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 - either 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 - one 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 - the 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 - one 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 - the 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 - short 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 - a 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 - one 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 - evolving 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 - the 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 - the 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 - a 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 - one 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 - one that, for a given function, implies it is now and always will be a nofail function. noexcept Specifier (1117)" (EMCppSfe 2021)

* "nondefining declaration - one — 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 - a 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 - a function whose contract offers no mechanism to report whether the principal action requested was performed. noexcept Specifier (1119)" (EMCppSfe 2021)

* "nonstatic data member - one declared without the static keyword, an instance of which appears in every object of the class. constexpr Variables (305)" (EMCppSfe 2021)

* "non-trivial constructor - not 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 - not 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 - one that is not trivial; see also special member function. union ’11 (1174)" (EMCppSfe 2021)

* "non-type parameter - short for non-type template parameter. Variadic Templates (902)" (EMCppSfe 2021)

* "non-type parameter pack - a template parameter pack made up of non-type template parameters. Variadic Templates (902)" (EMCppSfe 2021)

* "non-type template parameter - one 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 - implies, 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 - the 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 - a 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 - an empty statement consisting of just a single semicolon (;). constexpr Functions (268)" (EMCppSfe 2021)

* "null-terminated string - a 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 - a 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 - an 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 - a 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 - the 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 - a 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 - a 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 - a 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 - one 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 - in 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 - implies, 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 - the 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 - (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 - the 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 - the 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 - the act of creating an overload." (EMCppSfe 2021)

* "overriding - providing, for a virtual function declared in a base type, a suitable implementation specific to a derived type. Inheriting Ctors (539)" (EMCppSfe 2021)

* "owned resource - one, 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 - the 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 - the 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 - an 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 - one 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 - the (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 - The declaration of a parameter to a function within a function’s parameter list. Variadic Templates (888)" (EMCppSfe 2021)

* "parameter list - a sequence of formal parameter declarations, such as a function parameter list or a template parameter list." (EMCppSfe 2021)

* "parameter pack - a function parameter pack or a template parameter pack. Variable Templates (159), Variadic Templates (873), constexpr Functions ’14 (964)" (EMCppSfe 2021)

* "partial application - transforming 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 - the partial specialization of a class template. constexpr Functions ’14 (963)" (EMCppSfe 2021)

* "partial implementation - an 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 - the 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 - a 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 - implies, 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 - implies, 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 - (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 - storage 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 - one 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 - an 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 - one 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 - short for polymorphic memory resource." (EMCppSfe 2021)

* "POD - short 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 - the 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 - a 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 - one 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 - one that, in C++, is implemented as a polymorphic class. noexcept Operator (616), final (1011)" (EMCppSfe 2021)

* "positive semidefinite - implies, 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 - a 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 - implies, for a given expression, that it is not an unevaluated operand or part of one. noexcept Operator (615)" (EMCppSfe 2021)

* "precondition - a 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 - a Boolean-valued expression, typically indicating whether some particular property holds; see also predicate function. Lambdas (575)" (EMCppSfe 2021)

* "predicate function - one 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 - a 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 - short for primary-class-template declaration. Variadic Templates (881)" (EMCppSfe 2021)

* "private inheritance - derivation (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 - implies, 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 - an object of a proctor class. noexcept Operator (646), noexcept Specifier (1139)" (EMCppSfe 2021)

* "proctor class - one 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 - one 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 - implies, 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 - a 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 - an 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 - short 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 - implies, for a given member of a user-defined type, that its access level is public. Generalized PODs ’11 (489)" (EMCppSfe 2021)

* "pun - the act of type punning, i.e., accessing an object from other than a compatible type." (EMCppSfe 2021)

* "pure abstract interface - one that is a protocol, i.e., providing no implementation of any kind. Inheriting Ctors (540)" (EMCppSfe 2021)

* "pure function - one 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 - one 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 - short for quiet NaN." (EMCppSfe 2021)

* "QoI - short for quality of implementation." (EMCppSfe 2021)

* "qualified id - an 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 - one that contains the scope-resolution operator (::) — e.g., ::foo (global scope) or bar::baz (bar scope). inline namespace (1060)" (EMCppSfe 2021)

* "qualifier - (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 - short for resource acquisition is initialization. Deleted Functions (54), Forwarding References (388), noexcept Operator (644), Rvalue References (769), noexcept Specifier (1126)" (EMCppSfe 2021)

* "range - any 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 - a 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 - one that produces a range — i.e., one suitable for use in a range-based for loop. Range for (680)" (EMCppSfe 2021)

* "raw string literal - a 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]] - a user-defined-literal operator that is passed the unparsed literal string as a null-terminated const char*. User-Defined Literals (841)" (EMCppSfe 2021)

* "reachable - implies, 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 - the 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 - (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 - one that is superfluous in a defect-free program (a.k.a. defensive check). static_assert (115)" (EMCppSfe 2021)

* "ref-qualifier - one 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 - one 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 - a 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 - one designed to detect the recurrence of some previously corrected undesired property (e.g., a bug) in the software." (EMCppSfe 2021)

* "regular type - one 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 - a 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 - implies, 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 - a 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 - one 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 - a 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 - utilizing 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 - a 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 - a 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 - any 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 - a 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 - a 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 - a (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 - one, 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 - a 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 - one 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 - one 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 - one, 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 - an 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 - a 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 - a synonym for the comma operator. constexpr Functions (265)" (EMCppSfe 2021)

* "serial date - one 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 - implies, 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 - any observable modification of program state that occurs as the result of evaluating an expression. Attribute Syntax (16)" (EMCppSfe 2021)

* "signal - a 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 - an 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 - one 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 - one, 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 - the 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 - a 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 - short for signaling NaN." (EMCppSfe 2021)

* "soft UB - short for library undefined behavior. noexcept Specifier (1115)" (EMCppSfe 2021)

* "Software Capital - a 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 - short for basic source character set." (EMCppSfe 2021)

* "special member function - one 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 - the 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 - a 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 - a 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 - an 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 - implies, 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 - a 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 - a synonym for standard-layout class. Generalized PODs ’11 (420)" (EMCppSfe 2021)

* "standard-layout type - one 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 - a 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 - one 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 - that memory region of a running program holding objects having static storage duration. Variable Templates (165)" (EMCppSfe 2021)

* "static storage duration - the 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 - one 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 - a 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 - a 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 - one 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 - short for strong exception-safety guarantee. noexcept Operator (634), Rvalue References (746)" (EMCppSfe 2021)

* "strong typedef - a 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 - one 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 - a 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 - a 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 - a 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 - an 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 - the 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 - language 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 - the type, template, or value mapped to a template parameter in the instantiation of a template. Variadic Templates (899)" (EMCppSfe 2021)

* "template argument deduction - the 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 - the 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 - the keyword template and associated template parameter list used to introduce the declaration or definition of a template. Variable Templates (157)" (EMCppSfe 2021)

* "template instantiation - (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 - the 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 - one, 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 - the 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 - a 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 - a 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 - a 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 - short 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 - an 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 - an 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 - a 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 - the 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 - a 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 - the 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 - implies, 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 - one 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 - a trivial default constructor, trivial copy constructor, or trivial move constructor. Generalized PODs ’11 (408)" (EMCppSfe 2021)

* "trivial copy-assignment operator - a 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 - a 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 - one 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 - a 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 - the quality, for a given type, as to whether it’s trivially destructible. Generalized PODs ’11 (468)" (EMCppSfe 2021)

* "trivial destructor - a 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 - a 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 - a 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 - one 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 - a 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 - a 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 - implies, 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 - implies, 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 - implies, 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 - implies, 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 - one 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 - a 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 - implies, 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 - implies, 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 - one 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 - implies, 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 - implies, 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 - an 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 - short for function-template-argument type deduction. Forwarding References (380)" (EMCppSfe 2021)

* "type erasure - an 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 - the feature whereby the compiler substitutes the type of an expression for an auto placeholder or decltype specifier. alignof (193) type list - a 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 - short for type template parameter pack. Variadic Templates (903)" (EMCppSfe 2021)

* "type punning - circumventing 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 - characters 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 - a 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 - a 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 - a 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 - short for undefined behavior." (EMCppSfe 2021)

* "UDL - short for user-defined literal." (EMCppSfe 2021)

* "UDL operator]] - one 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]] - a family of UDL operator]]s 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]] - the 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]] - one 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 - short 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 - the 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 - an 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 - an 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 - an 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 - the 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 - a 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 - implies, 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 - a 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 - a (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 - a 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 - one 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 - an 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 - the 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 - either unsigned char or, on platforms where char is unsigned, char. Generalized PODs ’11 (515)" (EMCppSfe 2021)

* "usable - implies, 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 - one 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 - implies, 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 - implies, 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 - the 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 - implies, 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 - a special member function that is user provided. Defaulted Functions (33)" (EMCppSfe 2021)

* "using declaration - one 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 - short for using-namespace directive. constexpr Functions (268), User-Defined Literals (842), inline namespace (1056)" (EMCppSfe 2021)

* "using-namespace directive - one — 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 - short 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 - (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 - a 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 - one 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 - a 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 - implies, for a given object, that it has undergone value initialization. Braced Init (221), Generalized PODs ’11 (412), Rvalue References (764)" (EMCppSfe 2021)

* "value representation - the 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 - a named object having automatic, static, or thread storage duration." (EMCppSfe 2021)

* "variable template - one — 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 - one 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 - one 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 - one 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 - a variadic function template declared as a member of a class. Variadic Templates (892)" (EMCppSfe 2021)

* "vectorization - the 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 - a 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 - a 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 - a 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 - a 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 - one 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 - short for value-semantic type." (EMCppSfe 2021)

* "vtable - short for virtual-function table. noexcept Operator (617)" (EMCppSfe 2021)

* "vtable pointer - a 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 - implies, 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 - one 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 - the 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 - a 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 - the 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 - a 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 - a 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 - implies, 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 - a 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 - a 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.



----