- 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)
- “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)
- “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)
- “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)
- “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 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 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)
- “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::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 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)
- “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., 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(max_align_t)) — in other words, the largest power of 2, not larger than alignof(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 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)
- “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 vector::push_back) makes no mention of what happens if the operation were to fail. noexcept Specifier (1120)” (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)
- “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)
- “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)
- “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 ((