From b9a1ed62e9c7119356fe7969fb7a1ea82262ad93 Mon Sep 17 00:00:00 2001 From: Kevin Kennedy Date: Sun, 19 Mar 2017 10:07:40 -0400 Subject: [PATCH 1/6] Change Unicode EN SPACE (U+2002) characters to SPACE (U+0020) so that Pandoc-generated LaTeX can compile without Error --- CppCoreGuidelines.md | 224 +++++++++++++++++++++---------------------- 1 file changed, 112 insertions(+), 112 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index cbce281..f834595 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -19301,138 +19301,138 @@ When is a class a container? ??? A relatively informal definition of terms used in the guidelines (based of the glossary in [Programming: Principles and Practice using C++](http://www.stroustrup.com/programming.html)) -* *abstract class*: a class that cannot be directly used to create objects; often used to define an interface to derived classes. +* *abstract class*: a class that cannot be directly used to create objects; often used to define an interface to derived classes. A class is made abstract by having a pure virtual function or only protected constructors. -* *abstraction*: a description of something that selectively and deliberately ignores (hides) details (e.g., implementation details); selective ignorance. -* *address*: a value that allows us to find an object in a computer's memory. -* *algorithm*: a procedure or formula for solving a problem; a finite series of computational steps to produce a result. -* *alias*: an alternative way of referring to an object; often a name, pointer, or reference. -* *application*: a program or a collection of programs that is considered an entity by its users. -* *approximation*: something (e.g., a value or a design) that is close to the perfect or ideal (value or design). +* *abstraction*: a description of something that selectively and deliberately ignores (hides) details (e.g., implementation details); selective ignorance. +* *address*: a value that allows us to find an object in a computer's memory. +* *algorithm*: a procedure or formula for solving a problem; a finite series of computational steps to produce a result. +* *alias*: an alternative way of referring to an object; often a name, pointer, or reference. +* *application*: a program or a collection of programs that is considered an entity by its users. +* *approximation*: something (e.g., a value or a design) that is close to the perfect or ideal (value or design). Often an approximation is a result of trade-offs among ideals. -* *argument*: a value passed to a function or a template, in which it is accessed through a parameter. -* *array*: a homogeneous sequence of elements, usually numbered, e.g., \[0:max). -* *assertion*: a statement inserted into a program to state (assert) that something must always be true at this point in the program. -* *base class*: a class used as the base of a class hierarchy. Typically a base class has one or more virtual functions. -* *bit*: the basic unit of information in a computer. A bit can have the value 0 or the value 1. -* *bug*: an error in a program. -* *byte*: the basic unit of addressing in most computers. Typically, a byte holds 8 bits. -* *class*: a user-defined type that may contain data members, function members, and member types. -* *code*: a program or a part of a program; ambiguously used for both source code and object code. -* *compiler*: a program that turns source code into object code. -* *complexity*: a hard-to-precisely-define notion or measure of the difficulty of constructing a solution to a problem or of the solution itself. +* *argument*: a value passed to a function or a template, in which it is accessed through a parameter. +* *array*: a homogeneous sequence of elements, usually numbered, e.g., \[0:max). +* *assertion*: a statement inserted into a program to state (assert) that something must always be true at this point in the program. +* *base class*: a class used as the base of a class hierarchy. Typically a base class has one or more virtual functions. +* *bit*: the basic unit of information in a computer. A bit can have the value 0 or the value 1. +* *bug*: an error in a program. +* *byte*: the basic unit of addressing in most computers. Typically, a byte holds 8 bits. +* *class*: a user-defined type that may contain data members, function members, and member types. +* *code*: a program or a part of a program; ambiguously used for both source code and object code. +* *compiler*: a program that turns source code into object code. +* *complexity*: a hard-to-precisely-define notion or measure of the difficulty of constructing a solution to a problem or of the solution itself. Sometimes complexity is used to (simply) mean an estimate of the number of operations needed to execute an algorithm. -* *computation*: the execution of some code, usually taking some input and producing some output. +* *computation*: the execution of some code, usually taking some input and producing some output. * *concept*: (1) a notion, and idea; (2) a set of requirements, usually for a template argument. -* *concrete class*: class for which objects can be created. -* *constant*: a value that cannot be changed (in a given scope); not mutable. -* *constructor*: an operation that initializes ("constructs") an object. +* *concrete class*: class for which objects can be created. +* *constant*: a value that cannot be changed (in a given scope); not mutable. +* *constructor*: an operation that initializes ("constructs") an object. Typically a constructor establishes an invariant and often acquires resources needed for an object to be used (which are then typically released by a destructor). -* *container*: an object that holds elements (other objects). +* *container*: an object that holds elements (other objects). * *copy*: an operation that makes two object have values that compare equal. See also move. -* *correctness*: a program or a piece of a program is correct if it meets its specification. +* *correctness*: a program or a piece of a program is correct if it meets its specification. Unfortunately, a specification can be incomplete or inconsistent, or can fail to meet users' reasonable expectations. Thus, to produce acceptable code, we sometimes have to do more than just follow the formal specification. -* *cost*: the expense (e.g., in programmer time, run time, or space) of producing a program or of executing it. +* *cost*: the expense (e.g., in programmer time, run time, or space) of producing a program or of executing it. Ideally, cost should be a function of complexity. * *customization point*: ??? -* *data*: values used in a computation. -* *debugging*: the act of searching for and removing errors from a program; usually far less systematic than testing. -* *declaration*: the specification of a name with its type in a program. -* *definition*: a declaration of an entity that supplies all information necessary to complete a program using the entity. +* *data*: values used in a computation. +* *debugging*: the act of searching for and removing errors from a program; usually far less systematic than testing. +* *declaration*: the specification of a name with its type in a program. +* *definition*: a declaration of an entity that supplies all information necessary to complete a program using the entity. Simplified definition: a declaration that allocates memory. -* *derived class*: a class derived from one or more base classes. -* *design*: an overall description of how a piece of software should operate to meet its specification. -* *destructor*: an operation that is implicitly invoked (called) when an object is destroyed (e.g., at the end of a scope). Often, it releases resources. -* *encapsulation*: protecting something meant to be private (e.g., implementation details) from unauthorized access. -* *error*: a mismatch between reasonable expectations of program behavior (often expressed as a requirement or a users' guide) and what a program actually does. -* *executable*: a program ready to be run (executed) on a computer. -* *feature creep*: a tendency to add excess functionality to a program "just in case." -* *file*: a container of permanent information in a computer. -* *floating-point number*: a computer's approximation of a real number, such as 7.93 and 10.78e-3. -* *function*: a named unit of code that can be invoked (called) from different parts of a program; a logical unit of computation. -* *generic programming*: a style of programming focused on the design and efficient implementation of algorithms. +* *derived class*: a class derived from one or more base classes. +* *design*: an overall description of how a piece of software should operate to meet its specification. +* *destructor*: an operation that is implicitly invoked (called) when an object is destroyed (e.g., at the end of a scope). Often, it releases resources. +* *encapsulation*: protecting something meant to be private (e.g., implementation details) from unauthorized access. +* *error*: a mismatch between reasonable expectations of program behavior (often expressed as a requirement or a users' guide) and what a program actually does. +* *executable*: a program ready to be run (executed) on a computer. +* *feature creep*: a tendency to add excess functionality to a program "just in case." +* *file*: a container of permanent information in a computer. +* *floating-point number*: a computer's approximation of a real number, such as 7.93 and 10.78e-3. +* *function*: a named unit of code that can be invoked (called) from different parts of a program; a logical unit of computation. +* *generic programming*: a style of programming focused on the design and efficient implementation of algorithms. A generic algorithm will work for all argument types that meet its requirements. In C++, generic programming typically uses templates. * *global variable*: technically, a named object in namespace scope. * *handle*: a class that allows access to another through a member pointer or reference. See also resource, copy, move. -* *header*: a file containing declarations used to share interfaces between parts of a program. -* *hiding*: the act of preventing a piece of information from being directly seen or accessed. +* *header*: a file containing declarations used to share interfaces between parts of a program. +* *hiding*: the act of preventing a piece of information from being directly seen or accessed. For example, a name from a nested (inner) scope can prevent that same name from an outer (enclosing) scope from being directly used. -* *ideal*: the perfect version of something we are striving for. Usually we have to make trade-offs and settle for an approximation. -* *implementation*: (1) the act of writing and testing code; (2) the code that implements a program. -* *infinite loop*: a loop where the termination condition never becomes true. See iteration. -* *infinite recursion*: a recursion that doesn't end until the machine runs out of memory to hold the calls. +* *ideal*: the perfect version of something we are striving for. Usually we have to make trade-offs and settle for an approximation. +* *implementation*: (1) the act of writing and testing code; (2) the code that implements a program. +* *infinite loop*: a loop where the termination condition never becomes true. See iteration. +* *infinite recursion*: a recursion that doesn't end until the machine runs out of memory to hold the calls. In reality, such recursion is never infinite but is terminated by some hardware error. -* *information hiding*: the act of separating interface and implementation, thus hiding implementation details not meant for the user's attention and providing an abstraction. -* *initialize*: giving an object its first (initial) value. -* *input*: values used by a computation (e.g., function arguments and characters typed on a keyboard). -* *integer*: a whole number, such as 42 and -99. -* *interface*: a declaration or a set of declarations specifying how a piece of code (such as a function or a class) can be called. -* *invariant*: something that must be always true at a given point (or points) of a program; typically used to describe the state (set of values) of an object or the state of a loop before entry into the repeated statement. -* *iteration*: the act of repeatedly executing a piece of code; see recursion. -* *iterator*: an object that identifies an element of a sequence. -* *library*: a collection of types, functions, classes, etc. implementing a set of facilities (abstractions) meant to be potentially used as part of more that one program. -* *lifetime*: the time from the initialization of an object until it becomes unusable (goes out of scope, is deleted, or the program terminates). -* *linker*: a program that combines object code files and libraries into an executable program. -* *literal*: a notation that directly specifies a value, such as 12 specifying the integer value "twelve." -* *loop*: a piece of code executed repeatedly; in C++, typically a for-statement or a while-statement. +* *information hiding*: the act of separating interface and implementation, thus hiding implementation details not meant for the user's attention and providing an abstraction. +* *initialize*: giving an object its first (initial) value. +* *input*: values used by a computation (e.g., function arguments and characters typed on a keyboard). +* *integer*: a whole number, such as 42 and -99. +* *interface*: a declaration or a set of declarations specifying how a piece of code (such as a function or a class) can be called. +* *invariant*: something that must be always true at a given point (or points) of a program; typically used to describe the state (set of values) of an object or the state of a loop before entry into the repeated statement. +* *iteration*: the act of repeatedly executing a piece of code; see recursion. +* *iterator*: an object that identifies an element of a sequence. +* *library*: a collection of types, functions, classes, etc. implementing a set of facilities (abstractions) meant to be potentially used as part of more that one program. +* *lifetime*: the time from the initialization of an object until it becomes unusable (goes out of scope, is deleted, or the program terminates). +* *linker*: a program that combines object code files and libraries into an executable program. +* *literal*: a notation that directly specifies a value, such as 12 specifying the integer value "twelve." +* *loop*: a piece of code executed repeatedly; in C++, typically a for-statement or a while-statement. * *move*: an operation that transfers a value from one object to another leaving behind a value representing "empty." See also copy. -* *mutable*: changeable; the opposite of immutable, constant, and invariable. -* *object*: (1) an initialized region of memory of a known type which holds a value of that type; (2) a region of memory. -* *object code*: output from a compiler intended as input for a linker (for the linker to produce executable code). -* *object file*: a file containing object code. -* *object-oriented programming*: (OOP) a style of programming focused on the design and use of classes and class hierarchies. -* *operation*: something that can perform some action, such as a function and an operator. -* *output*: values produced by a computation (e.g., a function result or lines of characters written on a screen). -* *overflow*: producing a value that cannot be stored in its intended target. -* *overload*: defining two functions or operators with the same name but different argument (operand) types. -* *override*: defining a function in a derived class with the same name and argument types as a virtual function in the base class, thus making the function callable through the interface defined by the base class. +* *mutable*: changeable; the opposite of immutable, constant, and invariable. +* *object*: (1) an initialized region of memory of a known type which holds a value of that type; (2) a region of memory. +* *object code*: output from a compiler intended as input for a linker (for the linker to produce executable code). +* *object file*: a file containing object code. +* *object-oriented programming*: (OOP) a style of programming focused on the design and use of classes and class hierarchies. +* *operation*: something that can perform some action, such as a function and an operator. +* *output*: values produced by a computation (e.g., a function result or lines of characters written on a screen). +* *overflow*: producing a value that cannot be stored in its intended target. +* *overload*: defining two functions or operators with the same name but different argument (operand) types. +* *override*: defining a function in a derived class with the same name and argument types as a virtual function in the base class, thus making the function callable through the interface defined by the base class. * *owner*: an object responsible for releasing a resource. -* *paradigm*: a somewhat pretentious term for design or programming style; often used with the (erroneous) implication that there exists a paradigm that is superior to all others. -* *parameter*: a declaration of an explicit input to a function or a template. When called, a function can access the arguments passed through the names of its parameters. -* *pointer*: (1) a value used to identify a typed object in memory; (2) a variable holding such a value. -* *post-condition*: a condition that must hold upon exit from a piece of code, such as a function or a loop. -* *pre-condition*: a condition that must hold upon entry into a piece of code, such as a function or a loop. -* *program*: code (possibly with associated data) that is sufficiently complete to be executed by a computer. -* *programming*: the art of expressing solutions to problems as code. -* *programming language*: a language for expressing programs. -* *pseudo code*: a description of a computation written in an informal notation rather than a programming language. -* *pure virtual function*: a virtual function that must be overridden in a derived class. -* *RAII*: ("Resource Acquisition Is Initialization") a basic technique for resource management based on scopes. -* *range*: a sequence of values that can be described by a start point and an end point. For example, \[0:5) means the values 0, 1, 2, 3, and 4. -* *recursion*: the act of a function calling itself; see also iteration. -* *reference*: (1) a value describing the location of a typed value in memory; (2) a variable holding such a value. -* *regular expression*: a notation for patterns in character strings. -* *requirement*: (1) a description of the desired behavior of a program or part of a program; (2) a description of the assumptions a function or template makes of its arguments. -* *resource*: something that is acquired and must later be released, such as a file handle, a lock, or memory. See also handle, owner. -* *rounding*: conversion of a value to the mathematically nearest value of a less precise type. +* *paradigm*: a somewhat pretentious term for design or programming style; often used with the (erroneous) implication that there exists a paradigm that is superior to all others. +* *parameter*: a declaration of an explicit input to a function or a template. When called, a function can access the arguments passed through the names of its parameters. +* *pointer*: (1) a value used to identify a typed object in memory; (2) a variable holding such a value. +* *post-condition*: a condition that must hold upon exit from a piece of code, such as a function or a loop. +* *pre-condition*: a condition that must hold upon entry into a piece of code, such as a function or a loop. +* *program*: code (possibly with associated data) that is sufficiently complete to be executed by a computer. +* *programming*: the art of expressing solutions to problems as code. +* *programming language*: a language for expressing programs. +* *pseudo code*: a description of a computation written in an informal notation rather than a programming language. +* *pure virtual function*: a virtual function that must be overridden in a derived class. +* *RAII*: ("Resource Acquisition Is Initialization") a basic technique for resource management based on scopes. +* *range*: a sequence of values that can be described by a start point and an end point. For example, \[0:5) means the values 0, 1, 2, 3, and 4. +* *recursion*: the act of a function calling itself; see also iteration. +* *reference*: (1) a value describing the location of a typed value in memory; (2) a variable holding such a value. +* *regular expression*: a notation for patterns in character strings. +* *requirement*: (1) a description of the desired behavior of a program or part of a program; (2) a description of the assumptions a function or template makes of its arguments. +* *resource*: something that is acquired and must later be released, such as a file handle, a lock, or memory. See also handle, owner. +* *rounding*: conversion of a value to the mathematically nearest value of a less precise type. * *RTTI*: Run-Time Type Information. ??? -* *scope*: the region of program text (source code) in which a name can be referred to. -* *sequence*: elements that can be visited in a linear order. -* *software*: a collection of pieces of code and associated data; often used interchangeably with program. -* *source code*: code as produced by a programmer and (in principle) readable by other programmers. -* *source file*: a file containing source code. -* *specification*: a description of what a piece of code should do. -* *standard*: an officially agreed upon definition of something, such as a programming language. -* *state*: a set of values. +* *scope*: the region of program text (source code) in which a name can be referred to. +* *sequence*: elements that can be visited in a linear order. +* *software*: a collection of pieces of code and associated data; often used interchangeably with program. +* *source code*: code as produced by a programmer and (in principle) readable by other programmers. +* *source file*: a file containing source code. +* *specification*: a description of what a piece of code should do. +* *standard*: an officially agreed upon definition of something, such as a programming language. +* *state*: a set of values. * *STL*: the containers, iterators, and algorithms part of the standard library. -* *string*: a sequence of characters. -* *style*: a set of techniques for programming leading to a consistent use of language features; sometimes used in a very restricted sense to refer just to low-level rules for naming and appearance of code. -* *subtype*: derived type; a type that has all the properties of a type and possibly more. -* *supertype*: base type; a type that has a subset of the properties of a type. -* *system*: (1) a program or a set of programs for performing a task on a computer; (2) a shorthand for "operating system", that is, the fundamental execution environment and tools for a computer. -* *template*: a class or a function parameterized by one or more types or (compile-time) values; the basic C++ language construct supporting generic programming. -* *testing*: a systematic search for errors in a program. -* *trade-off*: the result of balancing several design and implementation criteria. -* *truncation*: loss of information in a conversion from a type into another that cannot exactly represent the value to be converted. -* *type*: something that defines a set of possible values and a set of operations for an object. -* *uninitialized*: the (undefined) state of an object before it is initialized. -* *unit*: (1) a standard measure that gives meaning to a value (e.g., km for a distance); (2) a distinguished (e.g., named) part of a larger whole. -* *use case*: a specific (typically simple) use of a program meant to test its functionality and demonstrate its purpose. -* *value*: a set of bits in memory interpreted according to a type. -* *variable*: a named object of a given type; contains a value unless uninitialized. -* *virtual function*: a member function that can be overridden in a derived class. -* *word*: a basic unit of memory in a computer, often the unit used to hold an integer. +* *string*: a sequence of characters. +* *style*: a set of techniques for programming leading to a consistent use of language features; sometimes used in a very restricted sense to refer just to low-level rules for naming and appearance of code. +* *subtype*: derived type; a type that has all the properties of a type and possibly more. +* *supertype*: base type; a type that has a subset of the properties of a type. +* *system*: (1) a program or a set of programs for performing a task on a computer; (2) a shorthand for "operating system", that is, the fundamental execution environment and tools for a computer. +* *template*: a class or a function parameterized by one or more types or (compile-time) values; the basic C++ language construct supporting generic programming. +* *testing*: a systematic search for errors in a program. +* *trade-off*: the result of balancing several design and implementation criteria. +* *truncation*: loss of information in a conversion from a type into another that cannot exactly represent the value to be converted. +* *type*: something that defines a set of possible values and a set of operations for an object. +* *uninitialized*: the (undefined) state of an object before it is initialized. +* *unit*: (1) a standard measure that gives meaning to a value (e.g., km for a distance); (2) a distinguished (e.g., named) part of a larger whole. +* *use case*: a specific (typically simple) use of a program meant to test its functionality and demonstrate its purpose. +* *value*: a set of bits in memory interpreted according to a type. +* *variable*: a named object of a given type; contains a value unless uninitialized. +* *virtual function*: a member function that can be overridden in a derived class. +* *word*: a basic unit of memory in a computer, often the unit used to hold an integer. # To-do: Unclassified proto-rules From 04fd2a5807dd51731ee85e8b9132f8d38ee9dbe6 Mon Sep 17 00:00:00 2001 From: Jacob Langley Date: Mon, 13 Feb 2017 13:08:08 -0800 Subject: [PATCH 2/6] Fix spellcheck errors Line 1037: analyser -> analyses Line 2399: yu -> yew Line 3745: funtions -> functions Line 3748: multimethods -> multi methods Line 6652: mixins -> mixing Line 11991: unittests -> unittest --- CppCoreGuidelines.md | 2 +- scripts/hunspell/isocpp.dic | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index f834595..441b0b9 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -3747,7 +3747,7 @@ This rule becomes even better if C++ gets ["uniform function call"](http://www.o The language requires `virtual` functions to be members, and not all `virtual` functions directly access data. In particular, members of an abstract class rarely do. -Note [multimethods](https://parasol.tamu.edu/~yuriys/papers/OMM10.pdf). +Note [multi-methods](https://parasol.tamu.edu/~yuriys/papers/OMM10.pdf). ##### Exception diff --git a/scripts/hunspell/isocpp.dic b/scripts/hunspell/isocpp.dic index 3820a99..429ba9d 100644 --- a/scripts/hunspell/isocpp.dic +++ b/scripts/hunspell/isocpp.dic @@ -277,6 +277,8 @@ Meyers15 Meyers96 Meyers97 microbenchmarks +mixin +mixins modify1 modify2 moredata @@ -510,6 +512,7 @@ unenforceable uninit uniqueptrparam unittest +unittests unnamed2 use1 users' From 48b40df328d07a647b27f471993ac1de78c1b0ea Mon Sep 17 00:00:00 2001 From: Jacob Langley Date: Mon, 13 Feb 2017 13:11:10 -0800 Subject: [PATCH 3/6] Fix markdown lint errors 11979:3 warning Incorrect indentation before bullet: remove 1 space list-item-bullet-indent 19412:1-19462:23 warning Missing blank line before block node no-missing-blank-lines --- CppCoreGuidelines.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 441b0b9..eab67ce 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -12000,12 +12000,12 @@ Unfortunately people's needs and constraints differ so dramatically that we cann but we can mention: * Static enforcement tools: both [clang](http://clang.llvm.org/docs/ThreadSafetyAnalysis.html) - and some older versions of [GCC](https://gcc.gnu.org/wiki/ThreadSafetyAnnotation) - have some support for static annotation of thread safety properties. - Consistent use of this technique turns many classes of thread-safety errors into compile-time errors. - The annotations are generally local (marking a particular member variable as guarded by a particular mutex), - and are usually easy to learn. However, as with many static tools, it can often present false negatives; - cases that should have been caught but were allowed. +and some older versions of [GCC](https://gcc.gnu.org/wiki/ThreadSafetyAnnotation) +have some support for static annotation of thread safety properties. +Consistent use of this technique turns many classes of thread-safety errors into compile-time errors. +The annotations are generally local (marking a particular member variable as guarded by a particular mutex), +and are usually easy to learn. However, as with many static tools, it can often present false negatives; +cases that should have been caught but were allowed. * dynamic enforcement tools: Clang's [Thread Sanitizer](http://clang.llvm.org/docs/ThreadSanitizer.html) (aka TSAN) is a powerful example of dynamic tools: it changes the build and execution of your program to add bookkeeping on memory access, From a2dba2e78b826f53ee85b34e6d4962b756682cdf Mon Sep 17 00:00:00 2001 From: Jacob Langley Date: Mon, 13 Feb 2017 13:14:42 -0800 Subject: [PATCH 4/6] Fix cpplint issues Rconc-create0.cpp:20: Line ends in whitespace. Consider deleting these extra spaces. [whitespace/end_of_line] [4] Res-always5.cpp:15: Missing space after , [whitespace/comma] [3] Rp-lib0.cpp:15: Missing space after , [whitespace/comma] [3] Rs-using-directive0.cpp:25: Extra space after ( in function call [whitespace/parens] [4] Rs-using-directive0.cpp:25: Extra space before ) [whitespace/parens] [2] --- CppCoreGuidelines.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index eab67ce..71ef50b 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -1067,7 +1067,7 @@ So, if a suitable library exists for your application domain, use it. ##### Example - std::sort(begin(v),end(v),std::greater<>()); + std::sort(begin(v), end(v), std::greater<>()); Unless you are an expert in sorting algorithms and have plenty of time, this is more likely to be correct and to run faster than anything you write for a specific application. @@ -9105,7 +9105,7 @@ Readability. Minimize resource retention. Note: C++17 also adds `if` and `switch` initializer statements. These require C++17 support. - map mymap; + map mymap; if (auto result = mymap.insert(value); result.second) { // insert succeeded, and result is valid for this block @@ -9508,7 +9508,7 @@ Assuming that there is a logical connection between `i` and `j`, that connection Obviously, what we really would like is a construct that initialized n variables from a `tuple`. For example: - auto [i,j] = make_related_widgets(cond); // C++17, not C++14 + auto [i, j] = make_related_widgets(cond); // C++17, not C++14 Today, we might approximate that using `tie()`: @@ -12494,8 +12494,7 @@ Thread creation is expensive. // process } - void - (istream& is) + void master(istream& is) { for (Message m; is >> m; ) run_list.push_back(new thread(worker, m)); @@ -16574,10 +16573,10 @@ Doing so takes away an `#include`r's ability to effectively disambiguate and to // user.cpp #include "bad.h" - bool copy( /*... some parameters ...*/); // some function that happens to be named copy + bool copy(/*... some parameters ...*/); // some function that happens to be named copy int main() { - copy( /*...*/ ); // now overloads local ::copy and std::copy, could be ambiguous + copy(/*...*/); // now overloads local ::copy and std::copy, could be ambiguous } ##### Enforcement From 2c8b34653df679518bba4b964e4b75d3e2d8b725 Mon Sep 17 00:00:00 2001 From: Jacob Langley Date: Tue, 28 Feb 2017 09:27:50 -0800 Subject: [PATCH 5/6] Add a line to help remark identify code block inside bullet list --- CppCoreGuidelines.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 71ef50b..16eea29 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -14027,8 +14027,10 @@ This is a problem for people modernizing code. You can * update the library to be `const`-correct; preferred long-term solution -* "cast away `const`"; [best avoided](#Res-casts-const). -* provide a wrapper function; for example +* "cast away `const`"; [best avoided](#Res-casts-const) +* provide a wrapper function + +Example: void f(int* p); // old code: f() does not modify `*p` void f(const int* p) { f(const_cast(p); } // wrapper From 847bd8205e875bb27693dba51d9e1228e6bcd6bf Mon Sep 17 00:00:00 2001 From: Thibault Kruse Date: Mon, 20 Mar 2017 11:19:07 +0900 Subject: [PATCH 6/6] Warn on the presence of Uniceode EN space instead of plain blank --- scripts/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile b/scripts/Makefile index 529b3d9..a96e9e9 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -79,8 +79,8 @@ check-badchars: $(SOURCEPATH) $(BUILD_DIR) Makefile # old file still might be around @rm -f $(BUILD_DIR)/CppCoreGuidelines.md.badchars # print file, add line numbers, grep for bad chars - @cat ../$(SOURCEFILE) | nl -ba | perl -ne 'print if /’|‘|”|“|¸|–|…|¦/' > $(BUILD_DIR)/$(SOURCEFILE).badchars || true - @if [ -s $(BUILD_DIR)/CppCoreGuidelines.md.badchars ]; then echo 'Warning: Undesired chars (–’‘“”¸…¦) found, use straight quotes instead:'; cat $(BUILD_DIR)/CppCoreGuidelines.md.badchars; false; fi; + @cat ../$(SOURCEFILE) | nl -ba | perl -ne 'print if /’|‘|”|“|¸| |–|…|¦/' > $(BUILD_DIR)/$(SOURCEFILE).badchars || true + @if [ -s $(BUILD_DIR)/CppCoreGuidelines.md.badchars ]; then echo 'Warning: Undesired chars (–’‘“”¸…¦) or Unicode EN SPACE found, use markdown-compatible symbols instead:'; cat $(BUILD_DIR)/CppCoreGuidelines.md.badchars; false; fi; .PHONY: hunspell-check