diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml new file mode 100644 index 000000000..87a8648d1 --- /dev/null +++ b/.github/workflows/build.yml @@ -0,0 +1,20 @@ +name: build +on: [push, pull_request] + +jobs: + build: + runs-on: ubuntu-latest + + steps: + - uses: actions/checkout@master + + - name: Install Hunspell + run: | + sudo apt-get update + sudo apt-get install hunspell + + - name: Run cd scripts; make -k + run: cd scripts; make -k + + - name: Run cd .. + run: cd .. diff --git a/.github/workflows/jekyll-gh-pages.yml b/.github/workflows/jekyll-gh-pages.yml new file mode 100644 index 000000000..0ebd768bf --- /dev/null +++ b/.github/workflows/jekyll-gh-pages.yml @@ -0,0 +1,51 @@ +# Sample workflow for building and deploying a Jekyll site to GitHub Pages +name: Deploy Jekyll with GitHub Pages dependencies preinstalled + +on: + # Runs on pushes targeting the default branch + push: + branches: ["master"] + + # Allows you to run this workflow manually from the Actions tab + workflow_dispatch: + +# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages +permissions: + contents: read + pages: write + id-token: write + +# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. +# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. +concurrency: + group: "pages" + cancel-in-progress: false + +jobs: + # Build job + build: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + - name: Setup Pages + uses: actions/configure-pages@v5 + - name: Build with Jekyll + uses: actions/jekyll-build-pages@v1 + with: + source: ./ + destination: ./_site + - name: Upload artifact + uses: actions/upload-pages-artifact@v3 + + # Deployment job + deploy: + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} + runs-on: ubuntu-latest + needs: build + steps: + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v4 diff --git a/.gitignore b/.gitignore new file mode 100644 index 000000000..51ce27723 --- /dev/null +++ b/.gitignore @@ -0,0 +1,12 @@ +scripts/build +scripts/nodesjs/build +node_modules +_site +scripts/python/__pycache__ +scripts/python/*.pyc + +# VS Code +.vs/ + +# MacOS-specific +.DS_Store \ No newline at end of file diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 000000000..4de6f81de --- /dev/null +++ b/.travis.yml @@ -0,0 +1,22 @@ +# This is the configuration for Travis CI, a free github-integrated service that runs this script for each pull request (if configured) + +# provides gcc, clang, make, scons, cmake +language: c++ + +# alternatives: gcc, clang, or both (as yaml list) +compiler: clang + +addons: + apt: + packages: + - hunspell + +install: + - + +script: + - cd scripts; make -k + - cd .. + +notifications: + email: false diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7541d6489..51fd05205 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -10,7 +10,7 @@ they can be freely copied and modified to meet your organization's needs. We encourage contributions to the C++ Core Guidelines in a number of ways: - **Individual feedback** Are you a developer who is passionate about your code? Join the discussion in [Issues](https://github.com/isocpp/CppCoreGuidelines/issues). We want to know which rules resonate with you and which don't. Were any rules -inordinately difficult to apply? Does your compiler vendor's Guideline Support Library (e.g., +inordinately difficult to apply? Does your compiler vendor's Guidelines Support Library (e.g., [Microsoft's implementation of the GSL](https://github.com/microsoft/gsl)) suit your needs in adopting these guidelines? - **Organizational adoption** While the guidelines are designed to be broadly adoptable they are also intended to be modified to fit your organization's particular needs. We encourage your organization to fork this repo and create your own copy of these guidelines with changes @@ -19,19 +19,19 @@ guidelines and that you provide a link back to the original set of [guidelines]( your local changes are appropriate to pull back into the original guidelines, please open an [Issue](https://github.com/isocpp/CppCoreGuidelines/issues) which can lead to a pull request. - **Maintain the Guidelines** The C++ Core Guidelines were created from a wealth of knowledge spread across a number of organizations -worldwide. If you or your organization is passionate about helping to create the guidelines consider becoming an editor or maintainer. If -you're a C++ expert who is serious about participating please -[email coreguidelines@isocpp.org](mailto:coreguidelines@isocpp.org?subject=Maintain the C++ Code Guidelines). +worldwide. If you or your organization is passionate about helping to create the guidelines, consider becoming an editor or maintainer. If +you're a C++ expert who is serious about participating, please +[email coreguidelines@isocpp.org](mailto:coreguidelines@isocpp.org?subject=Maintain%20the%20C++%20Code%20Guidelines). ## Contributor License Agreement By contributing content to the C++ Core Guidelines (i.e., submitting a pull request for inclusion in this repository) you agree with the [Standard C++ Foundation](https://isocpp.org/about) [Terms of Use](https://isocpp.org/home/terms-of-use), especially all of the terms specified regarding Copyright and Patents. - You warrant that your material is original, or you have the right to contribute it. -- With respect to the material that you own, you grant a worldwide non-exclusive irrevocable transferable royalty-free license to your contributed -material to Standard C++ Foundation to display, reproduce, perform, distribute and create derivative works of that material for commercial or +- With respect to the material that you own, you grant a worldwide, non-exclusive, irrevocable, transferable, and royalty-free license to your contributed +material to Standard C++ Foundation to display, reproduce, perform, distribute, and create derivative works of that material for commercial or non-commercial use. With respect to any other material you contribute, such material must be under a license sufficient to allow Standard C++ Foundation -to display, reproduce, perform, distribute and create derivative works of that material for commercial or non-commercial use. +to display, reproduce, perform, distribute, and create derivative works of that material for commercial or non-commercial use. - You agree that, if your contributed material is subsequently reflected in the ISO/IEC C++ standard in any form, it will be subject to all ISO/IEC JTC 1 policies including [copyrights](http://www.iso.org/iso/home/policies.htm), [patents](http://www.iso.org/iso/home/standards_development/governance_of_technical_work/patents.htm), and @@ -40,8 +40,59 @@ to display, reproduce, perform, distribute and create derivative works of that m ## Pull requests -We welcome pull requests for scoped changes to the guidelines--bug fixes in examples, clarifying ambiguous text, etc. Proposed changes should -first be discussed in the [Issues](https://github.com/isocpp/CppCoreGuidelines/issues) and the Issue number must be included in the pull -request. Changes should be made in a child commit of a recent commit in the master branch. Lastly, to avoid line ending issues, please -set `autocrlf = input` and `whitespace = cr-at-eol` in your git configuration. +We welcome pull requests for scoped changes to the guidelines--bug fixes in +examples, clarifying ambiguous text, etc. Significant changes should first be +discussed in the [Issues](https://github.com/isocpp/CppCoreGuidelines/issues) +and the Issue number must be included in the pull request. For +guideline-related changes, please specify the rule number in your Issue and/or +Pull Request. + +Changes should be made in a child commit of a recent commit in the master +branch. If you are making many small changes, please create separate PRs to +minimize merge issues. + +### Document Style Guidelines + +Documents in this repository are written in an unspecific flavor of Markdown, +which leaves some ambiguity for formatting text. We ask that pull requests +maintain the following style guidelines, though we are aware that the document +may not already be consistent. + +#### Indentation + +Code and nested text should use multiples of 4 spaces of indentation, and no +tab characters, like so: + + void func(const int x) + { + std::cout << x << '\n'; + } + +#### Code Blocks + +Please use 4-space indentation to trigger code parsing, rather than [fenced code blocks](https://help.github.com/articles/github-flavored-markdown/#fenced-code-blocks) or any other style, like so: + + This is some document text, with an example below: + + void func() + { + std::cout << "This is code.\n"; + } + +#### Document style decisions + +We've discussed and made decisions on a number of document style. Please do not open PRs that revisit these stylistic points: + +- The CppCoreGuidelines.md file is a single GH-flavored Markdown file. It is not split into separate chapters. +- We do not use syntax highlighting in the Core Guidelines. See PRs #33, #96, #328, and #779. If you want syntax highlighting you +can either view the "pretty" version at http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines or do your own post-processing. +- We're sticking with the ASCII character set. We do not use Unicode em-dashes, Unicode spaces, or pretty quotes. Lots of people edit this file with their various text editors. ASCII is simple and universally understood. + +### Update dictionary + +Code samples in the guidelines are run through a spelling checker. Be sure to add new class and variable names to [scripts/hunspell/isocpp.dic](https://github.com/isocpp/CppCoreGuidelines/blob/master/scripts/hunspell/isocpp.dic). + +### Miscellaneous + +To avoid line-ending issues, please set `autocrlf = input` and `whitespace = cr-at-eol` in your git configuration. diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index f28366f73..993bb2663 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -1,17 +1,16 @@ - -# C++ Core Guidelines +# C++ Core Guidelines -September 9, 2015 +May 8, 2025 Editors: * [Bjarne Stroustrup](http://www.stroustrup.com) * [Herb Sutter](http://herbsutter.com/) -This document is a very early draft. It is inkorrekt, incompleat, and pµøoorly formatted. -Had it been an open source (code) project, this would have been release 0.6. +This is a living document under continuous improvement. +Had it been an open-source (code) project, this would have been release 0.8. Copying, use, modification, and creation of derivative works from this project is licensed under an MIT-style license. -Contributing to this project requires agreeing to a Contributor License. See the accompanying LICENSE file for details. +Contributing to this project requires agreeing to a Contributor License. See the accompanying [LICENSE](https://github.com/isocpp/CppCoreGuidelines/blob/master/LICENSE) file for details. We make this project available to "friendly users" to use, copy, modify, and derive from, hoping for constructive input. Comments and suggestions for improvements are most welcome. @@ -21,92 +20,185 @@ The list of contributors is [here](#SS-ack). Problems: -* The sets of rules have not been thoroughly checked for completeness, consistency, or enforceability. -* Triple question marks (???) mark known missing information +* The sets of rules have not been completely checked for completeness, consistency, or enforceability. +* Triple question marks (???) mark known missing information. * Update reference sections; many pre-C++11 sources are too old. -* For a more-or-less up-to-date to-do list see: [To-do: Unclassified proto-rules](#S-unclassified) +* For a more-or-less up-to-date to-do list see: [To-do: Unclassified proto-rules](#S-unclassified). -You can [Read an explanation of the scope and structure of this Guide](#S-abstract) or just jump straight in: +You can [read an explanation of the scope and structure of this Guide](#S-abstract) or just jump straight in: +* [In: Introduction](#S-introduction) * [P: Philosophy](#S-philosophy) * [I: Interfaces](#S-interfaces) * [F: Functions](#S-functions) * [C: Classes and class hierarchies](#S-class) * [Enum: Enumerations](#S-enum) +* [R: Resource management](#S-resource) * [ES: Expressions and statements](#S-expr) +* [Per: Performance](#S-performance) +* [CP: Concurrency and parallelism](#S-concurrency) * [E: Error handling](#S-errors) -* [R: Resource management](#S-resource) +* [Con: Constants and immutability](#S-const) * [T: Templates and generic programming](#S-templates) -* [CP: Concurrency](#S-concurrency) -* [STL: The Standard library](#S-stdlib) -* [SF: Source files](#S-source) * [CPL: C-style programming](#S-cpl) -* [PRO: Profiles](#S-profile) -* [GSL: Guideline support library](#S-gsl) +* [SF: Source files](#S-source) +* [SL: The Standard Library](#sl-the-standard-library) Supporting sections: -* [NL: Naming and layout](#S-naming) -* [PER: Performance](#S-performance) -* [N: Non-Rules and myths](#S-not) +* [A: Architectural ideas](#S-A) +* [NR: Non-Rules and myths](#S-not) * [RF: References](#S-references) +* [Pro: Profiles](#S-profile) +* [GSL: Guidelines support library](#gsl-guidelines-support-library) +* [NL: Naming and layout suggestions](#S-naming) +* [FAQ: Answers to frequently asked questions](#S-faq) * [Appendix A: Libraries](#S-libraries) * [Appendix B: Modernizing code](#S-modernizing) * [Appendix C: Discussion](#S-discussion) +* [Appendix D: Supporting tools](#S-tools) +* [Glossary](#S-glossary) * [To-do: Unclassified proto-rules](#S-unclassified) -or look at a specific language feature - -* [assignment](#S-???) -* [`class`](#S-class) -* [constructor](#SS-ctor) -* [derived `class`](#SS-hier) -* [destructor](#SS-ctor) -* [exception](#S-errors) -* [`for`](#S-???) -* [`inline`](#S-class) -* [initialization](#S-???) -* [lambda expression](#SS-lambda) -* [operator](#S-???) -* [`public`, `private`, and `protected`](#S-???) -* [`static_assert`](#S-???) -* [`struct`](#S-class) -* [`template`](#S-???) -* [`unsigned`](#S-???) -* [`virtual`](#S-hier) - -Definitions of terms used to express and discuss the rules, that are not language-technical, but refer to design and programming techniques - -* error -* exception -* failure -* invariant -* leak -* precondition -* postcondition -* resource -* exception guarantee - - - -# Abstract +You can sample rules for specific language features: + +* assignment: +[regular types](#Rc-regular) -- +[prefer initialization](#Rc-initialize) -- +[copy](#Rc-copy-semantic) -- +[move](#Rc-move-semantic) -- +[other operations](#Rc-matched) -- +[default](#Rc-eqdefault) +* `class`: +[data](#Rc-org) -- +[invariant](#Rc-struct) -- +[members](#Rc-member) -- +[helpers](#Rc-helper) -- +[concrete types](#SS-concrete) -- +[ctors, =, and dtors](#S-ctor) -- +[hierarchy](#SS-hier) -- +[operators](#SS-overload) +* `concept`: +[rules](#SS-concepts) -- +[in generic programming](#Rt-raise) -- +[template arguments](#Rt-concepts) -- +[semantics](#Rt-low) +* constructor: +[invariant](#Rc-struct) -- +[establish invariant](#Rc-ctor) -- +[`throw`](#Rc-throw) -- +[default](#Rc-default0) -- +[not needed](#Rc-default) -- +[`explicit`](#Rc-explicit) -- +[delegating](#Rc-delegating) -- +[`virtual`](#Rc-ctor-virtual) +* derived `class`: +[when to use](#Rh-domain) -- +[as interface](#Rh-abstract) -- +[destructors](#Rh-dtor) -- +[copy](#Rh-copy) -- +[getters and setters](#Rh-get) -- +[multiple inheritance](#Rh-mi-interface) -- +[overloading](#Rh-using) -- +[slicing](#Rc-copy-virtual) -- +[`dynamic_cast`](#Rh-dynamic_cast) +* destructor: +[and constructors](#Rc-matched) -- +[when needed?](#Rc-dtor) -- +[must not fail](#Rc-dtor-fail) +* exception: +[errors](#S-errors) -- +[`throw`](#Re-throw) -- +[for errors only](#Re-errors) -- +[`noexcept`](#Re-noexcept) -- +[minimize `try`](#Re-catch) -- +[what if no exceptions?](#Re-no-throw-codes) +* `for`: +[range-for and for](#Res-for-range) -- +[for and while](#Res-for-while) -- +[for-initializer](#Res-for-init) -- +[empty body](#Res-empty) -- +[loop variable](#Res-loop-counter) -- +[loop variable type ???](#Res-???) +* function: +[naming](#Rf-package) -- +[single operation](#Rf-logical) -- +[no throw](#Rf-noexcept) -- +[arguments](#Rf-smart) -- +[argument passing](#Rf-conventional) -- +[multiple return values](#Rf-out-multi) -- +[pointers](#Rf-return-ptr) -- +[lambdas](#Rf-capture-vs-overload) +* `inline`: +[small functions](#Rf-inline) -- +[in headers](#Rs-inline) +* initialization: +[always](#Res-always) -- +[prefer `{}`](#Res-list) -- +[lambdas](#Res-lambda-init) -- +[default member initializers](#Rc-in-class-initializer) -- +[class members](#Rc-initialize) -- +[factory functions](#Rc-factory) +* lambda expression: +[when to use](#SS-lambdas) +* operator: +[conventional](#Ro-conventional) -- +[avoid conversion operators](#Ro-conversion) -- +[and lambdas](#Ro-lambda) +* `public`, `private`, and `protected`: +[information hiding](#Rc-private) -- +[consistency](#Rh-public) -- +[`protected`](#Rh-protected) +* `static_assert`: +[compile-time checking](#Rp-compile-time) -- +[and concepts](#Rt-check-class) +* `struct`: +[for organizing data](#Rc-org) -- +[use if no invariant](#Rc-struct) -- +[no private members](#Rc-class) +* `template`: +[abstraction](#Rt-raise) -- +[containers](#Rt-cont) -- +[concepts](#Rt-concepts) +* `unsigned`: +[and signed](#Res-mix) -- +[bit manipulation](#Res-unsigned) +* `virtual`: +[interfaces](#Ri-abstract) -- +[not `virtual`](#Rc-concrete) -- +[destructor](#Rc-dtor-virtual) -- +[never fail](#Rc-dtor-fail) + +You can look at design concepts used to express the rules: + +* assertion: ??? +* error: ??? +* exception: exception guarantee (???) +* failure: ??? +* invariant: ??? +* leak: ??? +* library: ??? +* precondition: ??? +* postcondition: ??? +* resource: ??? + +# Abstract This document is a set of guidelines for using C++ well. The aim of this document is to help people to use modern C++ effectively. -By "modern C++" we mean C++11 and C++14 (and soon C++17). +By "modern C++" we mean effective use of the ISO C++ standard (currently C++20, but almost all of our recommendations also apply to C++17, C++14 and C++11). In other words, what would you like your code to look like in 5 years' time, given that you can start now? In 10 years' time? -The guidelines are focused on relatively higher-level issues, such as interfaces, resource management, memory management, and concurrency. +The guidelines are focused on relatively high-level issues, such as interfaces, resource management, memory management, and concurrency. Such rules affect application architecture and library design. -Following the rules will lead to code that is statically type safe, -has no resource leaks, and catches many more programming logic errors than is common in code today. -And it will run fast - you can afford to do things right. +Following the rules will lead to code that is statically type safe, has no resource leaks, and catches many more programming logic errors than is common in code today. +And it will run fast -- you can afford to do things right. We are less concerned with low-level issues, such as naming conventions and indentation style. However, no topic that can help a programmer is out of bounds. -Our initial set of rules emphasize safety (of various forms) and simplicity. -They may very well be too strict. +Our initial set of rules emphasizes safety (of various forms) and simplicity. +They might very well be too strict. We expect to have to introduce more exceptions to better accommodate real-world needs. We also need more rules. @@ -118,9 +210,10 @@ In particular, we'd really like to have some of our rules backed up with measure You will find some of the rules obvious or even trivial. Please remember that one purpose of a guideline is to help someone who is less experienced or coming from a different background or language to get up to speed. -The rules are designed to be supported by an analysis tool. +Many of the rules are designed to be supported by an analysis tool. Violations of rules will be flagged with references (or links) to the relevant rule. We do not expect you to memorize all the rules before trying to write code. +One way of thinking about these guidelines is as a specification for tools that happens to be readable by humans. The rules are meant for gradual introduction into a code base. We plan to build tools for that and hope others will too. @@ -128,11 +221,9 @@ We plan to build tools for that and hope others will too. Comments and suggestions for improvements are most welcome. We plan to modify and extend this document as our understanding improves and the language and the set of available libraries improve. +# In: Introduction - -# In: Introduction - -This is a set of core guidelines for modern C++, C++14, and taking likely future enhancements and taking ISO Technical Specifications (TSs) into account. +This is a set of core guidelines for modern C++ (currently C++20 and C++17) taking likely future enhancements and ISO Technical Specifications (TSs) into account. The aim is to help C++ programmers to write simpler, more efficient, more maintainable code. Introduction summary: @@ -144,54 +235,42 @@ Introduction summary: * [In.struct: The structure of this document](#SS-struct) * [In.sec: Major sections](#SS-sec) - - -## In.target: Target readership +## In.target: Target readership All C++ programmers. This includes [programmers who might consider C](#S-cpl). +## In.aims: Aims - -## In.aims: Aims +The purpose of this document is to help developers to adopt modern C++ (currently C++20 and C++17) and to achieve a more uniform style across code bases. -The purpose of this document is to help developers to adopt modern C++ (C++11, C++14, and soon C++17) and to achieve a more uniform style across code bases. - -We do not suffer the delusion that every one of these rules can be effectively applied to every code base. -Upgrading old systems is hard. -However, we do believe that a program that uses a rule is less error-prone and more maintainable than one that does not. -Often, rules also lead to faster/easier initial development. -As far as we can tell, these rules lead to code that performs as well or better than older, more conventional techniques; -they are meant to follow the zero-overhead principle -("what you don't use, you don't pay for" or "When you use an abstraction mechanism appropriately, -you get at least as good performance as if you had handcoded using lower-level language constructs"). -Consider these rules ideals for new code, opportunities to exploit when working on older code, and try to approximate these ideas as closely as feasible. +We do not suffer the delusion that every one of these rules can be effectively applied to every code base. Upgrading old systems is hard. However, we do believe that a program that uses a rule is less error-prone and more maintainable than one that does not. Often, rules also lead to faster/easier initial development. +As far as we can tell, these rules lead to code that performs as well or better than older, more conventional techniques; they are meant to follow the zero-overhead principle ("what you don't use, you don't pay for" or "when you use an abstraction mechanism appropriately, you get at least as good performance as if you had handcoded using lower-level language constructs"). +Consider these rules ideals for new code, opportunities to exploit when working on older code, and try to approximate these ideals as closely as feasible. Remember: - -### In.0: Don't panic! +### In.0: Don't panic! Take the time to understand the implications of a guideline rule on your program. -These guidelines are designed according to the "subset of a superset" principle ([Stroustrup,2005](#BS2005)). +These guidelines are designed according to the "subset of superset" principle ([Stroustrup05](#Stroustrup05)). They do not simply define a subset of C++ to be used (for reliability, safety, performance, or whatever). -Instead, they strongly recommend the use of a few simple "extensions" ([library components](#S-gsl)) +Instead, they strongly recommend the use of a few simple "extensions" ([library components](#gsl-guidelines-support-library)) that make the use of the most error-prone features of C++ redundant, so that they can be banned (in our set of rules). The rules emphasize static type safety and resource safety. For that reason, they emphasize possibilities for range checking, for avoiding dereferencing `nullptr`, for avoiding dangling pointers, and the systematic use of exceptions (via RAII). -Partly to achieve that and partly to minimize obscure code as a source of errors, -the rules also emphasize simplicity and the hiding of necessary complexity behind well-specified interfaces. +Partly to achieve that and partly to minimize obscure code as a source of errors, the rules also emphasize simplicity and the hiding of necessary complexity behind well-specified interfaces. Many of the rules are prescriptive. -We are uncomfortable with rules that simply states "don't do that!" without offering an alternative. +We are uncomfortable with rules that simply state "don't do that!" without offering an alternative. One consequence of that is that some rules can be supported only by heuristics, rather than precise and mechanically verifiable checks. Other rules articulate general principles. For these more general rules, more detailed and specific rules provide partial checking. -These guidelines address a core of C++ and its use. +These guidelines address the core of C++ and its use. We expect that most large organizations, specific application areas, and even large projects will need further rules, possibly further restrictions, and further library support. -For example, hard-real time programmers typically can't use free store (dynamic memory) freely and will be restricted in their choice of libraries. +For example, hard-real-time programmers typically can't use free store (dynamic memory) freely and will be restricted in their choice of libraries. We encourage the development of such more specific rules as addenda to these core guidelines. -Build your ideal small foundation library and use that, rather than lowering you level of programming to glorified assembly code. +Build your ideal small foundation library and use that, rather than lowering your level of programming to glorified assembly code. The rules are designed to allow [gradual adoption](#S-modernizing). @@ -199,14 +278,13 @@ Some rules aim to increase various forms of safety while others aim to reduce th The guidelines aimed at preventing accidents often ban perfectly legal C++. However, when there are two ways of expressing an idea and one has shown itself a common source of errors and the other has not, we try to guide programmers towards the latter. - -## In.not: Non-aims +## In.not: Non-aims The rules are not intended to be minimal or orthogonal. In particular, general rules can be simple, but unenforceable. Also, it is often hard to understand the implications of a general rule. More specialized rules are often easier to understand and to enforce, but without general rules, they would just be a long list of special cases. -We provide rules aimed as helping novices as well as rules supporting expert use. +We provide rules aimed at helping novices as well as rules supporting expert use. Some rules can be completely enforced, but others are based on heuristics. These rules are not meant to be read serially, like a book. @@ -221,7 +299,7 @@ If you need a tutorial for some given level of experience, see [the references]( This is not a guide on how to convert old C++ code to more modern code. It is meant to articulate ideas for new code in a concrete fashion. However, see [the modernization section](#S-modernizing) for some possible approaches to modernizing/rejuvenating/upgrading. -Importantly, the rules support gradual adoption: It is typically infeasible to convert all of a large code base at once. +Importantly, the rules support gradual adoption: It is typically infeasible to completely convert a large code base all at once. These guidelines are not meant to be complete or exact in every language-technical detail. For the final word on language definition issues, including every exception to general rules and every feature, see the ISO C++ standard. @@ -235,56 +313,88 @@ The rules are not value-neutral. They are meant to make code simpler and more correct/safer than most existing C++ code, without loss of performance. They are meant to inhibit perfectly valid C++ code that correlates with errors, spurious complexity, and poor performance. +The rules are not precise to the point where a person (or machine) can follow them without thinking. +The enforcement parts try to be that, but we would rather leave a rule or a definition a bit vague +and open to interpretation than specify something precisely and wrong. +Sometimes, precision comes only with time and experience. +Design is not (yet) a form of Math. + +The rules are not perfect. +A rule can do harm by prohibiting something that is useful in a given situation. +A rule can do harm by failing to prohibit something that enables a serious error in a given situation. +A rule can do a lot of harm by being vague, ambiguous, unenforceable, or by enabling every solution to a problem. +It is impossible to completely meet the "do no harm" criteria. +Instead, our aim is the less ambitious: "Do the most good for most programmers"; +if you cannot live with a rule, object to it, ignore it, but don't water it down until it becomes meaningless. +Also, suggest an improvement. - -## In.force: Enforcement +## In.force: Enforcement Rules with no enforcement are unmanageable for large code bases. Enforcement of all rules is possible only for a small weak set of rules or for a specific user community. -But we want lots of rules, and we want rules that everybody can use. -But different people have different needs. -But people don't like to read lots of rules. -But people can't remember many rules. + +* But we want lots of rules, and we want rules that everybody can use. +* But different people have different needs. +* But people don't like to read lots of rules. +* But people can't remember many rules. + So, we need subsetting to meet a variety of needs. -But arbitrary subsetting leads to chaos: We want guidelines that help a lot of people, make code more uniform, and strongly encourages people to modernize their code. + +* But arbitrary subsetting leads to chaos. + +We want guidelines that help a lot of people, make code more uniform, and strongly encourage people to modernize their code. We want to encourage best practices, rather than leave all to individual choices and management pressures. The ideal is to use all rules; that gives the greatest benefits. This adds up to quite a few dilemmas. We try to resolve those using tools. Each rule has an **Enforcement** section listing ideas for enforcement. -Enforcement might be by code review, by static analysis, by compiler, or by run-time checks. -Wherever possible, we prefer "mechanical" checking (humans are slow and bore easily) and static checking. -Run-time checks are suggested only rarely where no alternative exists; we do not want to introduce "distributed fat" - if that's what you want, you know where to find it. +Enforcement might be done by code review, by static analysis, by compiler, or by run-time checks. +Wherever possible, we prefer "mechanical" checking (humans are slow, inaccurate, and bore easily) and static checking. +Run-time checks are suggested only rarely where no alternative exists; we do not want to introduce "distributed bloat". Where appropriate, we label a rule (in the **Enforcement** sections) with the name of groups of related rules (called "profiles"). A rule can be part of several profiles, or none. For a start, we have a few profiles corresponding to common needs (desires, ideals): -* **types**: No type violations (reinterpreting a `T` as a `U` through casts/unions/varargs) +* **type**: No type violations (reinterpreting a `T` as a `U` through casts, unions, or varargs) * **bounds**: No bounds violations (accessing beyond the range of an array) * **lifetime**: No leaks (failing to `delete` or multiple `delete`) and no access to invalid objects (dereferencing `nullptr`, using a dangling reference). The profiles are intended to be used by tools, but also serve as an aid to the human reader. We do not limit our comment in the **Enforcement** sections to things we know how to enforce; some comments are mere wishes that might inspire some tool builder. +Tools that implement these rules shall respect the following syntax to explicitly suppress a rule: + + [[gsl::suppress("tag")]] + +and optionally with a message (following usual C++11 standard attribute syntax): + + [[gsl::suppress("tag", justification: "message")]] + +where - -## In.struct: The structure of this document +* `"tag"` is a string literal with the anchor name of the item where the Enforcement rule appears (e.g., for [C.134](#Rh-public) it is "Rh-public"), the +name of a profile group-of-rules ("type", "bounds", or "lifetime"), +or a specific rule in a profile ([type.4](#Pro-type-cstylecast), or [bounds.2](#Pro-bounds-arrayindex)). Any text that is not one of those should be rejected. + +* `"message"` is a string literal + +## In.struct: The structure of this document Each rule (guideline, suggestion) can have several parts: -* The rule itself - e.g., **no naked `new`** -* A rule reference number - e.g., **C.7** (the 7th rule related to classes). -Since the major sections are not inherently ordered, we use a letter as the first part of a rule reference "number". -We leave gaps in the numbering to minimize "disruption" when we add or remove rules. -* **Reason**s (rationales) - because programmers find it hard to follow rules they don't understand -* **Example**s - because rules are hard to understand in the abstract; can be positive or negative -* **Alternative**s - for "don't do this" rules -* **Exception**s - we prefer simple general rules. However, many rules apply widely, but not universally, so exceptions must be listed -* **Enforcement** - ideas about how the rule might be checked "mechanically" -* **See also**s - references to related rules and/or further discussion (in this document or elsewhere) -* **Note**s (comments) - something that needs saying that doesn't fit the other classifications -* **Discussion** - references to more extensive rationale and/or examples placed outside the main lists of rules +* The rule itself -- e.g., **no naked `new`** +* A rule reference number -- e.g., **C.7** (the 7th rule related to classes). + Since the major sections are not inherently ordered, we use letters as the first part of a rule reference "number". + We leave gaps in the numbering to minimize "disruption" when we add or remove rules. +* **Reason**s (rationales) -- because programmers find it hard to follow rules they don't understand +* **Example**s -- because rules are hard to understand in the abstract; can be positive or negative +* **Alternative**s -- for "don't do this" rules +* **Exception**s -- we prefer simple general rules. However, many rules apply widely, but not universally, so exceptions must be listed +* **Enforcement** -- ideas about how the rule might be checked "mechanically" +* **See also**s -- references to related rules and/or further discussion (in this document or elsewhere) +* **Note**s (comments) -- something that needs saying that doesn't fit the other classifications +* **Discussion** -- references to more extensive rationale and/or examples placed outside the main lists of rules Some rules are hard to check mechanically, but they all meet the minimal criteria that an expert programmer can spot many violations without too much trouble. We hope that "mechanical" tools will improve with time to approximate what such an expert programmer notices. @@ -293,220 +403,269 @@ Also, we assume that the rules will be refined over time to make them more preci A rule is aimed at being simple, rather than carefully phrased to mention every alternative and special case. Such information is found in the **Alternative** paragraphs and the [Discussion](#S-discussion) sections. If you don't understand a rule or disagree with it, please visit its **Discussion**. -If you feel that a discussion is missing or incomplete, send us an email. +If you feel that a discussion is missing or incomplete, enter an [Issue](https://github.com/isocpp/CppCoreGuidelines/issues) +explaining your concerns and possibly a corresponding PR. + +Examples are written to illustrate rules. + +* Examples are not intended to be production quality or to cover all tutorial dimensions. +For example, many examples are language-technical and use names like `f`, `base`, and `x`. +* We try to ensure that "good" examples follow the Core Guidelines. +* Comments are often illustrating rules where they would be unnecessary and/or distracting in "real code." +* We assume knowledge of the standard library. For example, we use plain `vector` rather than `std::vector`. This is not a language manual. It is meant to be helpful, rather than complete, fully accurate on technical details, or a guide to existing code. Recommended information sources can be found in [the references](#S-references). +## In.sec: Major sections - -## In.sec: Major sections - +* [In: Introduction](#S-introduction) * [P: Philosophy](#S-philosophy) * [I: Interfaces](#S-interfaces) * [F: Functions](#S-functions) * [C: Classes and class hierarchies](#S-class) * [Enum: Enumerations](#S-enum) +* [R: Resource management](#S-resource) * [ES: Expressions and statements](#S-expr) +* [Per: Performance](#S-performance) +* [CP: Concurrency and parallelism](#S-concurrency) * [E: Error handling](#S-errors) -* [R: Resource management](#S-resource) +* [Con: Constants and immutability](#S-const) * [T: Templates and generic programming](#S-templates) -* [CP: Concurrency](#S-concurrency) -* [STL: The Standard library](#S-stdlib) -* [SF: Source files](#S-source) * [CPL: C-style programming](#S-cpl) -* [PRO: Profiles](#S-profile) -* [GSL: Guideline support library](#S-gsl) +* [SF: Source files](#S-source) +* [SL: The Standard Library](#sl-the-standard-library) Supporting sections: -* [NL: Naming and layout](#S-naming) -* [PER: Performance](#S-performance) -* [N: Non-Rules and myths](#S-not) +* [A: Architectural ideas](#S-A) +* [NR: Non-Rules and myths](#S-not) * [RF: References](#S-references) +* [Pro: Profiles](#S-profile) +* [GSL: Guidelines support library](#gsl-guidelines-support-library) +* [NL: Naming and layout suggestions](#S-naming) +* [FAQ: Answers to frequently asked questions](#S-faq) * [Appendix A: Libraries](#S-libraries) * [Appendix B: Modernizing code](#S-modernizing) * [Appendix C: Discussion](#S-discussion) +* [Appendix D: Supporting tools](#S-tools) +* [Glossary](#S-glossary) * [To-do: Unclassified proto-rules](#S-unclassified) These sections are not orthogonal. -Each section (e.g., "P" for "Philosophy") and each subsection (e.g., "C.hier" for "Class Hierachies (OOP)") have an abbreviation for ease of searching and reference. +Each section (e.g., "P" for "Philosophy") and each subsection (e.g., "C.hier" for "Class Hierarchies (OOP)") have an abbreviation for ease of searching and reference. The main section abbreviations are also used in rule numbers (e.g., "C.11" for "Make concrete types regular"). - - -# P: Philosophy +# P: Philosophy The rules in this section are very general. Philosophy rules summary: * [P.1: Express ideas directly in code](#Rp-direct) -* [P.2: Write in ISO Standard C++](#Rp-C++) +* [P.2: Write in ISO Standard C++](#Rp-Cplusplus) * [P.3: Express intent](#Rp-what) * [P.4: Ideally, a program should be statically type safe](#Rp-typesafe) * [P.5: Prefer compile-time checking to run-time checking](#Rp-compile-time) * [P.6: What cannot be checked at compile time should be checkable at run time](#Rp-run-time) * [P.7: Catch run-time errors early](#Rp-early) -* [P.8: Don't leak any resource](#Rp-leak) +* [P.8: Don't leak any resources](#Rp-leak) * [P.9: Don't waste time or space](#Rp-waste) +* [P.10: Prefer immutable data to mutable data](#Rp-mutable) +* [P.11: Encapsulate messy constructs, rather than spreading through the code](#Rp-library) +* [P.12: Use supporting tools as appropriate](#Rp-tools) +* [P.13: Use support libraries as appropriate](#Rp-lib) Philosophical rules are generally not mechanically checkable. However, individual rules reflecting these philosophical themes are. -Without a philosophical basis the more concrete/specific/checkable rules lack rationale. +Without a philosophical basis, the more concrete/specific/checkable rules lack rationale. - -### P.1: Express ideas directly in code +### P.1: Express ideas directly in code -**Reason**: Compilers don't read comments (or design documents) and neither do many programmers (consistently). -What is expressed in code has a defined semantics and can (in principle) be checked by compilers and other tools. +##### Reason -**Example**: +Compilers don't read comments (or design documents) and neither do many programmers (consistently). +What is expressed in code has defined semantics and can (in principle) be checked by compilers and other tools. - class Date { - // ... - public: - Month month() const; // do - int month(); // don't - // ... - }; +##### Example + + class Date { + public: + Month month() const; // do + int month(); // don't + // ... + }; The first declaration of `month` is explicit about returning a `Month` and about not modifying the state of the `Date` object. The second version leaves the reader guessing and opens more possibilities for uncaught bugs. -**Example**: - - void do_something(vector& v) - { - string val; - cin>>val; - // ... - int index = 0; // bad - for(int i=0; i& v) + { + string val; + cin >> val; + // ... + int index = -1; // bad, plus should use gsl::index + for (int i = 0; i < v.size(); ++i) { + if (v[i] == val) { + index = i; + break; + } + } + // ... + } + +##### Example, good + A much clearer expression of intent would be: - void do_something(vector& v) - { - string val; - cin>>val; - // ... - auto p = find(v,val); // better - // ... - } + void f(vector& v) + { + string val; + cin >> val; + // ... + auto p = find(begin(v), end(v), val); // better + // ... + } A well-designed library expresses intent (what is to be done, rather than just how something is being done) far better than direct use of language features. -A C++ programmer should know the basics of the STL, and use it where appropriate. -Any programmer should know the basics of the foundation libraries of the project being worked on, and use it appropriately. -Any programmer using these guidelines should know the [Guidelines Support Library](#S-gsl), and use it appropriately. +A C++ programmer should know the basics of the standard library, and use it where appropriate. +Any programmer should know the basics of the foundation libraries of the project being worked on, and use them appropriately. +Any programmer using these guidelines should know the [guidelines support library](#gsl-guidelines-support-library), and use it appropriately. + +##### Example -**Example**: + change_speed(double s); // bad: what does s signify? + // ... + change_speed(2.3); - change_speed(double s); // bad: what does s signify? - // ... - change_speed(2.3); - A better approach is to be explicit about the meaning of the double (new speed or delta on old speed?) and the unit used: - change_speed(Speed s); // better: the meaning of s is specified - // ... - change_speed(2.3); // error: no unit - change_speed(23m/10s); // meters per second + change_speed(Speed s); // better: the meaning of s is specified + // ... + change_speed(2.3); // error: no unit + change_speed(23_m / 10s); // meters per second We could have accepted a plain (unit-less) `double` as a delta, but that would have been error-prone. If we wanted both absolute speed and deltas, we would have defined a `Delta` type. - -**Enforcement**: very hard in general. + +##### Enforcement + +Very hard in general. * use `const` consistently (check if member functions modify their object; check if functions modify arguments passed by pointer or reference) * flag uses of casts (casts neuter the type system) * detect code that mimics the standard library (hard) +### P.2: Write in ISO Standard C++ - -### P.2: Write in ISO Standard C++ +##### Reason -**Reason**: This is a set of guidelines for writing ISO Standard C++. +This is a set of guidelines for writing ISO Standard C++. -**Note**: There are environments where extensions are necessary, e.g., to access system resources. -In such cases, localize to use of necessary extensions and control their use with non-core Coding Guidelines. +##### Note -**Note**: There are environments where restrictions on use of standard C++ language or library features are necessary, -e.g., to avoid dynamic memory allocation as required by aircraft control software standards. -In such cases, control their (dis)use with non-core Coding Guidelines. +There are environments where extensions are necessary, e.g., to access system resources. +In such cases, localize the use of necessary extensions and control their use with non-core Coding Guidelines. If possible, build interfaces that encapsulate the extensions so they can be turned off or compiled away on systems that do not support those extensions. -**Enforcement**: Use an up-to-date C++ compiler (currently C++11 or C++14) with a set of options that do not accept extensions. - +Extensions often do not have rigorously defined semantics. Even extensions that +are common and implemented by multiple compilers might have slightly different +behaviors and edge case behavior as a direct result of *not* having a rigorous +standard definition. With sufficient use of any such extension, expected +portability will be impacted. - -### P.3: Express intent +##### Note -**Reason**: Unless the intent of some code is stated (e.g., in names or comments), it is impossible to tell whether the code does what it is supposed to do. +Using valid ISO C++ does not guarantee portability (let alone correctness). +Avoid dependence on undefined behavior (e.g., [undefined order of evaluation](#Res-order)) +and be aware of constructs with implementation defined meaning (e.g., `sizeof(int)`). -**Example**: +##### Note - int i = 0; - while (iP.3: Express intent + +##### Reason + +Unless the intent of some code is stated (e.g., in names or comments), it is impossible to tell whether the code does what it is supposed to do. + +##### Example + + gsl::index i = 0; + while (i < v.size()) { + // ... do something with v[i] ... + } + +The intent of "just" looping over the elements of `v` is not expressed here. The implementation detail of an index is exposed (so that it might be misused), and `i` outlives the scope of the loop, which might or might not be intended. The reader cannot know from just this section of code. Better: - for (auto x : v) { /* do something with x */ } + for (const auto& x : v) { /* do something with the value of x */ } -Now, there is no explicit mention of the iteration mechanism, and the loop operates on a copy of elements so that accidental modification cannot happen. If modification is desired, say so: +Now, there is no explicit mention of the iteration mechanism, and the loop operates on a reference to `const` elements so that accidental modification cannot happen. If modification is desired, say so: - for (auto& x : v) { /* do something with x */ } + for (auto& x : v) { /* modify x */ } -Sometimes better still, use a named algorithm: +For more details about for-statements, see [ES.71](#Res-for-range). +Sometimes better still, use a named algorithm. This example uses the `for_each` from the Ranges TS because it directly expresses the intent: - for_each(v,[](int x) { /* do something with x */ }); - for_each(parallel.v,[](int x) { /* do something with x */ }); + for_each(v, [](int x) { /* do something with the value of x */ }); + for_each(par, v, [](int x) { /* do something with the value of x */ }); The last variant makes it clear that we are not interested in the order in which the elements of `v` are handled. A programmer should be familiar with -* [The guideline support library](#S-gsl) -* [The ISO C++ standard library](#S-stdlib) +* [The guidelines support library](#gsl-guidelines-support-library) +* [The ISO C++ Standard Library](#sl-the-standard-library) * Whatever foundation libraries are used for the current project(s) -**Note**: Alternative formulation: Say what should be done, rather than just how it should be done +##### Note -**Note**: Some language constructs express intent better than others. +Alternative formulation: Say what should be done, rather than just how it should be done. -**Example**: if two `int`s are meant to be the coordinates of a 2D point, say so: +##### Note - drawline(int,int,int,int); // obscure - drawline(Point,Point); // clearer +Some language constructs express intent better than others. -**Enforcement**: Look for common patterns for which there are better alternatives +##### Example + +If two `int`s are meant to be the coordinates of a 2D point, say so: + + draw_line(int, int, int, int); // obscure: (x1,y1,x2,y2)? (x,y,h,w)? ...? + // need to look up documentation to know + + draw_line(Point, Point); // clearer + +##### Enforcement + +Look for common patterns for which there are better alternatives * simple `for` loops vs. range-`for` loops -* `f(T*,int)` interfaces vs. `f(array_view)` interfaces -* loop variable in a too large scope +* `f(T*, int)` interfaces vs. `f(span)` interfaces +* loop variables in too large a scope * naked `new` and `delete` -* functions with many arguments of built-in types +* functions with many parameters of built-in types There is a huge scope for cleverness and semi-automated program transformation. +### P.4: Ideally, a program should be statically type safe - -### P.4: Ideally, a program should be statically type safe +##### Reason -**Reason**: Ideally, a program would be completely statically (compile-time) type safe. +Ideally, a program would be completely statically (compile-time) type safe. Unfortunately, that is not possible. Problem areas: * unions @@ -515,10159 +674,20252 @@ Unfortunately, that is not possible. Problem areas: * range errors * narrowing conversions -**Note**: These areas are sources of serious problems (e.g., crashes and security violations). +##### Note + +These areas are sources of serious problems (e.g., crashes and security violations). We try to provide alternative techniques. -**Enforcement**: We can ban, restrain, or detect the individual problem categories separately, as required and feasible for individual programs. +##### Enforcement + +We can ban, restrain, or detect the individual problem categories separately, as required and feasible for individual programs. Always suggest an alternative. For example: -* unions - use `variant` -* casts - minimize their use; templates can help -* array decay - use `array_view` -* range errors - use `array_view` -* narrowing conversions - minimize their use and use `narrow` or `narrow_cast` where they are necessary +* unions -- use `variant` (in C++17) +* casts -- minimize their use; templates can help +* array decay -- use `span` (from the GSL) +* range errors -- use `span` +* narrowing conversions -- minimize their use and use `narrow` or `narrow_cast` (from the GSL) where they are necessary +### P.5: Prefer compile-time checking to run-time checking - -### P.5: Prefer compile-time checking to run-time checking +##### Reason -**Reason**: Code clarity and performance. You don't need to write error handlers for errors caught at compile time. +Code clarity and performance. +You don't need to write error handlers for errors caught at compile time. -**Example**: +##### Example - void initializer(Int x) - // Int is an alias used for integers - { - static_assert(sizeof(Int)>=4); // do: compile-time check + // Int is an alias used for integers + int bits = 0; // don't: avoidable code + for (Int i = 1; i; i <<= 1) + ++bits; + if (bits < 32) + cerr << "Int too small\n"; - int bits = 0; // don't: avoidable code - for (Int i = 1; i; i<<=1) - ++bits; - if (bits<32) - cerr << "Int too small\n"; - - // ... - } +This example fails to achieve what it is trying to achieve (because overflow is undefined) and should be replaced with a simple `static_assert`: -**Example; don't**: + // Int is an alias used for integers + static_assert(sizeof(Int) >= 4); // do: compile-time check - void read(int* p, int n); // read max n integers into *p - -**Example**: +Or better still just use the type system and replace `Int` with `int32_t`. - void read(array_view r); // read into the range of integers r +##### Example -**Alternative formulation**: Don't postpone to run time what can be done well at compile time. + void read(int* p, int n); // read max n integers into *p -**Enforcement**: + int a[100]; + read(a, 1000); // bad, off the end -* look for pointer arguments -* look for run-time checks for range violations. +better + void read(span r); // read into the range of integers r - -### P.6: What cannot be checked at compile time should be checkable at run time + int a[100]; + read(a); // better: let the compiler figure out the number of elements -**Reason**: Leaving hard-to-detect errors in a program is asking for crashes and bad results. +**Alternative formulation**: Don't postpone to run time what can be done well at compile time. -**Note**: Ideally we catch all errors (that are not errors in the programmer's logic) at either compile-time or run-time. It is impossible to catch all errors at compile time and often not affordable to catch all remaining errors at run time. However, we should endeavor to write programs that in principle can be checked, given sufficient resources (analysis programs, run-time checks, machine resources, time). +##### Enforcement -**Example, bad**: +* Look for pointer arguments. +* Look for run-time checks for range violations. - extern void f(int* p); // separately compiled, possibly dynamically loaded - - void g(int n) - { - f(new int[n]); // bad: the number of elements is not passed to f() - } +### P.6: What cannot be checked at compile time should be checkable at run time -Here, a crucial bit of information (the number of elements) has been so thoroughly "obscured" that static analysis is probably rendered infeasible and dynamic checking can be very difficult when `f()` is part of an ABI so that we cannot "instrument" that pointer. We could embed helpful information into the free store, but that requires global changes to a system and maybe to the compiler. What we have here is a design that makes error detection very hard. +##### Reason -**Example, bad**: We can of course pass the number of elements along with the pointer: +Leaving hard-to-detect errors in a program is asking for crashes and bad results. - extern void f2(int* p, int n); // separately compiled, possibly dynamically loaded - - void g2(int n) - { - f2(new int[n],m); // bad: the wrong number of elements can be passed to f() - } +##### Note -Passing the number of elements as an argument is better (and far more common) that just passing the pointer and relying on some (unstated) convention for knowing or discovering the number of elements. However (as shown), a simple typo can introduce a serious error. The connection between the two arguments of `f2()` is conventional, rather than explicit. +Ideally, we catch all errors (that are not errors in the programmer's logic) at either compile time or run time. It is impossible to catch all errors at compile time and often not affordable to catch all remaining errors at run time. However, we should endeavor to write programs that in principle can be checked, given sufficient resources (analysis programs, run-time checks, machine resources, time). -Also, it is implicit that `f2()` is supposed to `delete` its argument (or did the caller make a second mistake?). +##### Example, bad -**Example, bad**: The standard library resource management pointers fail to pass the size when they point to an object: + // separately compiled, possibly dynamically loaded + extern void f(int* p); - extern void f3(unique_ptr, int n); // separately compiled, possibly dynamically loaded + void g(int n) + { + // bad: the number of elements is not passed to f() + f(new int[n]); + } - void g3(int n) - { - f3(make_unique(n),m); // bad: pass ownership and size separately - } +Here, a crucial bit of information (the number of elements) has been so thoroughly "obscured" that static analysis is probably rendered infeasible and dynamic checking can be very difficult when `f()` is part of an ABI so that we cannot "instrument" that pointer. We could embed helpful information into the free store, but that requires global changes to a system and maybe to the compiler. What we have here is a design that makes error detection very hard. -**Example**: We need to pass the pointer and the number of elements as an integral object: +##### Example, bad - extern void f4(vector&); // separately compiled, possibly dynamically loaded - extern void f4(array_view); // separately compiled, possibly dynamically loaded +We can of course pass the number of elements along with the pointer: - void g3(int n) - { - vector v(n); - f4(v); // pass a reference, retain ownership - f4(array_view{v}); // pass a view, retain ownership - } + // separately compiled, possibly dynamically loaded + extern void f2(int* p, int n); -This design carries the number of elements along as an integral part of an object, so that errors are unlikely and dynamic (run-time) checking is always feasible, if not always affordable. + void g2(int n) + { + f2(new int[n], m); // bad: a wrong number of elements can be passed to f() + } -**Example**: How do we transfer both ownership and all information needed for validating use? - - vector f5(int n) // OK: move - { - vector v(n); - // ... initialize v ... - return v; - } - - unique_ptr f6(int n) // bad: loses n - { - auto p = make_unique(n); - // ... initialize *p ... - return p; - } - - owner f7(int n) // bad: loses n and we might forget to delete - { - owner p = new int[n]; - // ... initialize *p ... - return p; - } - -**Example**: - - show how possible checks are avoided by interfaces that pass polymorphic base classes around, when they actually know what they need? - Or strings as "free-style" options - -**Enforcement**: - -* Flag (pointer,count) interfaces (this will flag a lot of examples that can't be fixed for compatibility reasons) -* ??? +Passing the number of elements as an argument is better (and far more common) than just passing the pointer and relying on some (unstated) convention for knowing or discovering the number of elements. However (as shown), a simple typo can introduce a serious error. The connection between the two arguments of `f2()` is conventional, rather than explicit. - -### P.7: Catch run-time errors early +Also, it is implicit that `f2()` is supposed to `delete` its argument (or did the caller make a second mistake?). -**Reason**: Avoid "mysterious" crashes. -Avoid errors leading to (possibly unrecognized) wrong results. +##### Example, bad -**Example**: +The standard library resource management pointers fail to pass the size when they point to an object: - void increment1(int* p, int n) // bad: error prone - { - for (int i=0; i, int n); - void use1(int m) - { - const int n = 10; - int a[n] = {}; - // ... - increment1(a,m); // maybe typo, maybe m<=n is supposed - // but assume that m==20 - // ... - } + void g3(int n) + { + f3(make_unique(n), m); // bad: pass ownership and size separately + } -Here we made a small error in `use1` that will lead to corrupted data or a crash. -The (pointer,count) interface leaves `increment1()` with no realistic way of defending itself against out-of-range errors. -Assuming that we could check subscripts for out of range access, the error would not be discovered until `p[10]` was accessed. -We could check earlier and improve the code: +##### Example - void increment2(array_view p) - { - for (int& x : p) ++x; - } - - void use2(int m) - { - const int n = 10; - int a[n] = {}; - // ... - increment2({a,m}); // maybe typo, maybe m<=n is supposed - // ... - } - -Now, `m<=n` can be checked at the point of call (early) rather than later. -If all we had was a typo so that we meant to use `n` as the bound, the code could be further simplified (eliminating the possibility of an error): +We need to pass the pointer and the number of elements as an integral object: - void use3(int m) - { - const int n = 10; - int a[n] = {}; - // ... - increment2(a); // the number of elements of a need not be repeated - // ... - } - -**Example, bad**: Don't repeatedly check the same value. Don't pass structured data as strings: - - Date read_date(istream& is); // read date from istream - - Date extract_date(const string& s); // extract date from string - - user1(const string& date) // manipulate date - { - auto d = extract_date(date); - // ... - } - - void user2() - { - Date d = read_date(cin); - // ... - user1(d.to_string()); - // ... - } - -The date is validated twice (by the `Date` constructor) and passed as an character string (unstructured data). - -**Example**: Excess checking can be costly. -There are cases where checking early is dumb because you may not ever need the value, -or may only need part of the value that is more easily checked than the whole. - - class Jet { // Physics says: e*e < x*x + y*y + z*z - float fx, fy, fz, fe; - public: - Jet(float x, float y, float z, float e) - :fx(x), fy(y), fz(z), fe(e) - { - // Should I check the here that the values are physically meaningful? - } - - float m() const - { - // Should I handle the degenerate case here? - return sqrt(x*x + y*y + z*z - e*e); - } - - ??? - }; - -The physical law for a jet (`e*e < x*x + y*y + z*z`) is not an invariant because the possibility of measurement errors. + extern void f4(vector&); // separately compiled, possibly dynamically loaded + extern void f4(span); // separately compiled, possibly dynamically loaded + // NB: this assumes the calling code is ABI-compatible, using a + // compatible C++ compiler and the same stdlib implementation -??? + void g3(int n) + { + vector v(n); + f4(v); // pass a reference, retain ownership + f4(span{v}); // pass a view, retain ownership + } -**Enforcement**: +This design carries the number of elements along as an integral part of an object, so that errors are unlikely and dynamic (run-time) checking is always feasible, if not always affordable. -* Look at pointers and arrays: Do range-checking early -* Look at conversions: eliminate or mark narrowing conversions. -* Look for unchecked values coming from input -* Look for structured data (objects of classes with invariants) being converted into strings -* ??? +##### Example +How do we transfer both ownership and all information needed for validating use? - -### P.8: Don't leak any resource + vector f5(int n) // OK: move + { + vector v(n); + // ... initialize v ... + return v; + } -**Reason**: Essential for long-running programs. Efficiency. Ability to recover from errors. + unique_ptr f6(int n) // bad: loses n + { + auto p = make_unique(n); + // ... initialize *p ... + return p; + } -**Example, bad**: + owner f7(int n) // bad: loses n and we might forget to delete + { + owner p = new int[n]; + // ... initialize *p ... + return p; + } - void f(char* name) - { - FILE* input = fopen(name,"r"); - // ... - if (something) return; // bad: if something==true, a file handle is leaked - // ... - fclose(input); - } +##### Example -Prefer [RAII](#Rr-raii): +* ??? +* show how possible checks are avoided by interfaces that pass polymorphic base classes around, when they actually know what they need? + Or strings as "free-style" options - void f(char* name) - { - ifstream input {name}; - // ... - if (something) return; // OK: no leak - // ... - } +##### Enforcement -**See also**: [The resource management section](#S-resources) +* Flag (pointer, count)-style interfaces (this will flag a lot of examples that can't be fixed for compatibility reasons) +* ??? -**Enforcement**: +### P.7: Catch run-time errors early -* Look at pointers: classify them into non-owners (the default) and owners. -Where feasible, replace owners with standard-library resource handles (as in the example above). -Alternatively, mark an owner as such using `owner` from [the GSL](#S-gsl). -* Look for naked `new` and `delete` -* look for known resource allocating functions returning raw pointers (such as `fopen`, `malloc`, and `strdup`) - - - -### P.9: Don't waste time or space - -**Reason**: This is C++. - -**Note**: Time and space that you spend well to achieve a goal (e.g., speed of development, resource safety, or simplification of testing) is not wasted. - -**Example**: ??? more and better suggestions for gratuitous waste welcome ??? - - struct X { - char ch; - int i; - string s; - char ch2; - - X& operator=(const X& a); - X(const X&); - }; - - X waste(const char* p) - { - if (p==nullptr) throw Nullptr_error{}; - int n = strlen(p); - auto buf = new char[n]; - for (int i = 0; i -# I: Interfaces + void use1(int m) + { + const int n = 10; + int a[n] = {}; + // ... + increment1(a, m); // maybe typo, maybe m <= n is supposed + // but assume that m == 20 + // ... + } -An interface is a contract between two parts of a program. Precisely stating what is expected of a supplier of a service and a user of that service is essential. -Having good (easy-to-understand, encouraging efficient use, not error-prone, supporting testing, etc.) interfaces is probably the most important single aspect of code organization. +Here we made a small error in `use1` that will lead to corrupted data or a crash. +The (pointer, count)-style interface leaves `increment1()` with no realistic way of defending itself against out-of-range errors. +If we could check subscripts for out of range access, then the error would not be discovered until `p[10]` was accessed. +We could check earlier and improve the code: -Interface rule summary: + void increment2(span p) + { + for (int& x : p) ++x; + } -* [I.1: Make interfaces explicit](#Ri-explicit) -* [I.2: Avoid global variables](#Ri-global) -* [I.3: Avoid singletons](#Ri-singleton) -* [I.4: Make interfaces precisely and strongly typed](#Ri-type) -* [I.5: State preconditions (if any)](#Ri-pre) -* [I.6: Prefer `Expects()` for expressing preconditions](#Ri-expects) -* [I.7: State postconditions](#Ri-post) -* [I.8: Prefer `Ensures()` for expressing postconditions](#Ri-ensures) -* [I.9: If an interface is a template, document its parameters using concepts](#Ri-concepts) -* [I.10: Use exceptions to signal a failure to perform a required tasks](#Ri-except) -* [I.11: Never transfer ownership by a raw pointer (`T*`)](#Ri-raw) -* [I.12: Declare a pointer that must not be null as `not_null`](#Ri-nullptr) -* [I.13: Do not pass an array as a single pointer](#Ri-array) -* [I.23: Keep the number of function arguments low](#Ri-nargs) -* [I.24: Avoid adjacent unrelated parameters of the same type](#Ri-unrelated) -* [I.25: Prefer abstract classes as interfaces to class hierarchies](#Ri-abstract) -* [I.26: If you want a cross-compiler ABI, use a C-style subset](#Ri-abi) + void use2(int m) + { + const int n = 10; + int a[n] = {}; + // ... + increment2({a, m}); // maybe typo, maybe m <= n is supposed + // ... + } -See also +Now, `m <= n` can be checked at the point of call (early) rather than later. +If all we had was a typo so that we meant to use `n` as the bound, the code could be further simplified (eliminating the possibility of an error): -* [F: Functions](#S-functions) -* [C.concrete: Concrete types](#SS-concrete) -* [C.hier: Class hierarchies](#SS-hier) -* [C.over: Overloading and overloaded operators](#SS-overload) -* [C.con: Containers and other resource handles](#SS-containers) -* [E: Error handling](#S-errors) -* [T: Templates and generic programming](#S-templates) + void use3(int m) + { + const int n = 10; + int a[n] = {}; + // ... + increment2(a); // the number of elements of a need not be repeated + // ... + } - -### I.1: Make interfaces explicit +##### Example, bad -**Reason**: Correctness. Assumptions not stated in an interface are easily overlooked and hard to test. +Don't repeatedly check the same value. Don't pass structured data as strings: -**Example, bad**: -Controlling the behavior of a function through a global (namespace scope) variable (a call mode) is implicit and potentially confusing. For example, + Date read_date(istream& is); // read date from istream - int rnd(double d) - { - return (rnd_up) ? ceil(d) : d; // don't: "invisible" dependency - } + Date extract_date(const string& s); // extract date from string -It will not be obvious to a caller that the meaning of two calls of `rnd(7.2)` might give different results. + void user1(const string& date) // manipulate date + { + auto d = extract_date(date); + // ... + } -**Exception**: Sometimes we control the details of a set of operations by an environment variable, e.g., normal vs. verbose output or debug vs. optimized. -The use of a non-local control is potentially confusing, but controls only implementation details of an otherwise fixed semantics. + void user2() + { + Date d = read_date(cin); + // ... + user1(d.to_string()); + // ... + } -**Example, bad**: Reporting through non-local variables (e.g., `errno`) is easily ignored. For example: +The date is validated twice (by the `Date` constructor) and passed as a character string (unstructured data). - fprintf(connection,"logging: %d %d %d\n",x,y,s); // don't: no test of printf's return value - -What if the connection goes down so than no logging output is produced? See Rule I.??. +##### Example -**Alternative**: Throw an exception. An exception cannot be ignored. - -**Alternative formulation**: Avoid passing information across an interface through non-local state. -Note that non-`const` member functions pass information to other member functions thorough their object's state. +Excess checking can be costly. +There are cases where checking early is inefficient because you might never need the value, or might only need part of the value that is more easily checked than the whole. Similarly, don't add validity checks that change the asymptotic behavior of your interface (e.g., don't add a `O(n)` check to an interface with an average complexity of `O(1)`). -**Alternative formulation**: An interface should be a function or a set of functions. -Functions can be template functions and sets of functions can be classes or class templates. + class Jet { // Physics says: e * e < x * x + y * y + z * z + float x; + float y; + float z; + float e; + public: + Jet(float x, float y, float z, float e) + :x(x), y(y), z(z), e(e) + { + // Should I check here that the values are physically meaningful? + } -**Enforcement**: + float m() const + { + // Should I handle the degenerate case here? + return sqrt(x * x + y * y + z * z - e * e); + } -* (Simple) A function should not make control-flow decisions based on the values of variables declared at namespace scope. -* (Simple) A function should not write to variables declared at namespace scope. + ??? + }; - -### I.2 Avoid global variables +The physical law for a jet (`e * e < x * x + y * y + z * z`) is not an invariant because of the possibility for measurement errors. -**Reason**: Non-`const` global variables hide dependencies and make the dependencies subject to unpredictable changes. +??? -**Example**: +##### Enforcement - struct Data { - // ... lots of stuff ... - } data; // non-const data +* Look at pointers and arrays: Do range-checking early and not repeatedly +* Look at conversions: Eliminate or mark narrowing conversions +* Look for unchecked values coming from input +* Look for structured data (objects of classes with invariants) being converted into strings +* ??? - void compute() // don't - { - // ...use data ... - } +### P.8: Don't leak any resources - void output() // don't - { - // ... use data ... - } +##### Reason -Who else might modify `data`? +Even a slow growth in resources will, over time, exhaust the availability of those resources. +This is particularly important for long-running programs, but is an essential piece of responsible programming behavior. -**Note**: global constants are useful. +##### Example, bad -**Note**: The rule against global variables applies to namespace scope variables as well. + void f(char* name) + { + FILE* input = fopen(name, "r"); + // ... + if (something) return; // bad: if something == true, a file handle is leaked + // ... + fclose(input); + } -**Alternative**: If you use global (more generally namespace scope data) to avoid copying, consider passing the data as an object by const reference. -Another solution is to define the data as the state of some objects and the operations as member functions. +Prefer [RAII](#Rr-raii): -**Warning**: Beware of data races: if one thread can access nonlocal data (or data passed by reference) while another thread execute the callee, we can have a data race. -Every pointer or reference to mutable data is a potential data race. + void f(char* name) + { + ifstream input {name}; + // ... + if (something) return; // OK: no leak + // ... + } -**Note**: You cannot have a race condition on immutable data. +**See also**: [The resource management section](#S-resource) -**Reference**: See the [rules for calling functions](#SS-call). +##### Note -**Enforcement**: (Simple) Report all non-`const` variables declared at namespace scope. +A leak is colloquially "anything that isn't cleaned up." +The more important classification is "anything that can no longer be cleaned up." +For example, allocating an object on the heap and then losing the last pointer that points to that allocation. +This rule should not be taken as requiring that allocations within long-lived objects must be returned during program shutdown. +For example, relying on system guaranteed cleanup such as file closing and memory deallocation upon process shutdown can simplify code. +However, relying on abstractions that implicitly clean up can be as simple, and often safer. +##### Note - -### I.3: Avoid singletons +Enforcing [the lifetime safety profile](#SS-lifetime) eliminates leaks. +When combined with resource safety provided by [RAII](#Rr-raii), it eliminates the need for "garbage collection" (by generating no garbage). +Combine this with enforcement of [the type and bounds profiles](#SS-force) and you get complete type- and resource-safety, guaranteed by tools. -**Reason**: Singletons are basically complicated global objects in disguise. +##### Enforcement -**Example**: - - class Singleton { - // ... lots of stuff to ensure that only one Singleton object is created, that it is initialized properly, etc. - }; +* Look at pointers: Classify them into non-owners (the default) and owners. + Where feasible, replace owners with standard-library resource handles (as in the example above). + Alternatively, mark an owner as such using `owner` from [the GSL](#gsl-guidelines-support-library). +* Look for naked `new` and `delete` +* Look for known resource allocating functions returning raw pointers (such as `fopen`, `malloc`, and `strdup`) -There are many variants of the singleton idea. -That's part of the problem. - -**Note**: If you don't want a global object to change, declare it `const` or `constexpr`. +### P.9: Don't waste time or space -**Exception**: You can use the simplest "singleton" (so simple that it is often not considered a singleton) to get initialization on first use, if any: +##### Reason - X& myX() - { - static X my_x {3}; - return my_x; - } +This is C++. -This one of the most effective solution to problem related to initialization order. -In a multi-threaded environment the initialization of the static object does not introduce a race condition -(unless you carelessly access a shared objects from within its constructor). +##### Note -If you, as many do, define a singleton as a class for which only one object is created, functions like `myX` are not singletons, -and this useful technique is not an exception to the no-singleton rule. - -**Enforcement**: Very hard in general +Time and space that you spend well to achieve a goal (e.g., speed of development, resource safety, or simplification of testing) is not wasted. +"Another benefit of striving for efficiency is that the process forces you to understand the problem in more depth." - Alex Stepanov -* Look for classes with name that includes `singleton` -* Look for classes for which only a single object is created (by counting objects or by examining constructors) +##### Example, bad + struct X { + char ch; + int i; + string s; + char ch2; - -### I.4: Make interfaces precisely and strongly typed + X& operator=(const X& a); + X(const X&); + }; -Reason: Types are the simplest and best documentation, have well-defined meaning, and are guaranteed to be checked at compile time. -Also, precisely typed code often optimize better. + X waste(const char* p) + { + if (!p) throw Nullptr_error{}; + int n = strlen(p); + auto buf = new char[n]; + if (!buf) throw Allocation_error{}; + for (int i = 0; i < n; ++i) buf[i] = p[i]; + // ... manipulate buffer ... + X x; + x.ch = 'a'; + x.s = string(n); // give x.s space for *p + for (gsl::index i = 0; i < x.s.size(); ++i) x.s[i] = buf[i]; // copy buf into x.s + delete[] buf; + return x; + } -**Example; don't**: Consider + void driver() + { + X x = waste("Typical argument"); + // ... + } - void pass(void* data); // void* is suspicious +Yes, this is a caricature, but we have seen every individual mistake in production code, and worse. +Note that the layout of `X` guarantees that at least 6 bytes (and most likely more) are wasted. +The spurious definition of copy operations disables move semantics so that the return operation is slow +(please note that the Return Value Optimization, RVO, is not guaranteed here). +The use of `new` and `delete` for `buf` is redundant; if we really needed a local string, we should use a local `string`. +There are several more performance bugs and gratuitous complication. -Now the callee has to cast the data pointer (back) to a correct type to use it. That is error-prone and often verbose. -Avoid `void*` in interfaces. -Consider using a variant or a pointer to base instead. (Future note: Consider a pointer to concept.) +##### Example, bad -**Alternative**: Often, a template parameter can eliminate the `void*` turning it into a `T*` or something like that. + void lower(zstring s) + { + for (int i = 0; i < strlen(s); ++i) s[i] = tolower(s[i]); + } -**Example; bad**: Consider +This is actually an example from production code. +We can see that in our condition we have `i < strlen(s)`. This expression will be evaluated on every iteration of the loop, which means that `strlen` must walk through string every loop to discover its length. While the string contents are changing, it's assumed that `tolower` will not affect the length of the string, so it's better to cache the length outside the loop and not incur that cost each iteration. - void draw_rect(int,int,int,int); // great opportunities for mistakes - - draw_rect(p.x,p.y,10,20); // what does 10,20 mean? +##### Note -An `int` can carry arbitrary forms of information, so we must guess about the meaning of the four `int`s. -Most likely, the first two are an `x`,`y` coordinate pair, but what are the last two? -Comments and parameter names can help, but we could be explicit: +An individual example of waste is rarely significant, and where it is significant, it is typically easily eliminated by an expert. +However, waste spread liberally across a code base can easily be significant and experts are not always as available as we would like. +The aim of this rule (and the more specific rules that support it) is to eliminate most waste related to the use of C++ before it happens. +After that, we can look at waste related to algorithms and requirements, but that is beyond the scope of these guidelines. - void draw_rectangle(Point top_left, Point bottom_right); - void draw_rectangle(Point top_left, Size height_width); - - draw_rectangle(p,Point{10,20}); // two corners - draw_rectangle(p,Size{10,20}); // one corner and a (height,width) pair +##### Enforcement -Obviously, we cannot catch all errors through the static type system -(e.g., the fact that a first argument is supposed to be a top-left point is left to convention (naming and comments)). - +Many more specific rules aim at the overall goals of simplicity and elimination of gratuitous waste. -**Example**: ??? units: time duration ??? +* Flag an unused return value from a user-defined non-defaulted postfix `operator++` or `operator--` function. Prefer using the prefix form instead. (Note: "User-defined non-defaulted" is intended to reduce noise. Review this enforcement if it's still too noisy in practice.) -**Enforcement**: -* (Simple) Report the use of void* as a parameter or return type. -* (Hard to do well) Look for member functions with many built-in type arguments +### P.10: Prefer immutable data to mutable data +##### Reason - -### I.5: State preconditions (if any) +It is easier to reason about constants than about variables. +Something immutable cannot change unexpectedly. +Sometimes immutability enables better optimization. +You can't have a data race on a constant. -**Reason**: Arguments have meaning that may constrain their proper use in the callee. +See [Con: Constants and immutability](#S-const) -**Example**: Consider +### P.11: Encapsulate messy constructs, rather than spreading through the code - double sqrt(double x); +##### Reason -Here `x` must be nonnegative. The type system cannot (easily and naturally) express that, so we must use other means. For example: +Messy code is more likely to hide bugs and harder to write. +A good interface is easier and safer to use. +Messy, low-level code breeds more such code. - double sqrt(double x); // x must be nonnegative +##### Example -Some preconditions can be expressed as assertions. For example: + int sz = 100; + int* p = (int*) malloc(sizeof(int) * sz); + int count = 0; + // ... + for (;;) { + // ... read an int into x, exit loop if end of file is reached ... + // ... check that x is valid ... + if (count == sz) + p = (int*) realloc(p, sizeof(int) * sz * 2); + p[count++] = x; + // ... + } - double sqrt(double x) { Expects(x>=0); /* ... */ } +This is low-level, verbose, and error-prone. +For example, we "forgot" to test for memory exhaustion and assign new value to `sz`. +Instead, we could use `vector`: -Ideally, that `Expects(x>=0)` should be part of the interface of `sqrt()` but that's not easily done. For now, we place it in the definition (function body). + vector v; + v.reserve(100); + // ... + for (int x; cin >> x; ) { + // ... check that x is valid ... + v.push_back(x); + } -**Reference**: `Expects()` is described in [GSL](#S-gsl). +##### Note -**Note**: Prefer a formal specification of requirements, such as `Expects(p!=nullptr);` If that is infeasible, use English text in comments, such as -`// the sequence [p:q) is ordered using <` +The standards library and the GSL are examples of this philosophy. +For example, instead of messing with the arrays, unions, cast, tricky lifetime issues, `gsl::owner`, etc., +that are needed to implement key abstractions, such as `vector`, `span`, `lock_guard`, and `future`, we use the libraries +designed and implemented by people with more time and expertise than we usually have. +Similarly, we can and should design and implement more specialized libraries, rather than leaving the users (often ourselves) +with the challenge of repeatedly getting low-level code well. +This is a variant of the [subset of superset principle](#R0) that underlies these guidelines. -**Note**: Most member functions have as a precondition that some class invariant holds. -That invariant is established by a constructor and must be reestablished upon exit by every member function called from outside the class. -We don't need to mention it for each member function. +##### Enforcement -**Enforcement**: (Not enforceable) +* Look for "messy code" such as complex pointer manipulation and casting outside the implementation of abstractions. -**See also**: the rules for passing pointers. +### P.12: Use supporting tools as appropriate - -### I.6: Prefer `Expects()` for expressing preconditions +##### Reason -**Reason**: To make it clear that the condition is a precondition and to enable tool use. +There are many things that are done better "by machine". +Computers don't tire or get bored by repetitive tasks. +We typically have better things to do than repeatedly do routine tasks. -**Example**: +##### Example - int area(int height, int width) - { - Expects(height>0 && width>0); // good - if (height<=0 || width<=0) my_error(); // obscure - // ... - } +Run a static analyzer to verify that your code follows the guidelines you want it to follow. -**Note**: Preconditions can be stated in many ways, including comments, `if`-statements, and `assert()`. This can make them hard to distinguish from ordinary code, hard to update, hard to manipulate by tools, and may have the wrong semantics (do you always want to abort in debug mode and check nothing in productions runs?). +##### Note -**Note**: Preconditions should be part of the interface rather than part of the implementation, but we don't yet have the language facilities to do that. +See -**Note**: `Expects()` can also be used to check a condition in the middle of an algorithm. +* [Static analysis tools](https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis) +* [Concurrency tools](#Rconc-tools) +* [Testing tools](https://github.com/isocpp/CppCoreGuidelines/tree/master) -**Enforcement**: (Not enforceable) Finding the variety of ways preconditions can be asserted is not feasible. Warning about those that can be easily identified (assert()) has questionable value in the absence of a language facility. +There are many other kinds of tools, such as source code repositories, build tools, etc., +but those are beyond the scope of these guidelines. +##### Note - -### I.7: State postconditions +Be careful not to become dependent on over-elaborate or over-specialized tool chains. +Those can make your otherwise portable code non-portable. -**Reason**: To detect misunderstandings about the result and possibly catch erroneous implementations. -**Example; bad**: Consider +### P.13: Use support libraries as appropriate - int area(int height, int width) { return height*width; } // bad +##### Reason -Here, we (incautiously) left out the precondition specification, so it is not explicit that height and width must be positive. -We also left out the postcondition specification, so it is not obvious that the algorithm (`height*width`) is wrong for areas larger than the largest integer. -Overflow can happen. -Consider using: +Using a well-designed, well-documented, and well-supported library saves time and effort; +its quality and documentation are likely to be greater than what you could do +if the majority of your time must be spent on an implementation. +The cost (time, effort, money, etc.) of a library can be shared over many users. +A widely used library is more likely to be kept up-to-date and ported to new systems than an individual application. +Knowledge of a widely-used library can save time on other/future projects. +So, if a suitable library exists for your application domain, use it. - int area(int height, int width) - { - auto res = height*width; - Ensures(res>0); - return res; - } +##### Example -**Example, bad**: Consider a famous security bug + std::sort(begin(v), end(v), std::greater<>()); - void f() // problematic - { - char buffer[MAX]; - // ... - memset(buffer,0,MAX); - } +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. +You need a reason not to use the standard library (or whatever foundational libraries your application uses) rather than a reason to use it. -There was no postcondition stating that the buffer should be cleared and the optimizer eliminated the apparently redundant `memset()` call: +##### Note - void f() // better - { - char buffer[MAX]; - // ... - memset(buffer,0,MAX); - Ensures(buffer[0]==0); - } +By default use -**Note** postconditions are often informally stated in a comment that states the purpose of a function; `Ensures()` can be used to make this more systematic, visible, and checkable. +* The [ISO C++ Standard Library](#sl-the-standard-library) +* The [Guidelines Support Library](#gsl-guidelines-support-library) -**Note**: Postconditions are especially important when they relate to something that is not directly reflected in a returned result, such as a state of a data structure used. +##### Note -**Example**: Consider a function that manipulates a `Record`, using a `mutex` to avoid race conditions: +If no well-designed, well-documented, and well-supported library exists for an important domain, +maybe you should design and implement it, and then use it. - mutex m; - void manipulate(Record& r) // don't - { - m.lock(); - // ... no m.unlock() ... - } +# I: Interfaces -Here, we "forgot" to state that the `mutex` should be released, so we don't know if the failure to ensure release of the `mutex` was a bug or a feature. Stating the postcondition would have made it clear: +An interface is a contract between two parts of a program. Precisely stating what is expected of a supplier of a service and a user of that service is essential. +Having good (easy-to-understand, encouraging efficient use, not error-prone, supporting testing, etc.) interfaces is probably the most important single aspect of code organization. - void manipulate(Record& r) // better: hold the mutex m while and only while manipulating r - { - m.lock(); - // ... no m.unlock() ... - } +Interface rule summary: -The bug is now obvious. +* [I.1: Make interfaces explicit](#Ri-explicit) +* [I.2: Avoid non-`const` global variables](#Ri-global) +* [I.3: Avoid singletons](#Ri-singleton) +* [I.4: Make interfaces precisely and strongly typed](#Ri-typed) +* [I.5: State preconditions (if any)](#Ri-pre) +* [I.6: Prefer `Expects()` for expressing preconditions](#Ri-expects) +* [I.7: State postconditions](#Ri-post) +* [I.8: Prefer `Ensures()` for expressing postconditions](#Ri-ensures) +* [I.9: If an interface is a template, document its parameters using concepts](#Ri-concepts) +* [I.10: Use exceptions to signal a failure to perform a required task](#Ri-except) +* [I.11: Never transfer ownership by a raw pointer (`T*`) or reference (`T&`)](#Ri-raw) +* [I.12: Declare a pointer that must not be null as `not_null`](#Ri-nullptr) +* [I.13: Do not pass an array as a single pointer](#Ri-array) +* [I.22: Avoid complex initialization of global objects](#Ri-global-init) +* [I.23: Keep the number of function arguments low](#Ri-nargs) +* [I.24: Avoid adjacent parameters that can be invoked by the same arguments in either order with different meaning](#Ri-unrelated) +* [I.25: Prefer empty abstract classes as interfaces to class hierarchies](#Ri-abstract) +* [I.26: If you want a cross-compiler ABI, use a C-style subset](#Ri-abi) +* [I.27: For stable library ABI, consider the Pimpl idiom](#Ri-pimpl) +* [I.30: Encapsulate rule violations](#Ri-encapsulate) -Better still, use [RAII](#Rr-raii) to ensure that the postcondition ("the lock must be released") is enforced in code: +**See also**: - void manipulate(Record& r) // best - { - lock_guard _ {m}; - // ... - } - -**Note**: Ideally, postconditions are stated in the interface/declaration so that users can easily see them. -Only postconditions related to the users can be stated in the interface. -Postconditions related only to internal state belongs in the definition/implementation. +* [F: Functions](#S-functions) +* [C.concrete: Concrete types](#SS-concrete) +* [C.hier: Class hierarchies](#SS-hier) +* [C.over: Overloading and overloaded operators](#SS-overload) +* [C.con: Containers and other resource handles](#SS-containers) +* [E: Error handling](#S-errors) +* [T: Templates and generic programming](#S-templates) -**Enforcement**: (Not enforceable) This is a philosophical guideline that is infeasible to check directly. +### I.1: Make interfaces explicit +##### Reason - -### I.8: Prefer `Ensures()` for expressing postconditions +Correctness. Assumptions not stated in an interface are easily overlooked and hard to test. -**Reason**: To make it clear that the condition is a postcondition and to enable tool use. +##### Example, bad -**Example**: +Controlling the behavior of a function through a global (namespace scope) variable (a call mode) is implicit and potentially confusing. For example: - void f() - { - char buffer[MAX]; - // ... - memset(buffer,0,MAX); - Ensures(buffer[0]==0); - } + int round(double d) + { + return (round_up) ? ceil(d) : d; // don't: "invisible" dependency + } -**Note**: postconditions can be stated in many ways, including comments, `if`-statements, and `assert()`. This can make them hard to distinguish from ordinary code, hard to update, hard to manipulate by tools, and may have the wrong semantics. +It will not be obvious to a caller that the meaning of two calls of `round(7.2)` might give different results. -**Alternative**: Postconditions of the form "this resource must be released" are best expressed by [RAII](#Rr-raii). +##### Exception -Ideally, that `Ensured` should be part of the interface that's not easily done. For now, we place it in the definition (function body). +Sometimes we control the details of a set of operations by an environment variable, e.g., normal vs. verbose output or debug vs. optimized. +The use of a non-local control is potentially confusing, but controls only implementation details of otherwise fixed semantics. -**Enforcement**: (Not enforceable) Finding the variety of ways postconditions can be asserted is not feasible. Warning about those that can be easily identified (assert()) has questionable value in the absence of a language facility. +##### Example, bad +Reporting through non-local variables (e.g., `errno`) is easily ignored. For example: - -### I.9: If an interface is a template, document its parameters using concepts + // don't: no test of fprintf's return value + fprintf(connection, "logging: %d %d %d\n", x, y, s); -**Reason**: Make the interface precisely specified and compile-time checkable in the (not so distant) future. +What if the connection goes down so that no logging output is produced? See I.???. -**Example**: Use the ISO Concepts TS style of requirements specification. For example: +**Alternative**: Throw an exception. An exception cannot be ignored. - template - // requires InputIterator && EqualityComparable>,Val> - Iter find(Iter first, Iter last, Val v) - { - // ... - } +**Alternative formulation**: Avoid passing information across an interface through non-local or implicit state. +Note that non-`const` member functions pass information to other member functions through their object's state. -**Note**: Soon (maybe in 2016), most compilers will be able to check `requires` clauses once the `//` is removed. +**Alternative formulation**: An interface should be a function or a set of functions. +Functions can be function templates and sets of functions can be classes or class templates. -**See also**: See [generic programming](???) and [???](???) +##### Enforcement -**Enforcement**: (Not enforceable yet) A language facility is under specification. When the language facility is available, warn if any non-variadic template parameter is not constrained by a concept (in its declaration or mentioned in a `requires` clause. +* (Simple) A function should not make control-flow decisions based on the values of variables declared at namespace scope. +* (Simple) A function should not write to variables declared at namespace scope. +### I.2: Avoid non-`const` global variables - -### I.10: Use exceptions to signal a failure to perform an required task +##### Reason -**Reason**: It should not be possible to ignore an error because that could leave the system or a computation in an undefined (or unexpected) state. -This is a major source of errors. +Non-`const` global variables hide dependencies and make the dependencies subject to unpredictable changes. -**Example**: +##### Example - int printf(const char* ...); // bad: return negative number if output fails + struct Data { + // ... lots of stuff ... + } data; // non-const data - template - explicit thread(F&& f, Args&&... args); // good: throw system_error if unable to start the new thread + void compute() // don't + { + // ... use data ... + } - -**Note**: What is an error? -An error means that the function cannot achieve its advertised purpose (including establishing postconditions). -Calling code that ignores the error could lead to wrong results or undefined systems state. -For example, not being able to connect to a remote server is not by itself an error: -the server can refuse a connection for all kinds of reasons, so the natural thing is to return a result that the caller always has to check. -However, if failing to make a connection is considered an error, then a failure should throw an exception. + void output() // don't + { + // ... use data ... + } -**Exception**: Many traditional interface functions (e.g., UNIX signal handlers) use error codes (e.g., `errno`) to report what are really status codes, rather than errors. You don't have good alternative to using such, so calling these does not violate the rule. +Who else might modify `data`? -**Alternative**: If you can't use exceptions (e.g. because your code is full of old-style raw-pointer use or because there are hard-real-time constraints), -consider using a style that returns a pair of values: +**Warning**: The initialization of global objects is not totally ordered. +If you use a global object initialize it with a constant. +Note that it is possible to get undefined initialization order even for `const` objects. - int val; - int error_code; - tie(val,error_code) = do_something(); - if (error_code==0) { - // ... handle the error or exit ... - } - // ... use val ... +##### Exception -**Note**: We don't consider "performance" a valid reason not to use exceptions. +A global object is often better than a singleton. -* Often, explicit error checking and handling consume as much time and space as exception handling. -* Often, cleaner code yield better performance with exceptions (simplifying the tracing of paths through the program and their optimization). -* A good rule for performance critical code is to move checking outside the critical part of the code ([checking](#Rper-checking)). -* In the longer term, more regular code gets better optimized. +##### Note -**See also**: Rule I.??? and I.??? for reporting precondition and postcondition violations. +Global constants are useful. -**Enforcement**: +##### Note -* (Not enforceable) This is a philosophical guideline that is infeasible to check directly. -* look for `errno`. +The rule against global variables applies to namespace scope variables as well. +**Alternative**: If you use global (more generally namespace scope) data to avoid copying, consider passing the data as an object by reference to `const`. +Another solution is to define the data as the state of some object and the operations as member functions. - -### I.11: Never transfer ownership by a raw pointer (`T*`) +**Warning**: Beware of data races: If one thread can access non-local data (or data passed by reference) while another thread executes the callee, we can have a data race. +Every pointer or reference to mutable data is a potential data race. -**Reason**: if there is any doubt whether the caller or the callee owns an object, leaks or premature destruction will occur. +Using global pointers or references to access and change non-const, and otherwise non-global, +data isn't a better alternative to non-const global variables since that doesn't solve the issues of hidden dependencies or potential race conditions. -**Example**: Consider +##### Note - X* compute(args) // don't - { - X* res = new X{}; - // ... - return res; - } +You cannot have a race condition on immutable data. -Who deletes the returned `X`? The problem would be harder to spot if compute returned a reference. -Consider returning the result by value (use move semantics if the result is large): +**References**: See the [rules for calling functions](#SS-call). - vector compute(args) // good - { - vector res(10000); - // ... - return res; - } +##### Note -**Alternative**: Pass ownership using a "smart pointer", such as `unique_ptr` (for exclusive ownership) and `shared_ptr` (for shared ownership). -However that is less elegant and less efficient unless reference semantics are needed. +The rule is "avoid", not "don't use." Of course there will be (rare) exceptions, such as `cin`, `cout`, and `cerr`. -**Alternative**: Sometimes older code can't be modified because of ABI compatibility requirements or lack of resources. -In that case, mark owning pointers using `owner` : +##### Enforcement - owner compute(args) // It is now clear that ownership is transferred - { - owner res = new X{}; - // ... - return res; - } +(Simple) Report all non-`const` variables declared at namespace scope and global pointers/references to non-const data. -This tells analysis tools that `res` is an owner. -That is, its value must be `delete`d or transferred to another owner, as is done here by the `return`. -`owner` is used similarly in the implementation of resource handles. +### I.3: Avoid singletons -`owner` is defined in the [Guideline Support Library](#S-gsl). +##### Reason -**Note**: Every object passed as a raw pointer (or iterator) is assumed to be owned by the caller, so that its lifetime is handled by the caller. +Singletons are basically complicated global objects in disguise. -**See also**: [Argument passing](#Rf-conventional) and [value return](#Rf-T-return). +##### Example -**Enforcement**: + class Singleton { + // ... lots of stuff to ensure that only one Singleton object is created, + // that it is initialized properly, etc. + }; -* (Simple) Warn on `delete` of a raw pointer that is not an `owner`. -* (Simple) Warn on failure to either `reset` or explicitly `delete` an `owner` pointer on every code path. -* (Simple) Warn if the return value of `new` or a function call with return value of pointer type is assigned to a raw pointer. +There are many variants of the singleton idea. +That's part of the problem. +##### Note - -### I.12: Declare a pointer that must not be null as `not_null` +If you don't want a global object to change, declare it `const` or `constexpr`. -**Reason**: To help avoid dereferencing `nullptr` errors. To improve performance by avoiding redundant checks for `nullptr`. +##### Exception -**Example**: +You can use the simplest "singleton" (so simple that it is often not considered a singleton) to get initialization on first use, if any: - int length(const char* p); // it is not clear whether strlen(nullptr) is valid + X& myX() + { + static X my_x {3}; + return my_x; + } - length(nullptr); // OK? +This is one of the most effective solutions to problems related to initialization order. +In a multi-threaded environment, the initialization of the static object does not introduce a race condition +(unless you carelessly access a shared object from within its constructor). - int length(not_null p); // better: we can assume that p cannot be nullptr +Note that the initialization of a local `static` does not imply a race condition. +However, if the destruction of `X` involves an operation that needs to be synchronized we must use a less simple solution. +For example: - int length(const char* p); // we must assume that p can be nullptr + X& myX() + { + static auto p = new X {3}; + return *p; // potential leak + } -By stating the intent in source, implementers and tools can provide better diagnostics, such as finding some classes of errors through static analysis, and perform optimizations, such as removing branches and null tests. +Now someone must `delete` that object in some suitably thread-safe way. +That's error-prone, so we don't use that technique unless -**Note**: The assumption that the pointer to `char` pointed to a C-style string (a zero-terminated string of characters) was still implicit, and a potential source of confusion and errors. Use `zstring` in preference to `const char*`. +* `myX` is in multi-threaded code, +* that `X` object needs to be destroyed (e.g., because it releases a resource), and +* `X`'s destructor's code needs to be synchronized. - int length(not_null p); // we can assume that p cannot be nullptr - // we can assume that p points to a zero-terminated array of characters +If you, as many do, define a singleton as a class for which only one object is created, functions like `myX` are not singletons, and this useful technique is not an exception to the no-singleton rule. -Note: `length()` is, of course, `std::strlen()` in disguise. +##### Enforcement -**Enforcement**: +Very hard in general. -* (Simple) ((Foundation)) If a function checks a pointer parameter against `nullptr` before access, on all control-flow paths, then warn it should be declared `not_null`. -* (Complex) If a function with pointer return value ensures it is not `nullptr` on all return paths, then warn the return type should be declared `not_null`. +* Look for classes with names that include `singleton`. +* Look for classes for which only a single object is created (by counting objects or by examining constructors). +* If a class X has a public static function that contains a function-local static of the class' type X and returns a pointer or reference to it, ban that. +### I.4: Make interfaces precisely and strongly typed - -### I.13: Do not pass an array as a single pointer +##### Reason -**Reason**: (pointer,size)-style interfaces are error-prone. Also, plain pointer (to array) must relies on some convention to allow the callee to determine the size. +Types are the simplest and best documentation, improve legibility due to their well-defined meaning, and are checked at compile time. +Also, precisely typed code is often optimized better. -**Example**: Consider +##### Example, don't - void copy_n(const T* p, T* q, int n); // copy from [p:p+n) to [q:q+n) +Consider: -What if there are fewer than `n` elements in the array pointed to by `q`? Then, we overwrite some probably unrelated memory. -What if there are fewer than `n` elements in the array pointed to by `p`? Then, we read some probably unrelated memory. -Either is undefined behavior and a potentially very nasty bug. + void pass(void* data); // weak and under qualified type void* is suspicious -**Alternative**: Consider using explicit ranges, +Callers are unsure what types are allowed and if the data may +be mutated as `const` is not specified. Note all pointer types +implicitly convert to `void*`, so it is easy for callers to provide this value. - void copy(array_view r, array_view r2); // copy r to r2 +The callee must `static_cast` data to an unverified type to use it. +That is error-prone and verbose. -**Example, bad**: Consider +Only use `const void*` for passing in data in designs that are indescribable in C++. Consider using a `variant` or a pointer to base instead. - void draw(Shape* p, int n); // poor interface; poor code - Circle arr[10]; - // ... - draw(arr,10); +**Alternative**: Often, a template parameter can eliminate the `void*` turning it into a `T*` or `T&`. +For generic code these `T`s can be general or concept constrained template parameters. -Passing `10` as the `n` argument may be a mistake: the most common convention is to assume [`0`:`n`) but that is nowhere stated. Worse is that the call of `draw()` compiled at all: there was an implicit conversion from array to pointer (array decay) and then another implicit conversion from `Circle` to `Shape`. There is no way that `draw()` can safely iterate through that array: it has no way of knowing the size of the elements. +##### Example, bad -**Alternative**: Use a support class that ensures that the number of elements is correct and prevents dangerous implicit conversions. For example: +Consider: - void draw2(array_view); - Circle arr[10]; - // ... - draw2(array_view(arr)); // deduce the number of elements - draw2(arr); // deduce the element type and array size + draw_rect(100, 200, 100, 500); // what do the numbers specify? - void draw3(array_view); - draw3(arr); // error: cannot convert Circle[10] to array_view + draw_rect(p.x, p.y, 10, 20); // what units are 10 and 20 in? -This `draw2()` passes the same amount of information to `draw()`, but makes the fact that it is supposed to be a range of `Circle`s explicit. See ???. +It is clear that the caller is describing a rectangle, but it is unclear what parts they relate to. Also, an `int` can carry arbitrary forms of information, including values of many units, so we must guess about the meaning of the four `int`s. Most likely, the first two are an `x`,`y` coordinate pair, but what are the last two? -**Exception**: Use `zstring` and `czstring` to represent a C-style, zero-terminated strings. But see ???. +Comments and parameter names can help, but we could be explicit: -**Enforcement**: + void draw_rectangle(Point top_left, Point bottom_right); + void draw_rectangle(Point top_left, Size height_width); -* (Simple) ((Bounds)) Warn for any expression that would rely on implicit conversion of an array type to a pointer type. Allow exception for zstring/czstring pointer types. -* (Simple) ((Bounds)) Warn for any arithmetic operation on an expression of pointer type that results in a value of pointer type. Allow exception for zstring/czstring pointer types. + draw_rectangle(p, Point{10, 20}); // two corners + draw_rectangle(p, Size{10, 20}); // one corner and a (height, width) pair +Obviously, we cannot catch all errors through the static type system +(e.g., the fact that a first argument is supposed to be a top-left point is left to convention (naming and comments)). - -### I.14: Keep the number of function arguments low +##### Example, bad -**Reason**: Having many arguments opens opportunities for confusion. Passing lots of arguments is often costly compared to alternatives. +Consider: -**Example**: The standard-library `merge()` is at the limit of what we can comfortably handle + set_settings(true, false, 42); // what do the numbers specify? - template - OutputIterator merge(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result, Compare comp); +The parameter types and their values do not communicate what settings are being specified or what those values mean. -Here, we have four template arguments and six function arguments. -To simplify the most frequent and simplest uses, the comparison argument can be defaulted to `<`: +This design is more explicit, safe and legible: - template - OutputIterator merge(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result); + alarm_settings s{}; + s.enabled = true; + s.displayMode = alarm_settings::mode::spinning_light; + s.frequency = alarm_settings::every_10_seconds; + set_settings(s); -This doesn't reduce the total complexity, but it reduces the surface complexity presented to many users. -To really reduce the number of arguments, we need to bundle the arguments into higher-level abstractions: +For the case of a set of boolean values consider using a flags `enum`; a pattern that expresses a set of boolean values. - template - OutputIterator merge(InputRange1 r1, InputRange2 r2, OutputIterator result); + enable_lamp_options(lamp_option::on | lamp_option::animate_state_transitions); -Grouping arguments into "bundles" is a general technique to reduce the number of arguments and to increase the opportunities for checking. +##### Example, bad -**Note**: How many arguments are too many? Four arguments is a lot. -There are functions that are best expressed with four individual arguments, but not many. +In the following example, it is not clear from the interface what `time_to_blink` means: Seconds? Milliseconds? -**Alternative**: Group arguments into meaningful objects and pass the objects (by value or by reference). + void blink_led(int time_to_blink) // bad -- the unit is ambiguous + { + // ... + // do something with time_to_blink + // ... + } -**Alternative**: Use default arguments or overloads to allow the most common forms of calls to be done with fewer arguments. + void use() + { + blink_led(2); + } -**Enforcement**: - - Warn when a functions declares two iterators (including pointers) of the same type instead of a range or a view. - - (Not enforceable) This is a philosophical guideline that is infeasible to check directly. +##### Example, good +`std::chrono::duration` types helps making the unit of time duration explicit. - -### I.15: Avoid adjacent unrelated parameters of the same type + void blink_led(milliseconds time_to_blink) // good -- the unit is explicit + { + // ... + // do something with time_to_blink + // ... + } -**Reason**: Adjacent arguments of the same type are easily swapped by mistake. + void use() + { + blink_led(1500ms); + } -**Example; bad**: Consider +The function can also be written in such a way that it will accept any time duration unit. - void copy_n(T* p, T* q, int n); // copy from [p:p+n) to [q:q+n) + template + void blink_led(duration time_to_blink) // good -- accepts any unit + { + // assuming that millisecond is the smallest relevant unit + auto milliseconds_to_blink = duration_cast(time_to_blink); + // ... + // do something with milliseconds_to_blink + // ... + } -This is a nasty variant of a K&R C-style interface. It is easy to reverse the "to" and "from" arguments. + void use() + { + blink_led(2s); + blink_led(1500ms); + } -Use `const` for the "from" argument: +##### Enforcement - void copy_n(const T* p, T* q, int n); // copy from [p:p+n) to [q:q+n) +* (Simple) Report the use of `void*` as a parameter or return type. +* (Simple) Report the use of more than one `bool` parameter. +* (Hard to do well) Look for functions that use too many primitive type arguments. -**Alternative**: Don't pass arrays as pointers, pass an object representing a range (e.g., an `array_view`): +### I.5: State preconditions (if any) - void copy_n(array_view p, array_view q); // copy from b to q +##### Reason -**Enforcement**: (Simple) Warn if two consecutive parameters share the same type. +Arguments have meaning that might constrain their proper use in the callee. +##### Example - -### I.16: Prefer abstract classes as interfaces to class hierarchies +Consider: -**Reason**: Abstract classes are more likely to be stable than base classes with state. + double sqrt(double x); -**Example; bad**: You just knew that `Shape` would turn up somewhere :-) +Here `x` must be non-negative. The type system cannot (easily and naturally) express that, so we must use other means. For example: - class Shape { // bad: interface class loaded with data - public: - Point center() { return c; } - virtual void draw(); - virtual void rotate(int); - // ... - private: - Point c; - vector outline; - Color col; - }; + double sqrt(double x); // x must be non-negative -This will force every derived class to compute a center -- even if that's non-trivial and the center is never used. Similarly, not every `Shape` has a `Color`, and many `Shape`s are best represented without an outline defined as a sequence of `Point`s. Abstract classes were invented to discourage users from writing such classes: +Some preconditions can be expressed as assertions. For example: - class Shape { // better: Shape is a pure interface - public: - virtual Point center() =0; // pure virtual function - virtual void draw() =0; - virtual void rotate(int) =0; - // ... - // ... no data members ... - }; + double sqrt(double x) { Expects(x >= 0); /* ... */ } -**Enforcement**: (Simple) Warn if a pointer to a class `C` is assigned to a pointer to a base of `C` and the base class contains data members. +Ideally, that `Expects(x >= 0)` should be part of the interface of `sqrt()` but that's not easily done. For now, we place it in the definition (function body). +**References**: `Expects()` is described in [GSL](#gsl-guidelines-support-library). - -### I.16: If you want a cross-compiler ABI, use a C-style subset +##### Note -**Reason**: Different compilers implement different binary layouts for classes, exception handling, function names, and other implementation details. +Prefer a formal specification of requirements, such as `Expects(p);`. +If that is infeasible, use English text in comments, such as `// the sequence [p:q) is ordered using <`. -**Exception**: You can carefully craft an interface using a few carefully selected higher-level C++ types. See ???. +##### Note -**Exception**: Common ABIs are emerging on some platforms freeing you from the more Draconian restrictions. +Most member functions have as a precondition that some class invariant holds. +That invariant is established by a constructor and must be reestablished upon exit by every member function called from outside the class. +We don't need to mention it for each member function. -**Note**: if you use a single compiler, you can use full C++ in interfaces. That may require recompilation after an upgrade to a new compiler version. +##### Enforcement -**Enforcement**: (Not enforceable) It is difficult to reliably identify where an interface forms part of an ABI. +(Not enforceable) +**See also**: The rules for passing pointers. ??? - -# F: Functions +### I.6: Prefer `Expects()` for expressing preconditions -A function specifies an action or a computation that takes the system from one consistent state to the next. It is the fundamental building block of programs. +##### Reason -It should be possible to name a function meaningfully, to specify the requirements of its argument, and clearly state the relationship between the arguments and the result. An implementation is not a specification. Try to think about what a function does as well as about how it does it. -Functions are the most critical part in most interfaces, so see the interface rules. +To make it clear that the condition is a precondition and to enable tool use. -Function rule summary: +##### Example -Function definition rules: + int area(int height, int width) + { + Expects(height > 0 && width > 0); // good + if (height <= 0 || width <= 0) my_error(); // obscure + // ... + } -* [F.1: "Package" meaningful operations as carefully named functions](#Rf-package) -* [F.2: A function should perform a single logical operation](#Rf-logical) -* [F.3: Keep functions short and simple](#Rf-single) -* [F.4: If a function may have to be evaluated at compile time, declare it `constexpr`](#Rf-constexpr) -* [F.5: If a function is very small and time critical, declare it inline](#Rf-inline) -* [F.6: If your function may not throw, declare it `noexcept`](#Rf-noexcept) -* [F.7: For general use, take `T*` arguments rather than a smart pointers](#Rf-smart) -* [F.8: Prefer pure functions](#Rf-pure) +##### Note -Argument passing rules: +Preconditions can be stated in many ways, including comments, `if`-statements, and `assert()`. +This can make them hard to distinguish from ordinary code, hard to update, hard to manipulate by tools, and might have the wrong semantics (do you always want to abort in debug mode and check nothing in productions runs?). -* [F.15: Prefer simple and conventional ways of passing information](#Rf-conventional) -* [F.16: Use `T*` or `owner` or a smart pointer to designate a single object](#Rf-ptr) -* [F.17: Use a `not_null` to indicate "null" is not a valid value](#Rf-nullptr) -* [F.18: Use an `array_view` or an `array_view_p` to designate a half-open sequence](#Rf-range) -* [F.19: Use a `zstring` or a `not_null` to designate a C-style string](#Rf-string) -* [F.20: Use a `const T&` parameter for a large object](#Rf-const-T-ref) -* [F.21: Use a `T` parameter for a small object](#Rf-T) -* [F.22: Use `T&` for an in-out-parameter](#Rf-T-re) -* [F.23: Use `T&` for an out-parameter that is expensive to move (only)](#Rf-T-return-out) -* [F.24: Use a `TP&&` parameter when forwarding (only)](#Rf-pass-ref-ref) -* [F.25: Use a `T&&` parameter together with `move` for rare optimization opportunities](#Rf-pass-ref-move) -* [F.26: Use a `unique_ptr` to transfer ownership where a pointer is needed](#Rf-unique_ptr) -* [F.27: Use a `shared_ptr` to share ownership](#Rf-shared_ptr) +##### Note -Value return rules: +Preconditions should be part of the interface rather than part of the implementation, +but we don't yet have the language facilities to do that. +Once language support becomes available (e.g., see the [contract proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf)) we will adopt the standard version of preconditions, postconditions, and assertions. -* [F.40: Prefer return values to out-parameters](#Rf-T-return) -* [F.41: Prefer to return tuples to multiple out-parameters](#Rf-T-multi) -* [F.42: Return a `T*` to indicate a position (only)](#Rf-return-ptr) -* [F.43: Never (directly or indirectly) return a pointer to a local object](#Rf-dangle) -* [F.44: Return a `T&` when "returning no object" isn't an option](#Rf-return-ref) -* [F.45: Don't return a `T&&`](#Rf-return-ref-ref) +##### Note -Other function rules: +`Expects()` can also be used to check a condition in the middle of an algorithm. -* [F.50: Use a lambda when a function won't do (to capture local variables, or to write a local function)](#Rf-capture-vs-overload) -* [F.51: Prefer overloading over default arguments for virtual functions](#Rf-default-arg) -* [F.52: Prefer capturing by reference in lambdas that will be used locally, including passed to algorithms](#Rf-reference-capture) -* [F.53: Avoid capturing by reference in lambdas that will be used nonlocally, including returned, stored on the heap, or passed to another thread](#Rf-value-capture) +##### Note -Functions have strong similarities to lambdas and function objects so see also Section ???. +No, using `unsigned` is not a good way to sidestep the problem of [ensuring that a value is non-negative](#Res-nonnegative). +##### Enforcement - -## F.def: Function definitions +(Not enforceable) Finding the variety of ways preconditions can be asserted is not feasible. Warning about those that can be easily identified (`assert()`) has questionable value in the absence of a language facility. -A function definition is a function declaration that also specifies the function's implementation, the function body. +### I.7: State postconditions +##### Reason - -### F.1: "Package" meaningful operations as carefully named functions +To detect misunderstandings about the result and possibly catch erroneous implementations. -**Reason**: Factoring out common code makes code more readable, more likely to be reused, and limit errors from complex code. -If something is a well-specified action, separate it out from its surrounding code and give it a name. +##### Example, bad -**Example, don't**: +Consider: - void read_and_print(istream& is) // read and print an int - { - int x; - if (is>>x) - cout << "the int is " << x << '\n'; - else - cerr << "no int on input\n"; - } - -Almost everything is wrong with `read_and_print`. -It reads, it writes (to a fixed `ostream`), it write error messages (to a fixed `ostream`), it handles only `int`s. -There is nothing to reuse, logically separate operations are intermingled and local variables are in scope after the end of their logical use. -For a tiny example, this looks OK, but if the input operation, the output operation, and the error handling had been more complicated the tangled -mess could become hard to understand. + int area(int height, int width) { return height * width; } // bad -**Note**: If you write a non-trivial lambda that potentially can be used in more than one place, -give it a name by assigning it to a (usually non-local) variable. +Here, we (incautiously) left out the precondition specification, so it is not explicit that height and width must be positive. +We also left out the postcondition specification, so it is not obvious that the algorithm (`height * width`) is wrong for areas larger than the largest integer. +Overflow can happen. +Consider using: -**Example**: + int area(int height, int width) + { + auto res = height * width; + Ensures(res > 0); + return res; + } - sort(a, b, [](T x, T y) { return x.valid() && y.valid() && x.value() -### F.2: A function should perform a single logical operation +Postconditions are especially important when they relate to something that is not directly reflected in a returned result, such as a state of a data structure used. -**Reason**: A function that performs a single operation is simpler to understand, test, and reuse. +##### Example -**Example**: Consider +Consider a function that manipulates a `Record`, using a `mutex` to avoid race conditions: - void read_and_print() // bad - { - int x; - cin >> x; - // check for errors - cout << x << "\n"; - } + mutex m; -This is a monolith that is tied to a specific input and will never find a another (different) use. Instead, break functions up into suitable logical parts and parameterize: + void manipulate(Record& r) // don't + { + m.lock(); + // ... no m.unlock() ... + } - int read(istream& is) // better - { - int x; - is >> x; - // check for errors - return x; - } +Here, we "forgot" to state that the `mutex` should be released, so we don't know if the failure to ensure release of the `mutex` was a bug or a feature. +Stating the postcondition would have made it clear: - void print(ostream& os, int x) - { - os << x << "\n"; - } + void manipulate(Record& r) // postcondition: m is unlocked upon exit + { + m.lock(); + // ... no m.unlock() ... + } -These can now be combined where needed: +The bug is now obvious (but only to a human reading comments). - void read_and_print() - { - auto x = read(cin); - print(cout, x); - } +Better still, use [RAII](#Rr-raii) to ensure that the postcondition ("the lock must be released") is enforced in code: -If there was a need, we could further templatize `read()` and `print()` on the data type, the I/O mechanism, etc. Example: + void manipulate(Record& r) // best + { + lock_guard _ {m}; + // ... + } - auto read = [](auto& input, auto& value) // better - { - input >> value; - // check for errors - } +##### Note - auto print(auto& output, const auto& value) - { - output << value << "\n"; - } +Ideally, postconditions are stated in the interface/declaration so that users can easily see them. +Only postconditions related to the users can be stated in the interface. +Postconditions related only to internal state belongs in the definition/implementation. -**Enforcement**: +##### Enforcement -* Consider functions with more than one "out" parameter suspicious. Use return values instead, including `tuple` for multiple return values. -* Consider "large" functions that don't fit on one editor screen suspicious. Consider factoring such a function into smaller well-named suboperations. -* Consider functions with 7 or more parameters suspicious. +(Not enforceable) This is a philosophical guideline that is infeasible to check +directly in the general case. Domain specific checkers (like lock-holding +checkers) exist for many toolchains. +### I.8: Prefer `Ensures()` for expressing postconditions - -### F.3: Keep functions short and simple +##### Reason -**Reason**: Large functions are hard to read, more likely to contain complex code, and more likely to have variables in larger than minimal scopes. -Functions with complex control structures are more likely to be long and more likely to hide logical errors +To make it clear that the condition is a postcondition and to enable tool use. -**Example**: Consider - - double simpleFunc(double val, int flag1, int flag2) - // simpleFunc: takes a value and calculates the expected ASIC output, given the two mode flags. - { - double intermediate; - if (flag1 > 0) { - intermediate = func1(val); - if (flag2 % 2) - intermediate = sqrt(intermediate); - } - else if (flag1 == -1) { - intermediate = func1(-val); - if (flag2 % 2) - intermediate = sqrt(-intermediate); - flag1 = -flag1; - } - if (abs(flag2) > 10) { - intermediate = func2(intermediate); - } - switch (flag2 / 10) { - case 1: if (flag1 == -1) return finalize(intermediate, 1.171); break; - case 2: return finalize(intermediate, 13.1); - default: ; - } - return finalize(intermediate, 0.); - } - -This is too complex (and also pretty long). -How would you know if all possible alternatives have been correctly handled? -Yes, it break other rules also. +##### Example -We can refactor: + void f() + { + char buffer[MAX]; + // ... + memset(buffer, 0, MAX); + Ensures(buffer[0] == 0); + } - double func1_muon(double val, int flag) - { - // ??? - } - - double funct1_tau(double val, int flag1, int flag2) - { - // ??? - } - - double simpleFunc(double val, int flag1, int flag2) - // simpleFunc: takes a value and calculates the expected ASIC output, given the two mode flags. - { - if (flag1 > 0) - return func1_muon(val, flag2); - if (flag1 == -1) - return func1_tau(-val, flag1, flag2); // handled by func1_tau: flag1 = -flag1; - return 0.; - } - -**Note**: "It doesn't fit on a screen" is often a good practical definition of "far too large." -One-to-five-line functions should be considered normal. +##### Note -**Note**: Break large functions up into smaller cohesive and named functions. -Small simple functions are easily inlined where the cost of a function call is significant. +Postconditions can be stated in many ways, including comments, `if`-statements, and `assert()`. +This can make them hard to distinguish from ordinary code, hard to update, hard to manipulate by tools, and might have the wrong semantics. -**Enforcement**: +**Alternative**: Postconditions of the form "this resource must be released" are best expressed by [RAII](#Rr-raii). -* Flag functions that do not "fit on a screen." -How big is a screen? Try 60 lines by 140 characters; that's roughly the maximum that's comfortable for a book page. -* Flag functions that are too complex. How complex is too complex? -You could use cyclomatic complexity. Try "more that 10 logical path through." Count a simple switch as one path. +##### Note +Ideally, that `Ensures` should be part of the interface, but that's not easily done. +For now, we place it in the definition (function body). +Once language support becomes available (e.g., see the [contract proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf)) we will adopt the standard version of preconditions, postconditions, and assertions. - -### F.4: If a function may have to be evaluated at compile time, declare it `constexpr` +##### Enforcement -**Reason**: `constexpr` is needed to tell the compiler to allow compile-time evaluation. +(Not enforceable) Finding the variety of ways postconditions can be asserted is not feasible. Warning about those that can be easily identified (`assert()`) has questionable value in the absence of a language facility. -**Example**: The (in)famous factorial: +### I.9: If an interface is a template, document its parameters using concepts - constexpr int fac(int n) - { - constexpr int max_exp = 17; // constexpr enables this to be used in Expects - Expects(0<=x && x -### F.5: If a function is very small and time critical, declare it `inline` + template + requires input_iterator && equality_comparable_with, Val> + Iter find(Iter first, Iter last, Val v) + { + // ... + } -**Reason**: Some optimizers are good an inlining without hints from the programmer, but don't rely on it. -Measure! Over the last 40 years or so, we have been promised compilers that can inline better than humans without hints from humans. -We are still waiting. -Specifying `inline` encourages the compiler to do a better job. +**See also**: [Generic programming](#SS-GP) and [concepts](#SS-concepts). -**Exception**: Do not put an `inline` function in what is meant to be a stable interface unless you are really sure that it will not change. -An inline function is part of the ABI. +##### Enforcement -**Note**: `constexpr` implies `inline`. +Warn if any non-variadic template parameter is not constrained by a concept (in its declaration or mentioned in a `requires` clause). -**Note**: Member functions defined in-class are `inline` by default. +### I.10: Use exceptions to signal a failure to perform a required task -**Exception**: Template functions (incl. template member functions) must be in headers and therefore inline. +##### Reason -**Enforcement**: Flag `inline` functions that are more than three statements and could have been declared out of line (such as class member functions). -To fix: Declare the function out of line. [[NM: Certainly possible, but size-based metrics can be very annoying.]] +It should not be possible to ignore an error because that could leave the system or a computation in an undefined (or unexpected) state. +This is a major source of errors. +##### Example - -### F.6: If your function may not throw, declare it `noexcept` + int printf(const char* ...); // bad: return negative number if output fails -**Reason**: If an exception is not supposed to be thrown, the program cannot be assumed to cope with the error and should be terminated as soon as possible. Declaring a function `noexcept` helps optimizers by reducing the number of alternative execution paths. It also speeds up the exit after failure. + template + // good: throw system_error if unable to start the new thread + explicit thread(F&& f, Args&&... args); -**Example**: Put `noexcept` on every function written completely in C or in any other language without exceptions. -The C++ standard library does that implicitly for all functions in the C standard library. +##### Note -**Note**: `constexpr` functions cannot throw, so you don't need to use `noexcept` for those. +What is an error? -**Example**: You can use `noexcept` even on functions that can throw: +An error means that the function cannot achieve its advertised purpose (including establishing postconditions). +Calling code that ignores an error could lead to wrong results or undefined systems state. +For example, not being able to connect to a remote server is not by itself an error: +the server can refuse a connection for all kinds of reasons, so the natural thing is to return a result that the caller should always check. +However, if failing to make a connection is considered an error, then a failure should throw an exception. - vector collect(istream& is) noexcept - { - vector res; - for(string s; is>>s; ) - res.push_back(s); - return res; - } +##### Exception -If `collect()` runs out of memory, the program crashes. -Unless the program is crafted to survive memory exhaustion, that may be just the right thing to do; -`terminate()` may generate suitable error log information (but after memory runs out it is hard to do anything clever). +Many traditional interface functions (e.g., UNIX signal handlers) use error codes (e.g., `errno`) to report what are really status codes, rather than errors. You don't have a good alternative to using such, so calling these does not violate the rule. -**Note**: In most programs, most functions can throw -(e.g., because they use `new`, call functions that do, or use library functions that reports failure by throwing), -so don't just springle `noexcept` all over the place. -`noexcept` is most useful for frequently used, low-level functions. +##### Alternative -**Note**: Destructors, `swap` functions, move operations, and default constructors should never throw. +If you can't use exceptions (e.g., because your code is full of old-style raw-pointer use or because there are hard-real-time constraints), consider using a style that returns a pair of values: + int val; + int error_code; + tie(val, error_code) = do_something(); + if (error_code) { + // ... handle the error or exit ... + } + // ... use val ... -**Enforcement**: +This style unfortunately leads to uninitialized variables. +Since C++17 the "structured bindings" feature can be used to initialize variables directly from the return value: -* Flag functions that are not `noexcept`, yet cannot throw -* Flag throwing `swap`, `move`, destructors, and default constructors. + auto [val, error_code] = do_something(); + if (error_code) { + // ... handle the error or exit ... + } + // ... use val ... +##### Note - -### F.7: For general use, take `T*` arguments rather than a smart pointers +We don't consider "performance" a valid reason not to use exceptions. -**Reason**: Passing a smart pointer transfers or shares ownership. -Passing by smart pointer restricts the use of a function to callers that use smart pointers. -Passing a shared smart pointer (e.g., `std::shared_ptr`) implies a run-time cost. +* Often, explicit error checking and handling consume as much time and space as exception handling. +* Often, cleaner code yields better performance with exceptions (simplifying the tracing of paths through the program and their optimization). +* A good rule for performance critical code is to move checking outside the [critical](#Rper-critical) part of the code. +* In the longer term, more regular code gets better optimized. +* Always carefully [measure](#Rper-measure) before making performance claims. -**Example**: +**See also**: [I.5](#Ri-pre) and [I.7](#Ri-post) for reporting precondition and postcondition violations. - void f(int*); // accepts any int* - void g(unique_ptr); // can only accept ints for which you want to transfer ownership - void g(shared_ptr); // can only accept ints for which you are willing to share ownership +##### Enforcement -**Note**: We can catch dangling pointers statically, so we don't need to rely on resource management to avoid violations from dangling pointers. +* (Not enforceable) This is a philosophical guideline that is infeasible to check directly. +* Look for `errno`. -**See also**: Discussion of [smart pointer use](#Rr-summary-smartptrs). +### I.11: Never transfer ownership by a raw pointer (`T*`) or reference (`T&`) -**Enforcement**: Flag smart pointer arguments. +##### Reason +If there is any doubt whether the caller or the callee owns an object, leaks or premature destruction will occur. - -### F.8: Prefer pure functions +##### Example +Consider: -**Reason**: Pure functions are easier to reason about, sometimes easier to optimize (and even parallelize), and sometimes can be memoized. + X* compute(args) // don't + { + X* res = new X{}; + // ... + return res; + } -**Example**: +Who deletes the returned `X`? The problem would be harder to spot if `compute` returned a reference. +Consider returning the result by value (use move semantics if the result is large): - template - auto square(T t) { return t*t; } - -**Note**: `constexpr` functions are pure. - -**Enforcement**: not possible. + vector compute(args) // good + { + vector res(10000); + // ... + return res; + } +**Alternative**: [Pass ownership](#Rr-smartptrparam) using a "smart pointer", such as `unique_ptr` (for exclusive ownership) and `shared_ptr` (for shared ownership). +However, that is less elegant and often less efficient than returning the object itself, +so use smart pointers only if reference semantics are needed. - -## F.call: Argument passing +**Alternative**: Sometimes older code can't be modified because of ABI compatibility requirements or lack of resources. +In that case, mark owning pointers using `owner` from the [guidelines support library](#gsl-guidelines-support-library): -There are a variety of ways to pass arguments to a function and to return values. + owner compute(args) // It is now clear that ownership is transferred + { + owner res = new X{}; + // ... + return res; + } +This tells analysis tools that `res` is an owner. +That is, its value must be `delete`d or transferred to another owner, as is done here by the `return`. - -### Rule F.15: Prefer simple and conventional ways of passing information +`owner` is used similarly in the implementation of resource handles. -**Reason**: Using "unusual and clever" techniques causes surprises, slows understanding by other programmers, and encourages bugs. -If you really feel the need for an optimization beyond the common techniques, measure to ensure that it really is an improvement, -and document/comment because the improvement may not be portable. +##### Note -![Normal parameter passing table](./param-passing-normal.png "Normal parameter passing") +Every object passed as a raw pointer (or iterator) is assumed to be owned by the +caller, so that its lifetime is handled by the caller. Viewed another way: +ownership transferring APIs are relatively rare compared to pointer-passing APIs, +so the default is "no ownership transfer." -**For an "output-only" value:** Prefer return values to output parameters. -This includes large objects like standard containers that use implicit move operations for performance and to avoid explicit memory management. -If you have multiple values to return, [use a tuple](#Rf-T-multi) or similar multi-member type. +**See also**: [Argument passing](#Rf-conventional), [use of smart pointer arguments](#Rr-smartptrparam), and [value return](#Rf-value-return). -**Example**: +##### Enforcement - vector find_all(const vector&, int x); // return pointers to elements with the value x - -**Example, bad**: +* (Simple) Warn on `delete` of a raw pointer that is not an `owner`. Suggest use of standard-library resource handle or use of `owner`. +* (Simple) Warn on failure to either `reset` or explicitly `delete` an `owner` pointer on every code path. +* (Simple) Warn if the return value of `new` or a function call with an `owner` return value is assigned to a raw pointer or non-`owner` reference. - void find_all(const vector&, vector& out, int x); // place pointers to elements with value x in out +### I.12: Declare a pointer that must not be null as `not_null` -**Exceptions**: +##### Reason -* For non-value types, such as types in an inheritance hierarchy, return the object by `unique_ptr` or `shared_ptr`. -* If a type is expensive to move (e.g., `array`), consider allocating it on the free store and return a handle (e.g., `unique_ptr`), or passing it in a non-`const` reference to a target object to fill (to be used as an out-parameter). -* In the special case of allowing a caller to reuse an object that carries capacity (e.g., `std::string`, `std::vector`) across multiple calls to the function in an inner loop, treat it as an in/out parameter instead and pass by `&`. This one use of the more generally named "caller-allocated out" pattern. +To help avoid dereferencing `nullptr` errors. +To improve performance by avoiding redundant checks for `nullptr`. -**For an "in-out" parameter:** Pass by non-`const` reference. This makes it clear to callers that the object is assumed to be modified. +##### Example -**For an "input-only" value:** If the object is cheap to copy, pass by value. -Otherwise, pass by `const&`. It is useful to know that a function does not mutate an argument, and both allow initialization by rvalues. -What is "cheap to copy" depends on the machine architecture, but two or three words (doubles, pointers, references) are usually best passed by value. -In particular, an object passed by value does not require an extra reference to access from the function. + int length(const char* p); // it is not clear whether length(nullptr) is valid -![Advanced parameter passing table](./param-passing-advanced.png "Advanced parameter passing") + length(nullptr); // OK? -For advanced uses (only), where you really need to optimize for rvalues passed to "input-only" parameters: + int length(not_null p); // better: we can assume that p cannot be nullptr -* If the function is going to unconditionally move from the argument, take it by `&&`. -* If the function is going to keep a copy of the argument, in addition to passing by `const&` add an overload that passes the parameter by `&&` and in the body `std::move`s it to its destination. (See [F.25](#Rf-pass-ref-move).) -* In special cases, such as multiple "input + copy" parameters, consider using perfect forwarding. (See [F.24](#Rf-pass-ref-ref).) + int length(const char* p); // we must assume that p can be nullptr -**Example**: +By stating the intent in source, implementers and tools can provide better diagnostics, such as finding some classes of errors through static analysis, and perform optimizations, such as removing branches and null tests. - int multiply(int, int); // just input ints, pass by value - - string& concatenate(string&, const string& suffix); // suffix is input-only but not as cheap as an int, pass by const& - - void sink(unique_ptr); // input only, and consumes the widget - -Avoid "esoteric techniques" such as: +##### Note -* Passing arguments as `T&&` "for efficiency". Most rumors about performance advantages from passing by `&&` are false or brittle (but see [F.25](#Rf-pass-ref-move).) -* Returning `const T&` from assignments and similar operations. +`not_null` is defined in the [guidelines support library](#gsl-guidelines-support-library). -**Example**: Assuming that `Matrix` has move operations (possibly by keeping its elements in a `std::vector`. +##### Note - Matrix operator+(const Matrix& a, const Matrix& b) - { - Matrix res; - // ... fill res with the sum ... - return res; - } +The assumption that the pointer to `char` pointed to a C-style string (a zero-terminated string of characters) was still implicit, and a potential source of confusion and errors. Use `czstring` in preference to `const char*`. - Matrix x = m1+m2; // move constructor + // we can assume that p cannot be nullptr + // we can assume that p points to a zero-terminated array of characters + int length(not_null p); - y = m3+m3; // move assignment +Note: `length()` is, of course, `std::strlen()` in disguise. -**Note**: The (optional) return value optimization doesn't handle the assignment case. +##### Enforcement -**See also**: [implicit arguments](#Ri-explicit). +* (Simple) ((Foundation)) If a function checks a pointer parameter against `nullptr` before access, on all control-flow paths, then warn it should be declared `not_null`. +* (Complex) If a function with pointer return value ensures it is not `nullptr` on all return paths, then warn the return type should be declared `not_null`. -**Enforcement**: This is a philosophical guideline that is infeasible to check directly and completely. -However, many of the the detailed rules (F.16-F.45) can be checked, -such as passing a `const int&`, returning an `array` by value, and returning a pointer to fre store alloced by the function. +### I.13: Do not pass an array as a single pointer +##### Reason - -### F.16: Use `T*` or `owner` to designate a single object + (pointer, size)-style interfaces are error-prone. Also, a plain pointer (to array) must rely on some convention to allow the callee to determine the size. -**Reason**: In traditional C and C++ code, "Plain `T*` is used for many weakly-related purposes, such as +##### Example -* Identify a (single) object (not to be deleted by this function) -* Point to an object allocated on the free store (and delete it later) -* Hold the `nullptr` -* Identify a C-style string (zero-terminated array of characters) -* Identify an array with a length specified separately -* Identify a location in an array +Consider: -Confusion about what meaning a `T*` is the source of many serious errors, so using separate names for pointers of these separate uses makes code clearer. -For debugging, `owner` and `not_null` can be instrumented to check. -For example, `not_null` makes it obvious to a reader (human or machine) that a test for `nullptr` is not necessary before dereference. + void copy_n(const T* p, T* q, int n); // copy from [p:p+n) to [q:q+n) -**Example**: Consider +What if there are fewer than `n` elements in the array pointed to by `q`? Then, we overwrite some probably unrelated memory. +What if there are fewer than `n` elements in the array pointed to by `p`? Then, we read some probably unrelated memory. +Either is undefined behavior and a potentially very nasty bug. - int length(Record* p); +##### Alternative -When I call `length(r)` should I test for `r==nullptr` first? Should the implementation of `length()` test for `p==nullptr`? +Consider using explicit spans: - int length(not_null p); // it is the caller's job to make sure p!=nullptr + void copy(span r, span r2); // copy r to r2 - int length(Record* p); // the implementor of length() must assume that p==nullptr is possible +##### Example, bad -**Note**: A `not_null` is assumed not to be the `nullptr`; a `T*` may be the `nullptr`; both can be represented in memory as a `T*` (so no run-time overhead is implied). +Consider: -**Note**: `owner` represents ownership. + void draw(Shape* p, int n); // poor interface; poor code + Circle arr[10]; + // ... + draw(arr, 10); -**Also**: Assume that a `T*` obtained from a smart pointer to `T` (e.g., unique_ptr<`T`>) pointes to a single element. +Passing `10` as the `n` argument might be a mistake: the most common convention is to assume `[0:n)` but that is nowhere stated. Worse is that the call of `draw()` compiled at all: there was an implicit conversion from array to pointer (array decay) and then another implicit conversion from `Circle` to `Shape`. There is no way that `draw()` can safely iterate through that array: it has no way of knowing the size of the elements. -**See also**: [Support library](#S-gsl). +**Alternative**: Use a support class that ensures that the number of elements is correct and prevents dangerous implicit conversions. For example: -**Enforcement**: + void draw2(span); + Circle arr[10]; + // ... + draw2(span(arr)); // deduce the number of elements + draw2(arr); // deduce the element type and array size -* (Simple) ((Bounds)) Warn for any arithmetic operation on an expression of pointer type that results in a value of pointer type. + void draw3(span); + draw3(arr); // error: cannot convert Circle[10] to span +This `draw2()` passes the same amount of information to `draw()`, but makes the fact that it is supposed to be a range of `Circle`s explicit. See ???. - -### F.17: Use a `not_null` to indicate that "null" is not a valid value +##### Exception -**Reason**: Clarity. Making it clear that a test for null isn't needed. +Use `zstring` and `czstring` to represent C-style, zero-terminated strings. +But when doing so, use `std::string_view` or `span` from the [GSL](#gsl-guidelines-support-library) to prevent range errors. -**Example**: +##### Enforcement - not_null check(T* p) { if (p) return not_null{p}; throw Unexpected_nullptr{}; } +* (Simple) ((Bounds)) Warn for any expression that would rely on implicit conversion of an array type to a pointer type. Allow exception for zstring/czstring pointer types. +* (Simple) ((Bounds)) Warn for any arithmetic operation on an expression of pointer type that results in a value of pointer type. Allow exception for zstring/czstring pointer types. - void computer(not_null> p) - { - if (0I.22: Avoid complex initialization of global objects -**Note**: `not_null` is not just for built-in pointers. It works for `array_view`, `string_view`, `unique_ptr`, `shared_ptr`, and other pointer-like types. +##### Reason -**Enforcement**: +Complex initialization can lead to undefined order of execution. -* (Simple) Warn if a raw pointer is dereferenced without being tested against `nullptr` (or equivalent) within a function, suggest it is declared `not_null` instead. -* (Simple) Error if a raw pointer is sometimes dereferenced after first being tested against `nullptr` (or equivalent) within the function and sometimes is not. -* (Simple) Warn if a `not_null` pointer is tested against `nullptr` within a function. +##### Example + // file1.c - -### F.18: Use an `array_view` or an `array_view_p` to designate a half-open sequence + extern const X x; -**Reason**: Informal/non-explicit ranges are a source of errors + const Y y = f(x); // read x; write y -**Example**: + // file2.c - X* find(array_view r, const X& v) // find v in r + extern const Y y; - vector vec; - // ... - auto p = find({vec.begin(),vec.end()},X{}); // find X{} in vec + const X x = g(y); // read y; write x -**Note**: Ranges are extremely common in C++ code. Typically, they are implicit and their correct use is very hard to ensure. In particular, given a pair of arguments `(p,n)` designating an array [`p`:`p+n`), it is in general impossible to know if there really are n elements to access following `*p`. `array_view` and `array_view_p` are simple helper classes designating a [p:q) range and a range starting with p and ending with the first element for which a predicate is true, respectively. +Since `x` and `y` are in different translation units the order of calls to `f()` and `g()` is undefined; +one will access an uninitialized `const`. +This shows that the order-of-initialization problem for global (namespace scope) objects is not limited to global *variables*. -**Note**: an `array_view` object does not own its elements and is so small that it can be passed by value. +##### Note -**Note**: Passing an `array_view` object as an argument is exactly as efficient as passing a pair of pointer arguments or passing a pointer and an integer count. +Order of initialization problems become particularly difficult to handle in concurrent code. +It is usually best to avoid global (namespace scope) objects altogether. -**See also**: [Support library](#S-gsl). +##### Enforcement -**Enforcement**: (Complex) Warn where accesses to pointer parameters are bounded by other parameters that are integral types and suggest they could use `array_view` instead. +* Flag initializers of globals that call non-`constexpr` functions +* Flag initializers of globals that access `extern` objects +### I.23: Keep the number of function arguments low - -### F.19: Use a `zstring` or a `not_null` to designate a C-style string +##### Reason -**Reason**: C-style strings are ubiquitous. -They are defined by convention: zero-terminated arrays of characters. -Functions are inconsistent in their use of `nullptr` and we must be more explicit. +Having many arguments opens opportunities for confusion. Passing lots of arguments is often costly compared to alternatives. -**Example**: Consider +##### Discussion - int length(const char* p); +The two most common reasons why functions have too many parameters are: -When I call `length(s)` should I test for `s==nullptr` first? Should the implementation of `length()` test for `p==nullptr`? +1. *Missing an abstraction.* + There is an abstraction missing, so that a compound value is being + passed as individual elements instead of as a single object that enforces an invariant. + This not only expands the parameter list, but it leads to errors because the component values + are no longer protected by an enforced invariant. - int length(zstring p); // it is the caller's job to make sure p!=nullptr +2. *Violating "one function, one responsibility."* + The function is trying to do more than one job and should probably be refactored. - int length(not_null p); // the implementor of length() must assume that p==nullptr is possible +##### Example -**Note**: `zstring` do not represent ownership. +The standard-library `merge()` is at the limit of what we can comfortably handle: -**See also**: [Support library](#S-gsl). + template + OutputIterator merge(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); +Note that this is because of problem 1 above -- missing abstraction. Instead of passing a range (abstraction), STL passed iterator pairs (unencapsulated component values). - -### F.20: Use a `const T&` parameter for a large object +Here, we have four template arguments and six function arguments. +To simplify the most frequent and simplest uses, the comparison argument can be defaulted to `<`: -**Reason**: Copying large objects can be expensive. A `const T&` is always cheap and protects the caller from unintended modification. + template + OutputIterator merge(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); -**Example**: +This doesn't reduce the total complexity, but it reduces the surface complexity presented to many users. +To really reduce the number of arguments, we need to bundle the arguments into higher-level abstractions: - void fct(const string& s); // OK: pass by const reference; always checp + template + OutputIterator merge(InputRange1 r1, InputRange2 r2, OutputIterator result); - void fct2(string s); // bad: potentially expensive +Grouping arguments into "bundles" is a general technique to reduce the number of arguments and to increase the opportunities for checking. -**Exception**: Sinks (that is, a function that eventually destroys an object or passes it along to another sink), may benefit ??? +Alternatively, we could use a standard library concept to define the notion of three types that must be usable for merging: -**Note**: A reference may be assumed to refer to a valid object (language rule). -There in no (legitimate) "null reference." -If you need the notion of an optional value, use a pointer, `std::optional`, or a special value used to denote "no value." + template + requires mergeable + Out merge(In1 r1, In2 r2, Out result); -**Enforcement**: +##### Example -* (Simple) ((Foundation)) Warn when a parameter being passed by value has a size greater than `4*sizeof(int)`. -Suggest using a `const` reference instead. +The safety Profiles recommend replacing + void f(int* some_ints, int some_ints_length); // BAD: C style, unsafe - -### F.21: Use a `T` parameter for a small object +with -**Reason**: Nothing beats the simplicity and safety of copying. -For small objects (up to two or three words) is is also faster than alternatives. + void f(gsl::span some_ints); // GOOD: safe, bounds-checked -**Example**: +Here, using an abstraction has safety and robustness benefits, and naturally also reduces the number of parameters. - void fct(int x); // OK: Unbeatable +##### Note - void fct(const int& x); // bad: overhead on access in fct2() +How many parameters are too many? Try to use fewer than four (4) parameters. +There are functions that are best expressed with four individual parameters, but not many. - void fct(int& x); // OK, but means something else; use only for an "out parameter" +**Alternative**: Use better abstraction: Group arguments into meaningful objects and pass the objects (by value or by reference). -**Enforcement**: +**Alternative**: Use default arguments or overloads to allow the most common forms of calls to be done with fewer arguments. -* (Simple) ((Foundation)) Warn when a `const` parameter being passed by reference has a size less than `3*sizeof(int)`. Suggest passing by value instead. +##### Enforcement +* Warn when a function declares two iterators (including pointers) of the same type instead of a range or a view. +* (Not enforceable) This is a philosophical guideline that is infeasible to check directly. - -### F.22: Use a `T&` for an in-out-parameter +### I.24: Avoid adjacent parameters that can be invoked by the same arguments in either order with different meaning -**Reason**: A called function can write to a non-`const` reference argument, so assume that it does. +##### Reason -**Example**: +Adjacent arguments of the same type are easily swapped by mistake. - void update(Record& r); // assume that update writes to r - -**Note**: A `T&` argument can pass information into a function as well as well as out of it. -Thus `T&` could be and in-out-parameter. That can in itself be a problem and a source of errors: +##### Example, bad - void f(string& s) - { - s = "New York"; // non-obvious error - } - - string g() - { - string buffer = "................................."; - f(buffer); - // ... - } - -Here, the writer of `g()` is supplying a buffer for `f()` to fill, -but `f()` simply replaces it (at a somewhat higher cost than a simple copy of the characters). -If the writer of `g()` makes an assumption about the size of `buffer` a bad logic error can happen. +Consider: -**Enforcement**: + void copy_n(T* p, T* q, int n); // copy from [p:p + n) to [q:q + n) -* (Moderate) ((Foundation)) Warn about functions with non-`const` reference arguments that do *not* write to them. -* Flag functions that take a `T&` and replace the `T` referred to, rather what the contents of that `T` +This is a nasty variant of a K&R C-style interface. It is easy to reverse the "to" and "from" arguments. +Use `const` for the "from" argument: - -### F.23: Use `T&` for an out-parameter that is expensive to move (only) + void copy_n(const T* p, T* q, int n); // copy from [p:p + n) to [q:q + n) -**Reason**: A return value is harder to miss and harder to misuse than a `T&` (an in-out parameter); [see also](#Rf-return); [see also](#Rf-T-multi). +##### Exception -**Example**: +If the order of the parameters is not important, there is no problem: - struct Package { - char header[16]; - char load[2024-16]; - }; - - Package fill(); // Bad: large return value - void fill(Package&); // OK - - int val(); // OK - val(int&); // Bad: Is val reading its argument + int max(int a, int b); -**Enforcement**: Hard to choose a cutover value for the size of the value returned. +##### Alternative +Don't pass arrays as pointers, pass an object representing a range (e.g., a `span`): - -### F.24: Use a `TP&&` parameter when forwarding (only) + void copy_n(span p, span q); // copy from p to q -**Reason**: When `TP` is a template type parameter, `TP&&` is a forwarding reference -- it both *ignores* and *preserves* const-ness and rvalue-ness. Therefore any code that uses a `T&&` is implicitly declaring that it itself doesn't care about the variable's const-ness and rvalue-ness (because it is ignored), but that intends to pass the value onward to other code that does care about const-ness and rvalue-ness (because it is preserved). When used as a parameter `TP&&` is safe because any temporary objects passed from the caller will live for the duration of the function call. A parameter of type `TP&&` should essentially always be passed onward via `std::forward` in the body of the function. +##### Alternative -**Example**: +Define a `struct` as the parameter type and name the fields for those parameters accordingly: - template - inline auto invoke(F&& f, Args&&... args) { - return forward(f)(forward(args)...); - } + struct SystemParams { + string config_file; + string output_path; + seconds timeout; + }; + void initialize(SystemParams p); -**Enforcement**: Flag a function that takes a `TP&&` parameter (where `TP` is a template type parameter name) and uses it without `std::forward`. +This tends to make invocations of this clear to future readers, as the parameters +are often filled in by name at the call site. +##### Note - -### F.25: Use a `T&&` parameter together with `move` for rare optimization opportunities +Only the interface's designer can adequately address the source of violations of this guideline. -**Reason**: Moving from an object leaves an object in its moved-from state behind. -In general, moved-from objects are dangerous. The only guaranteed operation is destruction (more generally, member functions without preconditions). -The standard library additionally requires that a moved-from object can be assigned to. -If you have performance justification to optimize for rvalues, overload on `&&` and then `move` from the parameter ([example of such overloading](#)). +##### Enforcement strategy -**Example**: +(Simple) Warn if two consecutive parameters share the same type - void somefct(string&&); - - void user() - { - string s = "this is going to be fun!"; - // ... - somefct(std::move(s)); // we don't need s any more, give it to somefct() - // - cout << s << '\n'; // Oops! What happens here? - } +We are still looking for a less-simple enforcement. -**Enforcement**: +### I.25: Prefer empty abstract classes as interfaces to class hierarchies -* Flag all `X&&` parameters (where `X` is not a template type parameter name) and uses it without `std::move`. -* Flag access to moved-from objects +##### Reason +Abstract classes that are empty (have no non-static member data) are more likely to be stable than base classes with state. - -### F.26: Use a `unique_ptr` to transfer ownership where a pointer is needed +##### Example, bad -**Reason**: Using `unique_ptr` is the cheapest way to pass a pointer safely. +You just knew that `Shape` would turn up somewhere :-) -**Example**: + class Shape { // bad: interface class loaded with data + public: + Point center() const { return c; } + virtual void draw() const; + virtual void rotate(int); + // ... + private: + Point c; + vector outline; + Color col; + }; - unique_ptr get_shape(istream& is) // assemble shape from input stream - { - auto kind = read_header(is); // read header and identify the next shape on input - switch (kind) { - case kCicle: - return make_unique(is); - case kTriangle: - return make_unique(is); - // ... - } +This will force every derived class to compute a center -- even if that's non-trivial and the center is never used. Similarly, not every `Shape` has a `Color`, and many `Shape`s are best represented without an outline defined as a sequence of `Point`s. Using an abstract class is better: -**Note**: You need to pass a pointer rather than an object if what you are transferring is an object from a class hierarchy that is to be used through an interface (base class). + class Shape { // better: Shape is a pure interface + public: + virtual Point center() const = 0; // pure virtual functions + virtual void draw() const = 0; + virtual void rotate(int) = 0; + // ... + // ... no data members ... + // ... + virtual ~Shape() = default; + }; -**Enforcement**: (Simple) Warn if a function returns a locally-allocated raw pointer. Suggest using either `unique_ptr` or `shared_ptr` instead. +##### Enforcement +(Simple) Warn if a pointer/reference to a class `C` is assigned to a pointer/reference to a base of `C` and the base class contains data members. - -### F.27: Use a `shared_ptr` to share ownership +### I.26: If you want a cross-compiler ABI, use a C-style subset -**Reason**: Using `std::shared_ptr` is the standard way to represent shared ownership. That is, the last owner deletes the object. +##### Reason -**Example**: +Different compilers implement different binary layouts for classes, exception handling, function names, and other implementation details. - shared_ptr im { read_image(somewhere); }; - - std::thread t0 {shade,args0,top_left,im}; - std::thread t1 {shade,args1,top_right,im}; - std::thread t2 {shade,args2,bottom_left,im}; - std::thread t3 {shade,args3,bottom_right,im}; - - // detach treads - // last thread to finish deletes the image +##### Exception +Common ABIs are emerging on some platforms freeing you from the more draconian restrictions. -**Note**: Prefer a `unique_ptr` over a `shared_ptr` if there is never more than one owner at a time. -`shared_ptr` is for shared ownership. +##### Note -**Alternative**: Have a single object own the shared object (e.g. a scoped object) and destroy that (preferably implicitly) when all users have completd. +If you use a single compiler, you can use full C++ in interfaces. That might require recompilation after an upgrade to a new compiler version. -**Enforcement**: (Not enforceable) This is a too complex pattern to reliably detect. +##### Enforcement +(Not enforceable) It is difficult to reliably identify where an interface forms part of an ABI. - -### F.40: Prefer return values to out-parameters +### I.27: For stable library ABI, consider the Pimpl idiom -**Reason**: It's self-documenting. A `&` parameter could be either in/out or out-only. +##### Reason -**Example**: +Because private data members participate in class layout and private member functions participate in overload resolution, changes to those +implementation details require recompilation of all users of a class that uses them. A non-polymorphic interface class holding a pointer to +implementation (Pimpl) can isolate the users of a class from changes in its implementation at the cost of an indirection. - void incr(int&); - int incr(); - - int i = 0; - incr(i); - i = incr(i); +##### Example -**Enforcement**: Flag non-const reference parameters that are not read before being written to and are a type that could be cheaply returned. +interface (widget.h) + class widget { + class impl; + std::unique_ptr pimpl; + public: + void draw(); // public API that will be forwarded to the implementation + widget(int); // defined in the implementation file + ~widget(); // defined in the implementation file, where impl is a complete type + widget(widget&&) noexcept; // defined in the implementation file + widget(const widget&) = delete; + widget& operator=(widget&&) noexcept; // defined in the implementation file + widget& operator=(const widget&) = delete; + }; - -### F.41: Prefer to return tuples to multiple out-parameters -**Reason**: A return value is self-documenting as an "output-only" value. -And yes, C++ does have multiple return values, by convention of using a `tuple`, with the extra convenience of `tie` at the call site. +implementation (widget.cpp) -**Example**: + class widget::impl { + int n; // private data + public: + void draw(const widget& w) { /* ... */ } + impl(int n) : n(n) {} + }; + void widget::draw() { pimpl->draw(*this); } + widget::widget(int n) : pimpl{std::make_unique(n)} {} + widget::widget(widget&&) noexcept = default; + widget::~widget() = default; + widget& widget::operator=(widget&&) noexcept = default; - int f( const string& input, /*output only*/ string& output_data ) { // BAD: output-only parameter documented in a comment - // ... - output_data = something(); - return status; - } +##### Notes - tuple f( const string& input ) { // GOOD: self-documenting - // ... - return make_tuple(something(), status); - } +See [GOTW #100](https://herbsutter.com/gotw/_100/) and [cppreference](http://en.cppreference.com/w/cpp/language/pimpl) for the trade-offs and additional implementation details associated with this idiom. -In fact, C++98's standard library already used this convenient feature, because a `pair` is like a two-element `tuple`. -For example, given a `set myset`, consider: +##### Enforcement - // C++98 - result = myset.insert( “Hello” ); - if (result.second) do_something_with( result.first ); // workaround - -With C++11 we can write this, putting the results directly in existing local variables: +(Not enforceable) It is difficult to reliably identify where an interface forms part of an ABI. - Sometype iter; // default initialize if we haven't already - Someothertype success; // used these variables for some other purpose +### I.30: Encapsulate rule violations - tie( iter, success ) = myset.insert( “Hello” ); // normal return value - if (success) do_something_with( iter ); +##### Reason -**Exception**: For types like `string` and `vector` that carry additional capacity, it can sometimes be useful to treat it as in/out instead by using the "caller-allocated out" pattern, which is to pass an output-only object by reference to non-`const` so that when the callee writes to it the object can reuse any capacity or other resources that it already contains. This technique can dramatically reduce the number of allocations in a loop that repeatedly calls other functions to get string values, by using a single string object for the entire loop. +To keep code simple and safe. +Sometimes, ugly, unsafe, or error-prone techniques are necessary for logical or performance reasons. +If so, keep them local, rather than "infecting" interfaces so that larger groups of programmers have to be aware of the +subtleties. +Implementation complexity should, if at all possible, not leak through interfaces into user code. -**Note**: In some cases it may be useful to return a specific, user-defined `Value_or_error` type along the lines of `variant`, -rather than using the generic `tuple`. +##### Example -**Enforcement**: +Consider a program that, depending on some form of input (e.g., arguments to `main`), should consume input +from a file, from the command line, or from standard input. +We might write - * Output parameters should be replaced by return values. - An output parameter is one that the function writes to, invokes a non-`const` member function, or passes on as a non-`const`. + bool owned; + owner inp; + switch (source) { + case std_in: owned = false; inp = &cin; break; + case command_line: owned = true; inp = new istringstream{argv[2]}; break; + case file: owned = true; inp = new ifstream{argv[2]}; break; + } + istream& in = *inp; +This violated the rule [against uninitialized variables](#Res-always), +the rule against [ignoring ownership](#Ri-raw), +and the rule [against magic constants](#Res-magic). +In particular, someone has to remember to somewhere write - -### F.42: Return a `T*` to indicate a position (only) + if (owned) delete inp; -**Reason**: That's what pointers are good for. -Returning a `T*` to transfer ownership is a misuse. +We could handle this particular example by using `unique_ptr` with a special deleter that does nothing for `cin`, +but that's complicated for novices (who can easily encounter this problem) and the example is an example of a more general +problem where a property that we would like to consider static (here, ownership) needs infrequently be addressed +at run time. +The common, most frequent, and safest examples can be handled statically, so we don't want to add cost and complexity to those. +But we must also cope with the uncommon, less-safe, and necessarily more expensive cases. +Such examples are discussed in [[Str15]](http://www.stroustrup.com/resource-model.pdf). -**Note**: Do not return a pointer to something that is not in the caller's scope. +So, we write a class -**Example**: + class Istream { [[gsl::suppress("lifetime")]] + public: + enum Opt { from_line = 1 }; + Istream() { } + Istream(czstring p) : owned{true}, inp{new ifstream{p}} {} // read from file + Istream(czstring p, Opt) : owned{true}, inp{new istringstream{p}} {} // read from command line + ~Istream() { if (owned) delete inp; } + operator istream&() { return *inp; } + private: + bool owned = false; + istream* inp = &cin; + }; - Node* find(Node* t, const string& s) // find s in a binary tree of Nodes - { - if (t == nullptr || t->name == s) return t; - if (auto p = find(t->left,s)) return p; - if (auto p = find(t->right,s)) return p; - return nullptr; - } +Now, the dynamic nature of `istream` ownership has been encapsulated. +Presumably, a bit of checking for potential errors would be added in real code. -If it isn't the `nullptr`, the pointer returned by `find` indicates a `Node` holding `s`. -Importantly, that does not imply a transfer of ownership of the pointed-to object to the caller. +##### Enforcement -**Note**: Positions can also be transferred by iterators, indices, and references. +* Hard, it is hard to decide what rule-breaking code is essential +* Flag rule suppression that enable rule-violations to cross interfaces -**Example, bad**: +# F: Functions - int* f() - { - int x = 7; - // ... - return &x; // Bad: returns pointer to object that is about to be destroyed - } +A function specifies an action or a computation that takes the system from one consistent state to the next. It is the fundamental building block of programs. -This applies to references as well: +It should be possible to name a function meaningfully, to specify the requirements of its argument, and clearly state the relationship between the arguments and the result. An implementation is not a specification. Try to think about what a function does as well as about how it does it. +Functions are the most critical part in most interfaces, so see the interface rules. - int& f() - { - int x = 7; - // ... - return x; // Bad: returns reference to object that is about to be destroyed - } +Function rule summary: -**See also**: [discussion of dangling pointer prevention](#???). +Function definition rules: -**Enforcement**: A slightly different variant of the problem is placing pointers in a container that outlives the objects pointed to. +* [F.1: "Package" meaningful operations as carefully named functions](#Rf-package) +* [F.2: A function should perform a single logical operation](#Rf-logical) +* [F.3: Keep functions short and simple](#Rf-single) +* [F.4: If a function might have to be evaluated at compile time, declare it `constexpr`](#Rf-constexpr) +* [F.5: If a function is very small and time-critical, declare it inline](#Rf-inline) +* [F.6: If your function must not throw, declare it `noexcept`](#Rf-noexcept) +* [F.7: For general use, take `T*` or `T&` arguments rather than smart pointers](#Rf-smart) +* [F.8: Prefer pure functions](#Rf-pure) +* [F.9: Unused parameters should be unnamed](#Rf-unused) +* [F.10: If an operation can be reused, give it a name](#Rf-name) +* [F.11: Use an unnamed lambda if you need a simple function object in one place only](#Rf-lambda) -* Compilers tend to catch return of reference to locals and could in many cases catch return of pointers to locals. -* Static analysis can catch most (all?) common patterns of the use of pointers indicating positions (thus eliminating dangling pointers) - - - -### F.43: Never (directly or indirectly) return a pointer to a local object - -**Reason**: To avoid the crashes and data corruption that can result from the use of such a dangling pointer. - -**Example**, bad: After the return from a function its local objects no longer exist: - - int* f() - { - int fx = 9; - return &fx; // BAD - } - - void g(int* p) // looks innocent enough - { - int gx; - cout << "*p == " << *p << '\n'; - *p = 999; - cout << "gx == " << gx << '\n'; - } - - void h() - { - int* p = f(); - int z = *p; // read from abandoned stack frame (bad) - g(p); // pass pointer to abandoned stack frame to function (bad) - - } - -Here on one popular implementation I got the output - - *p == 9 - cx == 999 - -I expected that because the call of `g()` reuses the stack space abandoned by the call of `f()` so `*p` refers to the space now occupied by `gx`. +Parameter passing expression rules: -Imagine what would happen if `fx` and `gx` were of different types. -Imagine what would happen if `fx` or `gx` was a type with an invariant. -Imagine what would happen if more that dangling pointer was passed around among a larger set of functions. -Imagine what a cracker could do with that dangling pointer. +* [F.15: Prefer simple and conventional ways of passing information](#Rf-conventional) +* [F.16: For "in" parameters, pass cheaply-copied types by value and others by reference to `const`](#Rf-in) +* [F.17: For "in-out" parameters, pass by reference to non-`const`](#Rf-inout) +* [F.18: For "will-move-from" parameters, pass by `X&&` and `std::move` the parameter](#Rf-consume) +* [F.19: For "forward" parameters, pass by `TP&&` and only `std::forward` the parameter](#Rf-forward) +* [F.20: For "out" output values, prefer return values to output parameters](#Rf-out) +* [F.21: To return multiple "out" values, prefer returning a struct](#Rf-out-multi) +* [F.60: Prefer `T*` over `T&` when "no argument" is a valid option](#Rf-ptr-ref) + +Parameter passing semantic rules: + +* [F.22: Use `T*` or `owner` to designate a single object](#Rf-ptr) +* [F.23: Use a `not_null` to indicate that "null" is not a valid value](#Rf-nullptr) +* [F.24: Use a `span` or a `span_p` to designate a half-open sequence](#Rf-range) +* [F.25: Use a `zstring` or a `not_null` to designate a C-style string](#Rf-zstring) +* [F.26: Use a `unique_ptr` to transfer ownership where a pointer is needed](#Rf-unique_ptr) +* [F.27: Use a `shared_ptr` to share ownership](#Rf-shared_ptr) -Fortunately, most (all?) modern compilers catch and warn against this simple case. +Value return semantic rules: -**Note**: you can construct similar examples using references. +* [F.42: Return a `T*` to indicate a position (only)](#Rf-return-ptr) +* [F.43: Never (directly or indirectly) return a pointer or a reference to a local object](#Rf-dangle) +* [F.44: Return a `T&` when copy is undesirable and "returning no object" isn't needed](#Rf-return-ref) +* [F.45: Don't return a `T&&`](#Rf-return-ref-ref) +* [F.46: `int` is the return type for `main()`](#Rf-main) +* [F.47: Return `T&` from assignment operators](#Rf-assignment-op) +* [F.48: Don't return `std::move(local)`](#Rf-return-move-local) +* [F.49: Don't return `const T`](#Rf-return-const) -**Note**: This applies only to non-`static` local variables. -All `static` variables are (as their name indicates) statically allocated, so that pointers to them cannot dangle. +Other function rules: -**Example**, bad: Not all examples of leaking a pointer to a local variable are that obvious: +* [F.50: Use a lambda when a function won't do (to capture local variables, or to write a local function)](#Rf-capture-vs-overload) +* [F.51: Where there is a choice, prefer default arguments over overloading](#Rf-default-args) +* [F.52: Prefer capturing by reference in lambdas that will be used locally, including passed to algorithms](#Rf-reference-capture) +* [F.53: Avoid capturing by reference in lambdas that will be used non-locally, including returned, stored on the heap, or passed to another thread](#Rf-value-capture) +* [F.54: When writing a lambda that captures `this` or any class data member, don't use `[=]` default capture](#Rf-this-capture) +* [F.55: Don't use `va_arg` arguments](#F-varargs) +* [F.56: Avoid unnecessary condition nesting](#F-nesting) - int* glob; // global variables are bad in so many ways +Functions have strong similarities to lambdas and function objects. - template - void steal(T x) - { - glob = x(); // BAD - } +**See also**: [C.lambdas: Function objects and lambdas](#SS-lambdas) - void f() - { - int i = 99; - steal([&] { return &i; }); - } +## F.def: Function definitions - int main() - { - f(); - cout << *glob << '\n'; - } - -Here I managed to read the location abandoned by the call of `f`. -The pointer stored in `glob` could be used much later and cause trouble in unpredictable ways. +A function definition is a function declaration that also specifies the function's implementation, the function body. -**Note**: The address of a local variable can be "returned"/leaked by a return statement, -by a `T&` out-parameter, as a member of a returned object, as an element of a returned array, and more. +### F.1: "Package" meaningful operations as carefully named functions -**Note**: Similar examples can be constructed "leaking" a pointer from an inner scope to an outer one; -such examples are handled equivalently to leaks of pointers out of a function. +##### Reason -**See also**: Another way of getting dangling pointers is [pointer invalidation](#???). -It can be detected/prevented with similar techniques. +Factoring out common code makes code more readable, more likely to be reused, and limit errors from complex code. +If something is a well-specified action, separate it out from its surrounding code and give it a name. -**Enforcement**: Preventable through static analysis. +##### Example, don't + void read_and_print(istream& is) // read and print an int + { + int x; + if (is >> x) + cout << "the int is " << x << '\n'; + else + cerr << "no int on input\n"; + } - -### F.44: Return a `T&` when "returning no object" isn't an option +Almost everything is wrong with `read_and_print`. +It reads, it writes (to a fixed `ostream`), it writes error messages (to a fixed `ostream`), it handles only `int`s. +There is nothing to reuse, logically separate operations are intermingled and local variables are in scope after the end of their logical use. +For a tiny example, this looks OK, but if the input operation, the output operation, and the error handling had been more complicated the tangled +mess could become hard to understand. -**Reason**: The language guarantees that a `T&` refers to an object, so that testing for `nullptr` isn't necessary. +##### Note -**See also**: The return of a reference must not imply transfer of ownership: -[discussion of dangling pointer prevention](#???) and [discussion of ownership](#???). +If you write a non-trivial lambda that potentially can be used in more than one place, give it a name by assigning it to a (usually non-local) variable. -**Example**: +##### Example - ??? + sort(a, b, [](T x, T y) { return x.rank() < y.rank() && x.value() < y.value(); }); -**Enforcement**: ??? +Naming that lambda breaks up the expression into its logical parts and provides a strong hint to the meaning of the lambda. + auto lessT = [](T x, T y) { return x.rank() < y.rank() && x.value() < y.value(); }; - -### F.45: Don't return a `T&&` + sort(a, b, lessT); -**Reason**: It's asking to return a reference to a destroyed temporary object. A `&&` is a magnet for temporary objects. This is fine when the reference to the temporary is being passed "downward" to a callee, because the temporary is guaranteed to outlive the function call. (See [F.24](#RF-pass-ref-ref) and [F.25](#Rf-pass-ref-move).) However, it's not fine when passing such a reference "upward" to a larger caller scope. See also [F54](#Rf-local-ref-ref). +The shortest code is not always the best for performance or maintainability. -For passthrough functions that pass in parameters (by ordinary reference or by perfect forwarding) and want to return values, use simple `auto` return type deduction (not `auto&&`). +##### Exception -**Example; bad**: If `F` returns by value, this function returns a reference to a temporary. +Loop bodies, including lambdas used as loop bodies, rarely need to be named. +However, large loop bodies (e.g., dozens of lines or dozens of pages) can be a problem. +The rule [Keep functions short and simple](#Rf-single) implies "Keep loop bodies short." +Similarly, lambdas used as callback arguments are sometimes non-trivial, yet unlikely to be reusable. - template - auto&& wrapper(F f) { - log_call(typeid(f)); // or whatever instrumentation - return f(); - } +##### Enforcement -**Example; good**: Better: - - template - auto wrapper(F f) { - log_call(typeid(f)); // or whatever instrumentation - return f(); - } +* See [Keep functions short and simple](#Rf-single) +* Flag identical and very similar lambdas used in different places. -**Exception**: `std::move` and `std::forward` do return `&&`, but they are just casts -- used by convention only in expression contexts where a reference to a temporary object is passed along within the same expression before the temporary is destroyed. We don't know of any other good examples of returning `&&`. +### F.2: A function should perform a single logical operation -**Enforcement**: Flag any use of `&&` as a return type, except in `std::move` and `std::forward`. +##### Reason +A function that performs a single operation is simpler to understand, test, and reuse. - -### F.50: Use a lambda when a function won't do (to capture local variables, or to write a local function) +##### Example -**Reason**: Functions can't capture local variables or be declared at local scope; if you need those things, prefer a lambda where possible, and a handwritten function object where not. On the other hand, lambdas and function objects don't overload; if you need to overload, prefer a function (the workarounds to make lambdas overload are ornate). If either will work, prefer writing a function; use the simplest tool necessary. +Consider: -**Example**: + void read_and_print() // bad + { + int x; + cin >> x; + // check for errors + cout << x << "\n"; + } - // writing a function that should only take an int or a string -- overloading is natural - void f(int); - void f(const string&); - - // writing a function object that needs to capture local state and appear - // at statement or expression scope -- a lambda is natural - vector v = lots_of_work(); - for(int tasknum = 0; tasknum < max; ++tasknum) { - pool.run([=, &v]{ - /* - ... - ... process 1/max-th of v, the tasknum-th chunk - ... - */ - }); - } - pool.join(); +This is a monolith that is tied to a specific input and will never find another (different) use. Instead, break functions up into suitable logical parts and parameterize: -**Exception**: Generic lambdas offer a concise way to write function templates and so can be useful even when a normal function template would do equally well with a little more syntax. This advantage will probably disappear in the future once all functions gain the ability to have Concept parameters. + int read(istream& is) // better + { + int x; + is >> x; + // check for errors + return x; + } -**Enforcement**: + void print(ostream& os, int x) + { + os << x << "\n"; + } - * Warn on use of a named non-generic lambda (e.g., `auto x = [](int i){ /*...*/; };`) that captures nothing and appears at global scope. Write an ordinary function instead. +These can now be combined where needed: + void read_and_print() + { + auto x = read(cin); + print(cout, x); + } +If there was a need, we could further templatize `read()` and `print()` on the data type, the I/O mechanism, the response to errors, etc. Example: - -### F.51: Prefer overloading over default arguments for virtual functions -??? possibly other situations? + auto read = [](auto& input, auto& value) // better + { + input >> value; + // check for errors + }; -**Reason**: Virtual function overrides do not inherit default arguments, leading to surprises. + void print(auto& output, const auto& value) + { + output << value << "\n"; + } -**Example; bad**: +##### Enforcement - class base { - public: - virtual int multiply(int value, int factor = 2) = 0; - }; +* Consider functions with more than one "out" parameter suspicious. Use return values instead, including `tuple` for multiple return values. +* Consider "large" functions that don't fit on one editor screen suspicious. Consider factoring such a function into smaller well-named suboperations. +* Consider functions with 7 or more parameters suspicious. - class derived : public base { - public: - override int multiply(int value, int factor = 10); - }; - - derived d; - base& b = d; - - b.multiply(10); // these two calls will call the same function but - d.multiply(10); // with different arguments and so different results +### F.3: Keep functions short and simple -**Enforcement**: Flag all uses of default arguments in virtual functions. +##### Reason +Large functions are hard to read, more likely to contain complex code, and more likely to have variables in larger than minimal scopes. +Functions with complex control structures are more likely to be long and more likely to hide logical errors - -### F.52: Prefer capturing by reference in lambdas that will be used locally, including passed to algorithms +##### Example -**Reason**: For efficiency and correctness, you nearly always want to capture by reference when using the lambda locally. This includes when writing or calling parallel algorithms that are local because they join before returning. +Consider: -**Example**: This is a simple three-stage parallel pipeline. Each `stage` object encapsulates a worker thread and a queue, has a `process` function to enqueue work, and in its destructor automatically blocks waiting for the queue to empty before ending the thread. + double simple_func(double val, int flag1, int flag2) + // simple_func: takes a value and calculates the expected ASIC output, + // given the two mode flags. + { + double intermediate; + if (flag1 > 0) { + intermediate = func1(val); + if (flag2 % 2) + intermediate = sqrt(intermediate); + } + else if (flag1 == -1) { + intermediate = func1(-val); + if (flag2 % 2) + intermediate = sqrt(-intermediate); + flag1 = -flag1; + } + if (abs(flag2) > 10) { + intermediate = func2(intermediate); + } + switch (flag2 / 10) { + case 1: if (flag1 == -1) return finalize(intermediate, 1.171); + break; + case 2: return finalize(intermediate, 13.1); + default: break; + } + return finalize(intermediate, 0.); + } - void send_packets( buffers& bufs ) { - stage encryptor ([] (buffer& b){ encrypt(b); }); - stage compressor ([&](buffer& b){ compress(b); encryptor.process(b); }); - stage decorator ([&](buffer& b){ decorate(b); compressor.process(b); }); - for (auto& b : bufs) { decorator.process(b); } - } // automatically blocks waiting for pipeline to finish +This is too complex. +How would you know if all possible alternatives have been correctly handled? +Yes, it breaks other rules also. -**Enforcement**: ??? +We can refactor: + double func1_muon(double val, int flag) + { + // ??? + } - -### F.53: Avoid capturing by reference in lambdas that will be used nonlocally, including returned, stored on the heap, or passed to another thread + double func1_tau(double val, int flag1, int flag2) + { + // ??? + } -**Reason**: Pointers and references to locals shouldn't outlive their scope. Lambdas that capture by reference are just another place to store a reference to a local object, and shouldn't do so if they (or a copy) outlive the scope. + double simple_func(double val, int flag1, int flag2) + // simple_func: takes a value and calculates the expected ASIC output, + // given the two mode flags. + { + if (flag1 > 0) + return func1_muon(val, flag2); + if (flag1 == -1) + // handled by func1_tau: flag1 = -flag1; + return func1_tau(-val, flag1, flag2); + return 0.; + } -**Example**: +##### Note - { - // ... - - // a, b, c are local variables - background_thread.queue_work([=]{ process(a,b,c); }); // want copies of a, b, and c - } +"It doesn't fit on a screen" is often a good practical definition of "far too large." +One-to-five-line functions should be considered normal. -**Enforcement**: ??? +##### Note +Break large functions up into smaller cohesive and named functions. +Small simple functions are easily inlined where the cost of a function call is significant. +##### Enforcement - -# C: Classes and Class Hierarchies +* Flag functions that do not "fit on a screen." + How big is a screen? Try 60 lines by 140 characters; that's roughly the maximum that's comfortable for a book page. +* Flag functions that are too complex. How complex is too complex? + You could use cyclomatic complexity. Try "more than 10 logical paths through." Count a simple switch as one path. -A class is a user-defined type, for which a programmer can define the representation, operations, and interfaces. -Class hierarchies are used to organize related classes into hierarchical structures. +### F.4: If a function might have to be evaluated at compile time, declare it `constexpr` -Class rule summary: +##### Reason -* [C.1: Organize related data into structures (`struct`s or `class`es)](#Rc-org) -* [C.2: Use `class` if the class has an invariant; use `struct` if the data members can vary independently](#Rc-struct) -* [C.3: Represent the distinction between an interface and an implementation using a class](#Rc-interface) -* [C.4: Make a function a member only if it needs direct access to the representation of a class](#Rc-member) -* [C.5: Place helper functions in the same namespace as the class they support](#Rc-member) -* [C.6: Declare a member function that does not modify the state of its object `const`](#Rc-const) + `constexpr` is needed to tell the compiler to allow compile-time evaluation. -Subsections: +##### Example -* [C.concrete: Concrete types](#SS-concrete) -* [C.ctor: Constructors, assignments, and destructors](#SS-ctor) -* [C.con: Containers and other resource handles](#SS-containers) -* [C.lambdas: Function objects and lambdas](#SS-lambdas) -* [C.hier: Class hierarchies (OOP)](SS-hier) -* [C.over: Overloading and overloaded operators](#SS-overload) -* [C.union: Unions](#SS-union) +The (in)famous factorial: + constexpr int fac(int n) + { + constexpr int max_exp = 17; // constexpr enables max_exp to be used in Expects + Expects(0 <= n && n < max_exp); // prevent silliness and overflow + int x = 1; + for (int i = 2; i <= n; ++i) x *= i; + return x; + } - -### C.1: Organize related data into structures (`struct`s or `class`es) +This is C++14. +For C++11, use a recursive formulation of `fac()`. -**Reason**: Ease of comprehension. If data is related (for fundamental reasons), that fact should be reflected in code. +##### Note -**Example**: +`constexpr` does not guarantee compile-time evaluation; +it just guarantees that the function can be evaluated at compile time for constant expression arguments if the programmer requires it or the compiler decides to do so to optimize. - void draw(int x, int y, int x2, int y2); // BAD: unnecessary implicit relationships - void draw(Point from, Point to) // better + constexpr int min(int x, int y) { return x < y ? x : y; } -**Note**: A simple class without virtual functions implies no space or time overhead. + void test(int v) + { + int m1 = min(-1, 2); // probably compile-time evaluation + constexpr int m2 = min(-1, 2); // compile-time evaluation + int m3 = min(-1, v); // run-time evaluation + constexpr int m4 = min(-1, v); // error: cannot evaluate at compile time + } -**Note**: From a language perspective `class` and `struct` differ only in the default visibility of their members. +##### Note -**Enforcement**: Probably impossible. Maybe a heuristic looking for date items used together is possible. +Don't try to make all functions `constexpr`. +Most computation is best done at run time. +##### Note - -### C.2: Use `class` if the class has an invariant; use `struct` if the data members can vary independently +Any API that might eventually depend on high-level run-time configuration or +business logic should not be made `constexpr`. Such customization can not be +evaluated by the compiler, and any `constexpr` functions that depended upon +that API would have to be refactored or drop `constexpr`. -**Reason**: Ease of comprehension. The use of `class` alerts the programmer to the need for an invariant +##### Enforcement -**Note**: An invariant is logical condition for the members of an object that a constructor must establish for the public member functions to assume. After the invariant is established (typically by a constructor) every member function can be called for the object. An invariant can be stated informally (e.g., in a comment) or more formally using `Expects`. +Impossible and unnecessary. +The compiler gives an error if a non-`constexpr` function is called where a constant is required. -**Example**: +### F.5: If a function is very small and time-critical, declare it `inline` - struct Pair { // the members can vary independently - string name; - int volume; - }; +##### Reason -but +Some optimizers are good at inlining without hints from the programmer, but don't rely on it. +Measure! Over the last 40 years or so, we have been promised compilers that can inline better than humans without hints from humans. +We are still waiting. +Specifying inline (explicitly, or implicitly when writing member functions inside a class definition) encourages the compiler to do a better job. - class Date { - private: - int y; - Month m; - char d; // day - public: - Date(int yy, Month mm, char dd); // validate that {yy,mm,dd} is a valid date and initialize - // ... - }; +##### Example -**Enforcement**: Look for `struct`s with all data private and `class`es with public members. + inline string cat(const string& s, const string& s2) { return s + s2; } +##### Exception - -### C.3: Represent the distinction between an interface and an implementation using a class +Do not put an `inline` function in what is meant to be a stable interface unless you are certain that it will not change. +An inline function is part of the ABI. -**Reason**: an explicit distinction between interface and implementation improves readability and simplifies maintenance. +##### Note -**Example**: +`constexpr` implies `inline`. - class Date { - // ... some representation ... - public: - Date(); - Date(int yy, Month mm, char dd); // validate that {yy,mm,dd} is a valid date and initialize +##### Note - int day() const; - Month month() const; - // ... - }; +Member functions defined in-class are `inline` by default. -For example, we can now change the representation of a `Date` without affecting its users (recompilation is likely, though). +##### Exception -**Note**: Using a class in this way to represent the distinction between interface and implementation is of course not the only way. -For example, we can use a set of declarations of freestanding functions in a namespace, -an abstract base class, -or a template fuction with concepts to represent an interface. -The most important issue is to explicitly distinguish between an interface and its implementation "details." -Ideally, and typically, an interface is far more stable than its implementation(s). +Function templates (including member functions of class templates `A::function()` and member function templates `A::function()`) are normally defined in headers and therefore inline. -**Enforcement**: ??? - +##### Note - -### C.4: Make a function a member only if it needs direct access to the representation of a class +Consider making functions out of line if they are more than three statements and can be declared out of line (such as class member functions). -**Reason**: Less coupling than with member functions, fewer functions that can cause trouble by modifying object state, reduces the number of functions that needs to be modified after a change in representation. +### F.6: If your function must not throw, declare it `noexcept` -**Example**: +##### Reason - class Date { - // ... relatively small interface ... - }; +If an exception is not supposed to be thrown, the program cannot be assumed to cope with the error and should be terminated as soon as possible. Declaring a function `noexcept` helps optimizers by reducing the number of alternative execution paths. It also speeds up the exit after failure. - // helper functions: - Date next_weekday(Date); - bool operator==(Date, Date); +##### Example -The "helper functions" have no need for direct access to the representation of a `Date`. +Put `noexcept` on every function written completely in C or in any other language without exceptions. +The C++ Standard Library does that implicitly for all functions in the C Standard Library. -**Note**: This rule becomes even better if C++17 gets "uniform function call." ??? +##### Note -**Enforcement**: Look for member function that do not touch data members directly. -The snag is that many member functions that do not need to touch data members directly do. +`constexpr` functions can throw when evaluated at run time, so you might need conditional `noexcept` for some of those. +##### Example - -### C.5: Place helper functions in the same namespace as the class they support +You can use `noexcept` even on functions that can throw: -**Reason**: A helper function is a function (usually supplied by the writer of a class) that does not need direct access to the representation of the class, -yet is seen as part of the useful interface to the class. -Placing them in the same namespace as the class makes their relationship to the class obvious and allows them to be found by argument dependent lookup. + vector collect(istream& is) noexcept + { + vector res; + for (string s; is >> s;) + res.push_back(s); + return res; + } -**Example**: - - namespace Chrono { // here we keep time-related services - - class Time { /* ... */ }; - class Date { /* ... */ }; - - // helper functions: - bool operator==(Date,Date); - Date next_weekday(Date); - // ... - } - -**Enforcement**: +If `collect()` runs out of memory, the program crashes. +Unless the program is crafted to survive memory exhaustion, that might be just the right thing to do; +`terminate()` might generate suitable error log information (but after memory runs out it is hard to do anything clever). -* Flag global functions taking argument types from a single namespace. +##### Note - - -### C.6: Declare a member function that does not modify the state of its object `const` +You must be aware of the execution environment that your code is running when +deciding whether to tag a function `noexcept`, especially because of the issue +of throwing and allocation. Code that is intended to be perfectly general (like +the standard library and other utility code of that sort) needs to support +environments where a `bad_alloc` exception could be handled meaningfully. +However, most programs and execution environments cannot meaningfully +handle a failure to allocate, and aborting the program is the cleanest and +simplest response to an allocation failure in those cases. If you know that +your application code cannot respond to an allocation failure, it could be +appropriate to add `noexcept` even on functions that allocate. -**Reason**: More precise statement of design intent, better readability, more errors caught by the compiler, more optimization opportunities. +Put another way: In most programs, most functions can throw (e.g., because they +use `new`, call functions that do, or use library functions that reports failure +by throwing), so don't just sprinkle `noexcept` all over the place without +considering whether the possible exceptions can be handled. -**Example**: +`noexcept` is most useful (and most clearly correct) for frequently used, +low-level functions. - int Date::day() const { return d; } +##### Note -**Note**: [Do not cast away `const`](#Res-casts-const). +Destructors, `swap` functions, move operations, and default constructors should never throw. +See also [C.44](#Rc-default00). -**Enforcement**: Flag non-`const` member functions that do not write to their objects +##### Note +Care must be taken on base virtual functions and functions part of a public interface because declaring a function `noexcept` is establishing a guarantee that all current and future implementations must abide by. For virtual function, all overriders must also be `noexcept` and removing `noexcept` from a function could break calling functions. - -## C.concrete: Concrete types +##### Enforcement -One ideal for a class is to be a regular type. -That means roughly "behaves like an `int`." A concrete type is the simplest kind of class. -A value of regular type can be copied and the result of a copy is an independent object with the same value as the original. -If a concrete type has both `=` and `==`, `a=b` should result in `a==b` being `true`. -Concrete classes without assignment and equality can be defined, but they are (and should be) rare. -The C++ built-in types are regular, and so are standard-library classes, such as `string`, `vector`, and `map`. -Concrete types are also often referred to as value types to distinguish them from types uses as part of a hierarchy. +* (hard) Flag low-level functions that are not `noexcept`, yet cannot throw. +* Flag throwing `swap`, `move`, destructors, and default constructors. -Concrete type rule summary: +### F.7: For general use, take `T*` or `T&` arguments rather than smart pointers -* [C.10: Prefer a concrete type over more complicated classes](#Rc-concrete) -* [C.11: Make a concrete types regular](#Rc-regular) +##### Reason +Passing a smart pointer transfers or shares ownership and should only be used when ownership semantics are intended. +A function that does not manipulate lifetime should take raw pointers or references instead. - -### C.10 Prefer a concrete type over more complicated classes +Passing by smart pointer restricts the use of a function to callers that use smart pointers. +A function that needs a `widget` should be able to accept any `widget` object, not just ones whose lifetimes are managed by a particular kind of smart pointer. -**Reason**: A concrete type is fundamentally simpler than a hierarchy: -easier to design, easier to implement, easier to use, easier to reason about, smaller, and faster. -You need a reason (use cases) for using a hierarchy. +Passing a shared smart pointer (e.g., `std::shared_ptr`) implies a run-time cost. -**Example** +##### Example - class Point1 { - int x, y; - // ... operations ... - // .. no virtual functions ... - }; + // accepts any int* + void f(int*); - class Point2 { - int x, y; - // ... operations, some virtual ... - virtual ~Point2(); - }; + // can only accept ints for which you want to transfer ownership + void g(unique_ptr); - void use() - { - Point1 p11 { 1,2}; // make an object on the stack - Point1 p12 {p11}; // a copy + // can only accept ints for which you are willing to share ownership + void g(shared_ptr); - auto p21 = make_unique(1,2); // make an object on the free store - auto p22 = p21.clone(); // make a copy + // doesn't change ownership, but requires a particular ownership of the caller + void h(const unique_ptr&); - // ... - } + // accepts any int + void h(int&); -If a class can be part of a hierarchy, we (in real code if not necessarily in small examples) must manipulate its objects through pointers or references. -That implies more memory overhead, more allocations and deallocations, and more run-time overhead to perform the resulting indirections. +##### Example, bad -**Note**: Concrete types can be stack allocated and be members of other classes. + // callee + void f(shared_ptr& w) + { + // ... + use(*w); // only use of w -- the lifetime is not used at all + // ... + }; -**Note**: The use of indirection is fundamental for run-time polymorphic interfaces. -The allocation/deallocation overhead is not (that's just the most common case). -We can use a base class as the interface of a scoped object of a derived class. -This is done where dynamic allocation is prohibited (e.g. hard real-time) and to provide a stable interface to some kinds of plug-ins. + // caller + shared_ptr my_widget = /* ... */; + f(my_widget); -**Enforcement**: ??? + widget stack_widget; + f(stack_widget); // error +##### Example, good - -### C.11: Make a concrete types regular + // callee + void f(widget& w) + { + // ... + use(w); + // ... + }; -**Reason**: Regular types are easier to understand and reason about than types that are not regular (irregularities requires extra effort to understand and use). + // caller + shared_ptr my_widget = /* ... */; + f(*my_widget); -**Example**: + widget stack_widget; + f(stack_widget); // ok -- now this works - struct Bundle { - string name; - vector vr; - }; +##### Note - bool operator==(const Bundle& a, const Bundle& b) { return a.name==b.name && a.vr==b.vr; } +We can catch many common cases of dangling pointers statically (see [lifetime safety profile](#SS-lifetime)). Function arguments naturally live for the lifetime of the function call, and so have fewer lifetime problems. - Bundle b1 { "my bundle", {r1,r2,r3}}; - Bundle b2 = b1; - if (!(b1==b2)) error("impossible!"); - b2.name = "the other bundle"; - if (b1==b2) error("No!"); +##### Enforcement -In particular, if a concrete type has an assignment also give it an equals operator so that `a=b` implies `a==b`. +* (Simple) Warn if a function takes a parameter of a smart pointer type (that overloads `operator->` or `operator*`) that is copyable but the function only calls any of: `operator*`, `operator->` or `get()`. + Suggest using a `T*` or `T&` instead. +* Flag a parameter of a smart pointer type (a type that overloads `operator->` or `operator*`) that is copyable/movable but never copied/moved from in the function body, and that is never modified, and that is not passed along to another function that could do so. That means the ownership semantics are not used. + Suggest using a `T*` or `T&` instead. -**Enforcement**: ??? +**See also**: +* [Prefer `T*` over `T&` when "no argument" is a valid option](#Rf-ptr-ref) +* [Smart pointer rule summary](#Rr-summary-smartptrs) - -## C.ctor: Constructors, assignments, and destructors +### F.8: Prefer pure functions -These functions control the lifecycle of objects: creation, copy, move, and destruction. -Define constructors to guarantee and simplify initialization of classes. +##### Reason -These are *default operations*: +Pure functions are easier to reason about, sometimes easier to optimize (and even parallelize), and sometimes can be memoized. -* a default constructor: `X()` -* a copy constructor: `X(const X&)` -* a copy assignment: `operator=(const X&)` -* a move constructor: `X(X&&)` -* a a move assignment: `operator=(X&&)` -* a destructor: `~X()` +##### Example -By default, the compiler defines each of these operations if it is used, but the default can be suppressed. + template + auto square(T t) { return t * t; } -The default operations are a set of related operations that together implement the lifecycle semantics of an object. -By default, C++ treats classes as value-like types, but not all types are value-like. +##### Enforcement -Set of default operations rules: +Not possible. -* [C.20: If you can avoid defining any default operations, do](#Rc-zero) -* [C.21: If you define or `=delete` any default operation, define or `=delete` them all](#Rc-five) -* [C.22: Make default operations consistent](#Rc-matched) +### F.9: Unused parameters should be unnamed -Destructor rules: +##### Reason -* [C.30: Define a destructor if a class needs an explicit action at object destruction](#Rc-dtor) -* [C.31: All resources acquired by a class must be released by the class's destructor](#Rc-dtor-release) -* [C.32: If a class has a raw pointer (`T*`) or reference (`T&`), consider whether it might be owning](#Rc-dtor-ptr) -* [C.33: If a class has an owning pointer member, define or `=delete` a destructor](#Rc-dtor-ptr) -* [C.34: If a class has an owning reference member, define or `=delete` a destructor](#Rc-dtor-ref) -* [C.35: A base class with a virtual function needs a virtual destructor](#Rc-dtor-virtual) -* [C.36: A destructor may not fail](#Rc-dtor-fail) -* [C.37: Make destructors `noexcept`](#Rc-dtor-noexcept) +Readability. +Suppression of unused parameter warnings. -Constructor rules: +##### Example -* [C.40: Define a constructor if a class has an invariant](#Rc-ctor) -* [C.41: A constructor should create a fully initialized object](#Rc-complete) -* [C.42: If a constructor cannot construct a valid object, throw an exception](#Rc-throw) -* [C.43: Give a class a default constructor](#Rc-default0) -* [C.44: Prefer default constructors to be simple and non-throwing](#Rc-default00) -* [C.45: Don't define a default constructor that only initializes data members; use member initializers instead](#Rc-default) -* [C.46: By default, declare single-argument constructors `explicit`](#Rc-explicit) -* [C.47: Define and initialize member variables in the order of member declaration](#Rc-order) -* [C.48: Prefer in-class initializers to member initializers in constructors for constant initializers](#Rc-in-class-initializer) -* [C.49: Prefer initialization to assignment in constructors](#Rc-initialize) -* [C.50: Use a factory function if you need "virtual behavior" during initialization](#Rc-factory) -* [C.51: Use delegating constructors to represent common actions for all constructors of a class](#Rc-delegating) -* [C.52: Use inheriting constructors to import constructors into a derived class that does not need further explicit initialization](#Rc-inheriting) + widget* find(const set& s, const widget& w, Hint); // once upon a time, a hint was used -Copy and move rules: +##### Note -* [C.60: Make copy assignment non-`virtual`, take the parameter by `const&`, and return by non-`const&`](#Rc-copy-assignment) -* [C.61: A copy operation should copy](#Rc-copy-semantic) -* [C.62: Make copy assignment safe for self-assignment](#Rc-move-self) -* [C.63: Make move assignment non-`virtual`, take the parameter by `&&`, and return by non-`const&`](#Rc-move-assignment) -* [C.64: A move operation should move and leave its source in a valid state](#Rc-move-semantic) -* [C.65: Make move assignment safe for self-assignment](#Rc-copy-self) -* [C.66: Make move operations `noexcept`](#Rc-move-noexcept) -* [C.67: A base class should suppress copying, and provide a virtual `clone` instead if "copying" is desired](#Rc-copy-virtual) +Allowing parameters to be unnamed was introduced in the early 1980s to address this problem. -Other default operations rules: +If parameters are conditionally unused, declare them with the `[[maybe_unused]]` attribute. +For example: -* [C.80: Use `=default` if you have to be explicit about using the default semantics](#Rc-=default) -* [C.81: Use `=delete` when you want to disable default behavior (without wanting an alternative)](#Rc-=delete) -* [C.82: Don't call virtual functions in constructors and destructors](#Rc-ctor-virtual) -* [C.83: For value-like types, consider providing a `noexcept` swap function](#Rc-swap) -* [C.84: A `swap` may not fail](#Rc-swap-fail) -* [C.85: Make `swap` `noexcept`](#Rc-swap-noexcept) -* [C.86: Make `==` symmetric with respect of operand types and `noexcept`](#Rc-eq) -* [C.87: Beware of `==` on base classes](#Rc-eq-base) -* [C.88: Make `<` symmetric with respect of operand types and `noexcept`](#Rc-lt) -* [C.89: Make a `hash` `noexcept`](#Rc-hash) + template + Value* find(const set& s, const Value& v, [[maybe_unused]] Hint h) + { + if constexpr (sizeof(Value) > CacheSize) + { + // a hint is used only if Value is of a certain size + } + } +##### Enforcement - -## C.defop: Default Operations +Flag named unused parameters. -By default, the language supply the default operations with their default semantics. -However, a programmer can disalble or replace these defaults. +### F.10: If an operation can be reused, give it a name +##### Reason - -### C.20: If you can avoid defining default operations, do +Documentation, readability, opportunity for reuse. -**Reason**: It's the simplest and gives the cleanest semantics. +##### Example -**Example**: + struct Rec { + string name; + string addr; + int id; // unique identifier + }; - struct Named_map { - public: - // ... no default operations declared ... - private: - string name; - map rep; - }; + bool same(const Rec& a, const Rec& b) + { + return a.id == b.id; + } - Named_map nm; // default construct - Named_map nm2 {nm}; // copy construct + vector find_id(const string& name); // find all records for "name" -Since `std::map` and `string` have all the special functions, not further work is needed. + auto x = find_if(vr.begin(), vr.end(), + [&](Rec& r) { + if (r.name.size() != n.size()) return false; // name to compare to is in n + for (int i = 0; i < r.name.size(); ++i) + if (tolower(r.name[i]) != tolower(n[i])) return false; + return true; + } + ); -**Note**: This is known as "the rule of zero". +There is a useful function lurking here (case insensitive string comparison), as there often is when lambda arguments get large. -**Enforcement**: (Not enforceable) While not enforceable, a good static analyzer can detect patterns that indicate a possible improvement to meet this rule. - For example, a class with a (pointer,size) pair of member and a destructor that `delete`s the pointer could probably be converted to a `vector`. + bool compare_insensitive(const string& a, const string& b) + { + if (a.size() != b.size()) return false; + for (int i = 0; i < a.size(); ++i) if (tolower(a[i]) != tolower(b[i])) return false; + return true; + } + auto x = find_if(vr.begin(), vr.end(), + [&](Rec& r) { return compare_insensitive(r.name, n); } + ); - -### C.21: If you define or `=delete` any default operation, define or `=delete` them all +Or maybe (if you prefer to avoid the implicit name binding to n): -**Reason**: The semantics of the special functions are closely related, so it one needs to be non-default, the odds are that other need modification. + auto cmp_to_n = [&n](const string& a) { return compare_insensitive(a, n); }; -**Example, bad**: + auto x = find_if(vr.begin(), vr.end(), + [](const Rec& r) { return cmp_to_n(r.name); } + ); - struct M2 { // bad: incomplete set of default operations - public: - // ... - // ... no copy or move operations ... - ~M2() { delete[] rep; } - private: - pair* rep; // zero-terminated set of pairs - }; +##### Note - void use() - { - M2 x; - M2 y; - // ... - x = y; // the default assignment - // ... - } +whether functions, lambdas, or operators. -Given that "special attention" was needed for the destructor (here, to deallocate), the likelihood that copy and move assignment (both will implicitly destroy an object) are correct is low (here, we would get double deletion). +##### Exception -**Note**: This is known as "the rule of five" or "the rule of six", depending on whether you count the default constructor. +* Lambdas logically used only locally, such as an argument to `for_each` and similar control flow algorithms. +* Lambdas as [initializers](#???) -**Note**: If you want a default implementation of a default operation (while defining another), write `=default` to show you're doing so intentionally for that function. -If you don't want a default operation, suppress it with `=delete`. +##### Enforcement -**Note:** Compilers enforce much of this rule and ideally warn about any violation. +* (hard) flag similar lambdas +* ??? -**Note**: Relying on an implicitly generated copy operation in a class with a destructor is deprecated. +### F.11: Use an unnamed lambda if you need a simple function object in one place only -**Enforcement**: (Simple) A class should have a declaration (even a `=delete` one) for either all or none of the special functions. +##### Reason +That makes the code concise and gives better locality than alternatives. - -### C.22: Make default operations consistent +##### Example -**Reason**: The default operations are conceptually a matched set. Their semantics is interrelated. -Users will be surprised if copy/move construction and copy/move assignment do logically different things. Users will be surprised if constructors and destructors do not provide a consistent view of resource management. Users will be surprised if copy and move doesn't reflect the way constructors and destructors work. + auto earlyUsersEnd = std::remove_if(users.begin(), users.end(), + [](const User &a) { return a.id > 100; }); -**Example; bad**: - class Silly { // BAD: Inconsistent copy operations - class Impl { - // ... - }; - shared_ptr p; - public: - Silly(const Silly& a) : p{a.p} { *p = *a.p; } // deep copy - Silly& operator=(const Silly& a) { p = a.p; } // shallow copy - // ... - }; +##### Exception -These operations disagree about copy semantics. This will lead to confusion and bugs. +Naming a lambda can be useful for clarity even if it is used only once. -**Enforcement**: +##### Enforcement -* (Complex) A copy/move constructor and the corresponding copy/move assignment operator should write to the same member variables at the same level of dereference. -* (Complex) Any member variables written in a copy/move constructor should also be initialized by all other constructors. -* (Complex) If a copy/move constructor performs a deep copy of a member variable, then the destructor should modify the member variable. -* (Complex) If a destructor is modifying a member variable, that member variable should be written in any copy/move constructors or assignment operators. +* Look for identical and near identical lambdas (to be replaced with named functions or named lambdas). +## F.call: Parameter passing +There are a variety of ways to pass parameters to a function and to return values. - -## C.dtor: Destructors +### F.15: Prefer simple and conventional ways of passing information -Does this class need a destructor is a surprisingly powerful design question. -For most classes the answer is "no" either because the class holds no resources or because destruction is handled by [the rule of zero](#Rc-zero); -that is, its members can take care of themselves as concerns destruction. -If the answer is "yes", much of the design of the class follows (see [the rule of five](#Rc-five). +##### Reason +Using "unusual and clever" techniques causes surprises, slows understanding by other programmers, and encourages bugs. +If you really feel the need for an optimization beyond the common techniques, measure to ensure that it really is an improvement, and document/comment because the improvement might not be portable. - -### C.30: Define a destructor if a class needs an explicit action at object destruction +The following tables summarize the advice in the following Guidelines, F.16-21. -**Reason**: A destructor is implicitly invoked at the end of an objects lifetime. -If the default destructor is sufficient, use it. -Only if you need code that is not simply destructors of members executed, define a non-default destructor. +Normal parameter passing: -**Example**: +![Normal parameter passing table](./param-passing-normal.png "Normal parameter passing") - template - struct Final_action { // slightly simplified - A act; - Final_action(F a) :act{a} {} - ~Final_action() { act(); } - }; +Advanced parameter passing: - template - Final_action finally(A act) // deduce action type - { - return Final_action{a}; - } +![Advanced parameter passing table](./param-passing-advanced.png "Advanced parameter passing") - void test() - { - auto act = finally([]{ cout<<"Exit test\n"; }); // establish exit action - // ... - if (something) return; // act done here - // ... - } // act done here +Use the advanced techniques only after demonstrating need, and document that need in a comment. -The whole purpose of `Final_action` is to get a piece of code (usually a lambda) executed upon destruction. +For passing sequences of characters see [String](#SS-string). -**Note**: There are two general categories of classes that need a user-defined destructor: +##### Exception -* A class with a resource that is not already represented as a class with a destructor, e.g., a `vector` or a transaction class. -* A class that exists primarily to execute an action upon destruction, such as a tracer or `Final_action`. +To express shared ownership using `shared_ptr` types, rather than following guidelines F.16-21, +follow [R.34](#Rr-sharedptrparam-owner), [R.35](#Rr-sharedptrparam), and [R.36](#Rr-sharedptrparam-const). -**Example, bad**: +### F.16: For "in" parameters, pass cheaply-copied types by value and others by reference to `const` - class Foo { // bad; use the default destructor - public: - // ... - ~Foo() { s=""; i=0; vi.clear(); } // clean up - private: - string s; - int i; - vector vi; - } +##### Reason -The default destructor does it better, more efficiently, and can't get it wrong. +Both let the caller know that a function will not modify the argument, and both allow initialization by rvalues. -**Note**: If the default destructor is needed, but its generation has been suppressed (e.g., by defining a move constructor), use `=default`. +What is "cheap to copy" depends on the machine architecture, but two or three words (doubles, pointers, references) are usually best passed by value. +When copying is cheap, nothing beats the simplicity and safety of copying, and for small objects (up to two or three words) it is also faster than passing by reference because it does not require an extra indirection to access from the function. -**Enforcement**: Look for likely "implicit resources", such as pointers and references. Look for classes with destructors even though all their data members have destructors. +##### Example + void f1(const string& s); // OK: pass by reference to const; always cheap - -### C.31: All resources acquired by a class must be released by the class's destructor + void f2(string s); // bad: potentially expensive -**Reason**: Prevention of resource leaks, especially in error cases. + void f3(int x); // OK: Unbeatable -**Note**: For resources represented as classes with a complete set of default operations, this happens automatically. + void f4(const int& x); // bad: overhead on access in f4() -**Example**: +For advanced uses (only), where you really need to optimize for rvalues passed to "input-only" parameters: - class X { - ifstream f; // may own a file - // ... no default operations defined or =deleted ... - }; +* If the function is going to unconditionally move from the argument, take it by `&&`. See [F.18](#Rf-consume). +* If the function is going to keep a locally modifiable copy of the argument only for its own local use, taking it by value is fine +* If the function is going to keep a copy of the argument to pass to another destination (to another function, or store in a non-local location), in addition to passing by `const&` (for lvalues), + add an overload that passes the parameter by `&&` (for rvalues) and in the body `std::move`s it to its destination. Essentially this overloads a "will-move-from"; see [F.18](#Rf-consume). +* In special cases, such as multiple "input + copy" parameters, consider using perfect forwarding. See [F.19](#Rf-forward). -`X`'s `ifstream` implicitly closes any file it may have open upon destruction of its `X`. +##### Example -**Example; bad**: + int multiply(int, int); // just input ints, pass by value - class X2 { // bad - FILE* f; // may own a file - // ... no default operations defined or =deleted ... - }; + // suffix is input-only but not as cheap as an int, pass by const& + string& concatenate(string&, const string& suffix); -`X2` may leak a file handle. + void sink(unique_ptr); // input only, and moves ownership of the widget -**Note**: What about a sockets that won't close? A destructor, close, or cleanup operation [should never fail](#Rc-dtor-fail). -If it does nevertheless, we have a problem that has no really good solution. -For starters, the writer of a destructor does not know why the destructor is called and cannot "refuse to act" by throwing an exception. -See [discussion](#Sd-never-fail). -To make the problem worse, many "close/release" operations are not retryable. -Many have tried to solve this problem, but no general solution is known. -If at all possible, consider failure to close/cleanup a fundamental design error and terminate. +Avoid "esoteric techniques" such as passing arguments as `T&&` "for efficiency". +Most rumors about performance advantages from passing by `&&` are false or brittle (but see [F.18](#Rf-consume) and [F.19](#Rf-forward)). -**Note**: A class can hold pointers and references to objects that it does not own. -Obviously, such objects should not be `delete`d by the class's destructor. -For example: +##### Notes - Preprocessor pp { /* ... */ }; - Parser p { pp, /* ... */ }; - Type_checker tc { p, /* ... */ }; +A reference can be assumed to refer to a valid object (language rule). +There is no (legitimate) "null reference." +If you need the notion of an optional value, use a pointer, `std::optional`, or a special value used to denote "no value." -Here `p` refers to `pp` but does not own it. +##### Enforcement -**Enforcement**: +* (Simple) ((Foundation)) Warn when a parameter being passed by value has a size greater than `2 * sizeof(void*)`. + Suggest using a reference to `const` instead. +* (Simple) ((Foundation)) Warn when a parameter passed by reference to `const` has a size less or equal than `2 * sizeof(void*)`. Suggest passing by value instead. +* (Simple) ((Foundation)) Warn when a parameter passed by reference to `const` is `move`d. -* (Simple) If a class has pointer or reference member variables that are owners -(e.g., deemed owners by using `GSL::owner`), then they should be referenced in its destructor. -* (Hard) Determine if pointer or reference member variables are owners when there is no explicit statement of ownership -(e.g., look into the constructors). +##### Exception +To express shared ownership using `shared_ptr` types, follow [R.34](#Rr-sharedptrparam-owner) or [R.36](#Rr-sharedptrparam-const), +depending on whether or not the function unconditionally takes a reference to the argument. - -### C.32: If a class has a raw pointer (`T*`) or reference (`T&`), consider whether it might be owning +### F.17: For "in-out" parameters, pass by reference to non-`const` -**Reason**: There is a lot of code that is non-specific about ownership. +##### Reason -**Example**: +This makes it clear to callers that the object is assumed to be modified. - ??? +##### Example -**Note**: If the `T*` or `T&` is owning, mark it `owning`. If the `T*` is not owning, consider marking it `ptr`. -This will aide documentation and analysis. + void update(Record& r); // assume that update writes to r -**Enforcement**: Look at the initialization of raw member pointers and member references and see if an allocation is used. +##### Note +Some user-defined and standard library types, such as `span` or the iterators +are [cheap to copy](#Rf-in) and may be passed by value, while doing so has +mutable (in-out) reference semantics: - -### C.33: If a class has an owning pointer member, define a destructor + void increment_all(span a) + { + for (auto&& e : a) + ++e; + } -**Reason**: An owned object must be `deleted` upon destruction of the object that owns it. +##### Note -**Example**: A pointer member may represent a resource. -[A `T*` should not do so](#Rr-ptr), but in older code, that's common. -Consider a `T*` a possible owner and therefore suspect. +A `T&` argument can pass information into a function as well as out of it. +Thus `T&` could be an in-out-parameter. That can in itself be a problem and a source of errors: - template - class Smart_ptr { - T* p; // BAD: vague about ownership of *p - // ... - public: - // ... no user-defined default operations ... - }; + void f(string& s) + { + s = "New York"; // non-obvious error + } - void use(Smart_ptr p1) - { - auto p2 = p1; // error: p2.p leaked (if not nullptr and not owned by some other code) - } + void g() + { + string buffer = "................................."; + f(buffer); + // ... + } -Note that if you define a destructor, you must define or delete [all default operations](#Rc-five): +Here, the writer of `g()` is supplying a buffer for `f()` to fill, but `f()` simply replaces it (at a somewhat higher cost than a simple copy of the characters). +A bad logic error can happen if the writer of `g()` incorrectly assumes the size of the `buffer`. - template - class Smart_ptr2 { - T* p; // BAD: vague about ownership of *p - // ... - public: - // ... no user-defined copy operations ... - ~Smart_ptr2() { delete p; } // p is an owner! - }; +##### Enforcement - void use(Smart_ptr p1) - { - auto p2 = p1; // error: double deletion - } +* (Moderate) ((Foundation)) Warn about functions regarding reference to non-`const` parameters that do *not* write to them. +* (Simple) ((Foundation)) Warn when a non-`const` parameter being passed by reference is `move`d. -The default copy operation will just copy the `p1.p` into `p2.p` leading to a double destruction of `p1.p`. Be explicit about ownership: +### F.18: For "will-move-from" parameters, pass by `X&&` and `std::move` the parameter - template - class Smart_ptr3 { - owner* p; // OK: explicit about ownership of *p - // ... - public: - // ... - // ... copy and move operations ... - ~Smart_ptr3() { delete p; } - }; +##### Reason - void use(Smart_ptr3 p1) - { - auto p2 = p1; // error: double deletion - } +It's efficient and eliminates bugs at the call site: `X&&` binds to rvalues, which requires an explicit `std::move` at the call site if passing an lvalue. +##### Example - **Note**: Often the simplest way to get a destructor is to replace the pointer with a smart pointer (e.g., `std::unique_ptr`) - and let the compiler arrange for proper destruction to be done implicitly. - -**Note**: Why not just require all owning pointers to be "smart pointers"? - That would sometimes require non-trivial code changes and may affect ABIs. + void sink(vector&& v) // sink takes ownership of whatever the argument owned + { + // usually there might be const accesses of v here + store_somewhere(std::move(v)); + // usually no more use of v here; it is moved-from + } -**Enforcement**: +Note that the `std::move(v)` makes it possible for `store_somewhere()` to leave `v` in a moved-from state. +[That could be dangerous](#Rc-move-semantic). -* A class with a pointer data member is suspect. -* A class with an `owner` should define its default operations. +##### Exception - -### C.34: If a class has an owning reference member, define a destructor +Unique owner types that are move-only and cheap-to-move, such as `unique_ptr`, can also be passed by value which is simpler to write and achieves the same effect. Passing by value does generate one extra (cheap) move operation, but prefer simplicity and clarity first. -**Reason**: A reference member may represent a resource. -It should not do so, but in older code, that's common. -See [pointer members and destructors](#Rc-dtor ptr). -Also, copying may lead to slicing. +For example: -**Example, bad**: + template + void sink(std::unique_ptr p) + { + // use p ... possibly std::move(p) onward somewhere else + } // p gets destroyed - class Handle { // Very suspect - Shape& s; // use reference rather than pointer to prevent rebinding - // BAD: vague about ownership of *p - // ... - public: - Handle(Shape& ss) : s{ss} { /* ... */ } - // ... - }; +##### Exception -The problem of whether `Handle` is responsible for the destruction of its `Shape` is the same as for the pointer case: -If the `Handle` owns the object referred to by `s` it must have a destructor. +If the "will-move-from" parameter is a `shared_ptr` follow [R.34](#Rr-sharedptrparam-owner) and pass the `shared_ptr` by value. -**Example**: +##### Enforcement - class Handle { // OK - owner s; // use reference rather than pointer to prevent rebinding - // ... - public: - Handle(Shape& ss) : s{ss} { /* ... */ } - ~Handle() { delete &s; } - // ... - }; +* Flag all `X&&` parameters (where `X` is not a template type parameter name) where the function body uses them without `std::move`. +* Flag access to moved-from objects. +* Don't conditionally move from objects -Independently of whether `Handle` owns its `Shape`, we must consider the default copy operations suspect: +### F.19: For "forward" parameters, pass by `TP&&` and only `std::forward` the parameter - Handle x {*new Circle{p1,17}}; // the Handle had better own the Circle or we have a leak - Handle y {*new Triangle{p1,p2,p3}}; - x = y; // the default assignment will try *x.s=*y.s +##### Reason -That `x=y` is highly suspect. -Assigning a `Triangle` to a `Circle`? -Unless `Shape` has its [copy assignment `=deleted`](#Rc-copy-virtual), only the `Shape` part of `Triangle` is copied into the `Circle`. +If the object is to be passed onward to other code and not directly used by this function, we want to make this function agnostic to the argument `const`-ness and rvalue-ness. +In that case, and only that case, make the parameter `TP&&` where `TP` is a template type parameter -- it both *ignores* and *preserves* `const`-ness and rvalue-ness. Therefore any code that uses a `TP&&` is implicitly declaring that it itself doesn't care about the variable's `const`-ness and rvalue-ness (because it is ignored), but that intends to pass the value onward to other code that does care about `const`-ness and rvalue-ness (because it is preserved). When used as a parameter `TP&&` is safe because any temporary objects passed from the caller will live for the duration of the function call. A parameter of type `TP&&` should essentially always be passed onward via `std::forward` in the body of the function. -**Note**: Why not just require all owning references to be replaced by "smart pointers"? - Changing from references to smart pointers implies code changes. - We don't (yet) have smart references. - Also, that may affect ABIs. +##### Example -**Enforcement**: +Usually you forward the entire parameter (or parameter pack, using `...`) exactly once on every static control flow path: -* A class with a reference data member is suspect. -* A class with an `owner` reference should define its default operations. + template + inline decltype(auto) invoke(F&& f, Args&&... args) + { + return forward(f)(forward(args)...); + } +##### Example - -### C.35: A base class with a virtual function needs a virtual destructor +Sometimes you may forward a composite parameter piecewise, each subobject once on every static control flow path: -**Reason**: To prevent undefined behavior. -If an application attempts to delete a derived class object through a base class pointer, the result is undefined if the base class's destructor is non-virtual. -In general, the writer of a base class does not know the appropriate action to be done upon destruction. + template + inline auto test(PairLike&& pairlike) + { + // ... + f1(some, args, and, forward(pairlike).first); // forward .first + f2(and, forward(pairlike).second, in, another, call); // forward .second + } -**Example; bad**: +##### Enforcement - struct Base { // BAD: no virtual destructor - virtual f(); - }; +* Flag a function that takes a `TP&&` parameter (where `TP` is a template type parameter name) and does anything with it other than `std::forward`ing it exactly once on every static path, or `std::forward`ing it more than once but qualified with a different data member exactly once on every static path. - struct D : Base { - string s {"a resource needing cleanup"}; - ~D() { /* ... do some cleanup ... */ } - // ... - }; +### F.20: For "out" output values, prefer return values to output parameters - void use() - { - unique_ptr p = make_unique(); - // ... - } // p's destruction calls ~Base(), not ~D(), which leaks D::s and possibly more +##### Reason -**Note**: A virtual function defines an interface to derived classes that can be used without looking at the derived classes. -Someone using such an interface is likely to also destroy using that interface. +A return value is self-documenting, whereas a `&` could be either in-out or out-only and is liable to be misused. -**Note**: A destructor must be `public` or it will prevent stack allocation and normal heap allocation via smart pointer (or in legacy code explicit `delete`): +This includes large objects like standard containers that use implicit move operations for performance and to avoid explicit memory management. - class X { - ~X(); // private destructor - // ... - }; +If you have multiple values to return, [use a tuple](#Rf-out-multi) or similar multi-member type. - void use() - { - X a; // error: cannot destroy - auto p = make_unique(); // error: cannot destroy - } +##### Example -**Enforcement**: (Simple) A class with any virtual functions should have a virtual destructor. + // OK: return pointers to elements with the value x + vector find_all(const vector&, int x); + // Bad: place pointers to elements with value x in-out + void find_all(const vector&, vector& out, int x); - -### C.36: A destructor may not fail +##### Note -**Reason**: In general we do not know how to write error-free code if a destructor should fail. -The standard library requires that all classes it deals with have destructors that do not exit by throwing. +A `struct` of many (individually cheap-to-move) elements might be in aggregate expensive to move. -**Example**: +##### Exceptions - class X { - public: - ~X() noexcept; - // ... - }; +* For non-concrete types, such as types in an inheritance hierarchy, return the object by `unique_ptr` or `shared_ptr`. +* If a type is expensive to move (e.g., `array`), consider allocating it on the free store and return a handle (e.g., `unique_ptr`), or passing it in a reference to non-`const` target object to fill (to be used as an out-parameter). +* To reuse an object that carries capacity (e.g., `std::string`, `std::vector`) across multiple calls to the function in an inner loop: [treat it as an in/out parameter and pass by reference](#Rf-out-multi). - X::~X() noexcept - { - // ... - if (cannot_release_a_resource) terminate(); - // ... - } +##### Example -**Note**: Many have tried to devise a fool-proof scheme for dealing with failure in destructors. -None have succeeded to come up with a general scheme. -This can be be a real practical problem: For example, what about a sockets that won't close? -The writer of a destructor does not know why the destructor is called and cannot "refuse to act" by throwing an exception. -See discussion. -To make the problem worse, many "close/release" operations are not retryable. -If at all possible, consider failure to close/cleanup a fundamental design error and terminate. +Assuming that `Matrix` has move operations (possibly by keeping its elements in a `std::vector`): -**Note**: Declare a destructor `noexcept`. That will ensure that it either completes normally or terminate the program. + Matrix operator+(const Matrix& a, const Matrix& b) + { + Matrix res; + // ... fill res with the sum ... + return res; + } -**Note**: If a resource cannot be released and the program may not fail, try to signal the failure to the rest of the system somehow -(maybe even by modifying some global state and hope something will notice and be able to take care of the problem). -Be fully aware that this technique is special-purpose and error-prone. -Consider the "my connection will not close" example. -Probably there is a problem at the other end of the connection and only a piece of code responsible for both ends of the connection can properly handle the problem. -The destructor could send a message (somehow) to the responsible part of the system, consider that to have closed the connection, and return normally. + Matrix x = m1 + m2; // move constructor -**Note**: If a destructor uses operations that may fail, it can catch exceptions and in some cases still complete successfully -(e.g., by using a different clean-up mechanism from the one that threw an exception). + y = m3 + m3; // move assignment -**Enforcement**: (Simple) A destructor should be declared `noexcept`. +##### Note - -### C.37: Make destructors `noexcept` +The return value optimization doesn't handle the assignment case, but the move assignment does. -**Reason**: [A destructor may not fail](#Rc-dtor fail). If a destructor tries to exit with an exception, it's a bad design error and the program had better terminate. +##### Example -**Enforcement**: (Simple) A destructor should be declared `noexcept`. + struct Package { // exceptional case: expensive-to-move object + char header[16]; + char load[2024 - 16]; + }; + Package fill(); // Bad: large return value + void fill(Package&); // OK + int val(); // OK + void val(int&); // Bad: Is val reading its argument - -## C.ctor: Constructors +##### Enforcement -A constuctor defined how an object is initialized (constructed). +* Flag reference to non-`const` parameters that are not read before being written to and are a type that could be cheaply returned; they should be "out" return values. +### F.21: To return multiple "out" values, prefer returning a struct - -### C.40: Define a constructor if a class has an invariant +##### Reason -**Reason**: That's what constructors are for. +A return value is self-documenting as an "output-only" value. +Note that C++ does have multiple return values, by convention of using tuple-like types (`struct`, `array`, `tuple`, etc.), +possibly with the extra convenience of structured bindings (C++17) at the call site. +Prefer using a named `struct` if possible. +Otherwise, a `tuple` is useful in variadic templates. -**Example**: +##### Example - class Date { // a Date represents a valid date - // in the January 1, 1900 to December 31, 2100 range - Date(int dd, int mm, int yy) - :d{dd}, m{mm}, y{yy} - { - if (!is_valid(d,m,y)) throw Bad_date{}; // enforce invariant - } - // ... - private: - int d,m,y; - }; + // BAD: output-only parameter documented in a comment + int f(const string& input, /*output only*/ string& output_data) + { + // ... + output_data = something(); + return status; + } -It is often a good idea to express the invariant as an `Ensure` on the constructor. + // GOOD: self-documenting + struct f_result { int status; string data; }; -**Note**: A constructor can be used for convenience even if a class does not have an invariant. For example: + f_result f(const string& input) + { + // ... + return {status, something()}; + } - struct Rec { - string s; - int i {0}; - Rec(const string& ss) : s{ss} {} - Rec(int ii) :i{ii} {} - }; +C++98's standard library used this style in places, by returning `pair` in some functions. +For example, given a `set my_set`, consider: - Rec r1 {7}; - Rec r2 {"Foo bar"}; + // C++98 + pair result = my_set.insert("Hello"); + if (result.second) + do_something_with(result.first); // workaround -**Note**: The C++11 initializer list rules eliminates the need for many constructors. For example: +With C++17 we are able to use "structured bindings" to give each member a name: - struct Rec2{ - string s; - int i; - Rec2(const string& ss, int ii = 0} :s{ss}, i{ii} {} // redundant - }; + if (auto [ iter, success ] = my_set.insert("Hello"); success) + do_something_with(iter); - Rec r1 {"Foo",7}; - Rec r2 {"Bar"}; +A `struct` with meaningful names is more common in modern C++. +See for example `ranges::min_max_result`, `from_chars_result`, and others. -The `Rec2` constructor is redundant. -Also, the default for `int` would be better done as a [member initializer](#Rc-in-class initializer). +##### Exception -**See also**: [construct valid object](#Rc-complete) and [constructor throws](#Rc-throw). +Sometimes, we need to pass an object to a function to manipulate its state. +In such cases, passing the object by reference [`T&`](#Rf-inout) is usually the right technique. +Explicitly passing an in-out parameter back out again as a return value is often not necessary. +For example: -**Enforcement**: + istream& operator>>(istream& in, string& s); // much like std::operator>>() -* Flag classes with user-define copy operations but no destructor (a user-defined copy is a good indicator that the class has an invariant) + for (string s; in >> s; ) { + // do something with line + } +Here, both `s` and `in` are used as in-out parameters. +We pass `in` by (non-`const`) reference to be able to manipulate its state. +We pass `s` to avoid repeated allocations. +By reusing `s` (passed by reference), we allocate new memory only when we need to expand `s`'s capacity. +This technique is sometimes called the "caller-allocated out" pattern and is particularly useful for types, +such as `string` and `vector`, that needs to do free store allocations. - -### C.41: A constructor should create a fully initialized object +To compare, if we passed out all values as return values, we would write something like this: -**Reason**: A constructor establishes the invariant for a class. A user of a class should be able to assume that a constructed object is usable. + struct get_string_result { istream& in; string s; }; -**Example; bad**: + get_string_result get_string(istream& in) // not recommended + { + string s; + in >> s; + return { in, move(s) }; + } - class X1 { - FILE* f; // call init() before any other fuction - // ... - public: - X1() {} - void init(); // initialize f - void read(); // read from f - // ... - }; + for (auto [in, s] = get_string(cin); in; s = get_string(in).s) { + // do something with string + } - void f() - { - X1 file; - file.read(); // crash or bad read! - // ... - file.init(); // too late - // ... - } +We consider that significantly less elegant with significantly less performance. -Compilers do not read comments. +For a truly strict reading of this rule (F.21), the exception isn't really an exception because it relies on in-out parameters, +rather than the plain out parameters mentioned in the rule. +However, we prefer to be explicit, rather than subtle. -**Exception**: If a valid object cannot conveniently be constructed by a constructor [use a factory function](#C factory). - -**Note**: If a constructor acquires a resource (to create a valid object), that resource should be [released by the destructor](#Rc-release). -The idiom of having constructors acquire resources and destructors release them is called [RAII](#Rr-raii) ("Resource Acquisitions Is Initialization"). - - - -### C.42: If a constructor cannot construct a valid object, throw an exception - -**Reason**: Leaving behind an invalid object is asking for trouble. - -**Example**: - - class X2 { - FILE* f; // call init() before any other fuction - // ... - public: - X2(const string& name) - :f{fopen(name.c_str(),"r"} - { - if (f==nullptr) throw runrime_error{"could not open" + name}; - // ... - } - - void read(); // read from f - // ... - }; - - void f() - { - X2 file {"Zeno"}; // throws if file isn't open - file.read(); // fine - // ... - } - -**Example, bad**: - - class X3 { // bad: the constructor leaves a non-valid object behind - FILE* f; // call init() before any other fuction - bool valid;; - // ... - public: - X3(const string& name) - :f{fopen(name.c_str(),"r"}, valid{false} - { - if (f) valid=true; - // ... - } - - void is_valid()() { return valid; } - void read(); // read from f - // ... - }; - - void f() - { - X3 file {Heraclides"}; - file.read(); // crash or bad read! - // ... - if (is_valid()()) { - file.read(); - // ... - } - else { - // ... handle error ... - } - // ... - } - -**Note**: For a variable definition (e.g., on the stack or as a member of another object) there is no explicit function call from which an error code could be returned. Leaving behind an invalid object an relying on users to consistently check an `is_valid()` function before use is tedious, error-prone, and inefficient. - -**Exception**: There are domains, such as some hard-real-time systems (think airplane controls) where (without additional tool support) exception handling is not sufficiently predictable from a timing perspective. There the `is_valed()` technique must be used. In such cases, check `is_valid()` consistently and immediately to simulate [RAII](#Rr-raii). - -**Alternative**: If you feel tempted to use some "post-constructor initialization" or "two-stage initialization" idiom, try not to do that. If you really have to, look at [factory functions](#Rc-factory). - -**Enforcement**: -* (Simple) Every constructor should initialize every member variable (either explicitly, via a delegating ctor call or via default construction). -* (Unknown) If a constructor has an `Ensures` contract, try to see if it holds as a postcondition. +##### Note +In most cases, it is useful to return a specific, user-defined type. +For example: - -### C.43: Give a class a default constructor + struct Distance { + int value; + int unit = 1; // 1 means meters + }; -**Reason**: Many language and library facilities rely on default constructors, -e.g. `T a[10]` and `std::vector v(10)` default initializes their elements. + Distance d1 = measure(obj1); // access d1.value and d1.unit + auto d2 = measure(obj2); // access d2.value and d2.unit + auto [value, unit] = measure(obj3); // access value and unit; somewhat redundant + // to people who know measure() + auto [x, y] = measure(obj4); // don't; it's likely to be confusing -**Example**: +The overly generic `pair` and `tuple` should be used only when the value returned represents independent entities rather than an abstraction. - class Date { - public: - Date(); - // ... - }; - - vector vd1(1000); // default Date needed here - vector vd2(1000,Date{Month::october,7,1885}); // alternative +Another option is to use `optional` or `expected`, rather than `pair` or `tuple`. +When used appropriately these types convey more information about what the members mean than `pair` or `pair` do. -There is no "natural" default date (the big bang is too far back in time to be useful for most people), so this example is non-trivial. -`{0,0,0}` is not a valid date in most calendar systems, so choosing that would be introducing something like floating-point's NaN. -However, most realistic `Date` classes has a "first date" (e.g. January 1, 1970 is popular), so making that the default is usually trivial. - -**Enforcement**: - -* Flag classes without a default constructor - - - -### C.44: Prefer default constructors to be simple and non-throwing - -**Reason**: Being able to set a value to "the default" without operations that might fail simplifies error handling and reasoning about move operations. - -**Example, problematic**: - - template - class Vector0 { // elem points to space-elem element allocated using new - public: - Vector0() :Vector0{0} {} - Vector0(int n) :elem{new T[n]}, space{elem+n}, last{elem} {} - // ... - private: - own elem; - T* space; - T* last; - }; - -This is nice and general, but setting a `Vector0` to empty after an error involves an allocation, which may fail. -Also, having a default `Vector` represented as `{new T[0],0,0}` seems wasteful. -For example, `Vector0 v(100)` costs 100 allocations. - -**Example**: - - template - class Vector1 { // elem is nullptr or elem points to space-elem element allocated using new - public: - Vector1() noexcept {} // sets the representation to {nullptr,nullptr,nullptr}; doesn't throw - Vector1(int n) :elem{new T[n]}, space{elem+n}, last{elem} {} - // ... - private: - own elem = nullptr; - T* space = nullptr; - T* last = nullptr; - }; - -Using `{nullptr,nullptr,nullptr}` makes `Vector1{}` cheap, but a special case and implies run-time checks. -Setting a `Vector1` to empty after detecting an error is trivial. +##### Note -**Enforcement**: +When the object to be returned is initialized from local variables that are expensive to copy, +explicit `move` may be helpful to avoid copying: -* Flag throwing default constructors + pair f(const string& input) + { + LargeObject large1 = g(input); + LargeObject large2 = h(input); + // ... + return { move(large1), move(large2) }; // no copies + } +Alternatively, - -### C.45: Don't define a default constructor that only initializes data members; use in-class member initializers instead + pair f(const string& input) + { + // ... + return { g(input), h(input) }; // no copies, no moves + } -**Reason**: Using in-class member initializers lets the compiler generate the function for you. The compiler-generated function can be more efficient. +Note this is different from the `return move(...)` anti-pattern from [ES.56](#Res-move) -**Example; bad**: +##### Enforcement - class X1 { // BAD: doesn't use member initializers - string s; - int i; - public: - X1() :s{"default"}, i{1} { } - // ... - }; +* Output parameters should be replaced by return values. + An output parameter is one that the function writes to, invokes a non-`const` member function, or passes on as a non-`const`. +* `pair` or `tuple` return types should be replaced by `struct`, if possible. + In variadic templates, `tuple` is often unavoidable. -**Example**: +### F.60: Prefer `T*` over `T&` when "no argument" is a valid option - class X2 { - string s = "default"; - int i = 1; - public: - // use compiler-generated default constructor - // ... - }; +##### Reason - -**Enforcement**: (Simple) A default constructor should do more than just initialize member variables with constants. +A pointer (`T*`) can be a `nullptr` and a reference (`T&`) cannot, there is no valid "null reference". +Sometimes having `nullptr` as an alternative to indicated "no object" is useful, but if it is not, a reference is notationally simpler and might yield better code. +##### Example - -### C.46: By default, declare single-argument constructors explicit + string zstring_to_string(zstring p) // zstring is a char*; that is a C-style string + { + if (!p) return string{}; // p might be nullptr; remember to check + return string{p}; + } -**Reason**: To avoid unintended conversions. + void print(const vector& r) + { + // r refers to a vector; no check needed + } -**Example; bad**: +##### Note - class String { - // ... - public: - String(int); // BAD - // ... - }; +It is possible, but not valid C++ to construct a reference that is essentially a `nullptr` (e.g., `T* p = nullptr; T& r = *p;`). +That error is very uncommon. - String s = 10; // surprise: string of size 10 +##### Note +If you prefer the pointer notation (`->` and/or `*` vs. `.`), `not_null` provides the same guarantee as `T&`. -**Exception**: If you really want an implicit conversion from the constructor argument type to the class type, don't use `explicit`: +##### Enforcement - class Complex { - // ... - public: - Complex(double d); // OK: we want a conversion from d to {d,0} - // ... - }; +* Flag ??? - Complex z = 10.7; // unsurprising conversion +### F.22: Use `T*` or `owner` to designate a single object -**See also**: [Discussion of implicit conversions](#Ro-conversion). +##### Reason -**Enforcement**: (Simple) Single-argument constructors should be declared `explicit`. Good single argument non-`explicit` constructors are rare in most code based. Warn for all that are not on a "positive list". +Readability: it makes the meaning of a plain pointer clear. +Enables significant tool support. +##### Note - -### C.47: Define and initialize member variables in the order of member declaration +In traditional C and C++ code, plain `T*` is used for many weakly-related purposes, such as: -**Reason**: To minimize confusion and errors. That is the order in which the initialization happens (independent of the order of member initializers). +* Identify a (single) object (not to be deleted by this function) +* Point to an object allocated on the free store (and delete it later) +* Hold the `nullptr` +* Identify a C-style string (zero-terminated array of characters) +* Identify an array with a length specified separately +* Identify a location in an array -**Example; bad**: +This makes it hard to understand what the code does and is supposed to do. +It complicates checking and tool support. - class Foo { - int m1; - int m2; - public: - Foo(int x) :m2{x}, m1{++x} { } // BAD: misleading initializer order - // ... - }; +##### Example - Foo x(1); // surprise: x.m1==x.m2==2 + void use(int* p, int n, char* s, int* q) + { + p[n - 1] = 666; // Bad: we don't know if p points to n elements; + // assume it does not or use span + cout << s; // Bad: we don't know if that s points to a zero-terminated array of char; + // assume it does not or use zstring + delete q; // Bad: we don't know if *q is allocated on the free store; + // assume it does not or use owner + } -**Enforcement**: (Simple) A member initializer list should mention the members in the same order they are declared. +better -**See also**: [Discussion](#Sd order) + void use2(span p, zstring s, owner q) + { + p[p.size() - 1] = 666; // OK, a range error can be caught + cout << s; // OK + delete q; // OK + } +##### Note - -### C.48: Prefer in-class initializers to member initializers in constructors for constant initializers +`owner` represents ownership, `zstring` represents a C-style string. -**Reason**: Makes it explicit that the same value is expected to be used in all constructors. Avoids repetition. Avoids maintenance problems. It leads to the shortest and most efficient code. +**Also**: Assume that a `T*` obtained from a smart pointer to `T` (e.g., `unique_ptr`) points to a single element. -**Example; bad**: +**See also**: [Support library](#gsl-guidelines-support-library) - class X { // BAD - int i; - string s; - int j; - public: - X() :i{666}, s{"qqq"} { } // j is uninitialized - X(int ii) :i{ii} {} // s is "" and j is uninitialized - // ... - }; +**See also**: [Do not pass an array as a single pointer](#Ri-array) -How would a maintainer know whether `j` was deliberately uninitialized (probably a poor idea anyway) and whether it was intentional to give `s` the default value `""` in one case and `qqq` in another (almost certainly a bug)? The problem with `j` (forgetting to initialize a member) often happens when a new member is added to an existing class. +##### Enforcement -**Example**: +* (Simple) ((Bounds)) Warn for any arithmetic operation on an expression of pointer type that results in a value of pointer type. - class X2 { - int i {666}; - string s {"qqq"}; - int j {0}; - public: - X2() = default; // all members are initialized to their defaults - X2(int ii) :i{ii} {} // s and j initialized to their defaults - // ... - }; +### F.23: Use a `not_null` to indicate that "null" is not a valid value -**Alternative**: We can get part of the benefits from default arguments to constructors, and that is not uncommon in older code. However, that is less explicit, causes more arguments to be passed, and is repetitive when there is more than one constructor: +##### Reason - class X3 { // BAD: inexplicit, argument passing overhead - int i; - string s; - int j; - public: - X3(int ii = 666, const string& ss = "qqq", int jj = 0) - :i{ii}, s{ss}, j{jj} { } // all members are initialized to their defaults - // ... - }; +Clarity. A function with a `not_null` parameter makes it clear that the caller of the function is responsible for any `nullptr` checks that might be necessary. +Similarly, a function with a return value of `not_null` makes it clear that the caller of the function does not need to check for `nullptr`. -**Enforcement**: -* (Simple) Every constructor should initialize every member variable (either explicitly, via a delegating ctor call or via default construction). -* (Simple) Default arguments to constructors suggest an in-class initalizer may be more appropriate. +##### Example +`not_null` makes it obvious to a reader (human or machine) that a test for `nullptr` is not necessary before dereference. +Additionally, when debugging, `owner` and `not_null` can be instrumented to check for correctness. - -### C.49: Prefer initialization to assignment in constructors +Consider: -**Reason**: An initialization explicitly states that initialization, rather than assignment, is done and can be more elegant and efficient. Prevents "use before set" errors. + int length(Record* p); -**Example; good**: +When I call `length(p)` should I check if `p` is `nullptr` first? Should the implementation of `length()` check if `p` is `nullptr`? - class A { // Good - string s1; - public: - A() : s1{"Hello, "} { } // GOOD: directly construct - // ... - }; + // it is the caller's job to make sure p != nullptr + int length(not_null p); -**Example; bad**: + // the implementor of length() must assume that p == nullptr is possible + int length(Record* p); - class B { // BAD - string s1; - public: - B() { s1 = "Hello, "; } // BAD: default constructor followed by assignment - // ... - }; +##### Note - class C { // UGLY, aka very bad - int* p; - public: - C() { cout << *p; p = new int{10}; } // accidental use before initialized - // ... - }; +A `not_null` is assumed not to be the `nullptr`; a `T*` might be the `nullptr`; both can be represented in memory as a `T*` (so no run-time overhead is implied). +##### Note +`not_null` is not just for built-in pointers. It works for `unique_ptr`, `shared_ptr`, and other pointer-like types. - -### C.50: Use a factory function if you need "virtual behavior" during initialization +##### Enforcement -**Reason**: If the state of a base class object must depend on the state of a derived part of the object, - we need to use a virtual function (or equivalent) while minimizing the window of opportunity to misuse an imperfectly constructed object. +* (Simple) Warn if a raw pointer is dereferenced without being tested against `nullptr` (or equivalent) within a function, suggest it is declared `not_null` instead. +* (Simple) Error if a raw pointer is sometimes dereferenced after first being tested against `nullptr` (or equivalent) within the function and sometimes is not. +* (Simple) Warn if a `not_null` pointer is tested against `nullptr` within a function. -**Example; bad**: +### F.24: Use a `span` or a `span_p` to designate a half-open sequence - class B { - public: - B() - { - // ... - f(); // BAD: virtual call in constructor - //... - } +##### Reason - virtual void f() = 0; +Informal/non-explicit ranges are a source of errors. - // ... - }; +##### Example -**Example*: + X* find(span r, const X& v); // find v in r - class B { - private: - B() { /* ... */ } // create an imperfectly initialized object + vector vec; + // ... + auto p = find({vec.begin(), vec.end()}, X{}); // find X{} in vec - virtual void PostInitialize() // to be called right after construction - { - // ... - f(); // GOOD: virtual dispatch is safe - // ... - } +##### Note - public: - virtual void f() = 0; +Ranges are extremely common in C++ code. Typically, they are implicit and their correct use is very hard to ensure. +In particular, given a pair of arguments `(p, n)` designating an array `[p:p+n)`, +it is in general impossible to know if there really are `n` elements to access following `*p`. +`span` and `span_p` are simple helper classes designating a `[p:q)` range and a range starting with `p` and ending with the first element for which a predicate is true, respectively. - template - static shared_ptr Create() // interface for creating objects - { - auto p = make_shared(); - p->PostInitialize(); - return p; - } - }; +##### Example - class D : public B { /* "¦ */ }; // some derived class +A `span` represents a range of elements, but how do we manipulate elements of that range? - shared_ptr p = D::Create(); // creating a D object + void f(span s) + { + // range traversal (guaranteed correct) + for (int x : s) cout << x << '\n'; -By making the constructor `private` we avoid an incompletely constructed object escaping into the wild. -By providing the factory function `Create()`, we make construction (on the free store) convenient. + // C-style traversal (potentially checked) + for (gsl::index i = 0; i < s.size(); ++i) cout << s[i] << '\n'; -**Note**: Conventional factory functions allocate on the free store, rather than on the stack or in an enclosing object. + // random access (potentially checked) + s[7] = 9; -**See also**: [Discussion](#Sd factory) + // extract pointers (potentially checked) + std::sort(&s[0], &s[s.size() / 2]); + } +##### Note - -### C.51: Use delegating constructors to represent common actions for all constructors of a class +A `span` object does not own its elements and is so small that it can be passed by value. -**Reason**: To avoid repetition and accidental differences +Passing a `span` object as an argument is exactly as efficient as passing a pair of pointer arguments or passing a pointer and an integer count. -**Example; bad**: +**See also**: [Support library](#gsl-guidelines-support-library) - class Date { // BAD: repetitive - int d; - Month m; - int y; - public: - Date(int ii, Month mm, year yy) - :i{ii}, m{mm} y{yy} - { if (!valid(i,m,y)) throw Bad_date{}; } +##### Enforcement - Date(int ii, Month mm) - :i{ii}, m{mm} y{current_year()} - { if (!valid(i,m,y)) throw Bad_date{}; } - // ... - }; +(Complex) Warn where accesses to pointer parameters are bounded by other parameters that are integral types and suggest they could use `span` instead. -The common action gets tedious to write and may accidentally not be common. +### F.25: Use a `zstring` or a `not_null` to designate a C-style string -**Example**: +##### Reason - - class Date2 { - int d; - Month m; - int y; - public: - Date2(int ii, Month mm, year yy) - :i{ii}, m{mm} y{yy} - { if (!valid(i,m,y)) throw Bad_date{}; } +C-style strings are ubiquitous. They are defined by convention: zero-terminated arrays of characters. +We must distinguish C-style strings from a pointer to a single character or an old-fashioned pointer to an array of characters. - Date2(int ii, Month mm) - :Date2{ii,mm,current_year()} {} - // ... - }; +If you don't need null termination, use `string_view`. -**See also**: If the "repeated action" is a simple initialization, consider [an in-class member initializer](#Rc-in-class initializer). +##### Example -**Enforcement**: (Moderate) Look for similar constructor bodies. +Consider: + int length(const char* p); - -### C.52: Use inheriting constructors to import constructors into a derived class that does not need further explicit initialization +When I call `length(s)` should I check if `s` is `nullptr` first? Should the implementation of `length()` check if `p` is `nullptr`? -**Reason**: If you need those constructors for a derived class, re-implementeing them is tedious and error prone. + // the implementor of length() must assume that p == nullptr is possible + int length(zstring p); -**Example**: `std::vector` has a lot of tricky constructors, so it I want my own `vector`, I don't want to reimplement them: + // it is the caller's job to make sure p != nullptr + int length(not_null p); - class Rec { - // ... data and lots of nice constructors ... - }; +##### Note - class Oper : public Rec { - using Rec::Rec; - // ... no data members ... - // ... lots of nice utility functions ... - }; +`zstring` does not represent ownership. -**Example; bad**: +**See also**: [Support library](#gsl-guidelines-support-library) - struct Rec2 : public Rec { - int x; - using Rec::Rec; - }; - - Rec2 r {"foo", 7}; - int val = r.x; // uninitialized - +### F.26: Use a `unique_ptr` to transfer ownership where a pointer is needed -**Enforcement**: Make sure that every member of the derived class is initialized. +##### Reason +Using `unique_ptr` is the cheapest way to pass a pointer safely. +**See also**: [C.50](#Rc-factory) regarding when to return a `shared_ptr` from a factory. - -## C.copy: Copy and move +##### Example -Value type should generally be copyable, but interfaces in a class hierarchy should not. -Resource handles, may or may not be copyable. -Types can be defined to move for logical as well as performance reasons. + unique_ptr get_shape(istream& is) // assemble shape from input stream + { + auto kind = read_header(is); // read header and identify the next shape on input + switch (kind) { + case kCircle: + return make_unique(is); + case kTriangle: + return make_unique(is); + // ... + } + } +##### Note - -### C.60: Make copy assignment non-`virtual`, take the parameter by `const&`, and return by non-`const&` - -**Reason**: It is simple and efficient. If you want to optimize for rvalues, provide an overload that takes a `&&` (see [F.24](#Rf-pass-ref-ref)). - -**Example**: - - class Foo { - public: - Foo& operator=(const Foo& x) - { - auto tmp = x; // GOOD: no need to check for self-assignment (other than performance) - std::swap(*this,tmp); - return *this; - } - // ... - }; - - Foo a; - Foo b; - Foo f(); - - a = b; // assign lvalue: copy - a = f(); // assign rvalue: potentially move - -**Note**: The `swap` implementation technique offers the [strong guarantee](???). - -**Example**: But what if you can get significant better performance by not making a temporary copy? Consider a simple `Vector` intended for a domain where assignment of large, equal-sized `Vector`s is common. In this case, the copy of elements implied by the `swap` implementation technique could cause an order of magnitude increase in cost: - - template - class Vector { - public: - Vector& operator=(const Vector&); - // ... - private: - T* elem; - int sz; - }; - - Vector& Vector::operator=(const Vector& a) - { - if (a.sz>sz) - { - // ... use the swap technique, it can't be bettered ... - *return *this - } - // ... copy sz elements from *a.elem to elem ... - if (a.szF.27: Use a `shared_ptr` to share ownership +##### Reason - -### C.61: A copy operation should copy +Using `std::shared_ptr` is the standard way to represent shared ownership. That is, the last owner deletes the object. -**Reason**: That is the generally assumed semantics. After `x=y`, we should have `x==y`. -After a copy `x` and `y` can be independent objects (value semantics, the way non-pointer built-in types and the standard-library types work) or refer to a shared object (pointer semantics, the way pointers work). +##### Example -**Example**: - - class X { // OK: value sementics - public: - X(); - X(const X&); // copy X - void modify(); // change the value of X - // ... - ~X() { delete[] p; } - private: - T* p; - int sz; - }; - - bool operator==(const X& a, const X& b) - { - return sz==a.sz && equal(p,p+sz,a.p,a.p+sz); - } - - X::X(const X& a) - :p{new T}, sz{a.sz} - { - copy(a.p,a.p+sz,a.p); - } - - X x; - X y = x; - if (x!=y) throw Bad{}; - x.modify(); - if (x==y) throw Bad{}; // assume value semantics - -**Example**: - - class X2 { // OK: pointer semantics - public: - X2(); - X2(const X&) = default; // shallow copy - ~X2() = default; - void modify(); // change the value of X - // ... - private: - T* p; - int sz; - }; - - bool operator==(const X2& a, const X2& b) - { - return sz==a.sz && p==a.p; - } - - X2 x; - X2 y = x; - if (x!=y) throw Bad{}; - x.modify(); - if (x!=y) throw Bad{}; // assume pointer semantics - -**Note**: Prefer copy semantics unless you are building a "smart pointer". Value semantics is the simplest to reason about and what the standard library facilities expect. - -**Enforcement**: (Not enforceable). - - - -### C.62: Make copy assignment safe for self-assignment - -**Reason**: If `x=x` changes the value of `x`, people will be surprised and bad errors will occur (often including leaks). - -**Example**: The standard-library containers handle self-assignment elegantly and efficiently: - - std::vector v = {3,1,4,1,5,9}; - v = v; - // the value of v is still {3,1,4,1,5,9} - -**Note**: The default assignment generated from members that handle self-assignment correctly handles self-assignment. - - struct Bar { - vector> v; - map m; - string s; - }; - - Bar b; - // ... - b = b; // correct and efficient - -**Note**: You can handle self-assignment by explicitly testing for self-assignment, but often it is faster and more elegant to cope without such a test (e.g., [using `swap`](#Rc-swap)). - - class Foo { - string s; - int i; - public: - Foo& operator=(const Foo& a); - // ... - }; - - Foo& Foo::operator=(const Foo& a) // OK, but there is a cost - { - if (this==&a) return *this; - s = a.s; - i = a.i; - return *this; - } + { + shared_ptr im { read_image(somewhere) }; -This is obviously safe and apparently efficient. -However, what if we do one self-assignment per million assignments? -That's about a million redundant tests (but since the answer is essentially always the same, the computer's branch predictor will guess right essentially every time). -Consider: + std::thread t0 {shade, args0, top_left, im}; + std::thread t1 {shade, args1, top_right, im}; + std::thread t2 {shade, args2, bottom_left, im}; + std::thread t3 {shade, args3, bottom_right, im}; - Foo& Foo::operator=(const Foo& a) // simpler, and probably much better - { - s = a.s; - i = a.i; - return *this; - } + // detaching threads requires extra care (e.g., to join before + // main ends), but even if we do detach the four threads here ... + } + // ... shared_ptr ensures that eventually the last thread to + // finish safely deletes the image -`std::string` is safe for self-assignment and so are `int`. All the cost is carried by the (rare) case of self-assignment. +##### Note -**Enforcement**: (Simple) Assignment operators should not contain the pattern `if (this==&a) return *this;` ??? +Prefer a `unique_ptr` over a `shared_ptr` if there is never more than one owner at a time. +`shared_ptr` is for shared ownership. - - -### C.63: Make move assignment non-`virtual`, take the parameter by `&&`, and return by non-`const `&` +Note that pervasive use of `shared_ptr` has a cost (atomic operations on the `shared_ptr`'s reference count have a measurable aggregate cost). -**Reason**: It is simple and efficient. +##### Alternative -**See**: [The rule for copy-assignment](#Rc-copy-assignment). +Have a single object own the shared object (e.g. a scoped object) and destroy that (preferably implicitly) when all users have completed. -**Enforcement**: Equivalent to what is done for [copy-assignment](#Rc-copy-assignment). -* (Simple) An assignment operator should not be virtual. Here be dragons! -* (Simple) An assignment operator should return `T&` to enable chaining, not alternatives like `const T&` which interfere with composability and putting objects in containers. -* (Moderate) A move assignment operator should (implicitly or explicitly) invoke all base and member move assignment operators. +##### Enforcement +(Not enforceable) This is a too complex pattern to reliably detect. - -### C.64: A move operation should move and leave its source in valid state +### F.42: Return a `T*` to indicate a position (only) -**Reason**: That is the generally assumed semantics. After `x=std::move(y)` the value of `x` should be the value `y` had and `y` should be in a valid state. +##### Reason -**Example**: - - class X { // OK: value sementics - public: - X(); - X(X&& a); // move X - void modify(); // change the value of X - // ... - ~X() { delete[] p; } - private: - T* p; - int sz; - }; +That's what pointers are good for. +Returning a `T*` to transfer ownership is a misuse. +##### Example - X::X(X&& a) - :p{a.p}, sz{a.sz} // steal representation - { - a.p = nullptr; // set to "empty" - a.sz = 0; - } + Node* find(Node* t, const string& s) // find s in a binary tree of Nodes + { + if (!t || t->name == s) return t; + if ((auto p = find(t->left, s))) return p; + if ((auto p = find(t->right, s))) return p; + return nullptr; + } - void use() - { - X x{}; - // ... - X y = std::move(x); - x = X{}; // OK - } // OK: x can be destroyed +If it isn't the `nullptr`, the pointer returned by `find` indicates a `Node` holding `s`. +Importantly, that does not imply a transfer of ownership of the pointed-to object to the caller. -**Note**: Ideally, that moved-from should be the default value of the type. Ensure that unless there is an exceptionally good reason not to. However, not all types have a default value and for some types establishing the default value can be expensive. The standard requires only that the moved-from object can be destroyed. -Often, we can easily and cheaply do better: The standard library assumes that it it possible to assign to a moved-from object. Always leave the moved-from object in some (necessarily specified) valid state. +##### Note -**Note**: Unless there is an exceptionally strong reason not to, make `x=std::move(y); y=z;` work with the conventional semantics. +Positions can also be transferred by iterators, indices, and references. +A reference is often a superior alternative to a pointer [if there is no need to use `nullptr`](#Rf-ptr-ref) or [if the object referred to should not change](#S-const). -**Enforcement**: (Not enforceable) look for assignments to members in the move operation. If there is a default constructor, compare those assignments to the initializations in the default constructor. +##### Note +Do not return a pointer to something that is not in the caller's scope; see [F.43](#Rf-dangle). - -### C.65: Make move assignment safe for self-assignment +**See also**: [discussion of dangling pointer prevention](#???) -**Reason**: If `x=x` changes the value of `x`, people will be surprised and bad errors may occur. However, people don't usually directly write a self-assignment that turn into a move, but it can occur. However, `std::swap` is implemented using move operations so if you accidentally do `swap(a,b)` where `a` and `b` refer to the same object, failing to handle self-move could be a serious and subtle error. +##### Enforcement -**Example**: +* Flag `delete`, `std::free()`, etc. applied to a plain `T*`. +Only owners should be deleted. +* Flag `new`, `malloc()`, etc. assigned to a plain `T*`. +Only owners should be responsible for deletion. - class Foo { - string s; - int i; - public: - Foo& operator=(Foo&& a); - // ... - }; - - Foo& Foo::operator=(Foo&& a) // OK, but there is a cost - { - if (this==&a) return *this; // this line is redundant - s = std::move(a.s); - i = a.i; - return *this; - } +### F.43: Never (directly or indirectly) return a pointer or a reference to a local object -The one-in-a-million argument against `if (this==&a) return *this;` tests from the discussion of [self-assignment](#Rc-copy self) is even more relevant for self-move. +##### Reason -**Note**: There is no know general way of avoiding a `if (this==&a) return *this;` test for a move assignment and still get a correct answer (i.e., after `x=x` the value of `x` is unchanged). +To avoid the crashes and data corruption that can result from the use of such a dangling pointer. -**Note** The ISO standard guarantees only a "valid but unspecified" state for the standard library containers. Apparently this has not been a problem in about 10 years of experimental and production use. Please contact the editors if you find a counter example. The rule here is more caution and insists on complete safety. +##### Example, bad -**Example**: Here is a way to move a pointer without a test (imagine it as code in the implementation a move assignment): +After the return from a function its local objects no longer exist: - // move from other.oter to this->ptr - T* temp = other.ptr; - other.ptr = nullptr; - delete ptr; - ptr = temp; - -**Enforcement**: + int* f() + { + int fx = 9; + return &fx; // BAD + } -* (Moderate) In the case of self-assignment, a move assignment operator should not leave the object holding pointer members that have been `delete`d or set to nullptr. -* (Not enforceable) Look at the use of standard-library container types (incl. `string`) and consider them safe for ordinary (not life-critical) uses. + void g(int* p) // looks innocent enough + { + int gx; + cout << "*p == " << *p << '\n'; + *p = 999; + cout << "gx == " << gx << '\n'; + } + void h() + { + int* p = f(); + int z = *p; // read from abandoned stack frame (bad) + g(p); // pass pointer to abandoned stack frame to function (bad) + } - -### C.66: Make move operations `noexcept` +Here on one popular implementation I got the output: -**Reason**: A throwing move violates most people's reasonably assumptions. -A non-throwing move will be used more efficiently by standard-library and language facilities. + *p == 999 + gx == 999 -**Example**: +I expected that because the call of `g()` reuses the stack space abandoned by the call of `f()` so `*p` refers to the space now occupied by `gx`. - class Vector { - // ... - Vector(Vector&& a) noexcept :elem{a.elem}, sz{a.sz} { a.sz=0; a.elem=nullptr; } - Vector& operator=(Vector&& a) noexcept { elem=a.elem; sz=a.sz; a.sz=0; a.elem=nullptr; } - //... - public: - T* elem; - int sz; - }; +* Imagine what would happen if `fx` and `gx` were of different types. +* Imagine what would happen if `fx` or `gx` was a type with an invariant. +* Imagine what would happen if more that dangling pointer was passed around among a larger set of functions. +* Imagine what a cracker could do with that dangling pointer. -These copy operations do not throw. +Fortunately, most (all?) modern compilers catch and warn against this simple case. -**Example, bad**: +##### Note - class Vector2 { - // ... - Vector2(Vector2&& a) { *this = a; } // just use the copy - Vector2& operator=(Vector2&& a) { *this = a; } // just use the copy - //... - public: - T* elem; - int sz; - }; +This applies to references as well: -This `Vector2` is not just inefficient, but since a vector copy requires allocation, it can throw. + int& f() + { + int x = 7; + // ... + return x; // Bad: returns reference to object that is about to be destroyed + } -**Enforcement**: (Simple) A move operation should be marked `noexcept`. +##### Note +This applies only to non-`static` local variables. +All `static` variables are (as their name indicates) statically allocated, so that pointers to them cannot dangle. +##### Example, bad +Not all examples of leaking a pointer to a local variable are that obvious: - -### C.67: A base class should suppress copying, and provide a virtual `clone` instead if "copying" is desired + int* glob; // global variables are bad in so many ways -**Reason**: To prevent slicing, because the normal copy operations will copy only the base portion of a derived object. + template + void steal(T x) + { + glob = x(); // BAD + } -**Example; bad**: + void f() + { + int i = 99; + steal([&] { return &i; }); + } - class B { // BAD: base class doesn't suppress copying - int data; - // ... nothing about copy operations, so uses default ... - }; + int main() + { + f(); + cout << *glob << '\n'; + } - class D : public B { - string moredata; // add a data member - // ... - }; +Here I managed to read the location abandoned by the call of `f`. +The pointer stored in `glob` could be used much later and cause trouble in unpredictable ways. - auto d = make_unique(); - auto b = make_unique(d); // oops, slices the object; gets only d.data but drops d.moredata +##### Note -**Example**: +The address of a local variable can be "returned"/leaked by a return statement, by a `T&` out-parameter, as a member of a returned object, as an element of a returned array, and more. - class B { // GOOD: base class suppresses copying - B(const B&) =delete; - B& operator=(const B&) =delete; - virtual unique_ptr clone() { return /* B object */; } - // ... - }; +##### Note - class D : public B { - string moredata; // add a data member - unique_ptr clone() override { return /* D object */; } - // ... - }; +Similar examples can be constructed "leaking" a pointer from an inner scope to an outer one; +such examples are handled equivalently to leaks of pointers out of a function. - auto d = make_unique(); - auto b = d.clone(); // ok, deep clone +A slightly different variant of the problem is placing pointers in a container that outlives the objects pointed to. -**Note**: It's good to return a smart pointer, but unlike with raw pointers the return type cannot be covariant (for example, `D::clone` can't return a `unique_ptr`. Don't let this tempt you into returning an owning raw pointer; this is a minor drawback compared to the major robustness benefit delivered by the owning smart pointer. +**See also**: Another way of getting dangling pointers is [pointer invalidation](#???). +It can be detected/prevented with similar techniques. -**Enforcement**: A class with any virtual function should not have a copy constructor or copy assignment operator (compiler-generated or handwritten). +##### Enforcement +* Compilers tend to catch return of reference to locals and could in many cases catch return of pointers to locals. +* Static analysis can catch many common patterns of the use of pointers indicating positions (thus eliminating dangling pointers) +### F.44: Return a `T&` when copy is undesirable and "returning no object" isn't needed -## C.other: Other default operations +##### Reason -??? +The language guarantees that a `T&` refers to an object, so that testing for `nullptr` isn't necessary. - -### C.80: Use `=default` if you have to be explicit about using the default semantics - -**Reason**: The compiler is more likely to get the default semantics right and you cannot implement these function better than the compiler. - -**Example**: - - class Tracer { - string message; - public: - Tracer(const string& m) : message{m} { cerr << "entering " << message <<'\n'; } - ~Tracer() { cerr << "exiting " << message <<'\n'; } - - Tracer(const Tracer&) = default; - Tracer& operator=(const Tracer&) = default; - Tracer(Tracer&&) = default; - Tracer& operator=(Tracer&&) = default; - }; - -Because we defined the destructor, we must define the copy and move operations. The `=default` is the best and simplest way of doing that. - -**Example, bad**: - - class Tracer2 { - string message; - public: - Tracer2(const string& m) : message{m} { cerr << "entering " << message <<'\n'; } - ~Tracer2() { cerr << "exiting " << message <<'\n'; } - - Tracer2(const Tracer2& a) : message{a.message} {} - Tracer2& operator=(const Tracer2& a) { message=a.message; } - Tracer2(Tracer2&& a) :message{a.message} {} - Tracer2& operator=(Tracer2&& a) { message=a.message; } - }; +**See also**: The return of a reference must not imply transfer of ownership: +[discussion of dangling pointer prevention](#???) and [discussion of ownership](#???). -Writing out the bodies of the copy and move operations is verbose, tedious, and error-prone. A compiler does it better. +##### Example -**Enforcement**: (Moderate) The body of a special operation should not have the same accessibility and semantics as the compiler-generated version, because that would be redundant + class Car + { + array w; + // ... + public: + wheel& get_wheel(int i) { Expects(i < w.size()); return w[i]; } + // ... + }; + void use() + { + Car c; + wheel& w0 = c.get_wheel(0); // w0 has the same lifetime as c + } - -### C.81: Use `=delete` when you want to disable default behavior (without wanting an alternative) +##### Enforcement -**Reason**: In a few cases, a default operation is not desirable. +Flag functions where no `return` expression could yield `nullptr` -**Example**: +### F.45: Don't return a `T&&` - class Immortal { - public: - ~Immortal() = delete; // do not allow destruction - // ... - }; +##### Reason - void use() - { - Immortal ugh; // error: ugh cannot be destroyed - Immortal* p = new Immortal{}; - delete p; // error: cannot destroy *p - } +It's asking to return a reference to a destroyed temporary object. +A `&&` is a magnet for temporary objects. -**Example**: A `unique_ptr` can be moved, but not copied. To achieve that its copy operations are deleted. To avoid copying it is necessary to `=delete` its copy operations from lvalues: +##### Example - template > class unique_ptr { - public: - // ... - constexpr unique_ptr() noexcept; - explicit unique_ptr(pointer p) noexcept; - // ... - unique_ptr(unique_ptr&& u) noexcept; // move constructor - // ... - unique_ptr(const unique_ptr&) = delete; // disable copy from lvalue - // ... - }; +A returned rvalue reference goes out of scope at the end of the full expression to which it is returned: - unique_ptr make(); // make "something" and return it by moving + auto&& x = max(0, 1); // OK, so far + foo(x); // Undefined behavior - void f() - { - unique_ptr pi {}; - auto pi2 {pi}; // error: no move constructor from lvalue - auto pi3 {make()}; // OK, move: the result of make() is an rvalue - } +This kind of use is a frequent source of bugs, often incorrectly reported as a compiler bug. +An implementer of a function should avoid setting such traps for users. -**Enforcement**: The elimination of a default operation is (should be) based on the desired semantics of the class. Consider such classes suspect, but maintain a "positive list" of classes where a human has asserted that the semantics is correct. +The [lifetime safety profile](#SS-lifetime) will (when completely implemented) catch such problems. - -### C.82: Don't call virtual functions in constructors and destructors -**Reason**: The function called will be that of the object constructed so far, rather than a possibly overriding function in a derived class. -This can be most confusing. -Worse, a direct or indirect call to an unimplemented pure virtual function from a constructor or destructor results in undefined behavior. +##### Example -**Example; bad**: +Returning an rvalue reference is fine when the reference to the temporary is being passed "downward" to a callee; +then, the temporary is guaranteed to outlive the function call (see [F.18](#Rf-consume) and [F.19](#Rf-forward)). +However, it's not fine when passing such a reference "upward" to a larger caller scope. +For passthrough functions that pass in parameters (by ordinary reference or by perfect forwarding) and want to return values, use simple `auto` return type deduction (not `auto&&`). - class base { - public: - virtual void f() = 0; // not implemented - virtual void g(); // implemented with base version - virtual void h(); // implemented with base version - }; +Assume that `F` returns by value: - class derived : public base { - public: - void g() override; // provide derived implementation - void h() final; // provide derived implementation + template + auto&& wrapper(F f) + { + log_call(typeid(f)); // or whatever instrumentation + return f(); // BAD: returns a reference to a temporary + } - derived() - { - f(); // BAD: attempt to call an unimplemented virtual function +Better: - g(); // BAD: will call derived::g, not dispatch further virtually - derived::g(); // GOOD: explicitly state intent to call only the visible version + template + auto wrapper(F f) + { + log_call(typeid(f)); // or whatever instrumentation + return f(); // OK + } - h(); // ok, no qualification needed, h is final - } - }; -Note that calling a specific explicitly qualified function is not a virtual call even if the function is `virtual`. +##### Exception -**See also** [factory functions](#Rc-factory) for how to achieve the effect of a call to a derived class function without risking undefined behavior. +`std::move` and `std::forward` do return `&&`, but they are just casts -- used by convention only in expression contexts where a reference to a temporary object is passed along within the same expression before the temporary is destroyed. We don't know of any other good examples of returning `&&`. +##### Enforcement - -### C.83: For value-like types, consider providing a `noexcept` swap function +Flag any use of `&&` as a return type, except in `std::move` and `std::forward`. -**Reason**: A `swap` can be handy for implementing a number of idioms, from smoothly moving objects around to implementing assignment easily to providing a guaranteed commit function that enables strongly error-safe calling code. Consider using swap to implement copy assignment in terms of copy construction. See also [destructors, deallocation, and swap must never fail]("#Re-never-fail). +### F.46: `int` is the return type for `main()` -**Example; good**: +##### Reason - class Foo { - // ... - public: - void swap(Foo& rhs) noexcept - { - m1.swap(rhs.m1); - std::swap(m2, rhs.m2); - } - private: - Bar m1; - int m2; - }; +It's a language rule, but violated through "language extensions" so often that it is worth mentioning. +Declaring `main` (the one global `main` of a program) `void` limits portability. -Providing a nonmember `swap` function in the same namespace as your type for callers' convenience. +##### Example - void swap(Foo& a, Foo& b) - { - a.swap(b); - } + void main() { /* ... */ }; // bad, not C++ -**Enforcement**: -* (Simple) A class without virtual functions should have a `swap` member function declared. -* (Simple) When a class has a `swap` member function, it should be declared `noexcept`. + int main() + { + std::cout << "This is the way to do it\n"; + } - -### C.84: A `swap` function may not fail +##### Note -**Reason**: `swap` is widely used in ways that are assumed never to fail and programs cannot easily be written to work correctly in the presence of a failing `swap`. The The standard-library containers and algorithms will not work correctly if a swap of an element type fails. +We mention this only because of the persistence of this error in the community. +Note that despite its non-void return type, the main function does not require an explicit return statement. -**Example, bad**: +##### Enforcement - void swap(My_vector& x, My_vector& y) - { - auto tmp = x; // copy elements - x = y; - y = tmp; - } +* The compiler should do it +* If the compiler doesn't do it, let tools flag it -This is not just slow, but if a memory allocation occur for the elements in `tmp`, this `swap` may throw and would make STL algorithms fail is used with them. +### F.47: Return `T&` from assignment operators -**Enforcement**: (Simple) When a class has a `swap` member function, it should be declared `noexcept`. +##### Reason +The convention for operator overloads (especially on concrete types) is for +`operator=(const T&)` to perform the assignment and then return (non-`const`) +`*this`. This ensures consistency with standard-library types and follows the +principle of "do as the ints do." - -### C.85: Make `swap` `noexcept` +##### Note -**Reason**: [A `swap` may not fail](#Rc-swap-fail). -If a `swap` tries to exit with an exception, it's a bad design error and the program had better terminate. +Historically there was some guidance to make the assignment operator return `const T&`. +This was primarily to avoid code of the form `(a = b) = c` -- such code is not common enough to warrant violating consistency with standard types. -**Enforcement**: (Simple) When a class has a `swap` member function, it should be declared `noexcept`. - - - -### C.86: Make `==` symmetric with respect to operand types and `noexcept` - -**Reason**: Assymetric treatment of operands is surprising and a source of errors where conversions are possible. -`==` is a fundamental operations and programmers should be able to use it without fear of failure. - -**Example**: - - class X { - string name; - int number; - }; - - bool operator==(const X& a, const X& b) noexcept { return a.name==b.name && a.number==b.number; } - -**Example, bad**: - - class B { - string name; - int number; - bool operator==(const B& a) const { return name==a.name && number==a.number; } - // ... - }; - -`B`'s comparison accepts conversions for its second operand, but not its first. +##### Example -**Note**: If a class has a failure state, like `double`'s `NaN`, there is a temptation to make a comparison against the failure state throw. -The alternative is to make two failure states compare equal and any valid state compare false against the failure state. + class Foo + { + public: + ... + Foo& operator=(const Foo& rhs) + { + // Copy members. + ... + return *this; + } + }; -**Enforcement**: ??? +##### Enforcement +This should be enforced by tooling by checking the return type (and return +value) of any assignment operator. - -### C.87: Beware of `==` on base classes +### F.48: Don't `return std::move(local)` -**Reason**: It is really hard to write a foolproof and useful `==` for a hierarchy. - -**Example, bad**: - - class B { - string name; - int number; - virtual bool operator==(const B& a) const { return name==a.name && number==a.number; } - // ... - }; - -// `B`'s comparison accpts conversions for its second operand, but not its first. +##### Reason - class D :B { - char character; - virtual bool operator==(const D& a) const { return name==a.name && number==a.number && character==a.character; } - // ... - }; - - B b = ... - D d = ... - b==d; // compares name and number, ignores d's character - d==b; // error: no == defined - D d2; - d==d2; // compares name, number, and character - B& b2 = d2; - b2==d; // compares name and number, ignores d2's and d's character - -Of course there are way of making `==` work in a hierarchy, but the naive approaches do not scale - -**Enforcement**: ??? +Returning a local variable implicitly moves it anyway. +An explicit `std::move` is always a pessimization, because it prevents Return Value Optimization (RVO), +which can eliminate the move completely. +##### Example, bad - -### C.88: Make `<` symmetric with respect to operand types and `noexcept` + S bad() + { + S result; + return std::move(result); + } -**Reason**: ??? +##### Example, good -**Example**: + S good() + { + S result; + // Named RVO: move elision at best, move construction at worst + return result; + } - ??? - -**Enforcement**: ??? +##### Enforcement +This should be enforced by tooling by checking the return expression . - -### C.89: Make a `hash` `noexcept` +### F.49: Don't return `const T` -**Reason**: ??? +##### Reason -**Example**: +It is not recommended to return a `const` value. +Such older advice is now obsolete; it does not add value, and it interferes with move semantics. - ??? - -**Enforcement**: ??? +##### Example - -## C.con: Containers and other resource handles + const vector fct(); // bad: that "const" is more trouble than it is worth -A container is an object holding a sequence of objects of some type; `std::vector` is the archetypical container. -A resource handle is a class that owns a resource; `std::vector` is the typical resource handle; its resource is its sequence of elements. + void g(vector& vx) + { + // ... + fct() = vx; // prevented by the "const" + // ... + vx = fct(); // expensive copy: move semantics suppressed by the "const" + // ... + } -Summary of container rules: +The argument for adding `const` to a return value is that it prevents (very rare) accidental access to a temporary. +The argument against is that it prevents (very frequent) use of move semantics. -* [C.100: Follow the STL when defining a container](#Rcon-stl) -* [C.101: Give a container value semantics](#Rcon-val) -* [C.102: Give a container move operations](#Rcon-move) -* [C.103: Give a container an initializer list constructor](#Rcon-init) -* [C.104: Give a container a default constructor that sets it to empty](#Rcon-empty) -* [C.105: Give a constructor and `Extent` constructor](#Rcon-val) -* ??? -* [C.109: If a resource handle has pointer semantics, provide `*` and `->`](#rcon-ptr) +**See also**: [F.20, the general item about "out" output values](#Rf-out) -**See also**: [Resources](#SS-resources) +##### Enforcement +* Flag returning a `const` value. To fix: Remove `const` to return a non-`const` value instead. - -## C.lambdas: Function objects and lambdas -A function object is an object supplying an overloaded `()` so that you can call it. -A lambda expression (colloquially often shortened to "a lambda") is a notation for generating a function object. +### F.50: Use a lambda when a function won't do (to capture local variables, or to write a local function) -Summary: +##### Reason -* [F.50: Use a lambda when a function won't do (to capture local variables, or to write a local function)](#Rf-capture-vs-overload) -* [F.52: Prefer capturing by reference in lambdas that will be used locally, including passed to algorithms](#Rf-reference-capture) -* [F.53: Avoid capturing by reference in lambdas that will be used nonlocally, including returned, stored on the heap, or passed to another thread](#Rf-value-capture) -* [ES.28: Use lambdas for complex initialization, especially of `const` variables](#Res-lambda-init) +Functions can't capture local variables or be defined at local scope; if you need those things, prefer a lambda where possible, and a handwritten function object where not. On the other hand, lambdas and function objects don't overload; if you need to overload, prefer a function (the workarounds to make lambdas overload are ornate). If either will work, prefer writing a function; use the simplest tool necessary. +##### Example + // writing a function that should only take an int or a string + // -- overloading is natural + void f(int); + void f(const string&); - -## C.hier: Class hierarchies (OOP) + // writing a function object that needs to capture local state and appear + // at statement or expression scope -- a lambda is natural + vector v = lots_of_work(); + for (int tasknum = 0; tasknum < max; ++tasknum) { + pool.run([=, &v] { + /* + ... + ... process 1 / max - th of v, the tasknum - th chunk + ... + */ + }); + } + pool.join(); -A class hierarchy is constructed to represent a set of hierarchically organized concepts (only). -Typically base classes act as interfaces. -There are two major uses for hierarchies, often named implementation inheritance and interface inheritance. +##### Exception -Class hierarchy rule summary: +Generic lambdas offer a concise way to write function templates and so can be useful even when a normal function template would do equally well with a little more syntax. This advantage will probably disappear in the future once all functions gain the ability to have Concept parameters. -* [C.120: Use class hierarchies to represent concepts with inherent hierarchical structure](#Rh-domain) -* [C.121: If a base class is used as an interface, make it a pure abstract class](#Rh-abstract) -* [C.122: Use abstract classes as interfaces when complete separation of interface and implementation is needed](#Rh-separation) +##### Enforcement -Designing rules for classes in a hierarchy summary: +* Warn on use of a named non-generic lambda (e.g., `auto x = [](int i) { /*...*/; };`) that captures nothing and appears at global scope. Write an ordinary function instead. -* [C.126: An abstract class typically doesn't need a constructor](#Rh-abstract-ctor) -* [C.127: A class with a virtual function should have a virtual destructor](#Rh-dtor) -* [C.128: Use `override` to make overriding explicit in large class hierarchies](#Rh-override) -* [C.129: When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance](#Rh-kind) -* [C.130: Redefine or prohibit copying for a base class; prefer a virtual `clone` function instead](#Rh-copy) - -* [C.131: Avoid trivial getters and setters](#Rh-get) -* [C.132: Don't make a function `virtual` without reason](#Rh-virtual) -* [C.133: Avoid `protected` data](#Rh-protected) -* [C.134: Ensure all data members have the same access level](#Rh-public) -* [C.135: Use multiple inheritance to represent multiple distinct interfaces](#Rh-mi-interface) -* [C.136: Use multiple inheritance to represent the union of implementation attributes](#Rh-mi-implementation) -* [C.137: Use `virtual` bases to avoid overly general base classes](#Rh-vbase) -* [C.138: Create an overload set for a derived class and its bases with `using`](#Rh-using) +### F.51: Where there is a choice, prefer default arguments over overloading -Accessing objects in a hierarchy rule summary: +##### Reason -* [C.145: Access polymorphic objects through pointers and references](#Rh-poly) -* [C.146: Use `dynamic_cast` where class hierarchy navigation is unavoidable](#Rh-dynamic_cast) -* [C.147: Use `dynamic_cast` to a reference type when failure to find the required class is considered an error](#Rh-ptr-cast) -* [C.148: Use `dynamic_cast` to a pointer type when failure to find the required class is considered a valid alternative](#Rh-ref-cast) -* [C.149: Use `unique_ptr` or `shared_ptr` to avoid forgetting to `delete` objects created using `new`](#Rh-smart) -* [C.150: Use `make_unique()` to construct objects owned by `unique_ptr`s or another smart pointer](#Rh-make_unique) -* [C.151: Use `make_shared()` to construct objects owned by `shared_ptr`s](#Rh-make_shared) -* [C.152: Never assign a pointer to an array of derived class objects to a pointer to its base](#Rh-array) +Default arguments simply provide alternative interfaces to a single implementation. +There is no guarantee that a set of overloaded functions all implement the same semantics. +The use of default arguments can avoid code replication. +##### Note - -### C.120: Use class hierarchies to represent concepts with inherent hierarchical structure (only) +There is a choice between using default argument and overloading when the alternatives are from a set of arguments of the same types. +For example: -**Reason**: Direct representation of ideas in code eases comprehension and maintenance. Make sure the idea represented in the base class exactly matches all derived types and there is not a better way to express it than using the tight coupling of inheritance. + void print(const string& s, format f = {}); -Do *not* use inheritance when simply having a data member will do. Usually this means that the derived type needs to override a base virtual function or needs access to a protected member. +as opposed to -**Example**: + void print(const string& s); // use default format + void print(const string& s, format f); - ??? Good old Shape example? - -**Example, bad**: -Do *not* represent non-hierarchical domain concepts as class hierarchies. +There is not a choice when a set of functions are used to do a semantically equivalent operation to a set of types. For example: - template - class Container { - public: - // list operations: - virtual T& get() = 0; - virtual void put(T&) = 0; - virtual void insert(Position) = 0; - // ... - // vector operations: - virtual T& operator[](int) = 0; - virtual void sort() = 0; - // ... - // tree operations: - virtual void balance() = 0; - // ... - }; - -Here most overriding classes cannot implement most of the functions required in the interface well. -Thus the base class becomes an implementation burden. -Furthermore, the user of `Container` cannot rely on the member functions actually performing a meaningful operations reasonably efficiently; -it may throw an exception instead. -Thus users have to resort to run-time checking and/or -not using this (over)general interface in favor of a particular interface found by a run-time type inquiry (e.g., a `dynamic_cast`). + void print(const char&); + void print(int); + void print(zstring); -**Enforcement**: +##### See also -* Look for classes with lots of members that do nothing but throw. -* Flag every use of a nonpublic base class where the derived class does not override a virtual function or access a protected base member. +[Default arguments for virtual functions](#Rh-virtual-default-arg) - -### C.121: If a base class is used as an interface, make it a pure abstract class +##### Enforcement -**Reason**: A class is more stable (less brittle) if it does not contain data. Interfaces should normally be composed entirely of public pure virtual functions. +* Warn on an overload set where the overloads have a common prefix of parameters (e.g., `f(int)`, `f(int, const string&)`, `f(int, const string&, double)`). (Note: Review this enforcement if it's too noisy in practice.) -**Example**: +### F.52: Prefer capturing by reference in lambdas that will be used locally, including passed to algorithms - ??? +##### Reason -**Enforcement**: +For efficiency and correctness, you nearly always want to capture by reference when using the lambda locally. This includes when writing or calling parallel algorithms that are local because they join before returning. -* Warn on any class that contains data members and also has an overridable (non-`final`) virtual function. +##### Discussion +The efficiency consideration is that most types are cheaper to pass by reference than by value. - -### C.122: Use abstract classes as interfaces when complete separation of interface and implementation is needed +The correctness consideration is that many calls want to perform side effects on the original object at the call site (see example below). Passing by value prevents this. -**Reason**: Such as on an ABI (link) boundary. +##### Note -**Example**: +Unfortunately, there is no simple way to capture by reference to `const` to get the efficiency for a local call but also prevent side effects. - ??? +##### Example -**Enforcement**: ??? +Here, a large object (a network message) is passed to an iterative algorithm, and it is not efficient or correct to copy the message (which might not be copyable): + std::for_each(begin(sockets), end(sockets), [&message](auto& socket) + { + socket.send(message); + }); +##### Example -## C.hierclass: Designing classes in a hierarchy: +This is a simple three-stage parallel pipeline. Each `stage` object encapsulates a worker thread and a queue, has a `process` function to enqueue work, and in its destructor automatically blocks waiting for the queue to empty before ending the thread. + void send_packets(buffers& bufs) + { + stage encryptor([](buffer& b) { encrypt(b); }); + stage compressor([&](buffer& b) { compress(b); encryptor.process(b); }); + stage decorator([&](buffer& b) { decorate(b); compressor.process(b); }); + for (auto& b : bufs) { decorator.process(b); } + } // automatically blocks waiting for pipeline to finish - -### C.126: An abstract class typically doesn't need a constructor +##### Enforcement -**Reason**: An abstract class typically does not have any data for a constructor to initialize. +Flag a lambda that captures by reference, but is used other than locally within the function scope or passed to a function by reference. (Note: This rule is an approximation, but does flag passing by pointer as those are more likely to be stored by the callee, writing to a heap location accessed via a parameter, returning the lambda, etc. The Lifetime rules will also provide general rules that flag escaping pointers and references including via lambdas.) -**Example**: +### F.53: Avoid capturing by reference in lambdas that will be used non-locally, including returned, stored on the heap, or passed to another thread - ??? - -**Exceptions**: -* A base class constructor that does work, such as registering an object somewhere, may need a constructor. -* In extremely rare cases, you might find a reasonable for an abstract class to have a bit of data shared by all derived classes -(e.g., use statistics data, debug information, etc.); such classes tend to have constructors. But be warned: Such classes also tend to be prone to requiring virtual inheritance. +##### Reason -**Enforcement**: Flag abstract classes with constructors. +Pointers and references to locals shouldn't outlive their scope. Lambdas that capture by reference are just another place to store a reference to a local object, and shouldn't do so if they (or a copy) outlive the scope. +##### Example, bad - -### C.127: A class with a virtual function should have a virtual destructor + int local = 42; -**Reason**: A class with a virtual function is usually (and in general) used via a pointer to base, including that the last user has to call delete on a pointer to base, often via a smart pointer to base. + // Want a reference to local. + // Note, that after program exits this scope, + // local no longer exists, therefore + // process() call will have undefined behavior! + thread_pool.queue_work([&] { process(local); }); -**Example, bad**: +##### Example, good - struct B { - // ... no destructor ... - }; + int local = 42; + // Want a copy of local. + // Since a copy of local is made, it will + // always be available for the call. + thread_pool.queue_work([=] { process(local); }); - struct D : B { // bad: class with a resource derived from a class without a virtual destructor - string s {"default"}; - }; +##### Note - void use() - { - B* p = new D; - delete p; // leak the string - } +If a non-local pointer must be captured, consider using `unique_ptr`; this handles both lifetime and synchronization. -**Note**: There are people who don't follow this rule because they plan to use a class only through a `shared_ptr`: `std::shared_ptr p = std::make_shared(args);` Here, the shared pointer will take care of deletion, so no leak will occur from and inappropriate `delete` of the base. People who do this consistently can get a false positive, but the rule is important -- what if one was allocated using `make_unique`? It's not safe unless the author of `B` ensures that it can never be misused, such as by making all constructors private and providing a factory functions to enforce the allocation with `make_shared`. +If the `this` pointer must be captured, consider using `[*this]` capture, which creates a copy of the entire object. -**Enforcement**: +##### Enforcement -* Flag a class with a virtual function and no virtual destructor. Note that this rule needs only be enforced for the first (base) class in which it occurs, derived classes inherit what they need. This flags the place where the problem arises, but can give false positives. -* Flag `delete` of a class with a virtual function but no virtual destructor. +* (Simple) Warn when capture-list contains a reference to a locally declared variable +* (Complex) Flag when capture-list contains a reference to a locally declared variable and the lambda is passed to a non-`const` and non-local context +### F.54: When writing a lambda that captures `this` or any class data member, don't use `[=]` default capture - -### C.128: Use `override` to make overriding explicit in large class hierarchies +##### Reason -**Reason**: Readability. Detection of mistakes. Explicit `override` allows the compiler to catch mismatch of types and/or names between base and derived classes. +It's confusing. Writing `[=]` in a member function appears to capture by value, but actually captures data members by reference because it actually captures the invisible `this` pointer by value. If you meant to do that, write `this` explicitly. -**Example, bad**: +##### Example - struct B { - void f1(int); - virtual void f2(int); - virtual void f3(int); - // ... - }; + class My_class { + int x = 0; + // ... - struct D : B { - void f1(int); // warn: D::f1() hides B::f1() - void f2(int); // warn: no explicit override - void f3(double); // warn: D::f3() hides B::f3() - // ... - }; + void f() + { + int i = 0; + // ... -**Enforcement**: + auto lambda = [=] { use(i, x); }; // BAD: "looks like" copy/value capture -* Compare names in base and derived classes and flag uses of the same name that does not override. -* Flag overrides without `override`. + x = 42; + lambda(); // calls use(0, 42); + x = 43; + lambda(); // calls use(0, 43); + // ... - -### C.129: When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance + auto lambda2 = [i, this] { use(i, x); }; // ok, most explicit and least confusing -**Reason**: ??? Herb: I've become a non-fan of implementation inheritance -- seems most often an antipattern. Are there reasonable examples of it? + // ... + } + }; -**Example**: +##### Note - ??? +If you intend to capture a copy of all class data members, consider C++17 `[*this]`. -**Enforcement**: ??? +##### Enforcement +* Flag any lambda capture-list that specifies a capture-default of `[=]` and also captures `this` (whether explicitly or via the default capture and a use of `this` in the body) - -### C.130: Redefine or prohibit copying for a base class; prefer a virtual `clone` function instead +### F.55: Don't use `va_arg` arguments -**Reason**: Copying a base is usually slicing. If you really need copy semantics, copy deeply: Provide a virtual `clone` function that will copy the actual most-derived type, and in derived classes return the derived type (use a covariant return type). +##### Reason -**Example**: +Reading from a `va_arg` assumes that the correct type was actually passed. +Passing to varargs assumes the correct type will be read. +This is fragile because it cannot generally be enforced to be safe in the language and so relies on programmer discipline to get it right. - class base { - public: - virtual base* clone() =0; - }; - - class derived : public base { - public: - derived* clone() override; - }; - -Note that because of language rules, the covariant return type cannot be a smart pointer. +##### Example -**Enforcement**: + int sum(...) + { + // ... + while (/*...*/) + result += va_arg(list, int); // BAD, assumes it will be passed ints + // ... + } -* Flag a class with a virtual function and a non-user-defined copy operation. -* Flag an assignment of base class objects (objects of a class from which another has been derived). - - - -### C.131: Avoid trivial getters and setters + sum(3, 2); // ok + sum(3.14159, 2.71828); // BAD, undefined -**Reason**: A trivial getter or setter adds no semantic value; the data item could just as well be `public`. + template + auto sum(Args... args) // GOOD, and much more flexible + { + return (... + args); // note: C++17 "fold expression" + } -**Example**: + sum(3, 2); // ok: 5 + sum(3.14159, 2.71828); // ok: ~5.85987 - class point { - int x; - int y; - public: - point(int xx, int yy) : x{xx}, y{yy} { } - int get_x() { return x; } - void set_x(int xx) { x = xx; } - int get_y() { return y; } - void set_y(int yy) { y = yy; } - // no behavioral member functions - }; +##### Alternatives -Consider making such a class a `struct` -- that is, a behaviorless bunch of variables, all public data and no member functions. +* overloading +* variadic templates +* `variant` arguments +* `initializer_list` (homogeneous) - struct point { - int x = 0; - int y = 0; - }; +##### Note -**Note**: A getter or a setter that converts from an internal type to an interface type is not trivial (it provides a form of information hiding). +Declaring a `...` parameter is sometimes useful for techniques that don't involve actual argument passing, notably to declare "take-anything" functions so as to disable "everything else" in an overload set or express a catchall case in a template metaprogram. -**Enforcement**: Flag multiple `get` and `set` member functions that simply access a member without additional semantics. +##### Enforcement +* Issue a diagnostic for using `va_list`, `va_start`, or `va_arg`. +* Issue a diagnostic for passing an argument to a vararg parameter of a function that does not offer an overload for a more specific type in the position of the vararg. To fix: Use a different function, or `[[suppress("type")]]`. - -### C.132: Don't make a function `virtual` without reason -**Reason**: Redundant `virtual` increases run-time and object-code size. -A virtual function can be overridden and is thus open to mistakes in a derived class. -A virtual function ensures code replication in a templated hierarchy. +### F.56: Avoid unnecessary condition nesting -**Example, bad**: +##### Reason - template - class Vector { - public: - // ... - virtual int size() const { return sz; } // bad: what good could a derived class do? - private: - T* elem; // the elements - int sz; // number of elements - }; +Shallow nesting of conditions makes the code easier to follow. It also makes the intent clearer. +Strive to place the essential code at outermost scope, unless this obscures intent. -This kind of "vector" isn't meant to be used as a base class at all. +##### Example -**Enforcement**: +Use a guard-clause to take care of exceptional cases and return early. -* Flag a class with virtual functions but no derived classes. -* Flag a class where all member functions are virtual and have implementations. + // Bad: Deep nesting + void foo() { + ... + if (x) { + computeImportantThings(x); + } + } + // Bad: Still a redundant else. + void foo() { + ... + if (!x) { + return; + } + else { + computeImportantThings(x); + } + } - -### C.133: Avoid `protected` data + // Good: Early return, no redundant else + void foo() { + ... + if (!x) + return; -**Reason**: `protected` data is a source of complexity and errors. -`protected` data complicated the statement of invariants. -`protected` data inherently violates the guidance against putting data in base classes, which usually leads to having to deal virtual inheritance as well. + computeImportantThings(x); + } -**Example**: +##### Example - ??? - -**Note**: Protected member function can be just fine. + // Bad: Unnecessary nesting of conditions + void foo() { + ... + if (x) { + if (y) { + computeImportantThings(x); + } + } + } -**Enforcement**: Flag classes with `protected` data. + // Good: Merge conditions + return early + void foo() { + ... + if (!(x && y)) + return; + computeImportantThings(x); + } - -### C.134: Ensure all data members have the same access level +##### Enforcement -**Reason**: If they don't, the type is confused about what it's trying to do. Only if the type is not really an abstraction, but just a convenience bundle to group individual variables with no larger behavior (a behaviorless bunch of variables), make all data members `public` and don't provide functions with behavior. Otherwise, the type is an abstraction, so make all its data members `private`. Don't mix `public` and `private` data. +Flag a redundant `else`. +Flag a functions whose body is simply a conditional statement enclosing a block. -**Example**: - ??? +# C: Classes and class hierarchies -**Enforcement**: Flag any class that has data members with different access levels. +A class is a user-defined type, for which a programmer can define the representation, operations, and interfaces. +Class hierarchies are used to organize related classes into hierarchical structures. +Class rule summary: - -### C.135: Use multiple inheritance to represent multiple distinct interfaces +* [C.1: Organize related data into structures (`struct`s or `class`es)](#Rc-org) +* [C.2: Use `class` if the class has an invariant; use `struct` if the data members can vary independently](#Rc-struct) +* [C.3: Represent the distinction between an interface and an implementation using a class](#Rc-interface) +* [C.4: Make a function a member only if it needs direct access to the representation of a class](#Rc-member) +* [C.5: Place helper functions in the same namespace as the class they support](#Rc-helper) +* [C.7: Don't define a class or enum and declare a variable of its type in the same statement](#Rc-standalone) +* [C.8: Use `class` rather than `struct` if any member is non-public](#Rc-class) +* [C.9: Minimize exposure of members](#Rc-private) -**Reason**: Not all classes will necessarily support all interfaces, and not all callers will necessarily want to deal with all operations. Especially to break apart monolithic interfaces into "aspects" of behavior supported by a given derived class. +Subsections: -**Example**: +* [C.concrete: Concrete types](#SS-concrete) +* [C.ctor: Constructors, assignments, and destructors](#S-ctor) +* [C.con: Containers and other resource handles](#SS-containers) +* [C.lambdas: Function objects and lambdas](#SS-lambdas) +* [C.hier: Class hierarchies (OOP)](#SS-hier) +* [C.over: Overloading and overloaded operators](#SS-overload) +* [C.union: Unions](#SS-union) - ??? - -**Note**: This is a very common use of inheritance because the need for multiple different interfaces to an implementation is common -and such interfaces are often not easily or naturally organized into a single-rooted hierarchy. +### C.1: Organize related data into structures (`struct`s or `class`es) -**Note**: Such interfaces are typically abstract classes. +##### Reason -**Enforcement**: ??? +Ease of comprehension. +If data is related (for fundamental reasons), that fact should be reflected in code. +##### Example - -### C.136: Use multiple inheritance to represent the union of implementation attributes + void draw(int x, int y, int x2, int y2); // BAD: unnecessary implicit relationships + void draw(Point from, Point to); // better -**Reason**: ??? Herb: Here's the second mention of implementation inheritance. I'm very skeptical, even of single implementation inheritance, never mind multiple implementation inheritance which just seems frightening -- I don't think that even policy-based design really needs to inherit from the policy types. Am I missing some good examples, or could we consider discouraging this as an anti-pattern? +##### Note -**Example**: +A simple class without virtual functions implies no space or time overhead. - ??? - -**Note**: This a relatively rare use because implementation can often be organized into a single-rooted hierarchy. +##### Note -**Enforcement**: ??? Herb: How about opposite enforcement: Flag any type that inherits from more than one non-empty base class? +From a language perspective `class` and `struct` differ only in the default visibility of their members. +##### Enforcement - -### C.137: Use `virtual` bases to avoid overly general base classes +Probably impossible. Maybe a heuristic looking for data items used together is possible. -**Reason**: ??? +### C.2: Use `class` if the class has an invariant; use `struct` if the data members can vary independently -**Example**: +##### Reason - ??? - -**Note**: ??? +Readability. +Ease of comprehension. +The use of `class` alerts the programmer to the need for an invariant. +This is a useful convention. -**Enforcement**: ??? +##### Note - -### C.138: Create an overload set for a derived class and its bases with `using` +An invariant is a logical condition for the members of an object that a constructor must establish for the public member functions to assume. +After the invariant is established (typically by a constructor) every member function can be called for the object. +An invariant can be stated informally (e.g., in a comment) or more formally using `Expects`. -**Reason**: ??? +If all data members can vary independently of each other, no invariant is possible. -**Example**: +##### Example - ??? + struct Pair { // the members can vary independently + string name; + int volume; + }; +but: -## C.hier-access: Accessing objects in a hierarchy + class Date { + public: + // validate that {yy, mm, dd} is a valid date and initialize + Date(int yy, Month mm, char dd); + // ... + private: + int y; + Month m; + char d; // day + }; +##### Note - -### C.145: Access polymorphic objects through pointers and references +If a class has any `private` data, a user cannot completely initialize an object without the use of a constructor. +Hence, the class definer will provide a constructor and must specify its meaning. +This effectively means the definer need to define an invariant. -**Reason**: If you have a class with a virtual function, you don't (in general) know which class provided the function to be used. +**See also**: -**Example**: +* [define a class with private data as `class`](#Rc-class) +* [Prefer to place the interface first in a class](#Rl-order) +* [minimize exposure of members](#Rc-private) +* [Avoid `protected` data](#Rh-protected) - struct B { int a; virtual int f(); }; - struct D : B { int b; int f() override; }; +##### Enforcement - void use(B b) - { - D d; - B b2 = d; // slice - B b3 = b; - } +Look for `struct`s with all data private and `class`es with public members. - void use2() - { - D d; - use(d); // slice - } +### C.3: Represent the distinction between an interface and an implementation using a class -Both `d`s are sliced. +##### Reason -**Exeption**: You can safely access a named polymorphic object in the scope of its definition, just don't slice it. - - void use3() - { - D d; - d.f(); // OK - } - -**Enforcement**: Flag all slicing. - - - -### C.146: Use `dynamic_cast` where class hierarchy navigation is unavoidable - -**Reason**: `dynamic_cast` is checked at run time. - -**Example**: - - struct B { // an interface - virtual void f(); - virtual void g(); - }; - - struct D : B { // a wider interface - void f() override; - virtual void h(); - }; - - void user(B* pb) - { - if (D* pd = dynamic_cast(pb)) { - // ... use D's interface ... - } - else { - // .. make do with B's interface ... - } - } - -**Note**: Like other casts, `dynamic_cast` is overused. -[Prefer virtual functions to casting](#???). -Prefer [static polymorphism](#???) to hierarchy navigation where it is possible (no run-time resolution necessary) -and reasonably convenient. +An explicit distinction between interface and implementation improves readability and simplifies maintenance. -**Exception**: If your implementation provided a really slow `dynamic_cast`, you may have to use a workaround. -However, all workarounds that cannot be statically resolved involve explicit casting (typically `static_cast`) and are error-prone. -You will basically be crafting your own special-purpose `dynamic_cast`. -So, first make sure that your `dynamic_cast` really is as slow as you think it is (there are a fair number of unsupported rumors about) -and that your use of `dynamic_cast` is really performance critical. +##### Example -**Enforcement**: Flag all uses of `static_cast` for downcasts, including C-style casts that perform a `static_cast`. + class Date { + public: + Date(); + // validate that {yy, mm, dd} is a valid date and initialize + Date(int yy, Month mm, char dd); + int day() const; + Month month() const; + // ... + private: + // ... some representation ... + }; - -### C.147: Use `dynamic_cast` to a reference type when failure to find the required class is considered an error - -**Reason**: Casting to a reference expresses that you intend to end up with a valid object, so the cast must succeed. `dynamic_cast` will then throw if it does not succeed. - -**Example**: - - ??? +For example, we can now change the representation of a `Date` without affecting its users (recompilation is likely, though). -**Enforcement**: ??? +##### Note +Using a class in this way to represent the distinction between interface and implementation is of course not the only way. +For example, we can use a set of declarations of freestanding functions in a namespace, an abstract base class, or a function template with concepts to represent an interface. +The most important issue is to explicitly distinguish between an interface and its implementation "details." +Ideally, and typically, an interface is far more stable than its implementation(s). - -### C.148: Use `dynamic_cast` to a pointer type when failure to find the required class is considered a valid alternative +##### Enforcement -**Reason**: ??? +??? -**Example**: +### C.4: Make a function a member only if it needs direct access to the representation of a class - ??? +##### Reason -**Enforcement**: ??? +Less coupling than with member functions, fewer functions that can cause trouble by modifying object state, reduces the number of functions that needs to be modified after a change in representation. +##### Example - -### C.149: Use `unique_ptr` or `shared_ptr` to avoid forgetting to `delete` objects created using `new` + class Date { + // ... relatively small interface ... + }; -**Reason**: Avoid resource leaks. + // helper functions: + Date next_weekday(Date); + bool operator==(Date, Date); -**Example**: +The "helper functions" have no need for direct access to the representation of a `Date`. - void use(int i) - { - auto p = new int {7}; // bad: initialize local pointers with new - auto q = make_unique(9); // ok: guarantee the release of the memory allocated for 9 - if(0 -### C.150: Use `make_unique()` to construct objects owne by `unique_ptr`s or other smart pointers +Note [multi-methods](https://web.archive.org/web/20200605021759/https://parasol.tamu.edu/~yuriys/papers/OMM10.pdf). -**Reason**: `make_unique` gives a more concise statement of the construction. +##### Exception -**Example**: +The language requires operators `=`, `()`, `[]`, and `->` to be members. - unique_ptr p {new{7}); // OK: but repetitive +##### Exception - auto q = make_unique(7); // Better: no repetition of Foo +An overload set could have some members that do not directly access `private` data: -**Enforcement**: + class Foobar { + public: + void foo(long x) { /* manipulate private data */ } + void foo(double x) { foo(std::lround(x)); } + // ... + private: + // ... + }; -* Flag the repetitive usage of template specialization list `` -* Flag variables declared to be `unique_ptr` +##### Exception +Similarly, a set of functions could be designed to be used in a chain: - -### C.151: Use `make_shared()` to construct objects owned by `shared_ptr`s + x.scale(0.5).rotate(45).set_color(Color::red); -**Reason**: `make_shared` gives a more concise statement of the construction. -It also gives an opportunity to eliminate a separate allocation for the reference counts, by placing the `shared_ptr`'s use counts next to its object. +Typically, some but not all of such functions directly access `private` data. -**Example**: +##### Enforcement - shared_ptr p {new{7}); // OK: but repetitive; and separate allocations for the Foo and shared_ptr's use count +* Look for non-`virtual` member functions that do not touch data members directly. +The snag is that many member functions that do not need to touch data members directly do. +* Ignore `virtual` functions. +* Ignore functions that are part of an overload set out of which at least one function accesses `private` members. +* Ignore functions returning `this`. - auto q = make_shared(7); // Better: no repetition of Foo; one object +### C.5: Place helper functions in the same namespace as the class they support -**Enforcement**: +##### Reason -* Flag the repetive usage of template specialization list`` -* Flag variables declared to be `shared_ptr` +A helper function is a function (usually supplied by the writer of a class) that does not need direct access to the representation of the class, yet is seen as part of the useful interface to the class. +Placing them in the same namespace as the class makes their relationship to the class obvious and allows them to be found by argument dependent lookup. +##### Example - -### C.152: Never assign a pointer to an array of derived class objects to a pointer to its base + namespace Chrono { // here we keep time-related services -**Reason**: Subscripting the resulting base pointer will lead to invalid object access and probably to memory corruption. + class Time { /* ... */ }; + class Date { /* ... */ }; -**Example**: + // helper functions: + bool operator==(Date, Date); + Date next_weekday(Date); + // ... + } - struct B { int x; }; - struct D : B { int y; }; +##### Note - void use(B*); +This is especially important for [overloaded operators](#Ro-namespace). - D a[] = { {1,2}, {3,4}, {5,6} }; - B* p = a; // bad: a decays to &a[0] which is converted to a B* - p[1].x = 7; // overwrite D[0].y +##### Enforcement - use(a); // bad: a decays to &a[0] which is converted to a B* +* Flag global functions taking argument types from a single namespace. -**Enforcement**: +### C.7: Don't define a class or enum and declare a variable of its type in the same statement -* Flag all combinations of array decay and base to derived conversions. -* Pass an array as an `array_view` rather than as a pointer, and don't let the array name suffer a derived-to-base conversion before getting into the `array_view` +##### Reason +Mixing a type definition and the definition of another entity in the same declaration is confusing and unnecessary. - -# C.over: Overloading and overloaded operators +##### Example, bad -You can overload ordinary functions, template functions, and operators. -You cannot overload function objects. + struct Data { /*...*/ } data{ /*...*/ }; -Overload rule summary: +##### Example, good -* [C.160: Define operators primarily to mimic conventional usage](#Ro-conventional) -* [C.161: Use nonmember functions for symmetric operators](#Ro-symmetric) -* [C.162: Overload operations that are roughly equivalent](#Ro-equivalent) -* [C.163: Overload only for operations that are roughly equivalent](#Ro-equivalent-2) -* [C.164: Avoid conversion operators](#Ro-conversion) -* [C.170: If you feel like overloading a lambda, use a generic lambda](#Ro-lambda) + struct Data { /*...*/ }; + Data data{ /*...*/ }; - -### C.140: Define operators primarily to mimic conventional usage +##### Enforcement -**Reason**: Minimize surprises. +* Flag if the `}` of a class or enumeration definition is not followed by a `;`. The `;` is missing. -**Example, bad**: +### C.8: Use `class` rather than `struct` if any member is non-public - X operator+(X a, X b) { return a.v-b.v; } // bad: makes + subtract +##### Reason -???. Non-member operators: namespace-level definition (traditional?) vs friend definition (as used by boost.operator, limits lookup to ADL only) +Readability. +To make it clear that something is being hidden/abstracted. +This is a useful convention. -**Enforcement**: Possibly impossible. +##### Example, bad + struct Date { + int d, m; - -### C.141: Use nonmember functions for symmetric operators + Date(int i, Month m); + // ... lots of functions ... + private: + int y; // year + }; -**Reason**: If you use member functions, you need two. -Unless you use a non-member function for (say) `==`, `a==b` and `b==a` will be subtly different. +There is nothing wrong with this code as far as the C++ language rules are concerned, +but nearly everything is wrong from a design perspective. +The private data is hidden far from the public data. +The data is split in different parts of the class declaration. +Different parts of the data have different access. +All of this decreases readability and complicates maintenance. -**Example**: +##### Note - bool operator==(Point a, Point b) { return a.x==b.x && a.y==b.y; } +Prefer to place the interface first in a class, [see NL.16](#Rl-order). -**Enforcement**: Flag member operator functions. +##### Enforcement +Flag classes declared with `struct` if there is a `private` or `protected` member. - -### C.142: Overload operations that are roughly equivalent +### C.9: Minimize exposure of members -**Reason**: Having different names for logically equivalent operations on different argument types is confusing, leads to encoding type information in function names, and inhibits generic programming. +##### Reason -**Example**: Consider +Encapsulation. +Information hiding. +Minimize the chance of unintended access. +This simplifies maintenance. - void print(int a); - void print(int a, int base); - void print(const string&); +##### Example -These three functions all prints their arguments (appropriately). Conversely + template + struct pair { + T a; + U b; + // ... + }; - void print_int(int a); - void print_based(int a, int base); - void print_string(const string&); +Whatever we do in the `//`-part, an arbitrary user of a `pair` can arbitrarily and independently change its `a` and `b`. +In a large code base, we cannot easily find which code does what to the members of `pair`. +This might be exactly what we want, but if we want to enforce a relation among members, we need to make them `private` +and enforce that relation (invariant) through constructors and member functions. +For example: -These three functions all prints their arguments (appropriately). Adding to the name just introduced verbosity and inhibits generic code. + class Distance { + public: + // ... + double meters() const { return magnitude*unit; } + void set_unit(double u) + { + // ... check that u is a factor of 10 ... + // ... change magnitude appropriately ... + unit = u; + } + // ... + private: + double magnitude; + double unit; // 1 is meters, 1000 is kilometers, 0.001 is millimeters, etc. + }; -**Enforcement**: ??? +##### Note +If the set of direct users of a set of variables cannot be easily determined, the type or usage of that set cannot be (easily) changed/improved. +For `public` and `protected` data, that's usually the case. - -### C.143: Overload only for operations that are roughly equivalent +##### Example -**Reason**: Having the same name for logically different functions is confusing and leads to errors when using generic programming. +A class can provide two interfaces to its users. +One for derived classes (`protected`) and one for general users (`public`). +For example, a derived class might be allowed to skip a run-time check because it has already guaranteed correctness: -**Example**: Consider - - void open_gate(Gate& g); // remove obstacle from garage exit lane - void fopen(const char*name, const char* mode); // open file + class Foo { + public: + int bar(int x) { check(x); return do_bar(x); } + // ... + protected: + int do_bar(int x); // do some operation on the data + // ... + private: + // ... data ... + }; -The two operations are fundamentally different (and unrelated) so it is good that their names differ. Conversely: + class Dir : public Foo { + //... + int mem(int x, int y) + { + /* ... do something ... */ + return do_bar(x + y); // OK: derived class can bypass check + } + }; - void open(Gate& g); // remove obstacle from garage exit lane - void open(const char*name, const char* mode ="r"); // open file + void user(Foo& x) + { + int r1 = x.bar(1); // OK, will check + int r2 = x.do_bar(2); // error: would bypass check + // ... + } -The two operations are still fundamentally different (and unrelated) but the names have been reduced to their (common) minimum, opening opportunities for confusion. - Fortunately, the type system will catch many such mistakes. +##### Note -**Note**: be particularly careful about common and popular names, such as `open`, `move`, `+`, and `==`. +[`protected` data is a bad idea](#Rh-protected). -**Enforcement**: ??? +##### Note +Prefer the order `public` members before `protected` members before `private` members; see [NL.16](#Rl-order). - -### C.144: Avoid conversion operators +##### Enforcement -**Reason**: Implicit conversions can be essential (e.g., `double` to '`int`) but often cause surprises (e.g., `String` to C-style string). +* [Flag protected data](#Rh-protected). +* Flag mixtures of `public` and `private` data -**Note**: Prefer explicitly named conversions until a serious need is demonstrated. -By "serious need" we mean a reason that is fundamental in the application domain (such as an integer to complex number conversion) -and frequently needed. Do not introduce implicit conversions (through conversion operators or non-`explicit` constructors) -just to gain a minor convenience. +## C.concrete: Concrete types -**Example, bad**: +Concrete type rule summary: - class String { // handle ownership and access to a sequence of characters - // ... - String(czstring p); // copy from *p to *(this->elem) - // ... - operator zstring() { return elem; } - // ... - }; - - void user(zstring p) - { - if (*p=="") { - String s {"Trouble ahead!"}; - // ... - p = s; - } - // use p - } +* [C.10: Prefer concrete types over class hierarchies](#Rc-concrete) +* [C.11: Make concrete types regular](#Rc-regular) +* [C.12: Don't make data members `const` or references in a copyable or movable type](#Rc-constref) -The string allocated for `s` and assigned to `p` is destroyed before it can be used. -**Enforcement**: Flag all conversion operators. +### C.10: Prefer concrete types over class hierarchies - -### C.170: If you feel like overloading a lambda, use a generic lambda +##### Reason -**Reason**: You can overload by defining two different lambdas with the same name +A concrete type is fundamentally simpler than a type in a class hierarchy: +easier to design, easier to implement, easier to use, easier to reason about, smaller, and faster. +You need a reason (use cases) for using a hierarchy. -**Example**: +##### Example - void f(int); - void f(double); - auto f = [](char); // error: cannot overload variable and function - - auto g = [](int) { /* ... */ }; - auto g = [](double) { /* ... */ }; // error: cannot overload variables - - auto h = [](auto) { /* ... */ }; // OK - -**Enforcement**: The compiler catches attempt to overload a lambda. + class Point1 { + int x, y; + // ... operations ... + // ... no virtual functions ... + }; + class Point2 { + int x, y; + // ... operations, some virtual ... + virtual ~Point2(); + }; - -## C.union: Unions + void use() + { + Point1 p11 {1, 2}; // make an object on the stack + Point1 p12 {p11}; // a copy -??? + auto p21 = make_unique(1, 2); // make an object on the free store + auto p22 = p21->clone(); // make a copy + // ... + } -Union rule summary: +If a class is part of a hierarchy, we (in real code if not necessarily in small examples) must manipulate its objects through pointers or references. +That implies more memory overhead, more allocations and deallocations, and more run-time overhead to perform the resulting indirections. -* [C.180: Use `union`s to ???](#Ru-union) -* [C.181: Avoid "naked" `union`s](#Ru-naked) -* [C.182: Use anonymous `union`s to implement tagged unions](#Ru-anonymous) -* ??? +##### Note +Concrete types can be stack-allocated and be members of other classes. - -### C.180: Use `union`s to ??? +##### Note -??? When should unions be used, if at all? What's a good future-proof way to re-interpret object representations of PODs? -??? variant +The use of indirection is fundamental for run-time polymorphic interfaces. +The allocation/deallocation overhead is not (that's just the most common case). +We can use a base class as the interface of a scoped object of a derived class. +This is done where dynamic allocation is prohibited (e.g. hard-real-time) and to provide a stable interface to some kinds of plug-ins. -**Reason**: ??? -**Example**: +##### Enforcement - ??? +??? -**Enforcement**: ??? +### C.11: Make concrete types regular - -### C.181: Avoid "naked" `union`s +##### Reason -**Reason**: Naked unions are a source of type errors. +Regular types are easier to understand and reason about than types that are not regular (irregularities requires extra effort to understand and use). -**Alternative**: Wrap them in a class together with a type field. +The C++ built-in types are regular, and so are standard-library classes such as `string`, `vector`, and `map`. Concrete classes without assignment and equality can be defined, but they are (and should be) rare. -**Alternative**: Use `variant`. +##### Example -**Example**: + struct Bundle { + string name; + vector vr; + }; - ??? + bool operator==(const Bundle& a, const Bundle& b) + { + return a.name == b.name && a.vr == b.vr; + } -**Enforcement**: ??? + Bundle b1 { "my bundle", {r1, r2, r3}}; + Bundle b2 = b1; + if (!(b1 == b2)) error("impossible!"); + b2.name = "the other bundle"; + if (b1 == b2) error("No!"); +In particular, if a concrete type is copyable, prefer to also give it an equality comparison operator, and ensure that `a = b` implies `a == b`. +##### Note - -### C.182: Use anonymous `union`s to implement tagged unions +For structs intended to be shared with C code, defining `operator==` may not be feasible. -**Reason**: ??? +##### Note -**Example**: +Handles for resources that cannot be cloned, e.g., a `scoped_lock` for a `mutex`, are concrete types but typically cannot be copied (instead, they can usually be moved), +so they can't be regular; instead, they tend to be move-only. - ??? +##### Enforcement -**Enforcement**: ??? +??? +### C.12: Don't make data members `const` or references in a copyable or movable type - -# Enum: Enumerations +##### Reason -Enumerations are used to define sets of integer values and for defining types for such sets of values. There are two kind of enumerations, "plain" `enum`s and `class enum`s. +`const` and reference data members are not useful in a copyable or movable type, and make such types difficult to use by making them at least partly uncopyable/unmovable for subtle reasons. -Enumeration rule summary: +##### Example; bad -* [Enum.1: Prefer enums over macros](#Renum-macro) -* [Enum.2: Use enumerations to represent sets of named constants](#Renum-set) -* [Enum.3: Prefer class enums over ``plain'' enums](#Renum-class) -* [Enum.4: Define operations on enumerations for safe and simple use](#Renum-oper) -* [Enum.5: Don't use ALL_CAPS for enumerators](#Renum-caps) -* [Enum.6: Use unnamed enumerations for ???](#Renum-unnamed) -* ??? + class bad { + const int i; // bad + string& s; // bad + // ... + }; +The `const` and `&` data members make this class "only-sort-of-copyable" -- copy-constructible but not copy-assignable. - -### Enum.1: Prefer enums over macros +##### Note -**Reason**: Macros do not obey scope and type rules. +If you need a member to point to something, use a pointer (raw or smart, and `gsl::not_null` if it should not be null) instead of a reference. -**Example**: +##### Enforcement - ??? +Flag a data member that is `const`, `&`, or `&&` in a type that has any copy or move operation. -**Enforcement**: ??? - -### Enum.2: Use enumerations to represent sets of named constants +## C.ctor: Constructors, assignments, and destructors -**Reason**: ??? +These functions control the lifecycle of objects: creation, copy, move, and destruction. +Define constructors to guarantee and simplify initialization of classes. -**Example**: +These are *default operations*: - ??? +* a default constructor: `X()` +* a copy constructor: `X(const X&)` +* a copy assignment: `operator=(const X&)` +* a move constructor: `X(X&&)` +* a move assignment: `operator=(X&&)` +* a destructor: `~X()` -**Enforcement**: ??? +By default, the compiler defines each of these operations if it is used, but the default can be suppressed. +The default operations are a set of related operations that together implement the lifecycle semantics of an object. +By default, C++ treats classes as value-like types, but not all types are value-like. - -### Enum.3: Prefer class enums over ``plain'' enums +Set of default operations rules: -**Reason**: to minimize surprises +* [C.20: If you can avoid defining any default operations, do](#Rc-zero) +* [C.21: If you define or `=delete` any copy, move, or destructor function, define or `=delete` them all](#Rc-five) +* [C.22: Make default operations consistent](#Rc-matched) -**Example**: +Destructor rules: - ??? +* [C.30: Define a destructor if a class needs an explicit action at object destruction](#Rc-dtor) +* [C.31: All resources acquired by a class must be released by the class's destructor](#Rc-dtor-release) +* [C.32: If a class has a raw pointer (`T*`) or reference (`T&`), consider whether it might be owning](#Rc-dtor-ptr) +* [C.33: If a class has an owning pointer member, define a destructor](#Rc-dtor-ptr2) +* [C.35: A base class destructor should be either public and virtual, or protected and non-virtual](#Rc-dtor-virtual) +* [C.36: A destructor must not fail](#Rc-dtor-fail) +* [C.37: Make destructors `noexcept`](#Rc-dtor-noexcept) -**Enforcement**: ??? +Constructor rules: +* [C.40: Define a constructor if a class has an invariant](#Rc-ctor) +* [C.41: A constructor should create a fully initialized object](#Rc-complete) +* [C.42: If a constructor cannot construct a valid object, throw an exception](#Rc-throw) +* [C.43: Ensure that a copyable class has a default constructor](#Rc-default0) +* [C.44: Prefer default constructors to be simple and non-throwing](#Rc-default00) +* [C.45: Don't define a default constructor that only initializes data members; use member initializers instead](#Rc-default) +* [C.46: By default, declare single-argument constructors `explicit`](#Rc-explicit) +* [C.47: Define and initialize data members in the order of member declaration](#Rc-order) +* [C.48: Prefer default member initializers to member initializers in constructors for constant initializers](#Rc-in-class-initializer) +* [C.49: Prefer initialization to assignment in constructors](#Rc-initialize) +* [C.50: Use a factory function if you need "virtual behavior" during initialization](#Rc-factory) +* [C.51: Use delegating constructors to represent common actions for all constructors of a class](#Rc-delegating) +* [C.52: Use inheriting constructors to import constructors into a derived class that does not need further explicit initialization](#Rc-inheriting) - -### Enum.4: Define operations on enumerations for safe and simple use +Copy and move rules: -**Reason**: Convenience of us and avoidance of errors. +* [C.60: Make copy assignment non-`virtual`, take the parameter by `const&`, and return by non-`const&`](#Rc-copy-assignment) +* [C.61: A copy operation should copy](#Rc-copy-semantic) +* [C.62: Make copy assignment safe for self-assignment](#Rc-copy-self) +* [C.63: Make move assignment non-`virtual`, take the parameter by `&&`, and return by non-`const&`](#Rc-move-assignment) +* [C.64: A move operation should move and leave its source in a valid state](#Rc-move-semantic) +* [C.65: Make move assignment safe for self-assignment](#Rc-move-self) +* [C.66: Make move operations `noexcept`](#Rc-move-noexcept) +* [C.67: A polymorphic class should suppress public copy/move](#Rc-copy-virtual) -**Example**: +Other default operations rules: - ??? +* [C.80: Use `=default` if you have to be explicit about using the default semantics](#Rc-eqdefault) +* [C.81: Use `=delete` when you want to disable default behavior (without wanting an alternative)](#Rc-delete) +* [C.82: Don't call virtual functions in constructors and destructors](#Rc-ctor-virtual) +* [C.83: For value-like types, consider providing a `noexcept` swap function](#Rc-swap) +* [C.84: A `swap` must not fail](#Rc-swap-fail) +* [C.85: Make `swap` `noexcept`](#Rc-swap-noexcept) +* [C.86: Make `==` symmetric with respect of operand types and `noexcept`](#Rc-eq) +* [C.87: Beware of `==` on base classes](#Rc-eq-base) +* [C.89: Make a `hash` `noexcept`](#Rc-hash) +* [C.90: Rely on constructors and assignment operators, not memset and memcpy](#Rc-memset) -**Enforcement**: ??? +## C.defop: Default Operations +By default, the language supplies the default operations with their default semantics. +However, a programmer can disable or replace these defaults. - -### Enum.5: Don't use ALL_CAPS for enumerators +### C.20: If you can avoid defining default operations, do -**Reason**: Avoid clashes with macros +##### Reason -**Example**: +It's the simplest and gives the cleanest semantics. - ??? +##### Example -**Enforcement**: ??? + struct Named_map { + public: + explicit Named_map(const string& n) : name(n) {} + // no copy/move constructors + // no copy/move assignment operators + // no destructor + private: + string name; + map rep; + }; + Named_map nm("map"); // construct + Named_map nm2 {nm}; // copy construct - -### Enum.6: Use unnamed enumerations for ??? +Since `std::map` and `string` have all the special functions, no further work is needed. -**Reason**: ??? +##### Note -**Example**: +This is known as "the rule of zero". - ??? +##### Enforcement -**Enforcement**: ??? +(Not enforceable) While not enforceable, a good static analyzer can detect patterns that indicate a possible improvement to meet this rule. +For example, a class with a (pointer, size) pair of members and a destructor that `delete`s the pointer could probably be converted to a `vector`. +### C.21: If you define or `=delete` any copy, move, or destructor function, define or `=delete` them all +##### Reason - -# R: Resource management +The semantics of copy, move, and destruction are closely related, so if one needs to be declared, the odds are that others need consideration too. -This section contains rules related to resources. -A resource is anything that must be acquired and (explicitly or implicitly) released, such as memory, file handles, sockets, and locks. -The reason it must be released is typically that it can be in short supply, so even delayed release may do harm. -The fundamental aim is to ensure that we don't leak any resources and that we don't hold a resource longer than we need to. -An entity that is responsible for releasing a resource is called an owner. +Declaring any copy/move/destructor function, +even as `=default` or `=delete`, will suppress the implicit declaration +of a move constructor and move assignment operator. +Declaring a move constructor or move assignment operator, even as +`=default` or `=delete`, will cause an implicitly generated copy constructor +or implicitly generated copy assignment operator to be defined as deleted. +So as soon as any of these are declared, the others should +all be declared to avoid unwanted effects like turning all potential moves +into more expensive copies, or making a class move-only. -There are a few cases where leaks can be acceptable or even optimal: -if you are writing a program that simply produces an output based on an input and the amount of memory needed is proportional to the size of the input, -the optimal strategy (for performance and ease of programming) is sometimes simply never to delete anything. -If you have enough memory to handle your largest input, leak away, but be sure to give a good error message if you are wrong. -Here, we ignore such cases. +##### Example, bad -Resource management rule summary: + struct M2 { // bad: incomplete set of copy/move/destructor operations + public: + // ... + // ... no copy or move operations ... + ~M2() { delete[] rep; } + private: + pair* rep; // zero-terminated set of pairs + }; -* [R.1: Manage resources automatically using resource handles and RAII (resource acquisition is initialization)](#Rr-raii) -* [R.2: In interfaces, use raw pointers to denote individual objects (only)](#Rr-use-ptr) -* [R.3: A raw pointer (a `T*`) is non-owning](#Rr-ptr) -* [R.4: A raw reference (a `T&`) is non-owning](#Rr-ref) -* [R.5: Prefer scoped objects](#Rr-scoped) -* [R.6: Avoid non-`const` global variables](#Rr-global) - -Alocation and deallocation rule summary: - -* [R.10: Avoid `malloc()` and `free()`](#Rr-mallocfree) -* [R.11: Avoid calling `new` and `delete` explicitly](#Rr-newdelete) -* [R.12: Immediately give the result of an explicit resource allocation to a manager object](#Rr-immediate-alloc) -* [R.13: Perform at most one explicit resource allocation in a single expression statement](#Rr-single-alloc) -* [R.14: ??? array vs. pointer parameter](#Rr-ap) -* [R.15: Always overload matched allocation/deallocation pairs](#Rr-pair) - -Smart pointer rule summary: - -* [R.20: Use `unique_ptr` or `shared_ptr` to represent ownership](#Rr-owner) -* [R.21: Prefer `unique_ptr` over `shared_ptr` unless you need to share ownership](#Rr-unique) -* [R.22: Use `make_shared()` to make `shared_ptr`s](#Rr-make_shared) -* [R.23: Use `make_unique()` to make `unique_ptr`s](#Rr-make_unique) -* [R.24: Use `std::weak_ptr` to break cycles of `shared_ptr`s](#Rr-weak_ptr) -* [R.30: Take smart pointers as parameters only to explicitly express lifetime semantics](#Rr-smartptrparam) -* [R.31: If you have non-`std` smart pointers, follow the basic pattern from `std`](#Rr-smart) -* [R.32: Take a `unique_ptr` parameter to express that a function assumes ownership of a `widget`](#Rr-uniqueptrparam) -* [R.33: Take a `unique_ptr&` parameter to express that a function reseats the`widget`](#Rr-reseat) -* [R.34: Take a `shared_ptr` parameter to express that a function is part owner](#Rr-sharedptrparam-owner) -* [R.35: Take a `shared_ptr&` parameter to express that a function might reseat the shared pointer](#Rr-sharedptrparam) -* [R.36: Take a `const shared_ptr&` parameter to express that it might retain a reference count to the object ???](#Rr-sharedptrparam-const&) -* [R.37: Do not pass a pointer or reference obtained from an aliased smart pointer](#Rr-smartptrget) - - - -### Rule R.1: Manage resources automatically using resource handles and RAII (resource acquisition is initialization) - -**Reason**: To avoid leaks and the complexity of manual resource management. - C++'s language-enforced constructor/destructor symmetry mirrors the symmetry inherent in resource acquire/release function pairs such as `fopen`/`fclose`, `lock`/`unlock`, and `new`/`delete`. - Whenever you deal with a resource that needs paired acquire/release function calls, - encapsulate that resource in an object that enforces pairing for you -- acquire the resource in its constructor, and release it in its destructor. - -**Example, bad**: Consider - - void send( X* x, cstring_view destination ) { - auto port = OpenPort(destination); - my_mutex.lock(); + void use() + { + M2 x; + M2 y; // ... - Send(port, x); + x = y; // the default assignment // ... - my_mutex.unlock(); - ClosePort(port); - delete x; - } + } -In this code, you have to remember to `unlock`, `ClosePort`, and `delete` on all paths, and do each exactly once. -Further, if any of the code marked `...` throws an exception, then `x` is leaked and `my_mutex` remains locked. +Given that "special attention" was needed for the destructor (here, to deallocate), the likelihood that the implicitly-defined copy and move assignment operators will be correct is low (here, we would get double deletion). -**Example**: Consider +##### Note - void send( unique_ptr x, cstring_view destination ) { // x owns the X - Port port{destination}; // port owns the PortHandle - lock_guard guard{my_mutex}; // guard owns the lock - // ... - Send(port, x); - // ... - } // automatically unlocks my_mutex and deletes the pointer in x +This is known as "the rule of five." -Now all resource cleanup is automatic, performed once on all paths whether or not there is an exception. As a bonus, the function now advertises that it takes over ownership of the pointer. +##### Note -What is `Port`? A handy wrapper that encapsulates the resource: +If you want a default implementation (while defining another), write `=default` to show you're doing so intentionally for that function. +If you don't want a generated default function, suppress it with `=delete`. - class Port { - PortHandle port; - public: - Port( cstring_view destination ) : port{OpenPort(destination)} { } - ~Port() { ClosePort(port); } - operator PortHandle() { return port; } +##### Example, good - // port handles can't usually be cloned, so disable copying and assignment if necessary - Port(const Port&) =delete; - Port& operator=(const Port&) =delete; +When a destructor needs to be declared just to make it `virtual`, it can be +defined as defaulted. + + class AbstractBase { + public: + virtual void foo() = 0; // at least one abstract method to make the class abstract + virtual ~AbstractBase() = default; + // ... }; -**Note**: Where a resource is "ill-behaved" in that it isn't represented as a class with a destructor, wrap it in a class or use [`finally`](#S-gsl) +To prevent slicing as per [C.67](#Rc-copy-virtual), +make the copy and move operations protected or `=delete`d, and add a `clone`: -**See also**: [RAII](#Rr-raii). + class CloneableBase { + public: + virtual unique_ptr clone() const; + virtual ~CloneableBase() = default; + CloneableBase() = default; + CloneableBase(const CloneableBase&) = delete; + CloneableBase& operator=(const CloneableBase&) = delete; + CloneableBase(CloneableBase&&) = delete; + CloneableBase& operator=(CloneableBase&&) = delete; + // ... other constructors and functions ... + }; +Defining only the move operations or only the copy operations would have the +same effect here, but stating the intent explicitly for each special member +makes it more obvious to the reader. - -### R.2: In interfaces, use raw pointers to denote individual objects (only) +##### Note -**Reason**: Arrays are best represented by a container type (e.g., `vector` (owning)) or an `array_view` (non-owning). -Such containers and views hold sufficient information to do range checking. +Compilers enforce much of this rule and ideally warn about any violation. -**Example, bad**: +##### Note - void f(int* p, int n) // n is the number of elements in p[] - { - // ... - p[2] = 7; // bad: subscript raw pointer - // ... - } +Relying on an implicitly generated copy operation in a class with a destructor is deprecated. -The compiler does not read comments, and without reading other code you do not know whether `p` really points to `n` elements. -Use an `array_view` instead. +##### Note -**Example**: +Writing these functions can be error-prone. +Note their argument types: - void g(int* p, int fmt) // print *p using format #fmt - { - // ... uses *p and p[0] only ... - } - -**Exception**: C-style strings are passed as single pointers to a zero-terminated sequence of characters. -Use `zstring` rather than `char*` to indicate that you rely on that convention. + class X { + public: + // ... + virtual ~X() = default; // destructor (virtual if X is meant to be a base class) + X(const X&) = default; // copy constructor + X& operator=(const X&) = default; // copy assignment + X(X&&) noexcept = default; // move constructor + X& operator=(X&&) noexcept = default; // move assignment + }; -**Note**: Many current uses of pointers to a single element could be references. -However, where `nullptr` is a possible value, a reference may not be an reasonable alternative. +A minor mistake (such as a misspelling, leaving out a `const`, using `&` instead of `&&`, or leaving out a special function) can lead to errors or warnings. +To avoid the tedium and the possibility of errors, try to follow the [rule of zero](#Rc-zero). -**Enforcement**: +##### Enforcement -* Flag pointer arithmetic (including `++`) on a pointer that is not part of a container, view, or iterator. -This rule would generate a huge number of false positives if applied to an older code base. -* Flag array names passed as simple pointers +(Simple) A class should have a declaration (even a `=delete` one) for either all or none of the copy/move/destructor functions. +### C.22: Make default operations consistent +##### Reason - -### R.3: A raw pointer (a `T*`) is non-owning +The default operations are conceptually a matched set. Their semantics are interrelated. +Users will be surprised if copy/move construction and copy/move assignment do logically different things. Users will be surprised if constructors and destructors do not provide a consistent view of resource management. Users will be surprised if copy and move don't reflect the way constructors and destructors work. -**Reason**: There is nothing (in the C++ standard or in most code) to say otherwise and most raw pointers are non-owning. -We want owning pointers identified so that we can reliably and efficiently delete the objects pointed to by owning pointers. +##### Example, bad -**Example**: + class Silly { // BAD: Inconsistent copy operations + class Impl { + // ... + }; + shared_ptr p; + public: + Silly(const Silly& a) : p(make_shared()) { *p = *a.p; } // deep copy + Silly& operator=(const Silly& a) { p = a.p; return *this; } // shallow copy + // ... + }; - void f() - { - int* p1 = new int{7}; // bad: raw owning pointer - auto p2 = make_unique(7); // OK: the int is owned by a unique pointer - // ... - } +These operations disagree about copy semantics. This will lead to confusion and bugs. -The `unique_ptr` protects against leaks by guaranteeing the deletion of its object (even in the presence of exceptions). The `T*` does not. +##### Enforcement -**Example**: +* (Complex) A copy/move constructor and the corresponding copy/move assignment operator should write to the same data members at the same level of dereference. +* (Complex) Any data members written in a copy/move constructor should also be initialized by all other constructors. +* (Complex) If a copy/move constructor performs a deep copy of a data member, then the destructor should modify the data member. +* (Complex) If a destructor is modifying a data member, that data member should be written in any copy/move constructors or assignment operators. - template - class X { - // ... - public: - T* p; // bad: it is unclear whether p is owning or not - T* q; // bad: it is unclear whether q is owning or not - }; +## C.dtor: Destructors -We can fix that problem by making ownership explicit: +"Does this class need a destructor?" is a surprisingly insightful design question. +For most classes the answer is "no" either because the class holds no resources or because destruction is handled by [the rule of zero](#Rc-zero); +that is, its members can take care of themselves as concerns destruction. +If the answer is "yes", much of the design of the class follows (see [the rule of five](#Rc-five)). - template - class X2 { - // ... - public: - owner p; // OK: p is owning - T* q; // OK: q is not owning - }; - -**Note**: The fact that there are billions of lines of code that violates this rule against owning `T*`s cannot be ignored. -This code cannot all be rewritten (ever assuming good code transformation software). -This problem cannot be solved (at scale) by transforming all owning pointer to `unique_ptr`s and `shared_ptr`s, partly because we need/use owning "raw pointers" in the implementation of our fundamental resource handles. For example, most `vector` implementations have one owning pointer and two non-owning pointers. -Also, many ABIs (and essentially all interfaces to C code) use `T*`s, some of them owning. - -**Note**: `owner` has no default semantics beyond `T*` it can be used without changing any code using it and without affecting ABIs. -It is simply a (most valuable) indicator to programmers and analysis tools. -For example, if an `owner` is a member of a class, that class better have a destructor that `delete`s it. - -**Example**, bad: -Returning a (raw) pointer imposes a life-time management burden on the caller; that is, who deletes the pointed-to object? - - Gadget* make_gadget(int n) - { - auto p = new Gadget{n}; - // ... - return p; - } - - void caller(int n) - { - auto p = make_gadget(n); // remember to delete p - // ... - delete p; - } - -In addition to suffering from then problem from [leak](#???), this adds a spurious allocation and deallocation operation, -and is needlessly verbose. If Gadget is cheap to move out of a function (i.e., is small or has an efficient move operation), -just return it "by value:' - - Gadget make_gadget(int n) - { - Gadget g{n}; - // ... - return g; - } - -**Note**: This rule applies to factory functions. - -**Note**: If pointer semantics is required (e.g., because the return type needs to refer to a base class of a class hierarchy (an interface)), -return a "smart pointer." - -**Enforcement**: +### C.30: Define a destructor if a class needs an explicit action at object destruction -* (Simple) Warn on `delete` of a raw pointer that is not an `owner`. -* (Moderate) Warn on failure to either `reset` or explicitly `delete` an `owner` pointer on every code path. -* (Simple) Warn if the return value of `new` or a function call with return value of pointer type is assigned to a raw pointer. -* (Simple) Warn if a function returns an object that was allocated within the function but has a move constructor. -Suggest considering returning it by value instead. +##### Reason +A destructor is implicitly invoked at the end of an object's lifetime. +If the default destructor is sufficient, use it. +Only define a non-default destructor if a class needs to execute code that is not already part of its members' destructors. - -### R.4: A raw reference (a `T&`) is non-owning +##### Example -**Reason**: There is nothing (in the C++ standard or in most code) to say otherwise and most raw references are non-owning. -We want owners identified so that we can reliably and efficiently delete the objects pointed to by owning pointers. + template + struct final_action { // slightly simplified + A act; + final_action(A a) : act{a} {} + ~final_action() { act(); } + }; -**Example**: + template + final_action finally(A act) // deduce action type + { + return final_action{act}; + } - void f() - { - int& r = *new int{7}; // bad: raw owning reference - // ... - delete &r; // bad: violated the rule against deleting raw pointers - } - -**See also**: [The raw pointer rule](#Rr-ptr) + void test() + { + auto act = finally([] { cout << "Exit test\n"; }); // establish exit action + // ... + if (something) return; // act done here + // ... + } // act done here -**Enforcement**: See [the raw pointer rule](#Rr-ptr) +The whole purpose of `final_action` is to get a piece of code (usually a lambda) executed upon destruction. +##### Note - -### R.5: Prefer scoped objects +There are two general categories of classes that need a user-defined destructor: -**Reason**: A scoped object is a local object, a global object, or a member. -This implies that there is no separate allocation and deallocation cost in excess that already used for the containing scope or object. -The members of a scoped object are themselves scoped and the scoped object's constructor and destructor manage the members' lifetimes. +* A class with a resource that is not already represented as a class with a destructor, e.g., a `vector` or a transaction class. +* A class that exists primarily to execute an action upon destruction, such as a tracer or `final_action`. -**Example**: the following example is inefficient (because it has unnecessary allocation and deallocation), vulnerable to exception throws and returns in the "¦ part (leading to leaks), and verbose: +##### Example, bad - void some_function(int n) - { - auto p = new Gadget{n}; - // ... - delete p; - } + class Foo { // bad; use the default destructor + public: + // ... + ~Foo() { s = ""; i = 0; vi.clear(); } // clean up + private: + string s; + int i; + vector vi; + }; -Instead, use a local variable: +The default destructor does it better, more efficiently, and can't get it wrong. - void some_function(int n) - { - Gadget g{n}; - // ... - } +##### Enforcement -**Enforcement**: +Look for likely "implicit resources", such as pointers and references. Look for classes with destructors even though all their data members have destructors. -* (Moderate) Warn if an object is allocated and then deallocated on all paths within a function. Suggest it should be a local `auto` stack object instead. -* (Simple) Warn if a local `Unique_ptr` or `Shared_ptr` is not moved, copied, reassigned or `reset` before its lifetime ends. +### C.31: All resources acquired by a class must be released by the class's destructor +##### Reason +Prevention of resource leaks, especially in error cases. - -### R.6: Avoid non-`const` global variables +##### Note -**Reason**: Global variables can be accessed from everywhere so they can introduce surprising dependencies between apparently unrelated objects. -They are a notable source of errors. +For resources represented as classes with a complete set of default operations, this happens automatically. -**Warning**: The initialization of global objects is not totally ordered. If you use a global object initialize it with a constant. +##### Example -**Exception**: a global object is often better than a singleton. + class X { + ifstream f; // might own a file + // ... no default operations defined or =deleted ... + }; -**Exception**: An immutable (`const`) global does not introduce the problems we try to avoid by banning global objects. +`X`'s `ifstream` implicitly closes any file it might have open upon destruction of its `X`. -**Enforcement**: [[??? NM: Obviously we can warn about non-const statics....do we want to?]] +##### Example, bad + class X2 { // bad + FILE* f; // might own a file + // ... no default operations defined or =deleted ... + }; - -## R.alloc: Alocation and deallocation +`X2` might leak a file handle. +##### Note - -### R.10: Avoid `malloc()` and `free()` +What about a socket that won't close? A destructor, close, or cleanup operation [should never fail](#Rc-dtor-fail). +If it does nevertheless, we have a problem that has no really good solution. +For starters, the writer of a destructor does not know why the destructor is called and cannot "refuse to act" by throwing an exception. +See [discussion](#Sd-never-fail). +To make the problem worse, many "close/release" operations are not retryable. +Many have tried to solve this problem, but no general solution is known. +If at all possible, consider failure to close/cleanup a fundamental design error and terminate. -**Reason**: `malloc()` and `free()` do not support construction and destruction, and do not mix well with `new` and `delete`. +##### Note -**Example**: +A class can hold pointers and references to objects that it does not own. +Obviously, such objects should not be `delete`d by the class's destructor. +For example: - class Record { - int id; - string name; - // ... - }; - - void use() - { - Record* p1 = static_cast(malloc(sizeof(Record))); - // p1 may be nullptr - // *p1 is not initialized; in particular, that string isn't a string, but a string-sizes bag of bits - - auto p2 = new Record; - - // unless an exception is thrown, *p2 is default initialized - auto p3 = new(nothrow) Record; - // p3 may be nullptr; if not, *p2 is default initialized - - // ... - - delete p1; // error: cannot delete object allocated by malloc() - free(p2); // error: cannot free() object allocatedby new - } + Preprocessor pp { /* ... */ }; + Parser p { pp, /* ... */ }; + Type_checker tc { p, /* ... */ }; -In some implementaions that `delete` and that `free()` might work, or maybe they will cause run-time errors. - -**Exception**: There are applications and sections of code where exceptions are not acceptable. -Some of the best such example are in life-critical hard real-time code. -Beware that many bans on exception use are based on superstition (bad) -or by concerns for older code bases with unsystematics resource management (unfortunately, but sometimes necessary). -In such cases, consider the `nothrow` versions of `new`. +Here `p` refers to `pp` but does not own it. -**Enforcement**: Flag explicit use of `malloc` and `free`. +##### Enforcement +* (Simple) If a class has pointer or reference members that are owners + (e.g., deemed owners by using `gsl::owner`), then they should be referenced in its destructor. +* (Hard) Determine if pointer or reference members are owners when there is no explicit statement of ownership + (e.g., look into the constructors). - -### R.11: Avoid calling `new` and `delete` explicitly +### C.32: If a class has a raw pointer (`T*`) or reference (`T&`), consider whether it might be owning -**Reason**: The pointer returned by `new` should belong to a resource handle (that can call `delete`). -If the pointer returned from `new` is assigned to a plain/naked pointer, the object can be leaked. +##### Reason -**Note**: In a large program, a naked `delete` (that is a `delete` in application code, rather than part of code devoted to resource management) -is a likely bug: if you have N `delete`s, how can you be certain that you don't need N+1 or N-1? -The bug may be latent: it may emerge only during maintenace. -If you have a naked `new`, you probably need a naked `delete` somewhere, so you probably have a bug. +There is a lot of code that is non-specific about ownership. -**Enforcement**: (Simple) Warn on any explicit use of `new` and `delete`. Suggest using `make_unique` instead. +##### Example + class legacy_class + { + foo* m_owning; // Bad: change to unique_ptr or owner + bar* m_observer; // OK: keep + } - -### R.12: Immediately give the result of an explicit resource allocation to a manager object +The only way to determine ownership may be code analysis. -**Reason**: If you don't, an exception or a return may lead to a leak. +##### Note -**Example, bad**: +Ownership should be clear in new code (and refactored legacy code) according to [R.20](#Rr-owner) for owning +pointers and [R.3](#Rr-ptr) for non-owning pointers. References should never own [R.4](#Rr-ref). - void f(const string& name) - { - FILE* f = fopen(name,"r"); // open the file - vector buf(1024); - auto _ = finally([] { fclose(f); } // remember to close the file - // ... - } +##### Enforcement -The allocation of `buf` may fail and leak the file handle. +Look at the initialization of raw member pointers and member references and see if an allocation is used. -**Example**: +### C.33: If a class has an owning pointer member, define a destructor - void f(const string& name) - { - ifstream {name,"r"}; // open the file - vector buf(1024); - // ... - } +##### Reason -The use of the file handle (in `ifstream`) is simple, efficient, and safe. +An owned object must be `deleted` upon destruction of the object that owns it. -**Enforcement**: +##### Example -* Flag explicit allocations used to initialize pointers (problem: how many direct resource allocations can we recognize?) +A pointer member could represent a resource. +[A `T*` should not do so](#Rr-ptr), but in older code, that's common. +Consider a `T*` a possible owner and therefore suspect. + template + class Smart_ptr { + T* p; // BAD: vague about ownership of *p + // ... + public: + // ... no user-defined default operations ... + }; - -### R.13: Perform at most one explicit resource allocation in a single expression statement + void use(Smart_ptr p1) + { + // error: p2.p leaked (if not nullptr and not owned by some other code) + auto p2 = p1; + } -**Reason**: If you perform two explicit resource allocations in one statement, -you could leak resources because the order of evaluation of many subexpressions, including function arguments, is unspecified. +Note that if you define a destructor, you must define or delete [all default operations](#Rc-five): -**Example**: + template + class Smart_ptr2 { + T* p; // BAD: vague about ownership of *p + // ... + public: + // ... no user-defined copy operations ... + ~Smart_ptr2() { delete p; } // p is an owner! + }; - void fun( shared_ptr sp1, shared_ptr sp2 ); + void use(Smart_ptr2 p1) + { + auto p2 = p1; // error: double deletion + } -This `fun` can be called like this: +The default copy operation will just copy the `p1.p` into `p2.p` leading to a double destruction of `p1.p`. Be explicit about ownership: - fun( shared_ptr(new Widget(a,b)), shared_ptr(new Widget(c,d)) ); // BAD: potential leak + template + class Smart_ptr3 { + owner p; // OK: explicit about ownership of *p + // ... + public: + // ... + // ... copy and move operations ... + ~Smart_ptr3() { delete p; } + }; -This is exception-unsafe because the compiler may reorder the two expressions building the function's two arguments. -In particular, the compiler can interleave execution of the two expressions: -Memory allocation (by calling `operator new`) could be done first for both objects, followed by attempts to call the two `Widget` constructors. -If one of the constructor calls throws an exception, then the other object's memory will never be released! + void use(Smart_ptr3 p1) + { + auto p2 = p1; // OK: no double deletion + } -This subtle problem has a simple solution: Never perform more than one explicit resource allocation in a single expression statement. -For example: +##### Note - shared_ptr sp1(new Widget(a,b)); // Better, but messy - fun( sp1, new Widget(c,d) ); +Often the simplest way to get a destructor is to replace the pointer with a smart pointer (e.g., `std::unique_ptr`) and let the compiler arrange for proper destruction to be done implicitly. -The best solution is to avoid explicit allocation entirely use factory functions that return owning objects: +##### Note - fun( make_shared(a,b), make_shared(c,d) ); // Best +Why not just require all owning pointers to be "smart pointers"? +That would sometimes require non-trivial code changes and might affect ABIs. -Write your own factory wrapper if there is not one already. - -**Enforcement**: +##### Enforcement -* Flag expressions with multiple explicit resource allocations (problem: how many direct resource allocations can we recognize?) +* A class with a pointer data member is suspect. +* A class with an `owner` should define its default operations. - -### R.14: ??? array vs. pointer parameter +### C.35: A base class destructor should be either public and virtual, or protected and non-virtual -**Reason**: An array decays to a pointer, thereby losing its size, opening the opportunity for range errors. +##### Reason -**Example**: +To prevent undefined behavior. +If the destructor is public, then calling code can attempt to destroy a derived class object through a base class pointer, and the result is undefined if the base class's destructor is non-virtual. +If the destructor is protected, then calling code cannot destroy through a base class pointer and the destructor does not need to be virtual; it does need to be protected, not private, so that derived destructors can invoke it. +In general, the writer of a base class does not know the appropriate action to be done upon destruction. - ??? what do we recommend: f(int*[]) or f(int**) ??? +##### Discussion -**Alternative**: Use `array_view` to preserve size information. +See [this in the Discussion section](#Sd-dtor). -**Enforcement**: Flag `[]` parameters. +##### Example, bad + struct Base { // BAD: implicitly has a public non-virtual destructor + virtual void f(); + }; + + struct D : Base { + string s {"a resource needing cleanup"}; + ~D() { /* ... do some cleanup ... */ } + // ... + }; + + void use() + { + unique_ptr p = make_unique(); + // ... + } // p's destruction calls ~Base(), not ~D(), which leaks D::s and possibly more + +##### Note + +A virtual function defines an interface to derived classes that can be used without looking at the derived classes. +If the interface allows destroying, it should be safe to do so. + +##### Note + +A destructor must be non-private or it will prevent using the type: + + class X { + ~X(); // private destructor + // ... + }; + + void use() + { + X a; // error: cannot destroy + auto p = make_unique(); // error: cannot destroy + } + +##### Exception + +We can imagine one case where you could want a protected virtual destructor: When an object of a derived type (and only of such a type) should be allowed to destroy *another* object (not itself) through a pointer to base. We haven't seen such a case in practice, though. + + +##### Enforcement + +* A class with any virtual functions should have a destructor that is either public and virtual or else protected and non-virtual. +* If a class inherits publicly from a base class, the base class should have a destructor that is either public and virtual or else protected and non-virtual. + +### C.36: A destructor must not fail + +##### Reason + +In general we do not know how to write error-free code if a destructor should fail. +The standard library requires that all classes it deals with have destructors that do not exit by throwing. + +##### Example + + class X { + public: + ~X() noexcept; + // ... + }; + + X::~X() noexcept + { + // ... + if (cannot_release_a_resource) terminate(); + // ... + } + +##### Note + +Many have tried to devise a fool-proof scheme for dealing with failure in destructors. +None have succeeded to come up with a general scheme. +This can be a real practical problem: For example, what about a socket that won't close? +The writer of a destructor does not know why the destructor is called and cannot "refuse to act" by throwing an exception. +See [discussion](#Sd-never-fail). +To make the problem worse, many "close/release" operations are not retryable. +If at all possible, consider failure to close/cleanup a fundamental design error and terminate. + +##### Note + +Declare a destructor `noexcept`. That will ensure that it either completes normally or terminates the program. + +##### Note + +If a resource cannot be released and the program must not fail, try to signal the failure to the rest of the system somehow +(maybe even by modifying some global state and hope something will notice and be able to take care of the problem). +Be fully aware that this technique is special-purpose and error-prone. +Consider the "my connection will not close" example. +Probably there is a problem at the other end of the connection and only a piece of code responsible for both ends of the connection can properly handle the problem. +The destructor could send a message (somehow) to the responsible part of the system, consider that to have closed the connection, and return normally. + +##### Note + +If a destructor uses operations that could fail, it can catch exceptions and in some cases still complete successfully +(e.g., by using a different clean-up mechanism from the one that threw an exception). + +##### Enforcement + +(Simple) A destructor should be declared `noexcept` if it could throw. + +### C.37: Make destructors `noexcept` + +##### Reason + + [A destructor must not fail](#Rc-dtor-fail). If a destructor tries to exit with an exception, it's a bad design error and the program had better terminate. + +##### Note + +A destructor (either user-defined or compiler-generated) is implicitly declared `noexcept` (independently of what code is in its body) if all of the members of its class have `noexcept` destructors. By explicitly marking destructors `noexcept`, an author guards against the destructor becoming implicitly `noexcept(false)` through the addition or modification of a class member. + +##### Example + +Not all destructors are noexcept by default; one throwing member poisons the whole class hierarchy + + struct X { + Details x; // happens to have a throwing destructor + // ... + ~X() { } // implicitly noexcept(false); aka can throw + }; + +So, if in doubt, declare a destructor noexcept. + +##### Note + +Why not then declare all destructors noexcept? +Because that would in many cases -- especially simple cases -- be distracting clutter. + +##### Enforcement + +(Simple) A destructor should be declared `noexcept` if it could throw. + +## C.ctor: Constructors + +A constructor defines how an object is initialized (constructed). + +### C.40: Define a constructor if a class has an invariant + +##### Reason + +That's what constructors are for. + +##### Example + + class Date { // a Date represents a valid date + // in the January 1, 1900 to December 31, 2100 range + Date(int dd, int mm, int yy) + :d{dd}, m{mm}, y{yy} + { + if (!is_valid(d, m, y)) throw Bad_date{}; // enforce invariant + } + // ... + private: + int d, m, y; + }; + +It is often a good idea to express the invariant as an `Ensures` on the constructor. + +##### Note + +A constructor can be used for convenience even if a class does not have an invariant. For example: + + struct Rec { + string s; + int i {0}; + Rec(const string& ss) : s{ss} {} + Rec(int ii) :i{ii} {} + }; + + Rec r1 {7}; + Rec r2 {"Foo bar"}; + +##### Note + +The C++11 initializer list rule eliminates the need for many constructors. For example: + + struct Rec2{ + string s; + int i; + Rec2(const string& ss, int ii = 0) :s{ss}, i{ii} {} // redundant + }; + + Rec2 r1 {"Foo", 7}; + Rec2 r2 {"Bar"}; + +The `Rec2` constructor is redundant. +Also, the default for `int` would be better done as a [default member initializer](#Rc-in-class-initializer). + +**See also**: [construct valid object](#Rc-complete) and [constructor throws](#Rc-throw). + +##### Enforcement + +* Flag classes with user-defined copy operations but no constructor (a user-defined copy is a good indicator that the class has an invariant) + +### C.41: A constructor should create a fully initialized object + +##### Reason + +A constructor establishes the invariant for a class. A user of a class should be able to assume that a constructed object is usable. + +##### Example, bad + + class X1 { + FILE* f; // call init() before any other function + // ... + public: + X1() {} + void init(); // initialize f + void read(); // read from f + // ... + }; + + void f() + { + X1 file; + file.read(); // crash or bad read! + // ... + file.init(); // too late + // ... + } + +Compilers do not read comments. + +##### Exception + +If a valid object cannot conveniently be constructed by a constructor, [use a factory function](#Rc-factory). + +##### Enforcement + +* (Simple) Every constructor should initialize every data member (either explicitly, via a delegating ctor call or via default construction). +* (Unknown) If a constructor has an `Ensures` contract, try to see if it holds as a postcondition. + +##### Note + +If a constructor acquires a resource (to create a valid object), that resource should be [released by the destructor](#Rc-dtor-release). +The idiom of having constructors acquire resources and destructors release them is called [RAII](#Rr-raii) ("Resource Acquisition Is Initialization"). + +### C.42: If a constructor cannot construct a valid object, throw an exception + +##### Reason + +Leaving behind an invalid object is asking for trouble. + +##### Example + + class X2 { + FILE* f; + // ... + public: + X2(const string& name) + :f{fopen(name.c_str(), "r")} + { + if (!f) throw runtime_error{"could not open" + name}; + // ... + } + + void read(); // read from f + // ... + }; + + void f() + { + X2 file {"Zeno"}; // throws if file isn't open + file.read(); // fine + // ... + } + +##### Example, bad + + class X3 { // bad: the constructor leaves a non-valid object behind + FILE* f; // call is_valid() before any other function + bool valid; + // ... + public: + X3(const string& name) + :f{fopen(name.c_str(), "r")}, valid{false} + { + if (f) valid = true; + // ... + } + + bool is_valid() { return valid; } + void read(); // read from f + // ... + }; + + void f() + { + X3 file {"Heraclides"}; + file.read(); // crash or bad read! + // ... + if (file.is_valid()) { + file.read(); + // ... + } + else { + // ... handle error ... + } + // ... + } + +##### Note + +For a variable definition (e.g., on the stack or as a member of another object) there is no explicit function call from which an error code could be returned. +Leaving behind an invalid object and relying on users to consistently check an `is_valid()` function before use is tedious, error-prone, and inefficient. + +##### Exception + +There are domains, such as some hard-real-time systems (think airplane controls) where (without additional tool support) exception handling is not sufficiently predictable from a timing perspective. +There the `is_valid()` technique must be used. In such cases, check `is_valid()` consistently and immediately to simulate [RAII](#Rr-raii). + +##### Alternative + +If you feel tempted to use some "post-constructor initialization" or "two-stage initialization" idiom, try not to do that. +If you really have to, look at [factory functions](#Rc-factory). + +##### Note + +One reason people have used `init()` functions rather than doing the initialization work in a constructor has been to avoid code replication. +[Delegating constructors](#Rc-delegating) and [default member initialization](#Rc-in-class-initializer) do that better. +Another reason has been to delay initialization until an object is needed; the solution to that is often [not to declare a variable until it can be properly initialized](#Res-init) + +##### Enforcement + +??? + +### C.43: Ensure that a copyable class has a default constructor + +##### Reason + +That is, ensure that if a concrete class is copyable it also satisfies the rest of "semiregular." + +Many language and library facilities rely on default constructors to initialize their elements, e.g. `T a[10]` and `std::vector v(10)`. +A default constructor often simplifies the task of defining a suitable [moved-from state](#???) for a type that is also copyable. + +##### Example + + class Date { // BAD: no default constructor + public: + Date(int dd, int mm, int yyyy); + // ... + }; + + vector vd1(1000); // default Date needed here + vector vd2(1000, Date{7, Month::October, 1885}); // alternative + +The default constructor is only auto-generated if there is no user-declared constructor, hence it's impossible to initialize the vector `vd1` in the example above. +The absence of a default value can cause surprises for users and complicate its use, so if one can be reasonably defined, it should be. + +`Date` is chosen to encourage thought: +There is no "natural" default date (the big bang is too far back in time to be useful for most people), so this example is non-trivial. +`{0, 0, 0}` is not a valid date in most calendar systems, so choosing that would be introducing something like floating-point's `NaN`. +However, most realistic `Date` classes have a "first date" (e.g. January 1, 1970 is popular), so making that the default is usually trivial. + + class Date { + public: + Date(int dd, int mm, int yyyy); + Date() = default; // [See also](#Rc-default) + // ... + private: + int dd {1}; + int mm {1}; + int yyyy {1970}; + // ... + }; + + vector vd1(1000); + +##### Note + +A class with members that all have default constructors implicitly gets a default constructor: + + struct X { + string s; + vector v; + }; + + X x; // means X{ { }, { } }; that is the empty string and the empty vector + +Beware that built-in types are not properly default constructed: + + struct X { + string s; + int i; + }; + + void f() + { + X x; // x.s is initialized to the empty string; x.i is uninitialized + + cout << x.s << ' ' << x.i << '\n'; + ++x.i; + } + +Statically allocated objects of built-in types are by default initialized to `0`, but local built-in variables are not. +Beware that your compiler might default initialize local built-in variables, whereas an optimized build will not. +Thus, code like the example above might appear to work, but it relies on undefined behavior. +Assuming that you want initialization, an explicit default initialization can help: + + struct X { + string s; + int i {}; // default initialize (to 0) + }; + +##### Notes + +Classes that don't have a reasonable default construction are usually not copyable either, so they don't fall under this guideline. + +For example, a base class should not be copyable, and so does not necessarily need a default constructor: + + // Shape is an abstract base class, not a copyable type. + // It might or might not need a default constructor. + struct Shape { + virtual void draw() = 0; + virtual void rotate(int) = 0; + // =delete copy/move functions + // ... + }; + +A class that must acquire a caller-provided resource during construction often cannot have a default constructor, but it does not fall under this guideline because such a class is usually not copyable anyway: + + // std::lock_guard is not a copyable type. + // It does not have a default constructor. + lock_guard g {mx}; // guard the mutex mx + lock_guard g2; // error: guarding nothing + +A class that has a "special state" that must be handled separately from other states by member functions or users causes extra work +(and most likely more errors). Such a type can naturally use the special state as a default constructed value, whether or not it is copyable: + + // std::ofstream is not a copyable type. + // It does happen to have a default constructor + // that goes along with a special "not open" state. + ofstream out {"Foobar"}; + // ... + out << log(time, transaction); + +Similar special-state types that are copyable, such as copyable smart pointers that have the special state "==nullptr", should use the special state as their default constructed value. + +However, it is preferable to have a default constructor default to a meaningful state such as `std::string`s `""` and `std::vector`s `{}`. + +##### Enforcement + +* Flag classes that are copyable by `=` without a default constructor +* Flag classes that are comparable with `==` but not copyable + + +### C.44: Prefer default constructors to be simple and non-throwing + +##### Reason + +Being able to set a value to "the default" without operations that might fail simplifies error handling and reasoning about move operations. + +##### Example, problematic + + template + // elem points to space-elem element allocated using new + class Vector0 { + public: + Vector0() :Vector0{0} {} + Vector0(int n) :elem{new T[n]}, space{elem + n}, last{elem} {} + // ... + private: + own elem; + T* space; + T* last; + }; + +This is nice and general, but setting a `Vector0` to empty after an error involves an allocation, which might fail. +Also, having a default `Vector` represented as `{new T[0], 0, 0}` seems wasteful. +For example, `Vector0 v[100]` costs 100 allocations. + +##### Example + + template + // elem is nullptr or elem points to space-elem element allocated using new + class Vector1 { + public: + // sets the representation to {nullptr, nullptr, nullptr}; doesn't throw + Vector1() noexcept {} + Vector1(int n) :elem{new T[n]}, space{elem + n}, last{elem} {} + // ... + private: + own elem {}; + T* space {}; + T* last {}; + }; + +Using `{nullptr, nullptr, nullptr}` makes `Vector1{}` cheap, but a special case and implies run-time checks. +Setting a `Vector1` to empty after detecting an error is trivial. + +##### Enforcement + +* Flag throwing default constructors + +### C.45: Don't define a default constructor that only initializes data members; use default member initializers instead + +##### Reason + +Using default member initializers lets the compiler generate the function for you. The compiler-generated function can be more efficient. + +##### Example, bad + + class X1 { // BAD: doesn't use member initializers + string s; + int i; + public: + X1() :s{"default"}, i{1} { } + // ... + }; + +##### Example + + class X2 { + string s {"default"}; + int i {1}; + public: + // use compiler-generated default constructor + // ... + }; + +##### Enforcement + +(Simple) A default constructor should do more than just initialize data members with constants. + +### C.46: By default, declare single-argument constructors explicit + +##### Reason + +To avoid unintended conversions. + +##### Example, bad + + class String { + public: + String(int); // BAD + // ... + }; + + String s = 10; // surprise: string of size 10 + +##### Exception + +If you really want an implicit conversion from the constructor argument type to the class type, don't use `explicit`: + + class Complex { + public: + Complex(double d); // OK: we want a conversion from d to {d, 0} + // ... + }; + + Complex z = 10.7; // unsurprising conversion + +**See also**: [Discussion of implicit conversions](#Ro-conversion) + +##### Note + +Copy and move constructors should not be made `explicit` because they do not perform conversions. Explicit copy/move constructors make passing and returning by value difficult. + +##### Enforcement + +(Simple) Single-argument constructors should be declared `explicit`. Good single argument non-`explicit` constructors are rare in most code bases. Warn for all that are not on a "positive list". + +### C.47: Define and initialize data members in the order of member declaration + +##### Reason + +To minimize confusion and errors. That is the order in which the initialization happens (independent of the order of member initializers). + +##### Example, bad + + class Foo { + int m1; + int m2; + public: + Foo(int x) :m2{x}, m1{++x} { } // BAD: misleading initializer order + // ... + }; + + Foo x(1); // surprise: x.m1 == x.m2 == 2 + +##### Enforcement + +(Simple) A member initializer list should mention the members in the same order they are declared. + +**See also**: [Discussion](#Sd-order) + +### C.48: Prefer default member initializers to member initializers in constructors for constant initializers + +##### Reason + +Makes it explicit that the same value is expected to be used in all constructors. Avoids repetition. Avoids maintenance problems. It leads to the shortest and most efficient code. + +##### Example, bad + + class X { // BAD + int i; + string s; + int j; + public: + X() :i{666}, s{"qqq"} { } // j is uninitialized + X(int ii) :i{ii} {} // s is "" and j is uninitialized + // ... + }; + +How would a maintainer know whether `j` was deliberately uninitialized (probably a bad idea anyway) and whether it was intentional to give `s` the default value `""` in one case and `qqq` in another (almost certainly a bug)? The problem with `j` (forgetting to initialize a member) often happens when a new member is added to an existing class. + +##### Example + + class X2 { + int i {666}; + string s {"qqq"}; + int j {0}; + public: + X2() = default; // all members are initialized to their defaults + X2(int ii) :i{ii} {} // s and j initialized to their defaults + // ... + }; + +**Alternative**: We can get part of the benefits from default arguments to constructors, and that is not uncommon in older code. However, that is less explicit, causes more arguments to be passed, and is repetitive when there is more than one constructor: + + class X3 { // BAD: inexplicit, argument passing overhead + int i; + string s; + int j; + public: + X3(int ii = 666, const string& ss = "qqq", int jj = 0) + :i{ii}, s{ss}, j{jj} { } // all members are initialized to their defaults + // ... + }; + +##### Enforcement + +* (Simple) Every constructor should initialize every data member (either explicitly, via a delegating ctor call or via default construction). +* (Simple) Default arguments to constructors suggest a default member initializer might be more appropriate. + +### C.49: Prefer initialization to assignment in constructors + +##### Reason + +An initialization explicitly states that initialization, rather than assignment, is done and can be more elegant and efficient. Prevents "use before set" errors. + +##### Example, good + + class A { // Good + string s1; + public: + A(czstring p) : s1{p} { } // GOOD: directly construct (and the C-string is explicitly named) + // ... + }; + +##### Example, bad + + class B { // BAD + string s1; + public: + B(const char* p) { s1 = p; } // BAD: default constructor followed by assignment + // ... + }; + + class C { // UGLY, aka very bad + int* p; + public: + C() { cout << *p; p = new int{10}; } // accidental use before initialized + // ... + }; + +##### Example, better still + +Instead of those `const char*`s we could use C++17 `std::string_view` or `gsl::span` +as [a more general way to present arguments to a function](#Rstr-view): + + class D { // Good + string s1; + public: + D(string_view v) : s1{v} { } // GOOD: directly construct + // ... + }; + +### C.50: Use a factory function if you need "virtual behavior" during initialization + +##### Reason + +If the state of a base class object must depend on the state of a derived part of the object, we need to use a virtual function (or equivalent) while minimizing the window of opportunity to misuse an imperfectly constructed object. + +##### Note + +The return type of the factory should normally be `unique_ptr` by default; if some uses are shared, the caller can `move` the `unique_ptr` into a `shared_ptr`. However, if the factory author knows that all uses of the returned object will be shared uses, return `shared_ptr` and use `make_shared` in the body to save an allocation. + +##### Example, bad + + class B { + public: + B() + { + /* ... */ + f(); // BAD: C.82: Don't call virtual functions in constructors and destructors + /* ... */ + } + + virtual void f() = 0; + }; + +##### Example + + class B { + protected: + class Token {}; + + public: + explicit B(Token) { /* ... */ } // create an imperfectly initialized object + virtual void f() = 0; + + template + static shared_ptr create() // interface for creating shared objects + { + auto p = make_shared(typename T::Token{}); + p->post_initialize(); + return p; + } + + protected: + virtual void post_initialize() // called right after construction + { /* ... */ f(); /* ... */ } // GOOD: virtual dispatch is safe + }; + + class D : public B { // some derived class + protected: + class Token {}; + + public: + explicit D(Token) : B{ B::Token{} } {} + void f() override { /* ... */ }; + + protected: + template + friend shared_ptr B::create(); + }; + + shared_ptr p = D::create(); // creating a D object + +`make_shared` requires that the constructor is public. By requiring a protected `Token` the constructor cannot be publicly called anymore, so we avoid an incompletely constructed object escaping into the wild. +By providing the factory function `create()`, we make construction (on the free store) convenient. + +##### Note + +Conventional factory functions allocate on the free store, rather than on the stack or in an enclosing object. + +**See also**: [Discussion](#Sd-factory) + +### C.51: Use delegating constructors to represent common actions for all constructors of a class + +##### Reason + +To avoid repetition and accidental differences. + +##### Example, bad + + class Date { // BAD: repetitive + int d; + Month m; + int y; + public: + Date(int dd, Month mm, year yy) + :d{dd}, m{mm}, y{yy} + { if (!valid(d, m, y)) throw Bad_date{}; } + + Date(int dd, Month mm) + :d{dd}, m{mm} y{current_year()} + { if (!valid(d, m, y)) throw Bad_date{}; } + // ... + }; + +The common action gets tedious to write and might accidentally not be common. + +##### Example + + class Date2 { + int d; + Month m; + int y; + public: + Date2(int dd, Month mm, year yy) + :d{dd}, m{mm}, y{yy} + { if (!valid(d, m, y)) throw Bad_date{}; } + + Date2(int dd, Month mm) + :Date2{dd, mm, current_year()} {} + // ... + }; + +**See also**: If the "repeated action" is a simple initialization, consider [a default member initializer](#Rc-in-class-initializer). + +##### Enforcement + +(Moderate) Look for similar constructor bodies. + +### C.52: Use inheriting constructors to import constructors into a derived class that does not need further explicit initialization + +##### Reason + +If you need those constructors for a derived class, re-implementing them is tedious and error-prone. + +##### Example + +`std::vector` has a lot of tricky constructors, so if I want my own `vector`, I don't want to reimplement them: + + class Rec { + // ... data and lots of nice constructors ... + }; + + class Oper : public Rec { + using Rec::Rec; + // ... no data members ... + // ... lots of nice utility functions ... + }; + +##### Example, bad + + struct Rec2 : public Rec { + int x; + using Rec::Rec; + }; + + Rec2 r {"foo", 7}; + int val = r.x; // uninitialized + +##### Enforcement + +Make sure that every member of the derived class is initialized. + +## C.copy: Copy and move + +Concrete types should generally be copyable, but interfaces in a class hierarchy should not. +Resource handles might or might not be copyable. +Types can be defined to move for logical as well as performance reasons. + +### C.60: Make copy assignment non-`virtual`, take the parameter by `const&`, and return by non-`const&` + +##### Reason + +It is simple and efficient. If you want to optimize for rvalues, provide an overload that takes a `&&` (see [F.18](#Rf-consume)). + +##### Example + + class Foo { + public: + Foo& operator=(const Foo& x) + { + // GOOD: no need to check for self-assignment (other than performance) + auto tmp = x; + swap(tmp); // see C.83 + return *this; + } + // ... + }; + + Foo a; + Foo b; + Foo f(); + + a = b; // assign lvalue: copy + a = f(); // assign rvalue: potentially move + +##### Note + +The `swap` implementation technique offers the [strong guarantee](#Abrahams01). + +##### Example + +But what if you can get significantly better performance by not making a temporary copy? Consider a simple `Vector` intended for a domain where assignment of large, equal-sized `Vector`s is common. In this case, the copy of elements implied by the `swap` implementation technique could cause an order of magnitude increase in cost: + + template + class Vector { + public: + Vector& operator=(const Vector&); + // ... + private: + T* elem; + int sz; + }; + + Vector& Vector::operator=(const Vector& a) + { + if (a.sz > sz) { + // ... use the swap technique, it can't be bettered ... + return *this; + } + // ... copy sz elements from *a.elem to elem ... + if (a.sz < sz) { + // ... destroy the surplus elements in *this and adjust size ... + } + return *this; + } + +By writing directly to the target elements, we will get only [the basic guarantee](#Abrahams01) rather than the strong guarantee offered by the `swap` technique. Beware of [self-assignment](#Rc-copy-self). + +**Alternatives**: If you think you need a `virtual` assignment operator, and understand why that's deeply problematic, don't call it `operator=`. Make it a named function like `virtual void assign(const Foo&)`. +See [copy constructor vs. `clone()`](#Rc-copy-virtual). + +##### Enforcement + +* (Simple) An assignment operator should not be virtual. Here be dragons! +* (Simple) An assignment operator should return `T&` to enable chaining, not alternatives like `const T&` which interfere with composability and putting objects in containers. +* (Moderate) An assignment operator should (implicitly or explicitly) invoke all base and member assignment operators. + Look at the destructor to determine if the type has pointer semantics or value semantics. + +### C.61: A copy operation should copy + +##### Reason + +That is the generally assumed semantics. After `x = y`, we should have `x == y`. +After a copy `x` and `y` can be independent objects (value semantics, the way non-pointer built-in types and the standard-library types work) or refer to a shared object (pointer semantics, the way pointers work). + +##### Example + + class X { // OK: value semantics + public: + X(); + X(const X&); // copy X + void modify(); // change the value of X + // ... + ~X() { delete[] p; } + private: + T* p; + int sz; + }; + + bool operator==(const X& a, const X& b) + { + return a.sz == b.sz && equal(a.p, a.p + a.sz, b.p, b.p + b.sz); + } + + X::X(const X& a) + :p{new T[a.sz]}, sz{a.sz} + { + copy(a.p, a.p + sz, p); + } + + X x; + X y = x; + if (x != y) throw Bad{}; + x.modify(); + if (x == y) throw Bad{}; // assume value semantics + +##### Example + + class X2 { // OK: pointer semantics + public: + X2(); + X2(const X2&) = default; // shallow copy + ~X2() = default; + void modify(); // change the pointed-to value + // ... + private: + T* p; + int sz; + }; + + bool operator==(const X2& a, const X2& b) + { + return a.sz == b.sz && a.p == b.p; + } + + X2 x; + X2 y = x; + if (x != y) throw Bad{}; + x.modify(); + if (x != y) throw Bad{}; // assume pointer semantics + +##### Note + +Prefer value semantics unless you are building a "smart pointer". Value semantics is the simplest to reason about and what the standard-library facilities expect. + +##### Enforcement + +(Not enforceable) + +### C.62: Make copy assignment safe for self-assignment + +##### Reason + +If `x = x` changes the value of `x`, people will be surprised and bad errors will occur (often including leaks). + +##### Example + +The standard-library containers handle self-assignment elegantly and efficiently: + + std::vector v = {3, 1, 4, 1, 5, 9}; + v = v; + // the value of v is still {3, 1, 4, 1, 5, 9} + +##### Note + +The default assignment generated from members that handle self-assignment correctly handles self-assignment. + + struct Bar { + vector> v; + map m; + string s; + }; + + Bar b; + // ... + b = b; // correct and efficient + +##### Note + +You can handle self-assignment by explicitly testing for self-assignment, but often it is faster and more elegant to cope without such a test (e.g., [using `swap`](#Rc-swap)). + + class Foo { + string s; + int i; + public: + Foo& operator=(const Foo& a); + // ... + }; + + Foo& Foo::operator=(const Foo& a) // OK, but there is a cost + { + if (this == &a) return *this; + s = a.s; + i = a.i; + return *this; + } + +This is obviously safe and apparently efficient. +However, what if we do one self-assignment per million assignments? +That's about a million redundant tests (but since the answer is essentially always the same, the computer's branch predictor will guess right essentially every time). +Consider: + + Foo& Foo::operator=(const Foo& a) // simpler, and probably much better + { + s = a.s; + i = a.i; + return *this; + } + +`std::string` is safe for self-assignment and so are `int`. All the cost is carried by the (rare) case of self-assignment. + +##### Enforcement + +(Simple) Assignment operators should not contain the pattern `if (this == &a) return *this;` ??? + +### C.63: Make move assignment non-`virtual`, take the parameter by `&&`, and return by non-`const&` + +##### Reason + +It is simple and efficient. + +**See**: [The rule for copy-assignment](#Rc-copy-assignment). + +##### Enforcement + +Equivalent to what is done for [copy-assignment](#Rc-copy-assignment). + +* (Simple) An assignment operator should not be virtual. Here be dragons! +* (Simple) An assignment operator should return `T&` to enable chaining, not alternatives like `const T&` which interfere with composability and putting objects in containers. +* (Moderate) A move assignment operator should (implicitly or explicitly) invoke all base and member move assignment operators. + +### C.64: A move operation should move and leave its source in a valid state + +##### Reason + +That is the generally assumed semantics. +After `y = std::move(x)` the value of `y` should be the value `x` had and `x` should be in a valid state. + +##### Example + + class X { // OK: value semantics + public: + X(); + X(X&& a) noexcept; // move X + X& operator=(X&& a) noexcept; // move-assign X + void modify(); // change the value of X + // ... + ~X() { delete[] p; } + private: + T* p; + int sz; + }; + + X::X(X&& a) noexcept + :p{a.p}, sz{a.sz} // steal representation + { + a.p = nullptr; // set to "empty" + a.sz = 0; + } + + void use() + { + X x{}; + // ... + X y = std::move(x); + x = X{}; // OK + } // OK: x can be destroyed + +##### Note + +Ideally, that moved-from should be the default value of the type. +Ensure that unless there is an exceptionally good reason not to. +However, not all types have a default value and for some types establishing the default value can be expensive. +The standard requires only that the moved-from object can be destroyed. +Often, we can easily and cheaply do better: The standard library assumes that it is possible to assign to a moved-from object. +Always leave the moved-from object in some (necessarily specified) valid state. + +##### Note + +Unless there is an exceptionally strong reason not to, make `x = std::move(y); y = z;` work with the conventional semantics. + +##### Enforcement + +(Not enforceable) Look for assignments to members in the move operation. If there is a default constructor, compare those assignments to the initializations in the default constructor. + +### C.65: Make move assignment safe for self-assignment + +##### Reason + +If `x = x` changes the value of `x`, people will be surprised and bad errors can occur. However, people don't usually directly write a self-assignment that turn into a move, but it can occur. However, `std::swap` is implemented using move operations so if you accidentally do `swap(a, b)` where `a` and `b` refer to the same object, failing to handle self-move could be a serious and subtle error. + +##### Example + + class Foo { + string s; + int i; + public: + Foo& operator=(Foo&& a) noexcept; + // ... + }; + + Foo& Foo::operator=(Foo&& a) noexcept // OK, but there is a cost + { + if (this == &a) return *this; // this line is redundant + s = std::move(a.s); + i = a.i; + return *this; + } + +The one-in-a-million argument against `if (this == &a) return *this;` tests from the discussion of [self-assignment](#Rc-copy-self) is even more relevant for self-move. + +##### Note + +There is no known general way of avoiding an `if (this == &a) return *this;` test for a move assignment and still get a correct answer (i.e., after `x = x` the value of `x` is unchanged). + +##### Note + +The ISO standard guarantees only a "valid but unspecified" state for the standard-library containers. Apparently this has not been a problem in about 10 years of experimental and production use. Please contact the editors if you find a counter example. The rule here is more caution and insists on complete safety. + +##### Example + +Here is a way to move a pointer without a test (imagine it as code in the implementation a move assignment): + + // move from other.ptr to this->ptr + T* temp = other.ptr; + other.ptr = nullptr; + delete ptr; // in self-move, this->ptr is also null; delete is a no-op + ptr = temp; // in self-move, the original ptr is restored + +##### Enforcement + +* (Moderate) In the case of self-assignment, a move assignment operator should not leave the object holding pointer members that have been `delete`d or set to `nullptr`. +* (Not enforceable) Look at the use of standard-library container types (incl. `string`) and consider them safe for ordinary (not life-critical) uses. + +### C.66: Make move operations `noexcept` + +##### Reason + +A throwing move violates most people's reasonable assumptions. +A non-throwing move will be used more efficiently by standard-library and language facilities. + +##### Example + + template + class Vector { + public: + Vector(Vector&& a) noexcept :elem{a.elem}, sz{a.sz} { a.elem = nullptr; a.sz = 0; } + Vector& operator=(Vector&& a) noexcept { + if (&a != this) { + delete elem; + elem = a.elem; a.elem = nullptr; + sz = a.sz; a.sz = 0; + } + return *this; + } + // ... + private: + T* elem; + int sz; + }; + +These operations do not throw. + +##### Example, bad + + template + class Vector2 { + public: + Vector2(Vector2&& a) noexcept { *this = a; } // just use the copy + Vector2& operator=(Vector2&& a) noexcept { *this = a; } // just use the copy + // ... + private: + T* elem; + int sz; + }; + +This `Vector2` is not just inefficient, but since a vector copy requires allocation, it can throw. + +##### Enforcement + +(Simple) A move operation should be marked `noexcept`. + +### C.67: A polymorphic class should suppress public copy/move + +##### Reason + +A *polymorphic class* is a class that defines or inherits at least one virtual function. It is likely that it will be used as a base class for other derived classes with polymorphic behavior. If it is accidentally passed by value, with the implicitly generated copy constructor and assignment, we risk slicing: only the base portion of a derived object will be copied, and the polymorphic behavior will be corrupted. + +If the class has no data, `=delete` the copy/move functions. Otherwise, make them protected. + +##### Example, bad + + class B { // BAD: polymorphic base class doesn't suppress copying + public: + virtual char m() { return 'B'; } + // ... nothing about copy operations, so uses default ... + }; + + class D : public B { + public: + char m() override { return 'D'; } + // ... + }; + + void f(B& b) + { + auto b2 = b; // oops, slices the object; b2.m() will return 'B' + } + + D d; + f(d); + +##### Example + + class B { // GOOD: polymorphic class suppresses copying + public: + B() = default; + B(const B&) = delete; + B& operator=(const B&) = delete; + virtual char m() { return 'B'; } + // ... + }; + + class D : public B { + public: + char m() override { return 'D'; } + // ... + }; + + void f(B& b) + { + auto b2 = b; // ok, compiler will detect inadvertent copying, and protest + } + + D d; + f(d); + +##### Note + +If you need to create deep copies of polymorphic objects, use `clone()` functions: see [C.130](#Rh-copy). + +##### Exception + +Classes that represent exception objects need both to be polymorphic and copy-constructible. + +##### Enforcement + +* Flag a polymorphic class with a public copy operation. +* Flag an assignment of polymorphic class objects. + +## C.other: Other default operation rules + +In addition to the operations for which the language offers default implementations, +there are a few operations that are so foundational that specific rules for their definition are needed: +comparisons, `swap`, and `hash`. + +### C.80: Use `=default` if you have to be explicit about using the default semantics + +##### Reason + +The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler. + +##### Example + + class Tracer { + string message; + public: + Tracer(const string& m) : message{m} { cerr << "entering " << message << '\n'; } + ~Tracer() { cerr << "exiting " << message << '\n'; } + + Tracer(const Tracer&) = default; + Tracer& operator=(const Tracer&) = default; + Tracer(Tracer&&) noexcept = default; + Tracer& operator=(Tracer&&) noexcept = default; + }; + +Because we defined the destructor, we must define the copy and move operations. The `= default` is the best and simplest way of doing that. + +##### Example, bad + + class Tracer2 { + string message; + public: + Tracer2(const string& m) : message{m} { cerr << "entering " << message << '\n'; } + ~Tracer2() { cerr << "exiting " << message << '\n'; } + + Tracer2(const Tracer2& a) : message{a.message} {} + Tracer2& operator=(const Tracer2& a) { message = a.message; return *this; } + Tracer2(Tracer2&& a) noexcept :message{a.message} {} + Tracer2& operator=(Tracer2&& a) noexcept { message = a.message; return *this; } + }; + +Writing out the bodies of the copy and move operations is verbose, tedious, and error-prone. A compiler does it better. + +##### Enforcement + +(Moderate) The body of a user-defined operation should not have the same semantics as the compiler-generated version, because that would be redundant. + +### C.81: Use `=delete` when you want to disable default behavior (without wanting an alternative) + +##### Reason + +In a few cases, a default operation is not desirable. + +##### Example + + class Immortal { + public: + ~Immortal() = delete; // do not allow destruction + // ... + }; + + void use() + { + Immortal ugh; // error: ugh cannot be destroyed + Immortal* p = new Immortal{}; + delete p; // error: cannot destroy *p + } + +##### Example + +A `unique_ptr` can be moved, but not copied. To achieve that its copy operations are deleted. To avoid copying it is necessary to `=delete` its copy operations from lvalues: + + template> class unique_ptr { + public: + // ... + constexpr unique_ptr() noexcept; + explicit unique_ptr(pointer p) noexcept; + // ... + unique_ptr(unique_ptr&& u) noexcept; // move constructor + // ... + unique_ptr(const unique_ptr&) = delete; // disable copy from lvalue + // ... + }; + + unique_ptr make(); // make "something" and return it by moving + + void f() + { + unique_ptr pi {}; + auto pi2 {pi}; // error: no move constructor from lvalue + auto pi3 {make()}; // OK, move: the result of make() is an rvalue + } + +Note that deleted functions should be public. + +##### Enforcement + +The elimination of a default operation is (should be) based on the desired semantics of the class. Consider such classes suspect, but maintain a "positive list" of classes where a human has asserted that the semantics is correct. + +### C.82: Don't call virtual functions in constructors and destructors + +##### Reason + +The function called will be that of the object constructed so far, rather than a possibly overriding function in a derived class. +This can be most confusing. +Worse, a direct or indirect call to an unimplemented pure virtual function from a constructor or destructor results in undefined behavior. + +##### Example, bad + + class Base { + public: + virtual void f() = 0; // not implemented + virtual void g(); // implemented with Base version + virtual void h(); // implemented with Base version + virtual ~Base(); // implemented with Base version + }; + + class Derived : public Base { + public: + void g() override; // provide Derived implementation + void h() final; // provide Derived implementation + + Derived() + { + // BAD: attempt to call an unimplemented virtual function + f(); + + // BAD: will call Derived::g, not dispatch further virtually + g(); + + // GOOD: explicitly state intent to call only the visible version + Derived::g(); + + // ok, no qualification needed, h is final + h(); + } + }; + +Note that calling a specific explicitly qualified function is not a virtual call even if the function is `virtual`. + +**See also** [factory functions](#Rc-factory) for how to achieve the effect of a call to a derived class function without risking undefined behavior. + +##### Note + +There is nothing inherently wrong with calling virtual functions from constructors and destructors. +The semantics of such calls is type safe. +However, experience shows that such calls are rarely needed, easily confuse maintainers, and become a source of errors when used by novices. + +##### Enforcement + +* Flag calls of virtual functions from constructors and destructors. + +### C.83: For value-like types, consider providing a `noexcept` swap function + +##### Reason + +A `swap` can be handy for implementing a number of idioms, from smoothly moving objects around to implementing assignment easily to providing a guaranteed commit function that enables strongly error-safe calling code. Consider using swap to implement copy assignment in terms of copy construction. See also [destructors, deallocation, and swap must never fail](#Re-never-fail). + +##### Example, good + + class Foo { + public: + void swap(Foo& rhs) noexcept + { + m1.swap(rhs.m1); + std::swap(m2, rhs.m2); + } + private: + Bar m1; + int m2; + }; + +Providing a non-member `swap` function in the same namespace as your type for callers' convenience. + + void swap(Foo& a, Foo& b) + { + a.swap(b); + } + +##### Enforcement + +* Non-trivially copyable types should provide a member swap or a free swap overload. +* (Simple) When a class has a `swap` member function, it should be declared `noexcept`. + +### C.84: A `swap` function must not fail + +##### Reason + + `swap` is widely used in ways that are assumed never to fail and programs cannot easily be written to work correctly in the presence of a failing `swap`. The standard-library containers and algorithms will not work correctly if a swap of an element type fails. + +##### Example, bad + + void swap(My_vector& x, My_vector& y) + { + auto tmp = x; // copy elements + x = y; + y = tmp; + } + +This is not just slow, but if a memory allocation occurs for the elements in `tmp`, this `swap` could throw and would make STL algorithms fail if used with them. + +##### Enforcement + +(Simple) When a class has a `swap` member function, it should be declared `noexcept`. + +### C.85: Make `swap` `noexcept` + +##### Reason + + [A `swap` must not fail](#Rc-swap-fail). +If a `swap` tries to exit with an exception, it's a bad design error and the program had better terminate. + +##### Enforcement + +(Simple) When a class has a `swap` member function, it should be declared `noexcept`. + +### C.86: Make `==` symmetric with respect to operand types and `noexcept` + +##### Reason + +Asymmetric treatment of operands is surprising and a source of errors where conversions are possible. +`==` is a fundamental operation and programmers should be able to use it without fear of failure. + +##### Example + + struct X { + string name; + int number; + }; + + bool operator==(const X& a, const X& b) noexcept { + return a.name == b.name && a.number == b.number; + } + +##### Example, bad + + class B { + string name; + int number; + bool operator==(const B& a) const { + return name == a.name && number == a.number; + } + // ... + }; + +`B`'s comparison accepts conversions for its second operand, but not its first. + +##### Note + +If a class has a failure state, like `double`'s `NaN`, there is a temptation to make a comparison against the failure state throw. +The alternative is to make two failure states compare equal and any valid state compare false against the failure state. + +##### Note + +This rule applies to all the usual comparison operators: `!=`, `<`, `<=`, `>`, and `>=`. + +##### Enforcement + +* Flag an `operator==()` for which the argument types differ; same for other comparison operators: `!=`, `<`, `<=`, `>`, and `>=`. +* Flag member `operator==()`s; same for other comparison operators: `!=`, `<`, `<=`, `>`, and `>=`. + +### C.87: Beware of `==` on base classes + +##### Reason + +It is really hard to write a foolproof and useful `==` for a hierarchy. + +##### Example, bad + + class B { + string name; + int number; + public: + virtual bool operator==(const B& a) const + { + return name == a.name && number == a.number; + } + // ... + }; + +`B`'s comparison accepts conversions for its second operand, but not its first. + + class D : public B { + char character; + public: + virtual bool operator==(const D& a) const + { + return B::operator==(a) && character == a.character; + } + // ... + }; + + B b = ... + D d = ... + b == d; // compares name and number, ignores d's character + d == b; // compares name and number, ignores d's character + D d2; + d == d2; // compares name, number, and character + B& b2 = d2; + b2 == d; // compares name and number, ignores d2's and d's character + +Of course there are ways of making `==` work in a hierarchy, but the naive approaches do not scale + +##### Note + +This rule applies to all the usual comparison operators: `!=`, `<`, `<=`, `>`, `>=`, and `<=>`. + +##### Enforcement + +* Flag a virtual `operator==()`; same for other comparison operators: `!=`, `<`, `<=`, `>`, `>=`, and `<=>`. + +### C.89: Make a `hash` `noexcept` + +##### Reason + +Users of hashed containers use hash indirectly and don't expect simple access to throw. +It's a standard-library requirement. + +##### Example, bad + + template<> + struct hash { // thoroughly bad hash specialization + using result_type = size_t; + using argument_type = My_type; + + size_t operator()(const My_type & x) const + { + size_t xs = x.s.size(); + if (xs < 4) throw Bad_My_type{}; // "Nobody expects the Spanish inquisition!" + return hash()(x.s.size()) ^ trim(x.s); + } + }; + + int main() + { + unordered_map m; + My_type mt{ "asdfg" }; + m[mt] = 7; + cout << m[My_type{ "asdfg" }] << '\n'; + } + +If you have to define a `hash` specialization, try simply to let it combine standard-library `hash` specializations with `^` (xor). +That tends to work better than "cleverness" for non-specialists. + +##### Enforcement + +* Flag throwing `hash`es. + +### C.90: Rely on constructors and assignment operators, not `memset` and `memcpy` + +##### Reason + +The standard C++ mechanism to construct an instance of a type is to call its constructor. As specified in guideline [C.41](#Rc-complete): a constructor should create a fully initialized object. No additional initialization, such as by `memcpy`, should be required. +A type will provide a copy constructor and/or copy assignment operator to appropriately make a copy of the class, preserving the type's invariants. Using memcpy to copy a non-trivially copyable type has undefined behavior. Frequently this results in slicing, or data corruption. + +##### Example, good + + struct base { + virtual void update() = 0; + std::shared_ptr sp; + }; + + struct derived : public base { + void update() override {} + }; + +##### Example, bad + + void init(derived& a) + { + memset(&a, 0, sizeof(derived)); + } + +This is type-unsafe and overwrites the vtable. + +##### Example, bad + + void copy(derived& a, derived& b) + { + memcpy(&a, &b, sizeof(derived)); + } + +This is also type-unsafe and overwrites the vtable. + +##### Enforcement + +* Flag passing a non-trivially-copyable type to `memset` or `memcpy`. + +## C.con: Containers and other resource handles + +A container is an object holding a sequence of objects of some type; `std::vector` is the archetypical container. +A resource handle is a class that owns a resource; `std::vector` is the typical resource handle; its resource is its sequence of elements. + +Summary of container rules: + +* [C.100: Follow the STL when defining a container](#Rcon-stl) +* [C.101: Give a container value semantics](#Rcon-val) +* [C.102: Give a container move operations](#Rcon-move) +* [C.103: Give a container an initializer list constructor](#Rcon-init) +* [C.104: Give a container a default constructor that sets it to empty](#Rcon-empty) +* ??? +* [C.109: If a resource handle has pointer semantics, provide `*` and `->`](#Rcon-ptr) + +**See also**: [Resources](#S-resource) + + +### C.100: Follow the STL when defining a container + +##### Reason + +The STL containers are familiar to most C++ programmers and a fundamentally sound design. + +##### Note + +There are of course other fundamentally sound design styles and sometimes reasons to depart from +the style of the standard library, but in the absence of a solid reason to differ, it is simpler +and easier for both implementers and users to follow the standard. + +In particular, `std::vector` and `std::map` provide useful relatively simple models. + +##### Example + + // simplified (e.g., no allocators): + + template + class Sorted_vector { + using value_type = T; + // ... iterator types ... + + Sorted_vector() = default; + Sorted_vector(initializer_list); // initializer-list constructor: sort and store + Sorted_vector(const Sorted_vector&) = default; + Sorted_vector(Sorted_vector&&) noexcept = default; + Sorted_vector& operator=(const Sorted_vector&) = default; // copy assignment + Sorted_vector& operator=(Sorted_vector&&) noexcept = default; // move assignment + ~Sorted_vector() = default; + + Sorted_vector(const std::vector& v); // store and sort + Sorted_vector(std::vector&& v); // sort and "steal representation" + + const T& operator[](int i) const { return rep[i]; } + // no non-const direct access to preserve order + + void push_back(const T&); // insert in the right place (not necessarily at back) + void push_back(T&&); // insert in the right place (not necessarily at back) + + // ... cbegin(), cend() ... + private: + std::vector rep; // use a std::vector to hold elements + }; + + template bool operator==(const Sorted_vector&, const Sorted_vector&); + template bool operator!=(const Sorted_vector&, const Sorted_vector&); + // ... + +Here, the STL style is followed, but incompletely. +That's not uncommon. +Provide only as much functionality as makes sense for a specific container. +The key is to define the conventional constructors, assignments, destructors, and iterators +(as meaningful for the specific container) with their conventional semantics. +From that base, the container can be expanded as needed. +Here, special constructors from `std::vector` were added. + +##### Enforcement + +??? + +### C.101: Give a container value semantics + +##### Reason + +Regular objects are simpler to think and reason about than irregular ones. +Familiarity. + +##### Note + +If meaningful, make a container `Regular` (the concept). +In particular, ensure that an object compares equal to its copy. + +##### Example + + void f(const Sorted_vector& v) + { + Sorted_vector v2 {v}; + if (v != v2) + cout << "Behavior against reason and logic.\n"; + // ... + } + +##### Enforcement + +??? + +### C.102: Give a container move operations + +##### Reason + +Containers tend to get large; without a move constructor and a copy constructor an object can be +expensive to move around, thus tempting people to pass pointers to it around and getting into +resource management problems. + +##### Example + + Sorted_vector read_sorted(istream& is) + { + vector v; + cin >> v; // assume we have a read operation for vectors + Sorted_vector sv = v; // sorts + return sv; + } + +A user can reasonably assume that returning a standard-like container is cheap. + +##### Enforcement + +??? + +### C.103: Give a container an initializer list constructor + +##### Reason + +People expect to be able to initialize a container with a set of values. +Familiarity. + +##### Example + + Sorted_vector sv {1, 3, -1, 7, 0, 0}; // Sorted_vector sorts elements as needed + +##### Enforcement + +??? + +### C.104: Give a container a default constructor that sets it to empty + +##### Reason + +To make it `Regular`. + +##### Example + + vector> vs(100); // 100 Sorted_sequences each with the value "" + +##### Enforcement + +??? + +### C.109: If a resource handle has pointer semantics, provide `*` and `->` + +##### Reason + +That's what is expected from pointers. +Familiarity. + +##### Example + + ??? + +##### Enforcement + +??? + +## C.lambdas: Function objects and lambdas + +A function object is an object supplying an overloaded `()` so that you can call it. +A lambda expression (colloquially often shortened to "a lambda") is a notation for generating a function object. +Function objects should be cheap to copy (and therefore [passed by value](#Rf-in)). + +Summary: + +* [F.10: If an operation can be reused, give it a name](#Rf-name) +* [F.11: Use an unnamed lambda if you need a simple function object in one place only](#Rf-lambda) +* [F.50: Use a lambda when a function won't do (to capture local variables, or to write a local function)](#Rf-capture-vs-overload) +* [F.52: Prefer capturing by reference in lambdas that will be used locally, including passed to algorithms](#Rf-reference-capture) +* [F.53: Avoid capturing by reference in lambdas that will be used non-locally, including returned, stored on the heap, or passed to another thread](#Rf-value-capture) +* [ES.28: Use lambdas for complex initialization, especially of `const` variables](#Res-lambda-init) + +## C.hier: Class hierarchies (OOP) + +A class hierarchy is constructed to represent a set of hierarchically organized concepts (only). +Typically base classes act as interfaces. +There are two major uses for hierarchies, often named implementation inheritance and interface inheritance. + +Class hierarchy rule summary: + +* [C.120: Use class hierarchies to represent concepts with inherent hierarchical structure (only)](#Rh-domain) +* [C.121: If a base class is used as an interface, make it a pure abstract class](#Rh-abstract) +* [C.122: Use abstract classes as interfaces when complete separation of interface and implementation is needed](#Rh-separation) + +Designing rules for classes in a hierarchy summary: + +* [C.126: An abstract class typically doesn't need a user-written constructor](#Rh-abstract-ctor) +* [C.127: A class with a virtual function should have a virtual or protected destructor](#Rh-dtor) +* [C.128: Virtual functions should specify exactly one of `virtual`, `override`, or `final`](#Rh-override) +* [C.129: When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance](#Rh-kind) +* [C.130: For making deep copies of polymorphic classes prefer a virtual `clone` function instead of public copy construction/assignment](#Rh-copy) +* [C.131: Avoid trivial getters and setters](#Rh-get) +* [C.132: Don't make a function `virtual` without reason](#Rh-virtual) +* [C.133: Avoid `protected` data](#Rh-protected) +* [C.134: Ensure all non-`const` data members have the same access level](#Rh-public) +* [C.135: Use multiple inheritance to represent multiple distinct interfaces](#Rh-mi-interface) +* [C.136: Use multiple inheritance to represent the union of implementation attributes](#Rh-mi-implementation) +* [C.137: Use `virtual` bases to avoid overly general base classes](#Rh-vbase) +* [C.138: Create an overload set for a derived class and its bases with `using`](#Rh-using) +* [C.139: Use `final` on classes sparingly](#Rh-final) +* [C.140: Do not provide different default arguments for a virtual function and an overrider](#Rh-virtual-default-arg) + +Accessing objects in a hierarchy rule summary: + +* [C.145: Access polymorphic objects through pointers and references](#Rh-poly) +* [C.146: Use `dynamic_cast` where class hierarchy navigation is unavoidable](#Rh-dynamic_cast) +* [C.147: Use `dynamic_cast` to a reference type when failure to find the required class is considered an error](#Rh-ref-cast) +* [C.148: Use `dynamic_cast` to a pointer type when failure to find the required class is considered a valid alternative](#Rh-ptr-cast) +* [C.149: Use `unique_ptr` or `shared_ptr` to avoid forgetting to `delete` objects created using `new`](#Rh-smart) +* [C.150: Use `make_unique()` to construct objects owned by `unique_ptr`s](#Rh-make_unique) +* [C.151: Use `make_shared()` to construct objects owned by `shared_ptr`s](#Rh-make_shared) +* [C.152: Never assign a pointer to an array of derived class objects to a pointer to its base](#Rh-array) +* [C.153: Prefer virtual function to casting](#Rh-use-virtual) + +### C.120: Use class hierarchies to represent concepts with inherent hierarchical structure (only) + +##### Reason + +Direct representation of ideas in code eases comprehension and maintenance. Make sure the idea represented in the base class exactly matches all derived types and there is not a better way to express it than using the tight coupling of inheritance. + +Do *not* use inheritance when simply having a data member will do. Usually this means that the derived type needs to override a base virtual function or needs access to a protected member. + +##### Example + + class DrawableUIElement { + public: + virtual void render() const = 0; + // ... + }; + + class AbstractButton : public DrawableUIElement { + public: + virtual void onClick() = 0; + // ... + }; + + class PushButton : public AbstractButton { + void render() const override; + void onClick() override; + // ... + }; + + class Checkbox : public AbstractButton { + // ... + }; + +##### Example, bad + +Do *not* represent non-hierarchical domain concepts as class hierarchies. + + template + class Container { + public: + // list operations: + virtual T& get() = 0; + virtual void put(T&) = 0; + virtual void insert(Position) = 0; + // ... + // vector operations: + virtual T& operator[](int) = 0; + virtual void sort() = 0; + // ... + // tree operations: + virtual void balance() = 0; + // ... + }; + +Here most overriding classes cannot implement most of the functions required in the interface well. +Thus the base class becomes an implementation burden. +Furthermore, the user of `Container` cannot rely on the member functions actually performing meaningful operations reasonably efficiently; +it might throw an exception instead. +Thus users have to resort to run-time checking and/or +not using this (over)general interface in favor of a particular interface found by a run-time type inquiry (e.g., a `dynamic_cast`). + +##### Enforcement + +* Look for classes with lots of members that do nothing but throw. +* Flag every use of a non-public base class `B` where the derived class `D` does not override a virtual function or access a protected member in `B`, and `B` is not one of the following: empty, a template parameter or parameter pack of `D`, a class template specialized with `D`. + +### C.121: If a base class is used as an interface, make it a pure abstract class + +##### Reason + +A class is more stable (less brittle) if it does not contain data. +Interfaces should normally be composed entirely of public pure virtual functions and a default/empty virtual destructor. + +##### Example + + class My_interface { + public: + // ...only pure virtual functions here ... + virtual ~My_interface() {} // or =default + }; + +##### Example, bad + + class Goof { + public: + // ...only pure virtual functions here ... + // no virtual destructor + }; + + class Derived : public Goof { + string s; + // ... + }; + + void use() + { + unique_ptr p {new Derived{"here we go"}}; + f(p.get()); // use Derived through the Goof interface + g(p.get()); // use Derived through the Goof interface + } // leak + +The `Derived` is `delete`d through its `Goof` interface, so its `string` is leaked. +Give `Goof` a virtual destructor and all is well. + + +##### Enforcement + +* Warn on any class that contains data members and also has an overridable (non-`final`) virtual function that wasn't inherited from a base class. + +### C.122: Use abstract classes as interfaces when complete separation of interface and implementation is needed + +##### Reason + +Such as on an ABI (link) boundary. + +##### Example + + struct Device { + virtual ~Device() = default; + virtual void write(span outbuf) = 0; + virtual void read(span inbuf) = 0; + }; + + class D1 : public Device { + // ... data ... + + void write(span outbuf) override; + void read(span inbuf) override; + }; + + class D2 : public Device { + // ... different data ... + + void write(span outbuf) override; + void read(span inbuf) override; + }; + +A user can now use `D1`s and `D2`s interchangeably through the interface provided by `Device`. +Furthermore, we can update `D1` and `D2` in ways that are not binary compatible with older versions as long as all access goes through `Device`. + +##### Enforcement + + ??? + +## C.hierclass: Designing classes in a hierarchy: + +### C.126: An abstract class typically doesn't need a user-written constructor + +##### Reason + +An abstract class typically does not have any data for a constructor to initialize. + +##### Example + + class Shape { + public: + // no user-written constructor needed in abstract base class + virtual Point center() const = 0; // pure virtual + virtual void move(Point to) = 0; + // ... more pure virtual functions... + virtual ~Shape() {} // destructor + }; + + class Circle : public Shape { + public: + Circle(Point p, int rad); // constructor in derived class + Point center() const override { return x; } + }; + +##### Exception + +* A base class constructor that does work, such as registering an object somewhere, might need a constructor. +* In extremely rare cases, you might find it reasonable for an abstract class to have a bit of data shared by all derived classes + (e.g., use statistics data, debug information, etc.); such classes tend to have constructors. But be warned: Such classes also tend to be prone to requiring virtual inheritance. + +##### Enforcement + +Flag abstract classes with constructors. + +### C.127: A class with a virtual function should have a virtual or protected destructor + +##### Reason + +A class with a virtual function is usually (and in general) used via a pointer to base. Usually, the last user has to call delete on a pointer to base, often via a smart pointer to base, so the destructor should be public and virtual. Less commonly, if deletion through a pointer to base is not intended to be supported, the destructor should be protected and non-virtual; see [C.35](#Rc-dtor-virtual). + +##### Example, bad + + struct B { + virtual int f() = 0; + // ... no user-written destructor, defaults to public non-virtual ... + }; + + // bad: derived from a class without a virtual destructor + struct D : B { + string s {"default"}; + // ... + }; + + void use() + { + unique_ptr p = make_unique(); + // ... + } // undefined behavior, might call B::~B only and leak the string + +##### Note + +There are people who don't follow this rule because they plan to use a class only through a `shared_ptr`: `std::shared_ptr p = std::make_shared(args);` Here, the shared pointer will take care of deletion, so no leak will occur from an inappropriate `delete` of the base. People who do this consistently can get a false positive, but the rule is important -- what if one was allocated using `make_unique`? It's not safe unless the author of `B` ensures that it can never be misused, such as by making all constructors private and providing a factory function to enforce the allocation with `make_shared`. + +##### Enforcement + +* A class with any virtual functions should have a destructor that is either public and virtual or else protected and non-virtual. +* Flag `delete` of a class with a virtual function but no virtual destructor. + +### C.128: Virtual functions should specify exactly one of `virtual`, `override`, or `final` + +##### Reason + +Readability. +Detection of mistakes. +Writing explicit `virtual`, `override`, or `final` is self-documenting and enables the compiler to catch mismatch of types and/or names between base and derived classes. However, writing more than one of these three is both redundant and a potential source of errors. + +It's simple and clear: + +* `virtual` means exactly and only "this is a new virtual function." +* `override` means exactly and only "this is a non-final overrider." +* `final` means exactly and only "this is a final overrider." + +##### Example, bad + + struct B { + void f1(int); + virtual void f2(int) const; + virtual void f3(int); + // ... + }; + + struct D : B { + void f1(int); // bad (hope for a warning): D::f1() hides B::f1() + void f2(int) const; // bad (but conventional and valid): no explicit override + void f3(double); // bad (hope for a warning): D::f3() hides B::f3() + // ... + }; + +##### Example, good + + struct Better : B { + void f1(int) override; // error (caught): Better::f1() hides B::f1() + void f2(int) const override; + void f3(double) override; // error (caught): Better::f3() hides B::f3() + // ... + }; + +#### Discussion + +We want to eliminate two particular classes of errors: + +* **implicit virtual**: the programmer intended the function to be implicitly virtual and it is (but readers of the code can't tell); or the programmer intended the function to be implicitly virtual but it isn't (e.g., because of a subtle parameter list mismatch); or the programmer did not intend the function to be virtual but it is (because it happens to have the same signature as a virtual in the base class) +* **implicit override**: the programmer intended the function to be implicitly an overrider and it is (but readers of the code can't tell); or the programmer intended the function to be implicitly an overrider but it isn't (e.g., because of a subtle parameter list mismatch); or the programmer did not intend the function to be an overrider but it is (because it happens to have the same signature as a virtual in the base class -- note this problem arises whether or not the function is explicitly declared virtual, because the programmer might have intended to create either a new virtual function or a new non-virtual function) + +Note: On a class defined as `final`, each individual virtual function should use either `override` or `final`; there is no semantic difference in this case. + +Note: Use `final` on functions sparingly. It does not necessarily lead to optimization, and it precludes further overriding. + +##### Enforcement + +* Compare virtual function names in base and derived classes and flag uses of the same name that do not override. +* Flag overrides with neither `override` nor `final`. +* Flag function declarations that use more than one of `virtual`, `override`, and `final`. + +### C.129: When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance + +##### Reason + +Implementation details in an interface make the interface brittle; +that is, make its users vulnerable to having to recompile after changes in the implementation. +Data in a base class increases the complexity of implementing the base and can lead to replication of code. + +##### Note + +Definition: + +* interface inheritance is the use of inheritance to separate users from implementations, +in particular to allow derived classes to be added and changed without affecting the users of base classes. +* implementation inheritance is the use of inheritance to simplify implementation of new facilities +by making useful operations available for implementers of related new operations (sometimes called "programming by difference"). + +A pure interface class is simply a set of pure virtual functions; see [I.25](#Ri-abstract). + +In early OOP (e.g., in the 1980s and 1990s), implementation inheritance and interface inheritance were often mixed +and bad habits die hard. +Even now, mixtures are not uncommon in old code bases and in old-style teaching material. + +The importance of keeping the two kinds of inheritance increases + +* with the size of a hierarchy (e.g., dozens of derived classes), +* with the length of time the hierarchy is used (e.g., decades), and +* with the number of distinct organizations in which a hierarchy is used +(e.g., it can be difficult to distribute an update to a base class) + + +##### Example, bad + + class Shape { // BAD, mixed interface and implementation + public: + Shape(); + Shape(Point ce = {0, 0}, Color co = none): cent{ce}, col {co} { /* ... */} + + Point center() const { return cent; } + Color color() const { return col; } + + virtual void rotate(int) = 0; + virtual void move(Point p) { cent = p; redraw(); } + + virtual void redraw(); + + // ... + private: + Point cent; + Color col; + }; + + class Circle : public Shape { + public: + Circle(Point c, int r) : Shape{c}, rad{r} { /* ... */ } + + // ... + private: + int rad; + }; + + class Triangle : public Shape { + public: + Triangle(Point p1, Point p2, Point p3); // calculate center + // ... + }; + +Problems: + +* As the hierarchy grows and more data is added to `Shape`, the constructors get harder to write and maintain. +* Why calculate the center for the `Triangle`? we might never use it. +* Add a data member to `Shape` (e.g., drawing style or canvas) +and all classes derived from `Shape` and all code using `Shape` will need to be reviewed, possibly changed, and probably recompiled. + +The implementation of `Shape::move()` is an example of implementation inheritance: +we have defined `move()` once and for all, for all derived classes. +The more code there is in such base class member function implementations and the more data is shared by placing it in the base, +the more benefits we gain - and the less stable the hierarchy is. + +##### Example + +This Shape hierarchy can be rewritten using interface inheritance: + + class Shape { // pure interface + public: + virtual Point center() const = 0; + virtual Color color() const = 0; + + virtual void rotate(int) = 0; + virtual void move(Point p) = 0; + + virtual void redraw() = 0; + + // ... + }; + +Note that a pure interface rarely has constructors: there is nothing to construct. + + class Circle : public Shape { + public: + Circle(Point c, int r, Color c) : cent{c}, rad{r}, col{c} { /* ... */ } + + Point center() const override { return cent; } + Color color() const override { return col; } + + // ... + private: + Point cent; + int rad; + Color col; + }; + +The interface is now less brittle, but there is more work in implementing the member functions. +For example, `center` has to be implemented by every class derived from `Shape`. + +##### Example, dual hierarchy + +How can we gain the benefit of stable hierarchies from interface hierarchies and the benefit of implementation reuse from implementation inheritance? +One popular technique is dual hierarchies. +There are many ways of implementing the idea of dual hierarchies; here, we use a multiple-inheritance variant. + +First we devise a hierarchy of interface classes: + + class Shape { // pure interface + public: + virtual Point center() const = 0; + virtual Color color() const = 0; + + virtual void rotate(int) = 0; + virtual void move(Point p) = 0; + + virtual void redraw() = 0; + + // ... + }; + + class Circle : public virtual Shape { // pure interface + public: + virtual int radius() = 0; + // ... + }; + +To make this interface useful, we must provide its implementation classes (here, named equivalently, but in the `Impl` namespace): + + class Impl::Shape : public virtual ::Shape { // implementation + public: + // constructors, destructor + // ... + Point center() const override { /* ... */ } + Color color() const override { /* ... */ } + + void rotate(int) override { /* ... */ } + void move(Point p) override { /* ... */ } + + void redraw() override { /* ... */ } + + // ... + }; + +Now `Shape` is a poor example of a class with an implementation, +but bear with us because this is just a simple example of a technique aimed at more complex hierarchies. + + class Impl::Circle : public virtual ::Circle, public Impl::Shape { // implementation + public: + // constructors, destructor + + int radius() override { /* ... */ } + // ... + }; + +And we could extend the hierarchies by adding a Smiley class (:-)): + + class Smiley : public virtual Circle { // pure interface + public: + // ... + }; + + class Impl::Smiley : public virtual ::Smiley, public Impl::Circle { // implementation + public: + // constructors, destructor + // ... + } + +There are now two hierarchies: + +* interface: Smiley -> Circle -> Shape +* implementation: Impl::Smiley -> Impl::Circle -> Impl::Shape + +Since each implementation is derived from its interface as well as its implementation base class we get a lattice (DAG): + + Smiley -> Circle -> Shape + ^ ^ ^ + | | | + Impl::Smiley -> Impl::Circle -> Impl::Shape + +As mentioned, this is just one way to construct a dual hierarchy. + +The implementation hierarchy can be used directly, rather than through the abstract interface. + + void work_with_shape(Shape&); + + int user() + { + Impl::Smiley my_smiley{ /* args */ }; // create concrete shape + // ... + my_smiley.some_member(); // use implementation class directly + // ... + work_with_shape(my_smiley); // use implementation through abstract interface + // ... + } + +This can be useful when the implementation class has members that are not offered in the abstract interface +or if direct use of a member offers optimization opportunities (e.g., if an implementation member function is `final`) + +##### Note + +Another (related) technique for separating interface and implementation is [Pimpl](#Ri-pimpl). + +##### Note + +There is often a choice between offering common functionality as (implemented) base class functions and freestanding functions +(in an implementation namespace). +Base classes give a shorter notation and easier access to shared data (in the base) +at the cost of the functionality being available only to users of the hierarchy. + +##### Enforcement + +* Flag a derived to base conversion to a base with both data and virtual functions +(except for calls from a derived class member to a base class member) +* ??? + + +### C.130: For making deep copies of polymorphic classes prefer a virtual `clone` function instead of public copy construction/assignment + +##### Reason + +Copying a polymorphic class is discouraged due to the slicing problem, see [C.67](#Rc-copy-virtual). If you really need copy semantics, copy deeply: Provide a virtual `clone` function that will copy the actual most-derived type and return an owning pointer to the new object, and then in derived classes return the derived type (use a covariant return type). + +##### Example + + class B { + public: + B() = default; + virtual ~B() = default; + virtual gsl::owner clone() const = 0; + protected: + B(const B&) = default; + B& operator=(const B&) = default; + B(B&&) noexcept = default; + B& operator=(B&&) noexcept = default; + // ... + }; + + class D : public B { + public: + gsl::owner clone() const override + { + return new D{*this}; + }; + }; + +Generally, it is recommended to use smart pointers to represent ownership (see [R.20](#Rr-owner)). However, because of language rules, the covariant return type cannot be a smart pointer: `D::clone` can't return a `unique_ptr` while `B::clone` returns `unique_ptr`. Therefore, you either need to consistently return `unique_ptr` in all overrides, or use `owner<>` utility from the [Guidelines Support Library](#SS-views). + + + +### C.131: Avoid trivial getters and setters + +##### Reason + +A trivial getter or setter adds no semantic value; the data item could just as well be `public`. + +##### Example + + class Point { // Bad: verbose + int x; + int y; + public: + Point(int xx, int yy) : x{xx}, y{yy} { } + int get_x() const { return x; } + void set_x(int xx) { x = xx; } + int get_y() const { return y; } + void set_y(int yy) { y = yy; } + // no behavioral member functions + }; + +Consider making such a class a `struct` -- that is, a behaviorless bunch of variables, all public data and no member functions. + + struct Point { + int x {0}; + int y {0}; + }; + +Note that we can put default initializers on data members: [C.49: Prefer initialization to assignment in constructors](#Rc-initialize). + +##### Note + +The key to this rule is whether the semantics of the getter/setter are trivial. While it is not a complete definition of "trivial", consider whether there would be any difference beyond syntax if the getter/setter was a public data member instead. Examples of non-trivial semantics would be: maintaining a class invariant or converting between an internal type and an interface type. + +##### Enforcement + +Flag multiple `get` and `set` member functions that simply access a member without additional semantics. + +### C.132: Don't make a function `virtual` without reason + +##### Reason + +Redundant `virtual` increases run-time and object-code size. +A virtual function can be overridden and is thus open to mistakes in a derived class. +A virtual function ensures code replication in a templated hierarchy. + +##### Example, bad + + template + class Vector { + public: + // ... + virtual int size() const { return sz; } // bad: what good could a derived class do? + private: + T* elem; // the elements + int sz; // number of elements + }; + +This kind of "vector" isn't meant to be used as a base class at all. + +##### Enforcement + +* Flag a class with virtual functions but no derived classes. +* Flag a class where all member functions are virtual and have implementations. + +### C.133: Avoid `protected` data + +**Alternative formulation**: Make member data `public` or (preferably) `private`. + +##### Reason + +`protected` data is a source of complexity and errors. +`protected` data complicates the statement of invariants. +`protected` data inherently violates the guidance against putting data in base classes, which usually leads to having to deal with virtual inheritance as well. + +##### Example, bad + + class Shape { + public: + // ... interface functions ... + protected: + // data for use in derived classes: + Color fill_color; + Color edge_color; + Style st; + }; + +Now it is up to every derived `Shape` to manipulate the protected data correctly. +This has been popular, but also a major source of maintenance problems. +In a large class hierarchy, the consistent use of protected data is hard to maintain because there can be a lot of code, +spread over a lot of classes. +The set of classes that can touch that data is open: anyone can derive a new class and start manipulating the protected data. +Often, it is not possible to examine the complete set of classes, so any change to the representation of the class becomes infeasible. +There is no enforced invariant for the protected data; it is much like a set of global variables. +The protected data has de facto become global to a large body of code. + +##### Note + +Protected data often looks tempting to enable arbitrary improvements through derivation. +Often, what you get is unprincipled changes and errors. +[Prefer `private` data](#Rc-private) with a well-specified and enforced invariant. +Alternative, and often better, [keep data out of any class used as an interface](#Rh-abstract). + +##### Note + +Protected member function can be just fine. + +##### Enforcement + +Flag classes with `protected` data. + +### C.134: Ensure all non-`const` data members have the same access level + +##### Reason + +Prevention of logical confusion leading to errors. +If the non-`const` data members don't have the same access level, the type is confused about what it's trying to do. +Is it a type that maintains an invariant or simply a collection of values? + +##### Discussion + +The core question is: What code is responsible for maintaining a meaningful/correct value for that variable? + +There are exactly two kinds of data members: + +* A: Ones that don't participate in the object's invariant. Any combination of values for these members is valid. +* B: Ones that do participate in the object's invariant. Not every combination of values is meaningful (else there'd be no invariant). Therefore all code that has write access to these variables must know about the invariant, know the semantics, and know (and actively implement and enforce) the rules for keeping the values correct. + +Data members in category A should just be `public` (or, more rarely, `protected` if you only want derived classes to see them). They don't need encapsulation. All code in the system might as well see and manipulate them. + +Data members in category B should be `private` or `const`. This is because encapsulation is important. To make them non-`private` and non-`const` would mean that the object can't control its own state: An unbounded amount of code beyond the class would need to know about the invariant and participate in maintaining it accurately -- if these data members were `public`, that would be all calling code that uses the object; if they were `protected`, it would be all the code in current and future derived classes. This leads to brittle and tightly coupled code that quickly becomes a nightmare to maintain. Any code that inadvertently sets the data members to an invalid or unexpected combination of values would corrupt the object and all subsequent uses of the object. + +Most classes are either all A or all B: + +* *All public*: If you're writing an aggregate bundle-of-variables without an invariant across those variables, then all the variables should be `public`. + [By convention, declare such classes `struct` rather than `class`](#Rc-struct) +* *All private*: If you're writing a type that maintains an invariant, then all the non-`const` variables should be private -- it should be encapsulated. + +##### Exception + +Occasionally classes will mix A and B, usually for debug reasons. An encapsulated object might contain something like non-`const` debug instrumentation that isn't part of the invariant and so falls into category A -- it isn't really part of the object's value or meaningful observable state either. In that case, the A parts should be treated as A's (made `public`, or in rarer cases `protected` if they should be visible only to derived classes) and the B parts should still be treated like B's (`private` or `const`). + +##### Enforcement + +Flag any class that has non-`const` data members with different access levels. + +### C.135: Use multiple inheritance to represent multiple distinct interfaces + +##### Reason + +Not all classes will necessarily support all interfaces, and not all callers will necessarily want to deal with all operations. +Especially to break apart monolithic interfaces into "aspects" of behavior supported by a given derived class. + +##### Example + + class iostream : public istream, public ostream { // very simplified + // ... + }; + +`istream` provides the interface to input operations; `ostream` provides the interface to output operations. +`iostream` provides the union of the `istream` and `ostream` interfaces and the synchronization needed to allow both on a single stream. + +##### Note + +This is a very common use of inheritance because the need for multiple different interfaces to an implementation is common +and such interfaces are often not easily or naturally organized into a single-rooted hierarchy. + +##### Note + +Such interfaces are typically abstract classes. + +##### Enforcement + +??? + +### C.136: Use multiple inheritance to represent the union of implementation attributes + +##### Reason + +Some forms of mixins have state and often operations on that state. +If the operations are virtual the use of inheritance is necessary, if not using inheritance can avoid boilerplate and forwarding. + +##### Example + + class iostream : public istream, public ostream { // very simplified + // ... + }; + +`istream` provides the interface to input operations (and some data); `ostream` provides the interface to output operations (and some data). +`iostream` provides the union of the `istream` and `ostream` interfaces and the synchronization needed to allow both on a single stream. + +##### Note + +This a relatively rare use because implementation can often be organized into a single-rooted hierarchy. + +##### Example + +Sometimes, an "implementation attribute" is more like a "mixin" that determine the behavior of an implementation and inject +members to enable the implementation of the policies it requires. +For example, see `std::enable_shared_from_this` +or various bases from boost.intrusive (e.g. `list_base_hook` or `intrusive_ref_counter`). + +##### Enforcement + +??? + +### C.137: Use `virtual` bases to avoid overly general base classes + +##### Reason + + Allow separation of shared data and interface. + To avoid all shared data to being put into an ultimate base class. + +##### Example + + struct Interface { + virtual void f(); + virtual int g(); + // ... no data here ... + }; + + class Utility { // with data + void utility1(); + virtual void utility2(); // customization point + public: + int x; + int y; + }; + + class Derive1 : public Interface, virtual protected Utility { + // override Interface functions + // Maybe override Utility virtual functions + // ... + }; + + class Derive2 : public Interface, virtual protected Utility { + // override Interface functions + // Maybe override Utility virtual functions + // ... + }; + +Factoring out `Utility` makes sense if many derived classes share significant "implementation details." + + +##### Note + +Obviously, the example is too "theoretical", but it is hard to find a *small* realistic example. +`Interface` is the root of an [interface hierarchy](#Rh-abstract) +and `Utility` is the root of an [implementation hierarchy](#Rh-kind). +Here is [a slightly more realistic example](https://www.quora.com/What-are-the-uses-and-advantages-of-virtual-base-class-in-C%2B%2B/answer/Lance-Diduck) with an explanation. + +##### Note + +Often, linearization of a hierarchy is a better solution. + +##### Enforcement + +Flag mixed interface and implementation hierarchies. + +### C.138: Create an overload set for a derived class and its bases with `using` + +##### Reason + +Without a using declaration, member functions in the derived class hide the entire inherited overload sets. + +##### Example, bad + + #include + class B { + public: + virtual int f(int i) { std::cout << "f(int): "; return i; } + virtual double f(double d) { std::cout << "f(double): "; return d; } + virtual ~B() = default; + }; + class D: public B { + public: + int f(int i) override { std::cout << "f(int): "; return i + 1; } + }; + int main() + { + D d; + std::cout << d.f(2) << '\n'; // prints "f(int): 3" + std::cout << d.f(2.3) << '\n'; // prints "f(int): 3" + } + +##### Example, good + + class D: public B { + public: + int f(int i) override { std::cout << "f(int): "; return i + 1; } + using B::f; // exposes f(double) + }; + +##### Note + +This issue affects both virtual and non-virtual member functions + +For variadic bases, C++17 introduced a variadic form of the using-declaration, + + template + struct Overloader : Ts... { + using Ts::operator()...; // exposes operator() from every base + }; + +##### Enforcement + +Diagnose name hiding + +### C.139: Use `final` on classes sparingly + +##### Reason + +Capping a hierarchy with `final` classes is rarely needed for logical reasons and can be damaging to the extensibility of a hierarchy. + +##### Example, bad + + class Widget { /* ... */ }; + + // nobody will ever want to improve My_widget (or so you thought) + class My_widget final : public Widget { /* ... */ }; + + class My_improved_widget : public My_widget { /* ... */ }; // error: can't do that + +##### Note + +Not every class is meant to be a base class. +Most standard-library classes are examples of that (e.g., `std::vector` and `std::string` are not designed to be derived from). +This rule is about using `final` on classes with virtual functions meant to be interfaces for a class hierarchy. + +##### Note + +Claims of performance improvements from `final` should be substantiated. +Too often, such claims are based on conjecture or experience with other languages. + +There are examples where `final` can be important for both logical and performance reasons. +One example is a performance-critical AST hierarchy in a compiler or language analysis tool. +New derived classes are not added every year and only by library implementers. +However, misuses are (or at least have been) far more common. + +##### Enforcement + +Flag uses of `final` on classes. + + +### C.140: Do not provide different default arguments for a virtual function and an overrider + +##### Reason + +That can cause confusion: An overrider does not inherit default arguments. + +##### Example, bad + + class Base { + public: + virtual int multiply(int value, int factor = 2) = 0; + virtual ~Base() = default; + }; + + class Derived : public Base { + public: + int multiply(int value, int factor = 10) override; + }; + + Derived d; + Base& b = d; + + b.multiply(10); // these two calls will call the same function but + d.multiply(10); // with different arguments and so different results + +##### Enforcement + +Flag default arguments on virtual functions if they differ between base and derived declarations. + +## C.hier-access: Accessing objects in a hierarchy + +### C.145: Access polymorphic objects through pointers and references + +##### Reason + +If you have a class with a virtual function, you don't (in general) know which class provided the function to be used. + +##### Example + + struct B { int a; virtual int f(); virtual ~B() = default }; + struct D : B { int b; int f() override; }; + + void use(B b) + { + D d; + B b2 = d; // slice + B b3 = b; + } + + void use2() + { + D d; + use(d); // slice + } + +Both `d`s are sliced. + +##### Exception + +You can safely access a named polymorphic object in the scope of its definition, just don't slice it. + + void use3() + { + D d; + d.f(); // OK + } + +##### See also + +[A polymorphic class should suppress copying](#Rc-copy-virtual) + +##### Enforcement + +Flag all slicing. + +### C.146: Use `dynamic_cast` where class hierarchy navigation is unavoidable + +##### Reason + +`dynamic_cast` is checked at run time. + +##### Example + + struct B { // an interface + virtual void f(); + virtual void g(); + virtual ~B(); + }; + + struct D : B { // a wider interface + void f() override; + virtual void h(); + }; + + void user(B* pb) + { + if (D* pd = dynamic_cast(pb)) { + // ... use D's interface ... + } + else { + // ... make do with B's interface ... + } + } + +Use of the other casts can violate type safety and cause the program to access a variable that is actually of type `X` to be accessed as if it were of an unrelated type `Z`: + + void user2(B* pb) // bad + { + D* pd = static_cast(pb); // I know that pb really points to a D; trust me + // ... use D's interface ... + } + + void user3(B* pb) // unsafe + { + if (some_condition) { + D* pd = static_cast(pb); // I know that pb really points to a D; trust me + // ... use D's interface ... + } + else { + // ... make do with B's interface ... + } + } + + void f() + { + B b; + user(&b); // OK + user2(&b); // bad error + user3(&b); // OK *if* the programmer got the some_condition check right + } + +##### Note + +Like other casts, `dynamic_cast` is overused. +[Prefer virtual functions to casting](#Rh-use-virtual). +Prefer [static polymorphism](#???) to hierarchy navigation where it is possible (no run-time resolution necessary) +and reasonably convenient. + +##### Note + +Some people use `dynamic_cast` where a `typeid` would have been more appropriate; +`dynamic_cast` is a general "is kind of" operation for discovering the best interface to an object, +whereas `typeid` is a "give me the exact type of this object" operation to discover the actual type of an object. +The latter is an inherently simpler operation that ought to be faster. +The latter (`typeid`) is easily hand-crafted if necessary (e.g., if working on a system where RTTI is -- for some reason -- prohibited), +the former (`dynamic_cast`) is far harder to implement correctly in general. + +Consider: + + struct B { + const char* name {"B"}; + // if pb1->id() == pb2->id() *pb1 is the same type as *pb2 + virtual const char* id() const { return name; } + // ... + }; + + struct D : B { + const char* name {"D"}; + const char* id() const override { return name; } + // ... + }; + + void use() + { + B* pb1 = new B; + B* pb2 = new D; + + cout << pb1->id(); // "B" + cout << pb2->id(); // "D" + + + if (pb2->id() == "D") { // looks innocent + D* pd = static_cast(pb2); + // ... + } + // ... + } + +The result of `pb2->id() == "D"` is actually implementation defined. +We added it to warn of the dangers of home-brew RTTI. +This code might work as expected for years, just to fail on a new machine, new compiler, or a new linker that does not unify character literals. + +If you implement your own RTTI, be careful. + +##### Exception + +If your implementation provided a really slow `dynamic_cast`, you might have to use a workaround. +However, all workarounds that cannot be statically resolved involve explicit casting (typically `static_cast`) and are error-prone. +You will basically be crafting your own special-purpose `dynamic_cast`. +So, first make sure that your `dynamic_cast` really is as slow as you think it is (there are a fair number of unsupported rumors about) +and that your use of `dynamic_cast` is really performance critical. + +We are of the opinion that current implementations of `dynamic_cast` are unnecessarily slow. +For example, under suitable conditions, it is possible to perform a `dynamic_cast` in [fast constant time](http://www.stroustrup.com/fast_dynamic_casting.pdf). +However, compatibility makes changes difficult even if all agree that an effort to optimize is worthwhile. + +In very rare cases, if you have measured that the `dynamic_cast` overhead is material, you have other means to statically guarantee that a downcast will succeed (e.g., you are using CRTP carefully), and there is no virtual inheritance involved, consider tactically resorting `static_cast` with a prominent comment and disclaimer summarizing this paragraph and that human attention is needed under maintenance because the type system can't verify correctness. Even so, in our experience such "I know what I'm doing" situations are still a known bug source. + +##### Exception + +Consider: + + template + class Dx : B { + // ... + }; + +##### Enforcement + +* Flag all uses of `static_cast` for downcasts, including C-style casts that perform a `static_cast`. +* This rule is part of the [type-safety profile](#Pro-type-downcast). + +### C.147: Use `dynamic_cast` to a reference type when failure to find the required class is considered an error + +##### Reason + +Casting to a reference expresses that you intend to end up with a valid object, so the cast must succeed. `dynamic_cast` will then throw if it does not succeed. + +##### Example + + std::string f(Base& b) + { + return dynamic_cast(b).to_string(); + } + +##### Enforcement + +??? + +### C.148: Use `dynamic_cast` to a pointer type when failure to find the required class is considered a valid alternative + +##### Reason + +The `dynamic_cast` conversion allows to test whether a pointer is pointing at a polymorphic object that has a given class in its hierarchy. Since failure to find the class merely returns a null value, it can be tested during run time. This allows writing code that can choose alternative paths depending on the results. + +Contrast with [C.147](#Rh-ref-cast), where failure is an error, and should not be used for conditional execution. + +##### Example + +The example below describes the `add` function of a `Shape_owner` that takes ownership of constructed `Shape` objects. The objects are also sorted into views, according to their geometric attributes. +In this example, `Shape` does not inherit from `Geometric_attributes`. Only its subclasses do. + + void add(Shape* const item) + { + // Ownership is always taken + owned_shapes.emplace_back(item); + + // Check the Geometric_attributes and add the shape to none/one/some/all of the views + + if (auto even = dynamic_cast(item)) + { + view_of_evens.emplace_back(even); + } + + if (auto trisym = dynamic_cast(item)) + { + view_of_trisyms.emplace_back(trisym); + } + } + +##### Notes + +A failure to find the required class will cause `dynamic_cast` to return a null value, and de-referencing a null-valued pointer will lead to undefined behavior. +Therefore the result of the `dynamic_cast` should always be treated as if it might contain a null value, and tested. + +##### Enforcement + +* (Complex) Unless there is a null test on the result of a `dynamic_cast` of a pointer type, warn upon dereference of the pointer. + +### C.149: Use `unique_ptr` or `shared_ptr` to avoid forgetting to `delete` objects created using `new` + +##### Reason + +Avoid resource leaks. + +##### Example + + void use(int i) + { + auto p = new int {7}; // bad: initialize local pointers with new + auto q = make_unique(9); // ok: guarantee the release of the memory-allocated for 9 + if (0 < i) return; // maybe return and leak + delete p; // too late + } + +##### Enforcement + +* Flag initialization of a naked pointer with the result of a `new` +* Flag `delete` of local variable + +### C.150: Use `make_unique()` to construct objects owned by `unique_ptr`s + +See [R.23](#Rr-make_unique) + +### C.151: Use `make_shared()` to construct objects owned by `shared_ptr`s + +See [R.22](#Rr-make_shared) + +### C.152: Never assign a pointer to an array of derived class objects to a pointer to its base + +##### Reason + +Subscripting the resulting base pointer will lead to invalid object access and probably to memory corruption. + +##### Example + + struct B { int x; }; + struct D : B { int y; }; + + void use(B*); + + D a[] = { {1, 2}, {3, 4}, {5, 6} }; + B* p = a; // bad: a decays to &a[0] which is converted to a B* + p[1].x = 7; // overwrite a[0].y + + use(a); // bad: a decays to &a[0] which is converted to a B* + +##### Enforcement + +* Flag all combinations of array decay and base to derived conversions. +* Pass an array as a `span` rather than as a pointer, and don't let the array name suffer a derived-to-base conversion before getting into the `span` + + +### C.153: Prefer virtual function to casting + +##### Reason + +A virtual function call is safe, whereas casting is error-prone. +A virtual function call reaches the most derived function, whereas a cast might reach an intermediate class and therefore +give a wrong result (especially as a hierarchy is modified during maintenance). + +##### Example + + ??? + +##### Enforcement + +See [C.146](#Rh-dynamic_cast) and ??? + +## C.over: Overloading and overloaded operators + +You can overload ordinary functions, function templates, and operators. +You cannot overload function objects. + +Overload rule summary: + +* [C.160: Define operators primarily to mimic conventional usage](#Ro-conventional) +* [C.161: Use non-member functions for symmetric operators](#Ro-symmetric) +* [C.162: Overload operations that are roughly equivalent](#Ro-equivalent) +* [C.163: Overload only for operations that are roughly equivalent](#Ro-equivalent-2) +* [C.164: Avoid implicit conversion operators](#Ro-conversion) +* [C.165: Use `using` for customization points](#Ro-custom) +* [C.166: Overload unary `&` only as part of a system of smart pointers and references](#Ro-address-of) +* [C.167: Use an operator for an operation with its conventional meaning](#Ro-overload) +* [C.168: Define overloaded operators in the namespace of their operands](#Ro-namespace) +* [C.170: If you feel like overloading a lambda, use a generic lambda](#Ro-lambda) + +### C.160: Define operators primarily to mimic conventional usage + +##### Reason + +Minimize surprises. + +##### Example + + class X { + public: + // ... + X& operator=(const X&); // member function defining assignment + friend bool operator==(const X&, const X&); // == needs access to representation + // after a = b we have a == b + // ... + }; + +Here, the conventional semantics is maintained: [Copies compare equal](#SS-copy). + +##### Example, bad + + X operator+(X a, X b) { return a.v - b.v; } // bad: makes + subtract + +##### Note + +Non-member operators should be either friends or defined in [the same namespace as their operands](#Ro-namespace). +[Binary operators should treat their operands equivalently](#Ro-symmetric). + +##### Enforcement + +Possibly impossible. + +### C.161: Use non-member functions for symmetric operators + +##### Reason + +If you use member functions, you need two. +Unless you use a non-member function for (say) `==`, `a == b` and `b == a` will be subtly different. + +##### Example + + bool operator==(Point a, Point b) { return a.x == b.x && a.y == b.y; } + +##### Enforcement + +Flag member operator functions. + +### C.162: Overload operations that are roughly equivalent + +##### Reason + +Having different names for logically equivalent operations on different argument types is confusing, leads to encoding type information in function names, and inhibits generic programming. + +##### Example + +Consider: + + void print(int a); + void print(int a, int base); + void print(const string&); + +These three functions all print their arguments (appropriately). Conversely: + + void print_int(int a); + void print_based(int a, int base); + void print_string(const string&); + +These three functions all print their arguments (appropriately). Adding to the name just introduced verbosity and inhibits generic code. + +##### Enforcement + +??? + +### C.163: Overload only for operations that are roughly equivalent + +##### Reason + +Having the same name for logically different functions is confusing and leads to errors when using generic programming. + +##### Example + +Consider: + + void open_gate(Gate& g); // remove obstacle from garage exit lane + void fopen(const char* name, const char* mode); // open file + +The two operations are fundamentally different (and unrelated) so it is good that their names differ. Conversely: + + void open(Gate& g); // remove obstacle from garage exit lane + void open(const char* name, const char* mode ="r"); // open file + +The two operations are still fundamentally different (and unrelated) but the names have been reduced to their (common) minimum, opening opportunities for confusion. +Fortunately, the type system will catch many such mistakes. + +##### Note + +Be particularly careful about common and popular names, such as `open`, `move`, `+`, and `==`. + +##### Enforcement + +??? + +### C.164: Avoid implicit conversion operators + +##### Reason + +Implicit conversions can be essential (e.g., `double` to `int`) but often cause surprises (e.g., `String` to C-style string). + +##### Note + +Prefer explicitly named conversions until a serious need is demonstrated. +By "serious need" we mean a reason that is fundamental in the application domain (such as an integer to complex number conversion) +and frequently needed. Do not introduce implicit conversions (through conversion operators or non-`explicit` constructors) +just to gain a minor convenience. + +##### Example + + struct S1 { + string s; + // ... + operator char*() { return s.data(); } // BAD, likely to cause surprises + }; + + struct S2 { + string s; + // ... + explicit operator char*() { return s.data(); } + }; + + void f(S1 s1, S2 s2) + { + char* x1 = s1; // OK, but can cause surprises in many contexts + char* x2 = s2; // error (and that's usually a good thing) + char* x3 = static_cast(s2); // we can be explicit (on your head be it) + } + +The surprising and potentially damaging implicit conversion can occur in arbitrarily hard-to spot contexts, e.g., + + S1 ff(); + + char* g() + { + return ff(); + } + +The string returned by `ff()` is destroyed before the returned pointer into it can be used. + +##### Enforcement + +Flag all non-explicit conversion operators. + +### C.165: Use `using` for customization points + +##### Reason + +To find function objects and functions defined in a separate namespace to "customize" a common function. + +##### Example + +Consider `swap`. It is a general (standard-library) function with a definition that will work for just about any type. +However, it is desirable to define specific `swap()`s for specific types. +For example, the general `swap()` will copy the elements of two `vector`s being swapped, whereas a good specific implementation will not copy elements at all. + + namespace N { + My_type X { /* ... */ }; + void swap(X&, X&); // optimized swap for N::X + // ... + } + + void f1(N::X& a, N::X& b) + { + std::swap(a, b); // probably not what we wanted: calls std::swap() + } + +The `std::swap()` in `f1()` does exactly what we asked it to do: it calls the `swap()` in namespace `std`. +Unfortunately, that's probably not what we wanted. +How do we get `N::X` considered? + + void f2(N::X& a, N::X& b) + { + swap(a, b); // calls N::swap + } + +But that might not be what we wanted for generic code. +There, we typically want the specific function if it exists and the general function if not. +This is done by including the general function in the lookup for the function: + + void f3(N::X& a, N::X& b) + { + using std::swap; // make std::swap available + swap(a, b); // calls N::swap if it exists, otherwise std::swap + } + +##### Enforcement + +Unlikely, except for known customization points, such as `swap`. +The problem is that the unqualified and qualified lookups both have uses. + +### C.166: Overload unary `&` only as part of a system of smart pointers and references + +##### Reason + +The `&` operator is fundamental in C++. +Many parts of the C++ semantics assume its default meaning. + +##### Example + + class Ptr { // a somewhat smart pointer + Ptr(X* pp) : p(pp) { /* check */ } + X* operator->() { /* check */ return p; } + X operator[](int i); + X operator*(); + private: + T* p; + }; + + class X { + Ptr operator&() { return Ptr{this}; } + // ... + }; + +##### Note + +If you "mess with" operator `&` be sure that its definition has matching meanings for `->`, `[]`, `*`, and `.` on the result type. +Note that operator `.` currently cannot be overloaded so a perfect system is impossible. +We hope to remedy that: [Operator Dot (R2)](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4477.pdf). +Note that `std::addressof()` always yields a built-in pointer. + +##### Enforcement + +Tricky. Warn if `&` is user-defined without also defining `->` for the result type. + +### C.167: Use an operator for an operation with its conventional meaning + +##### Reason + +Readability. Convention. Reusability. Support for generic code + +##### Example + + void cout_my_class(const My_class& c) // confusing, not conventional,not generic + { + std::cout << /* class members here */; + } + + std::ostream& operator<<(std::ostream& os, const my_class& c) // OK + { + return os << /* class members here */; + } + +By itself, `cout_my_class` would be OK, but it is not usable/composable with code that rely on the `<<` convention for output: + + My_class var { /* ... */ }; + // ... + cout << "var = " << var << '\n'; + +##### Note + +There are strong and vigorous conventions for the meaning of most operators, such as + +* comparisons (`==`, `!=`, `<`, `<=`, `>`, `>=`, and `<=>`), +* arithmetic operations (`+`, `-`, `*`, `/`, and `%`) +* access operations (`.`, `->`, unary `*`, and `[]`) +* assignment (`=`) + +Don't define those unconventionally and don't invent your own names for them. + +##### Enforcement + +Tricky. Requires semantic insight. + +### C.168: Define overloaded operators in the namespace of their operands + +##### Reason + +Readability. +Ability for find operators using ADL. +Avoiding inconsistent definition in different namespaces + +##### Example + + struct S { }; + S operator+(S, S); // OK: in the same namespace as S, and even next to S + S s; + + S r = s + s; + +##### Example + + namespace N { + struct S { }; + S operator+(S, S); // OK: in the same namespace as S, and even next to S + } + + N::S s; + + S r = s + s; // finds N::operator+() by ADL + +##### Example, bad + + struct S { }; + S s; + + namespace N { + bool operator!(S a) { return true; } + bool not_s = !s; + } + + namespace M { + bool operator!(S a) { return false; } + bool not_s = !s; + } + +Here, the meaning of `!s` differs in `N` and `M`. +This can be most confusing. +Remove the definition of `namespace M` and the confusion is replaced by an opportunity to make the mistake. + +##### Note + +If a binary operator is defined for two types that are defined in different namespaces, you cannot follow this rule. +For example: + + Vec::Vector operator*(const Vec::Vector&, const Mat::Matrix&); + +This might be something best avoided. + +##### See also + +This is a special case of the rule that [helper functions should be defined in the same namespace as their class](#Rc-helper). + +##### Enforcement + +* Flag operator definitions that are not in the namespace of their operands + +### C.170: If you feel like overloading a lambda, use a generic lambda + +##### Reason + +You cannot overload by defining two different lambdas with the same name. + +##### Example + + void f(int); + void f(double); + auto f = [](char); // error: cannot overload variable and function + + auto g = [](int) { /* ... */ }; + auto g = [](double) { /* ... */ }; // error: cannot overload variables + + auto h = [](auto) { /* ... */ }; // OK + +##### Enforcement + +The compiler catches the attempt to overload a lambda. + +## C.union: Unions + +A `union` is a `struct` where all members start at the same address so that it can hold only one member at a time. +A `union` does not keep track of which member is stored so the programmer has to get it right; +this is inherently error-prone, but there are ways to compensate. + +A type that is a `union` plus an indicator of which member is currently held is called a *tagged union*, a *discriminated union*, or a *variant*. + +Union rule summary: + +* [C.180: Use `union`s to save Memory](#Ru-union) +* [C.181: Avoid "naked" `union`s](#Ru-naked) +* [C.182: Use anonymous `union`s to implement tagged unions](#Ru-anonymous) +* [C.183: Don't use a `union` for type punning](#Ru-pun) +* ??? + +### C.180: Use `union`s to save memory + +##### Reason + +A `union` allows a single piece of memory to be used for different types of objects at different times. +Consequently, it can be used to save memory when we have several objects that are never used at the same time. + +##### Example + + union Value { + int x; + double d; + }; + + Value v = { 123 }; // now v holds an int + cout << v.x << '\n'; // write 123 + v.d = 987.654; // now v holds a double + cout << v.d << '\n'; // write 987.654 + +But heed the warning: [Avoid "naked" `union`s](#Ru-naked) + +##### Example + + // Short-string optimization + + constexpr size_t buffer_size = 16; // Slightly larger than the size of a pointer + + class Immutable_string { + public: + Immutable_string(const char* str) : + size(strlen(str)) + { + if (size < buffer_size) + strcpy_s(string_buffer, buffer_size, str); + else { + string_ptr = new char[size + 1]; + strcpy_s(string_ptr, size + 1, str); + } + } + + ~Immutable_string() + { + if (size >= buffer_size) + delete[] string_ptr; + } + + const char* get_str() const + { + return (size < buffer_size) ? string_buffer : string_ptr; + } + + private: + // If the string is short enough, we store the string itself + // instead of a pointer to the string. + union { + char* string_ptr; + char string_buffer[buffer_size]; + }; + + const size_t size; + }; + +##### Enforcement + +??? + +### C.181: Avoid "naked" `union`s + +##### Reason + +A *naked union* is a union without an associated indicator which member (if any) it holds, +so that the programmer has to keep track. +Naked unions are a source of type errors. + +##### Example, bad + + union Value { + int x; + double d; + }; + + Value v; + v.d = 987.654; // v holds a double + +So far, so good, but we can easily misuse the `union`: + + cout << v.x << '\n'; // BAD, undefined behavior: v holds a double, but we read it as an int + +Note that the type error happened without any explicit cast. +When we tested that program the last value printed was `1683627180` which is the integer value for the bit pattern for `987.654`. +What we have here is an "invisible" type error that happens to give a result that could easily look innocent. + +And, talking about "invisible", this code produced no output: + + v.x = 123; + cout << v.d << '\n'; // BAD: undefined behavior + +##### Alternative + +Wrap a `union` in a class together with a type field. + +The C++17 `variant` type (found in ``) does that for you: + + variant v; + v = 123; // v holds an int + int x = get(v); + v = 123.456; // v holds a double + double w = get(v); + +##### Enforcement + +??? + +### C.182: Use anonymous `union`s to implement tagged unions + +##### Reason + +A well-designed tagged union is type safe. +An *anonymous* union simplifies the definition of a class with a (tag, union) pair. + +##### Example + +This example is mostly borrowed from TC++PL4 pp216-218. +You can look there for an explanation. + +The code is somewhat elaborate. +Handling a type with user-defined assignment and destructor is tricky. +Saving programmers from having to write such code is one reason for including `variant` in the standard. + + class Value { // two alternative representations represented as a union + private: + enum class Tag { number, text }; + Tag type; // discriminant + + union { // representation (note: anonymous union) + int i; + string s; // string has default constructor, copy operations, and destructor + }; + public: + struct Bad_entry { }; // used for exceptions + + ~Value(); + Value& operator=(const Value&); // necessary because of the string variant + Value(const Value&); + // ... + int number() const; + string text() const; + + void set_number(int n); + void set_text(const string&); + // ... + }; + + int Value::number() const + { + if (type != Tag::number) throw Bad_entry{}; + return i; + } + + string Value::text() const + { + if (type != Tag::text) throw Bad_entry{}; + return s; + } + + void Value::set_number(int n) + { + if (type == Tag::text) { + s.~string(); // explicitly destroy string + type = Tag::number; + } + i = n; + } + + void Value::set_text(const string& ss) + { + if (type == Tag::text) + s = ss; + else { + new(&s) string{ss}; // placement new: explicitly construct string + type = Tag::text; + } + } + + Value& Value::operator=(const Value& e) // necessary because of the string variant + { + if (type == Tag::text && e.type == Tag::text) { + s = e.s; // usual string assignment + return *this; + } + + if (type == Tag::text) s.~string(); // explicit destroy + + switch (e.type) { + case Tag::number: + i = e.i; + break; + case Tag::text: + new(&s) string(e.s); // placement new: explicit construct + } + + type = e.type; + return *this; + } + + Value::~Value() + { + if (type == Tag::text) s.~string(); // explicit destroy + } + +##### Enforcement + +??? + +### C.183: Don't use a `union` for type punning + +##### Reason + +It is undefined behavior to read a `union` member with a different type from the one with which it was written. +Such punning is invisible, or at least harder to spot than using a named cast. +Type punning using a `union` is a source of errors. + +##### Example, bad + + union Pun { + int x; + unsigned char c[sizeof(int)]; + }; + +The idea of `Pun` is to be able to look at the character representation of an `int`. + + void bad(Pun& u) + { + u.x = 'x'; + cout << u.c[0] << '\n'; // undefined behavior + } + +If you wanted to see the bytes of an `int`, use a (named) cast: + + void if_you_must_pun(int& x) + { + auto p = reinterpret_cast(&x); + cout << to_integer(p[0]) << '\n'; // OK; better + // ... + } + +Accessing the result of a `reinterpret_cast` from the object's declared type to `char*`, `unsigned char*`, or `std::byte*` is defined behavior. (Using `reinterpret_cast` is discouraged, +but at least we can see that something tricky is going on.) + +##### Note + +Unfortunately, `union`s are commonly used for type punning. +We don't consider "sometimes, it works as expected" a conclusive argument. + +C++17 introduced a distinct type `std::byte` to facilitate operations on raw object representation. Use that type instead of `unsigned char` or `char` for these operations. + +##### Enforcement + +??? + + + +# Enum: Enumerations + +Enumerations are used to define sets of integer values and for defining types for such sets of values. +There are two kinds of enumerations, "plain" `enum`s and `class enum`s. + +Enumeration rule summary: + +* [Enum.1: Prefer enumerations over macros](#Renum-macro) +* [Enum.2: Use enumerations to represent sets of related named constants](#Renum-set) +* [Enum.3: Prefer `enum class`es over "plain" `enum`s](#Renum-class) +* [Enum.4: Define operations on enumerations for safe and simple use](#Renum-oper) +* [Enum.5: Don't use `ALL_CAPS` for enumerators](#Renum-caps) +* [Enum.6: Avoid unnamed enumerations](#Renum-unnamed) +* [Enum.7: Specify the underlying type of an enumeration only when necessary](#Renum-underlying) +* [Enum.8: Specify enumerator values only when necessary](#Renum-value) + +### Enum.1: Prefer enumerations over macros + +##### Reason + +Macros do not obey scope and type rules. Also, macro names are removed during preprocessing and so usually don't appear in tools like debuggers. + +##### Example + +First some bad old code: + + // webcolors.h (third party header) + #define RED 0xFF0000 + #define GREEN 0x00FF00 + #define BLUE 0x0000FF + + // productinfo.h + // The following define product subtypes based on color + #define RED 0 + #define PURPLE 1 + #define BLUE 2 + + int webby = BLUE; // webby == 2; probably not what was desired + +Instead use an `enum`: + + enum class Web_color { red = 0xFF0000, green = 0x00FF00, blue = 0x0000FF }; + enum class Product_info { red = 0, purple = 1, blue = 2 }; + + int webby = blue; // error: be specific + Web_color webby = Web_color::blue; + +We used an `enum class` to avoid name clashes. + +##### Note + +Also consider `constexpr` and `const inline` variables. + +##### Enforcement + +Flag macros that define integer values. Use `enum` or `const inline` or another non-macro alternative instead. + + +### Enum.2: Use enumerations to represent sets of related named constants + +##### Reason + +An enumeration shows the enumerators to be related and can be a named type. + + + +##### Example + + enum class Web_color { red = 0xFF0000, green = 0x00FF00, blue = 0x0000FF }; + + +##### Note + +Switching on an enumeration is common and the compiler can warn against unusual patterns of case labels. For example: + + enum class Product_info { red = 0, purple = 1, blue = 2 }; + + void print(Product_info inf) + { + switch (inf) { + case Product_info::red: cout << "red"; break; + case Product_info::purple: cout << "purple"; break; + } + } + +Such off-by-one `switch`-statements are often the results of an added enumerator and insufficient testing. + +##### Enforcement + +* Flag `switch`-statements where the `case`s cover most but not all enumerators of an enumeration. +* Flag `switch`-statements where the `case`s cover a few enumerators of an enumeration, but there is no `default`. + + +### Enum.3: Prefer class enums over "plain" enums + +##### Reason + +To minimize surprises: traditional enums convert to int too readily. + +##### Example + + void Print_color(int color); + + enum Web_color { red = 0xFF0000, green = 0x00FF00, blue = 0x0000FF }; + enum Product_info { red = 0, purple = 1, blue = 2 }; + + Web_color webby = Web_color::blue; + + // Clearly at least one of these calls is buggy. + Print_color(webby); + Print_color(Product_info::blue); + +Instead use an `enum class`: + + void Print_color(int color); + + enum class Web_color { red = 0xFF0000, green = 0x00FF00, blue = 0x0000FF }; + enum class Product_info { red = 0, purple = 1, blue = 2 }; + + Web_color webby = Web_color::blue; + Print_color(webby); // Error: cannot convert Web_color to int. + Print_color(Product_info::red); // Error: cannot convert Product_info to int. + +##### Enforcement + +(Simple) Warn on any non-class `enum` definition. + +### Enum.4: Define operations on enumerations for safe and simple use + +##### Reason + +Convenience of use and avoidance of errors. + +##### Example + + enum class Day { mon, tue, wed, thu, fri, sat, sun }; + + Day& operator++(Day& d) + { + return d = (d == Day::sun) ? Day::mon : static_cast(static_cast(d)+1); + } + + Day today = Day::sat; + Day tomorrow = ++today; + +The use of a `static_cast` is not pretty, but + + Day& operator++(Day& d) + { + return d = (d == Day::sun) ? Day::mon : Day{++d}; // error + } + +is an infinite recursion, and writing it without a cast, using a `switch` on all cases is long-winded. + + +##### Enforcement + +Flag repeated expressions cast back into an enumeration. + + +### Enum.5: Don't use `ALL_CAPS` for enumerators + +##### Reason + +Avoid clashes with macros. + +##### Example, bad + + // webcolors.h (third party header) + #define RED 0xFF0000 + #define GREEN 0x00FF00 + #define BLUE 0x0000FF + + // productinfo.h + // The following define product subtypes based on color + + enum class Product_info { RED, PURPLE, BLUE }; // syntax error + +##### Enforcement + +Flag ALL_CAPS enumerators. + +### Enum.6: Avoid unnamed enumerations + +##### Reason + +If you can't name an enumeration, the values are not related + +##### Example, bad + + enum { red = 0xFF0000, scale = 4, is_signed = 1 }; + +Such code is not uncommon in code written before there were convenient alternative ways of specifying integer constants. + +##### Alternative + +Use `constexpr` values instead. For example: + + constexpr int red = 0xFF0000; + constexpr short scale = 4; + constexpr bool is_signed = true; + +##### Enforcement + +Flag unnamed enumerations. + + +### Enum.7: Specify the underlying type of an enumeration only when necessary + +##### Reason + +The default is the easiest to read and write. +`int` is the default integer type. +`int` is compatible with C `enum`s. + +##### Example + + enum class Direction : char { n, s, e, w, + ne, nw, se, sw }; // underlying type saves space + + enum class Web_color : int32_t { red = 0xFF0000, + green = 0x00FF00, + blue = 0x0000FF }; // underlying type is redundant + +##### Note + +Specifying the underlying type is necessary to forward-declare an enum or enum class: + + enum Flags : char; + + void f(Flags); + + // .... + + enum Flags : char { /* ... */ }; + +or to ensure that values of that type have a specified bit-precision: + + enum Bitboard : uint64_t { /* ... */ }; + +##### Enforcement + +???? + + +### Enum.8: Specify enumerator values only when necessary + +##### Reason + +It's the simplest. +It avoids duplicate enumerator values. +The default gives a consecutive set of values that is good for `switch`-statement implementations. + +##### Example + + enum class Col1 { red, yellow, blue }; + enum class Col2 { red = 1, yellow = 2, blue = 2 }; // typo + enum class Month { jan = 1, feb, mar, apr, may, jun, + jul, august, sep, oct, nov, dec }; // starting with 1 is conventional + enum class Base_flag { dec = 1, oct = dec << 1, hex = dec << 2 }; // set of bits + +Specifying values is necessary to match conventional values (e.g., `Month`) +and where consecutive values are undesirable (e.g., to get separate bits as in `Base_flag`). + +##### Enforcement + +* Flag duplicate enumerator values +* Flag explicitly specified all-consecutive enumerator values + + +# R: Resource management + +This section contains rules related to resources. +A resource is anything that must be acquired and (explicitly or implicitly) released, such as memory, file handles, sockets, and locks. +The reason it must be released is typically that it can be in short supply, so even delayed release might do harm. +The fundamental aim is to ensure that we don't leak any resources and that we don't hold a resource longer than we need to. +An entity that is responsible for releasing a resource is called an owner. + +There are a few cases where leaks can be acceptable or even optimal: +If you are writing a program that simply produces an output based on an input and the amount of memory needed is proportional to the size of the input, the optimal strategy (for performance and ease of programming) is sometimes simply never to delete anything. +If you have enough memory to handle your largest input, leak away, but be sure to give a good error message if you are wrong. +Here, we ignore such cases. + +* Resource management rule summary: + + * [R.1: Manage resources automatically using resource handles and RAII (Resource Acquisition Is Initialization)](#Rr-raii) + * [R.2: In interfaces, use raw pointers to denote individual objects (only)](#Rr-use-ptr) + * [R.3: A raw pointer (a `T*`) is non-owning](#Rr-ptr) + * [R.4: A raw reference (a `T&`) is non-owning](#Rr-ref) + * [R.5: Prefer scoped objects, don't heap-allocate unnecessarily](#Rr-scoped) + * [R.6: Avoid non-`const` global variables](#Rr-global) + +* Allocation and deallocation rule summary: + + * [R.10: Avoid `malloc()` and `free()`](#Rr-mallocfree) + * [R.11: Avoid calling `new` and `delete` explicitly](#Rr-newdelete) + * [R.12: Immediately give the result of an explicit resource allocation to a manager object](#Rr-immediate-alloc) + * [R.13: Perform at most one explicit resource allocation in a single expression statement](#Rr-single-alloc) + * [R.14: Avoid `[]` parameters, prefer `span`](#Rr-ap) + * [R.15: Always overload matched allocation/deallocation pairs](#Rr-pair) + +* Smart pointer rule summary: + + * [R.20: Use `unique_ptr` or `shared_ptr` to represent ownership](#Rr-owner) + * [R.21: Prefer `unique_ptr` over `shared_ptr` unless you need to share ownership](#Rr-unique) + * [R.22: Use `make_shared()` to make `shared_ptr`s](#Rr-make_shared) + * [R.23: Use `make_unique()` to make `unique_ptr`s](#Rr-make_unique) + * [R.24: Use `std::weak_ptr` to break cycles of `shared_ptr`s](#Rr-weak_ptr) + * [R.30: Take smart pointers as parameters only to explicitly express lifetime semantics](#Rr-smartptrparam) + * [R.31: If you have non-`std` smart pointers, follow the basic pattern from `std`](#Rr-smart) + * [R.32: Take a `unique_ptr` parameter to express that a function assumes ownership of a `widget`](#Rr-uniqueptrparam) + * [R.33: Take a `unique_ptr&` parameter to express that a function reseats the `widget`](#Rr-reseat) + * [R.34: Take a `shared_ptr` parameter to express shared ownership](#Rr-sharedptrparam-owner) + * [R.35: Take a `shared_ptr&` parameter to express that a function might reseat the shared pointer](#Rr-sharedptrparam) + * [R.36: Take a `const shared_ptr&` parameter to express that it might retain a reference count to the object ???](#Rr-sharedptrparam-const) + * [R.37: Do not pass a pointer or reference obtained from an aliased smart pointer](#Rr-smartptrget) + +### R.1: Manage resources automatically using resource handles and RAII (Resource Acquisition Is Initialization) + +##### Reason + +To avoid leaks and the complexity of manual resource management. +C++'s language-enforced constructor/destructor symmetry mirrors the symmetry inherent in resource acquire/release function pairs such as `fopen`/`fclose`, `lock`/`unlock`, and `new`/`delete`. +Whenever you deal with a resource that needs paired acquire/release function calls, encapsulate that resource in an object that enforces pairing for you -- acquire the resource in its constructor, and release it in its destructor. + +##### Example, bad + +Consider: + + void send(X* x, string_view destination) + { + auto port = open_port(destination); + my_mutex.lock(); + // ... + send(port, x); + // ... + my_mutex.unlock(); + close_port(port); + delete x; + } + +In this code, you have to remember to `unlock`, `close_port`, and `delete` on all paths, and do each exactly once. +Further, if any of the code marked `...` throws an exception, then `x` is leaked and `my_mutex` remains locked. + +##### Example + +Consider: + + void send(unique_ptr x, string_view destination) // x owns the X + { + Port port{destination}; // port owns the PortHandle + lock_guard guard{my_mutex}; // guard owns the lock + // ... + send(port, x); + // ... + } // automatically unlocks my_mutex and deletes the pointer in x + +Now all resource cleanup is automatic, performed once on all paths whether or not there is an exception. As a bonus, the function now advertises that it takes over ownership of the pointer. + +What is `Port`? A handy wrapper that encapsulates the resource: + + class Port { + PortHandle port; + public: + Port(string_view destination) : port{open_port(destination)} { } + ~Port() { close_port(port); } + operator PortHandle() { return port; } + + // port handles can't usually be cloned, so disable copying and assignment if necessary + Port(const Port&) = delete; + Port& operator=(const Port&) = delete; + }; + +##### Note + +Where a resource is "ill-behaved" in that it isn't represented as a class with a destructor, wrap it in a class or use [`finally`](#Re-finally) + +**See also**: [RAII](#Re-raii) + +### R.2: In interfaces, use raw pointers to denote individual objects (only) + +##### Reason + +Arrays are best represented by a container type (e.g., `vector` (owning)) or a `span` (non-owning). +Such containers and views hold sufficient information to do range checking. + +##### Example, bad + + void f(int* p, int n) // n is the number of elements in p[] + { + // ... + p[2] = 7; // bad: subscript raw pointer + // ... + } + +The compiler does not read comments, and without reading other code you do not know whether `p` really points to `n` elements. +Use a `span` instead. + +##### Example + + void g(int* p, int fmt) // print *p using format #fmt + { + // ... uses *p and p[0] only ... + } + +##### Exception + +C-style strings are passed as single pointers to a zero-terminated sequence of characters. +Use `zstring` rather than `char*` to indicate that you rely on that convention. + +##### Note + +Many current uses of pointers to a single element could be references. +However, where `nullptr` is a possible value, a reference might not be a reasonable alternative. + +##### Enforcement + +* Flag pointer arithmetic (including `++`) on a pointer that is not part of a container, view, or iterator. + This rule would generate a huge number of false positives if applied to an older code base. +* Flag array names passed as simple pointers + +### R.3: A raw pointer (a `T*`) is non-owning + +##### Reason + +There is nothing (in the C++ standard or in most code) to say otherwise and most raw pointers are non-owning. +We want owning pointers identified so that we can reliably and efficiently delete the objects pointed to by owning pointers. + +##### Example + + void f() + { + int* p1 = new int{7}; // bad: raw owning pointer + auto p2 = make_unique(7); // OK: the int is owned by a unique pointer + // ... + } + +The `unique_ptr` protects against leaks by guaranteeing the deletion of its object (even in the presence of exceptions). The `T*` does not. + +##### Example + + template + class X { + public: + T* p; // bad: it is unclear whether p is owning or not + T* q; // bad: it is unclear whether q is owning or not + // ... + }; + +We can fix that problem by making ownership explicit: + + template + class X2 { + public: + owner p; // OK: p is owning + T* q; // OK: q is not owning + // ... + }; + +##### Exception + +A major class of exception is legacy code, especially code that must remain compilable as C or interface with C and C-style C++ through ABIs. +The fact that there are billions of lines of code that violate this rule against owning `T*`s cannot be ignored. +We'd love to see program transformation tools turning 20-year-old "legacy" code into shiny modern code, +we encourage the development, deployment and use of such tools, +we hope the guidelines will help the development of such tools, +and we even contributed (and contribute) to the research and development in this area. +However, it will take time: "legacy code" is generated faster than we can renovate old code, and so it will be for a few years. + +This code cannot all be rewritten (even assuming good code transformation software), especially not soon. +This problem cannot be solved (at scale) by transforming all owning pointers to `unique_ptr`s and `shared_ptr`s, +partly because we need/use owning "raw pointers" as well as simple pointers in the implementation of our fundamental resource handles. +For example, common `vector` implementations have one owning pointer and two non-owning pointers. +Many ABIs (and essentially all interfaces to C code) use `T*`s, some of them owning. +Some interfaces cannot be simply annotated with `owner` because they need to remain compilable as C +(although this would be a rare good use for a macro, that expands to `owner` in C++ mode only). + +##### Note + +`owner` has no default semantics beyond `T*`. It can be used without changing any code using it and without affecting ABIs. +It is simply an indicator to programmers and analysis tools. +For example, if an `owner` is a member of a class, that class better have a destructor that `delete`s it. + +##### Example, bad + +Returning a (raw) pointer imposes a lifetime management uncertainty on the caller; that is, who deletes the pointed-to object? + + Gadget* make_gadget(int n) + { + auto p = new Gadget{n}; + // ... + return p; + } + + void caller(int n) + { + auto p = make_gadget(n); // remember to delete p + // ... + delete p; + } + +In addition to suffering from the problem of [leak](#Rp-leak), this adds a spurious allocation and deallocation operation, and is needlessly verbose. If Gadget is cheap to move out of a function (i.e., is small or has an efficient move operation), just return it "by value" (see ["out" return values](#Rf-out)): + + Gadget make_gadget(int n) + { + Gadget g{n}; + // ... + return g; + } + +##### Note + +This rule applies to factory functions. + +##### Note + +If pointer semantics are required (e.g., because the return type needs to refer to a base class of a class hierarchy (an interface)), return a "smart pointer." + +##### Enforcement + +* (Simple) Warn on `delete` of a raw pointer that is not an `owner`. +* (Moderate) Warn on failure to either `reset` or explicitly `delete` an `owner` pointer on every code path. +* (Simple) Warn if the return value of `new` is assigned to a raw pointer. +* (Simple) Warn if a function returns an object that was allocated within the function but has a move constructor. + Suggest considering returning it by value instead. + +### R.4: A raw reference (a `T&`) is non-owning + +##### Reason + +There is nothing (in the C++ standard or in most code) to say otherwise and most raw references are non-owning. +We want owners identified so that we can reliably and efficiently delete the objects pointed to by owning pointers. + +##### Example + + void f() + { + int& r = *new int{7}; // bad: raw owning reference + // ... + delete &r; // bad: violated the rule against deleting raw pointers + } + +**See also**: [The raw pointer rule](#Rr-ptr) + +##### Enforcement + +See [the raw pointer rule](#Rr-ptr) + +### R.5: Prefer scoped objects, don't heap-allocate unnecessarily + +##### Reason + +A scoped object is a local object, a global object, or a member. +This implies that there is no separate allocation and deallocation cost in excess of that already used for the containing scope or object. +The members of a scoped object are themselves scoped and the scoped object's constructor and destructor manage the members' lifetimes. + +##### Example + +The following example is inefficient (because it has unnecessary allocation and deallocation), vulnerable to exception throws and returns in the `...` part (leading to leaks), and verbose: + + void f(int n) + { + auto p = new Gadget{n}; + // ... + delete p; + } + +Instead, use a local variable: + + void f(int n) + { + Gadget g{n}; + // ... + } + +##### Enforcement + +* (Moderate) Warn if an object is allocated and then deallocated on all paths within a function. Suggest it should be a local stack object instead. +* (Simple) Warn if a local `Unique_pointer` or `Shared_pointer` that is not moved, copied, reassigned or `reset` before its lifetime ends is not declared `const`. +Exception: Do not produce such a warning on a local `Unique_pointer` to an unbounded array. (See below.) + +##### Exception + +If your stack space is limited, it is OK to create a local `const unique_ptr` to store the object on the heap instead of the stack. + +### R.6: Avoid non-`const` global variables + +See [I.2](#Ri-global) + +## R.alloc: Allocation and deallocation + +### R.10: Avoid `malloc()` and `free()` + +##### Reason + + `malloc()` and `free()` do not support construction and destruction, and do not mix well with `new` and `delete`. + +##### Example + + class Record { + int id; + string name; + // ... + }; + + void use() + { + // p1 might be nullptr + // *p1 is not initialized; in particular, + // that string isn't a string, but a string-sized bag of bits + Record* p1 = static_cast(malloc(sizeof(Record))); + + auto p2 = new Record; + + // unless an exception is thrown, *p2 is default initialized + auto p3 = new(nothrow) Record; + // p3 might be nullptr; if not, *p3 is default initialized + + // ... + + delete p1; // error: cannot delete object allocated by malloc() + free(p2); // error: cannot free() object allocated by new + } + +In some implementations that `delete` and that `free()` might work, or maybe they will cause run-time errors. + +##### Exception + +There are applications and sections of code where exceptions are not acceptable. +Some of the best such examples are in life-critical hard-real-time code. +Beware that many bans on exception use are based on superstition (bad) +or by concerns for older code bases with unsystematic resource management (unfortunately, but sometimes necessary). +In such cases, consider the `nothrow` versions of `new`. + +##### Enforcement + +Flag explicit use of `malloc` and `free`. + +### R.11: Avoid calling `new` and `delete` explicitly + +##### Reason + +The pointer returned by `new` should belong to a resource handle (that can call `delete`). +If the pointer returned by `new` is assigned to a plain/naked pointer, the object can be leaked. + +##### Note + +In a large program, a naked `delete` (that is a `delete` in application code, rather than part of code devoted to resource management) +is a likely bug: if you have N `delete`s, how can you be certain that you don't need N+1 or N-1? +The bug might be latent: it might emerge only during maintenance. +If you have a naked `new`, you probably need a naked `delete` somewhere, so you probably have a bug. + +##### Enforcement + +(Simple) Warn on any explicit use of `new` and `delete`. Suggest using `make_unique` instead. + +### R.12: Immediately give the result of an explicit resource allocation to a manager object + +##### Reason + +If you don't, an exception or a return might lead to a leak. + +##### Example, bad + + void func(const string& name) + { + FILE* f = fopen(name, "r"); // open the file + vector buf(1024); + auto _ = finally([f] { fclose(f); }); // remember to close the file + // ... + } + +The allocation of `buf` might fail and leak the file handle. + +##### Example + + void func(const string& name) + { + ifstream f{name}; // open the file + vector buf(1024); + // ... + } + +The use of the file handle (in `ifstream`) is simple, efficient, and safe. + +##### Enforcement + +* Flag explicit allocations used to initialize pointers (problem: how many direct resource allocations can we recognize?) + +### R.13: Perform at most one explicit resource allocation in a single expression statement + +##### Reason + +If you perform two explicit resource allocations in one statement, you could leak resources because the order of evaluation of many subexpressions, including function arguments, is unspecified. + +##### Example + + void fun(shared_ptr sp1, shared_ptr sp2); + +This `fun` can be called like this: + + // BAD: potential leak + fun(shared_ptr(new Widget(a, b)), shared_ptr(new Widget(c, d))); + +This is exception-unsafe because the compiler might reorder the two expressions building the function's two arguments. +In particular, the compiler can interleave execution of the two expressions: +Memory allocation (by calling `operator new`) could be done first for both objects, followed by attempts to call the two `Widget` constructors. +If one of the constructor calls throws an exception, then the other object's memory will never be released! + +This subtle problem has a simple solution: Never perform more than one explicit resource allocation in a single expression statement. +For example: + + shared_ptr sp1(new Widget(a, b)); // Better, but messy + fun(sp1, new Widget(c, d)); + +The best solution is to avoid explicit allocation entirely use factory functions that return owning objects: + + fun(make_shared(a, b), make_shared(c, d)); // Best + +Write your own factory wrapper if there is not one already. + +##### Enforcement + +* Flag expressions with multiple explicit resource allocations (problem: how many direct resource allocations can we recognize?) + +### R.14: Avoid `[]` parameters, prefer `span` + +##### Reason + +An array decays to a pointer, thereby losing its size, opening the opportunity for range errors. +Use `span` to preserve size information. + +##### Example + + void f(int[]); // not recommended + + void f(int*); // not recommended for multiple objects + // (a pointer should point to a single object, do not subscript) + + void f(gsl::span); // good, recommended + +##### Enforcement + +Flag `[]` parameters. Use `span` instead. + +### R.15: Always overload matched allocation/deallocation pairs + +##### Reason + +Otherwise you get mismatched operations and chaos. + +##### Example + + class X { + // ... + void* operator new(size_t s); + void operator delete(void*); + // ... + }; + +##### Note + +If you want memory that cannot be deallocated, `=delete` the deallocation operation. +Don't leave it undeclared. + +##### Enforcement + +Flag incomplete pairs. + +## R.smart: Smart pointers + +### R.20: Use `unique_ptr` or `shared_ptr` to represent ownership + +##### Reason + +They can prevent resource leaks. + +##### Example + +Consider: + + void f() + { + X* p1 { new X }; // bad, p1 will leak + auto p2 = make_unique(); // good, unique ownership + auto p3 = make_shared(); // good, shared ownership + } + +This will leak the object used to initialize `p1` (only). + +##### Enforcement + +* (Simple) Warn if the return value of `new` is assigned to a raw pointer. +* (Simple) Warn if the result of a function returning a raw owning pointer is assigned to a raw pointer. + +### R.21: Prefer `unique_ptr` over `shared_ptr` unless you need to share ownership + +##### Reason + +A `unique_ptr` is conceptually simpler and more predictable (you know when destruction happens) and faster (you don't implicitly maintain a use count). + +##### Example, bad + +This needlessly adds and maintains a reference count. + + void f() + { + shared_ptr base = make_shared(); + // use base locally, without copying it -- refcount never exceeds 1 + } // destroy base + +##### Example + +This is more efficient: + + void f() + { + unique_ptr base = make_unique(); + // use base locally + } // destroy base + +##### Enforcement + +(Simple) Warn if a function uses a `Shared_pointer` with an object allocated within the function, but never returns the `Shared_pointer` or passes it to a function requiring a `Shared_pointer`. Suggest using `unique_ptr` instead. + +### R.22: Use `make_shared()` to make `shared_ptr`s + +##### Reason + +`make_shared` gives a more concise statement of the construction. +It also gives an opportunity to eliminate a separate allocation for the reference counts, by placing the `shared_ptr`'s use counts next to its object. +It also ensures exception safety in complex expressions (in pre-C++17 code). + +##### Example + +Consider: + + shared_ptr p1 { new X{2} }; // bad + auto p = make_shared(2); // good + +The `make_shared()` version mentions `X` only once, so it is usually shorter (as well as faster) than the version with the explicit `new`. + +##### Enforcement + +(Simple) Warn if a `shared_ptr` is constructed from the result of `new` rather than `make_shared`. + +### R.23: Use `make_unique()` to make `unique_ptr`s + +##### Reason + +`make_unique` gives a more concise statement of the construction. +It also ensures exception safety in complex expressions (in pre-C++17 code). + +##### Example + + unique_ptr p {new Foo{7}}; // OK: but repetitive + + auto q = make_unique(7); // Better: no repetition of Foo + +##### Enforcement + +(Simple) Warn if a `unique_ptr` is constructed from the result of `new` rather than `make_unique`. + +### R.24: Use `std::weak_ptr` to break cycles of `shared_ptr`s + +##### Reason + + `shared_ptr`'s rely on use counting and the use count for a cyclic structure never goes to zero, so we need a mechanism to +be able to destroy a cyclic structure. + +##### Example + + #include + + class bar; + + class foo { + public: + explicit foo(const std::shared_ptr& forward_reference) + : forward_reference_(forward_reference) + { } + private: + std::shared_ptr forward_reference_; + }; + + class bar { + public: + explicit bar(const std::weak_ptr& back_reference) + : back_reference_(back_reference) + { } + void do_something() + { + if (auto shared_back_reference = back_reference_.lock()) { + // Use *shared_back_reference + } + } + private: + std::weak_ptr back_reference_; + }; + +##### Note + + ??? (HS: A lot of people say "to break cycles", while I think "temporary shared ownership" is more to the point.) +???(BS: breaking cycles is what you must do; temporarily sharing ownership is how you do it. +You could "temporarily share ownership" simply by using another `shared_ptr`.) + +##### Enforcement + +??? probably impossible. If we could statically detect cycles, we wouldn't need `weak_ptr` + +### R.30: Take smart pointers as parameters only to explicitly express lifetime semantics + +See [F.7](#Rf-smart). + +### R.31: If you have non-`std` smart pointers, follow the basic pattern from `std` + +##### Reason + +The rules in the following section also work for other kinds of third-party and custom smart pointers and are very useful for diagnosing common smart pointer errors that cause performance and correctness problems. +You want the rules to work on all the smart pointers you use. + +Any type (including primary template or specialization) that overloads unary `*` and `->` is considered a smart pointer: + +* If it is copyable, it is recognized as a reference-counted `shared_ptr`. +* If it is not copyable, it is recognized as a unique `unique_ptr`. + +##### Example, bad + + // use Boost's intrusive_ptr + #include + void f(boost::intrusive_ptr p) // error under rule 'sharedptrparam' + { + p->foo(); + } + + // use Microsoft's CComPtr + #include + void f(CComPtr p) // error under rule 'sharedptrparam' + { + p->foo(); + } + +Both cases are an error under the [`sharedptrparam` guideline](#Rr-smartptrparam): +`p` is a `Shared_pointer`, but nothing about its sharedness is used here and passing it by value is a silent pessimization; +these functions should accept a smart pointer only if they need to participate in the widget's lifetime management. Otherwise they should accept a `widget*`, if it can be `nullptr`. Otherwise, and ideally, the function should accept a `widget&`. +These smart pointers match the `Shared_pointer` concept, so these guideline enforcement rules work on them out of the box and expose this common pessimization. + +### R.32: Take a `unique_ptr` parameter to express that a function assumes ownership of a `widget` + +##### Reason + +Using `unique_ptr` in this way both documents and enforces the function call's ownership transfer. + +##### Example + + void sink(unique_ptr); // takes ownership of the widget + + void uses(widget*); // just uses the widget + +##### Enforcement + +* (Simple) Warn if a function takes a `Unique_pointer` parameter by lvalue reference and does not either assign to it or call `reset()` on it on at least one code path. Suggest taking a `T*` or `T&` instead. + +### R.33: Take a `unique_ptr&` parameter to express that a function reseats the `widget` + +##### Reason + +Using `unique_ptr` in this way both documents and enforces the function call's reseating semantics. + +##### Note + +"reseat" means "making a pointer or a smart pointer refer to a different object." + +##### Example + + void reseat(unique_ptr&); // "will" or "might" reseat pointer + +##### Enforcement + +* (Simple) Warn if a function takes a `Unique_pointer` parameter by lvalue reference and does not either assign to it or call `reset()` on it on at least one code path. Suggest taking a `T*` or `T&` instead. + +### R.34: Take a `shared_ptr` parameter to express shared ownership + +##### Reason + +This makes the function's ownership sharing explicit. + +##### Example, good + + class WidgetUser + { + public: + // WidgetUser will share ownership of the widget + explicit WidgetUser(std::shared_ptr w) noexcept: + m_widget{std::move(w)} {} + // ... + private: + std::shared_ptr m_widget; + }; + +##### Enforcement + +* (Simple) Warn if a function takes a `Shared_pointer` parameter by lvalue reference and does not either assign to it or call `reset()` on it on at least one code path. Suggest taking a `T*` or `T&` instead. +* (Simple) ((Foundation)) Warn if a function takes a `Shared_pointer` by value or by reference to `const` and does not copy or move it to another `Shared_pointer` on at least one code path. Suggest taking a `T*` or `T&` instead. +* (Simple) ((Foundation)) Warn if a function takes a `Shared_pointer` by rvalue reference. Suggesting taking it by value instead. + +### R.35: Take a `shared_ptr&` parameter to express that a function might reseat the shared pointer + +##### Reason + +This makes the function's reseating explicit. + +##### Note + +"reseat" means "making a reference or a smart pointer refer to a different object." + +##### Example, good + + void ChangeWidget(std::shared_ptr& w) + { + // This will change the callers widget + w = std::make_shared(widget{}); + } + +##### Enforcement + +* (Simple) Warn if a function takes a `Shared_pointer` parameter by lvalue reference and does not either assign to it or call `reset()` on it on at least one code path. Suggest taking a `T*` or `T&` instead. +* (Simple) ((Foundation)) Warn if a function takes a `Shared_pointer` by value or by reference to `const` and does not copy or move it to another `Shared_pointer` on at least one code path. Suggest taking a `T*` or `T&` instead. +* (Simple) ((Foundation)) Warn if a function takes a `Shared_pointer` by rvalue reference. Suggesting taking it by value instead. + +### R.36: Take a `const shared_ptr&` parameter to express that it might retain a reference count to the object ??? + +##### Reason + +This makes the function's ??? explicit. + +##### Example, good + + void share(shared_ptr); // share -- "will" retain refcount + + void reseat(shared_ptr&); // "might" reseat ptr + + void may_share(const shared_ptr&); // "might" retain refcount + +##### Enforcement + +* (Simple) Warn if a function takes a `Shared_pointer` parameter by lvalue reference and does not either assign to it or call `reset()` on it on at least one code path. Suggest taking a `T*` or `T&` instead. +* (Simple) ((Foundation)) Warn if a function takes a `Shared_pointer` by value or by reference to `const` and does not copy or move it to another `Shared_pointer` on at least one code path. Suggest taking a `T*` or `T&` instead. +* (Simple) ((Foundation)) Warn if a function takes a `Shared_pointer` by rvalue reference. Suggesting taking it by value instead. + +### R.37: Do not pass a pointer or reference obtained from an aliased smart pointer + +##### Reason + +Violating this rule is the number one cause of losing reference counts and finding yourself with a dangling pointer. +Functions should prefer to pass raw pointers and references down call chains. +At the top of the call tree where you obtain the raw pointer or reference from a smart pointer that keeps the object alive. +You need to be sure that the smart pointer cannot inadvertently be reset or reassigned from within the call tree below. + +##### Note + +To do this, sometimes you need to take a local copy of a smart pointer, which firmly keeps the object alive for the duration of the function and the call tree. + +##### Example + +Consider this code: + + // global (static or heap), or aliased local ... + shared_ptr g_p = ...; + + void f(widget& w) + { + g(); + use(w); // A + } + + void g() + { + g_p = ...; // oops, if this was the last shared_ptr to that widget, destroys the widget + } + +The following should not pass code review: + + void my_code() + { + // BAD: passing pointer or reference obtained from a non-local smart pointer + // that could be inadvertently reset somewhere inside f or its callees + f(*g_p); + + // BAD: same reason, just passing it as a "this" pointer + g_p->func(); + } + +The fix is simple -- take a local copy of the pointer to "keep a ref count" for your call tree: + + void my_code() + { + // cheap: 1 increment covers this entire function and all the call trees below us + auto pin = g_p; + + // GOOD: passing pointer or reference obtained from a local unaliased smart pointer + f(*pin); + + // GOOD: same reason + pin->func(); + } + +##### Enforcement + +* (Simple) Warn if a pointer or reference obtained from a smart pointer variable (`Unique_pointer` or `Shared_pointer`) that is non-local, or that is local but potentially aliased, is used in a function call. If the smart pointer is a `Shared_pointer` then suggest taking a local copy of the smart pointer and obtain a pointer or reference from that instead. + +# ES: Expressions and statements + +Expressions and statements are the lowest and most direct way of expressing actions and computation. Declarations in local scopes are statements. + +For naming, commenting, and indentation rules, see [NL: Naming and layout](#S-naming). + +General rules: + +* [ES.1: Prefer the standard library to other libraries and to "handcrafted code"](#Res-lib) +* [ES.2: Prefer suitable abstractions to direct use of language features](#Res-abstr) +* [ES.3: Don't repeat yourself, avoid redundant code](#Res-DRY) + +Declaration rules: + +* [ES.5: Keep scopes small](#Res-scope) +* [ES.6: Declare names in for-statement initializers and conditions to limit scope](#Res-cond) +* [ES.7: Keep common and local names short, and keep uncommon and non-local names longer](#Res-name-length) +* [ES.8: Avoid similar-looking names](#Res-name-similar) +* [ES.9: Avoid `ALL_CAPS` names](#Res-not-CAPS) +* [ES.10: Declare one name (only) per declaration](#Res-name-one) +* [ES.11: Use `auto` to avoid redundant repetition of type names](#Res-auto) +* [ES.12: Do not reuse names in nested scopes](#Res-reuse) +* [ES.20: Always initialize an object](#Res-always) +* [ES.21: Don't introduce a variable (or constant) before you need to use it](#Res-introduce) +* [ES.22: Don't declare a variable until you have a value to initialize it with](#Res-init) +* [ES.23: Prefer the `{}`-initializer syntax](#Res-list) +* [ES.24: Use a `unique_ptr` to hold pointers](#Res-unique) +* [ES.25: Declare an object `const` or `constexpr` unless you want to modify its value later on](#Res-const) +* [ES.26: Don't use a variable for two unrelated purposes](#Res-recycle) +* [ES.27: Use `std::array` or `stack_array` for arrays on the stack](#Res-stack) +* [ES.28: Use lambdas for complex initialization, especially of `const` variables](#Res-lambda-init) +* [ES.30: Don't use macros for program text manipulation](#Res-macros) +* [ES.31: Don't use macros for constants or "functions"](#Res-macros2) +* [ES.32: Use `ALL_CAPS` for all macro names](#Res-ALL_CAPS) +* [ES.33: If you must use macros, give them unique names](#Res-MACROS) +* [ES.34: Don't define a (C-style) variadic function](#Res-ellipses) + +Expression rules: + +* [ES.40: Avoid complicated expressions](#Res-complicated) +* [ES.41: If in doubt about operator precedence, parenthesize](#Res-parens) +* [ES.42: Keep use of pointers simple and straightforward](#Res-ptr) +* [ES.43: Avoid expressions with undefined order of evaluation](#Res-order) +* [ES.44: Don't depend on order of evaluation of function arguments](#Res-order-fct) +* [ES.45: Avoid "magic constants"; use symbolic constants](#Res-magic) +* [ES.46: Avoid narrowing conversions](#Res-narrowing) +* [ES.47: Use `nullptr` rather than `0` or `NULL`](#Res-nullptr) +* [ES.48: Avoid casts](#Res-casts) +* [ES.49: If you must use a cast, use a named cast](#Res-casts-named) +* [ES.50: Don't cast away `const`](#Res-casts-const) +* [ES.55: Avoid the need for range checking](#Res-range-checking) +* [ES.56: Write `std::move()` only when you need to explicitly move an object to another scope](#Res-move) +* [ES.60: Avoid `new` and `delete` outside resource management functions](#Res-new) +* [ES.61: Delete arrays using `delete[]` and non-arrays using `delete`](#Res-del) +* [ES.62: Don't compare pointers into different arrays](#Res-arr2) +* [ES.63: Don't slice](#Res-slice) +* [ES.64: Use the `T{e}`notation for construction](#Res-construct) +* [ES.65: Don't dereference an invalid pointer](#Res-deref) + +Statement rules: + +* [ES.70: Prefer a `switch`-statement to an `if`-statement when there is a choice](#Res-switch-if) +* [ES.71: Prefer a range-`for`-statement to a `for`-statement when there is a choice](#Res-for-range) +* [ES.72: Prefer a `for`-statement to a `while`-statement when there is an obvious loop variable](#Res-for-while) +* [ES.73: Prefer a `while`-statement to a `for`-statement when there is no obvious loop variable](#Res-while-for) +* [ES.74: Prefer to declare a loop variable in the initializer part of a `for`-statement](#Res-for-init) +* [ES.75: Avoid `do`-statements](#Res-do) +* [ES.76: Avoid `goto`](#Res-goto) +* [ES.77: Minimize the use of `break` and `continue` in loops](#Res-continue) +* [ES.78: Don't rely on implicit fallthrough in `switch` statements](#Res-break) +* [ES.79: Use `default` to handle common cases (only)](#Res-default) +* [ES.84: Don't try to declare a local variable with no name](#Res-noname) +* [ES.85: Make empty statements visible](#Res-empty) +* [ES.86: Avoid modifying loop control variables inside the body of raw for-loops](#Res-loop-counter) +* [ES.87: Don't add redundant `==` or `!=` to conditions](#Res-if) + +Arithmetic rules: + +* [ES.100: Don't mix signed and unsigned arithmetic](#Res-mix) +* [ES.101: Use unsigned types for bit manipulation](#Res-unsigned) +* [ES.102: Use signed types for arithmetic](#Res-signed) +* [ES.103: Don't overflow](#Res-overflow) +* [ES.104: Don't underflow](#Res-underflow) +* [ES.105: Don't divide by integer zero](#Res-zero) +* [ES.106: Don't try to avoid negative values by using `unsigned`](#Res-nonnegative) +* [ES.107: Don't use `unsigned` for subscripts, prefer `gsl::index`](#Res-subscripts) + +### ES.1: Prefer the standard library to other libraries and to "handcrafted code" + +##### Reason + +Code using a library can be much easier to write than code working directly with language features, much shorter, tend to be of a higher level of abstraction, and the library code is presumably already tested. +The ISO C++ Standard Library is among the most widely known and best tested libraries. +It is available as part of all C++ implementations. + +##### Example + + auto sum = accumulate(begin(a), end(a), 0.0); // good + +a range version of `accumulate` would be even better: + + auto sum = accumulate(v, 0.0); // better + +but don't hand-code a well-known algorithm: + + int max = v.size(); // bad: verbose, purpose unstated + double sum = 0.0; + for (int i = 0; i < max; ++i) + sum = sum + v[i]; + +##### Exception + +Large parts of the standard library rely on dynamic allocation (free store). These parts, notably the containers but not the algorithms, are unsuitable for some hard-real-time and embedded applications. In such cases, consider providing/using similar facilities, e.g., a standard-library-style container implemented using a pool allocator. + +##### Enforcement + +Not easy. ??? Look for messy loops, nested loops, long functions, absence of function calls, lack of use of built-in types. Cyclomatic complexity? + +### ES.2: Prefer suitable abstractions to direct use of language features + +##### Reason + +A "suitable abstraction" (e.g., library or class) is closer to the application concepts than the bare language, leads to shorter and clearer code, and is likely to be better tested. + +##### Example + + vector read1(istream& is) // good + { + vector res; + for (string s; is >> s;) + res.push_back(s); + return res; + } + +The more traditional and lower-level near-equivalent is longer, messier, harder to get right, and most likely slower: + + char** read2(istream& is, int maxelem, int maxstring, int* nread) // bad: verbose and incomplete + { + auto res = new char*[maxelem]; + int elemcount = 0; + while (is && elemcount < maxelem) { + auto s = new char[maxstring]; + is.read(s, maxstring); + res[elemcount++] = s; + } + *nread = elemcount; + return res; + } + +Once the checking for overflow and error handling has been added that code gets quite messy, and there is the problem remembering to `delete` the returned pointer and the C-style strings that array contains. + +##### Enforcement + +Not easy. ??? Look for messy loops, nested loops, long functions, absence of function calls, lack of use of built-in types. Cyclomatic complexity? + +### ES.3: Don't repeat yourself, avoid redundant code + +Duplicated or otherwise redundant code obscures intent, makes it harder to understand the logic, and makes maintenance harder, among other problems. It often arises from cut-and-paste programming. + +Use standard algorithms where appropriate, instead of writing some own implementation. + +**See also**: [SL.1](#Rsl-lib), [ES.11](#Res-auto) + +##### Example + + void func(bool flag) // Bad, duplicated code. + { + if (flag) { + x(); + y(); + } + else { + x(); + z(); + } + } + + void func(bool flag) // Better, no duplicated code. + { + x(); + + if (flag) + y(); + else + z(); + } + + +##### Enforcement + +* Use a static analyzer. It will catch at least some redundant constructs. +* Code review + +## ES.dcl: Declarations + +A declaration is a statement. A declaration introduces a name into a scope and might cause the construction of a named object. + +### ES.5: Keep scopes small + +##### Reason + +Readability. Minimize resource retention. Avoid accidental misuse of value. + +**Alternative formulation**: Don't declare a name in an unnecessarily large scope. + +##### Example + + void use() + { + int i; // bad: i is needlessly accessible after loop + for (i = 0; i < 20; ++i) { /* ... */ } + // no intended use of i here + for (int i = 0; i < 20; ++i) { /* ... */ } // good: i is local to for-loop + + if (auto pc = dynamic_cast(ps)) { // good: pc is local to if-statement + // ... deal with Circle ... + } + else { + // ... handle error ... + } + } + +##### Example, bad + + void use(const string& name) + { + string fn = name + ".txt"; + ifstream is {fn}; + Record r; + is >> r; + // ... 200 lines of code without intended use of fn or is ... + } + +This function is by most measures too long anyway, but the point is that the resources used by `fn` and the file handle held by `is` +are retained for much longer than needed and that unanticipated use of `is` and `fn` could happen later in the function. +In this case, it might be a good idea to factor out the read: + + Record load_record(const string& name) + { + string fn = name + ".txt"; + ifstream is {fn}; + Record r; + is >> r; + return r; + } + + void use(const string& name) + { + Record r = load_record(name); + // ... 200 lines of code ... + } + +##### Enforcement + +* Flag loop variable declared outside a loop and not used after the loop +* Flag when expensive resources, such as file handles and locks are not used for N-lines (for some suitable N) + +### ES.6: Declare names in for-statement initializers and conditions to limit scope + +##### Reason + +Readability. +Limit the loop variable visibility to the scope of the loop. +Avoid using the loop variable for other purposes after the loop. +Minimize resource retention. + +##### Example + + void use() + { + for (string s; cin >> s;) + v.push_back(s); + + for (int i = 0; i < 20; ++i) { // good: i is local to for-loop + // ... + } + + if (auto pc = dynamic_cast(ps)) { // good: pc is local to if-statement + // ... deal with Circle ... + } + else { + // ... handle error ... + } + } + +##### Example, don't + + int j; // BAD: j is visible outside the loop + for (j = 0; j < 100; ++j) { + // ... + } + // j is still visible here and isn't needed + +**See also**: [Don't use a variable for two unrelated purposes](#Res-recycle) + +##### Enforcement + +* Warn when a variable modified inside the `for`-statement is declared outside the loop and not being used outside the loop. +* (hard) Flag loop variables declared before the loop and used after the loop for an unrelated purpose. + +**Discussion**: Scoping the loop variable to the loop body also helps code optimizers greatly. Recognizing that the induction variable +is only accessible in the loop body unblocks optimizations such as hoisting, strength reduction, loop-invariant code motion, etc. + +##### C++17 and C++20 example + +Note: C++17 and C++20 also add `if`, `switch`, and range-`for` initializer statements. These require C++17 and C++20 support. + + map mymap; + + if (auto result = mymap.insert(value); result.second) { + // insert succeeded, and result is valid for this block + use(result.first); // ok + // ... + } // result is destroyed here + +##### C++17 and C++20 enforcement (if using a C++17 or C++20 compiler) + +* Flag selection/loop variables declared before the body and not used after the body +* (hard) Flag selection/loop variables declared before the body and used after the body for an unrelated purpose. + +### ES.7: Keep common and local names short, and keep uncommon and non-local names longer + +##### Reason + +Readability. Lowering the chance of clashes between unrelated non-local names. + +##### Example + +Conventional short, local names increase readability: + + template // good + void print(ostream& os, const vector& v) + { + for (gsl::index i = 0; i < v.size(); ++i) + os << v[i] << '\n'; + } + +An index is conventionally called `i` and there is no hint about the meaning of the vector in this generic function, so `v` is as good name as any. Compare + + template // bad: verbose, hard to read + void print(ostream& target_stream, const vector& current_vector) + { + for (gsl::index current_element_index = 0; + current_element_index < current_vector.size(); + ++current_element_index + ) + target_stream << current_vector[current_element_index] << '\n'; + } + +Yes, it is a caricature, but we have seen worse. + +##### Example + +Unconventional and short non-local names obscure code: + + void use1(const string& s) + { + // ... + tt(s); // bad: what is tt()? + // ... + } + +Better, give non-local entities readable names: + + void use1(const string& s) + { + // ... + trim_tail(s); // better + // ... + } + +Here, there is a chance that the reader knows what `trim_tail` means and that the reader can remember it after looking it up. + +##### Example, bad + +Argument names of large functions are de facto non-local and should be meaningful: + + void complicated_algorithm(vector& vr, const vector& vi, map& out) + // read from events in vr (marking used Records) for the indices in + // vi placing (name, index) pairs into out + { + // ... 500 lines of code using vr, vi, and out ... + } + +We recommend keeping functions short, but that rule isn't universally adhered to and naming should reflect that. + +##### Enforcement + +Check length of local and non-local names. Also take function length into account. + +### ES.8: Avoid similar-looking names + +##### Reason + +Code clarity and readability. Too-similar names slow down comprehension and increase the likelihood of error. + +##### Example, bad + + if (readable(i1 + l1 + ol + o1 + o0 + ol + o1 + I0 + l0)) surprise(); + +##### Example, bad + +Do not declare a non-type with the same name as a type in the same scope. This removes the need to disambiguate with a keyword such as `struct` or `enum`. It also removes a source of errors, as `struct X` can implicitly declare `X` if lookup fails. + + struct foo { int n; }; + struct foo foo(); // BAD, foo is a type already in scope + struct foo x = foo(); // requires disambiguation + +##### Exception + +Antique header files might declare non-types and types with the same name in the same scope. + +##### Enforcement + +* Check names against a list of known confusing letter and digit combinations. +* Flag a declaration of a variable, function, or enumerator that hides a class or enumeration declared in the same scope. + +### ES.9: Avoid `ALL_CAPS` names + +##### Reason + +Such names are commonly used for macros. Thus, `ALL_CAPS` name are vulnerable to unintended macro substitution. + +##### Example + + // somewhere in some header: + #define NE != + + // somewhere else in some other header: + enum Coord { N, NE, NW, S, SE, SW, E, W }; + + // somewhere third in some poor programmer's .cpp: + switch (direction) { + case N: + // ... + case NE: + // ... + // ... + } + +##### Note + +Do not use `ALL_CAPS` for constants just because constants used to be macros. + +##### Enforcement + +Flag all uses of ALL CAPS. For older code, accept ALL CAPS for macro names and flag all non-ALL-CAPS macro names. + +### ES.10: Declare one name (only) per declaration + +##### Reason + +One declaration per line increases readability and avoids mistakes related to +the C/C++ grammar. It also leaves room for a more descriptive end-of-line +comment. + +##### Example, bad + + char *p, c, a[7], *pp[7], **aa[10]; // yuck! + +##### Exception + +A function declaration can contain several function argument declarations. + +##### Exception + +A structured binding (C++17) is specifically designed to introduce several variables: + + auto [iter, inserted] = m.insert_or_assign(k, val); + if (inserted) { /* new entry was inserted */ } + +##### Example + + template + bool any_of(InputIterator first, InputIterator last, Predicate pred); + +or better using concepts: + + bool any_of(input_iterator auto first, input_iterator auto last, predicate auto pred); + +##### Example + + double scalbn(double x, int n); // OK: x * pow(FLT_RADIX, n); FLT_RADIX is usually 2 + +or: + + double scalbn( // better: x * pow(FLT_RADIX, n); FLT_RADIX is usually 2 + double x, // base value + int n // exponent + ); + +or: + + // better: base * pow(FLT_RADIX, exponent); FLT_RADIX is usually 2 + double scalbn(double base, int exponent); + +##### Example + + int a = 10, b = 11, c = 12, d, e = 14, f = 15; + +In a long list of declarators it is easy to overlook an uninitialized variable. + +##### Enforcement + +Flag variable and constant declarations with multiple declarators (e.g., `int* p, q;`) + +### ES.11: Use `auto` to avoid redundant repetition of type names + +##### Reason + +* Simple repetition is tedious and error-prone. +* When you use `auto`, the name of the declared entity is in a fixed position in the declaration, increasing readability. +* In a function template declaration the return type can be a member type. + +##### Example + +Consider: + + auto p = v.begin(); // vector::iterator + auto z1 = v[3]; // makes copy of DataRecord + auto& z2 = v[3]; // avoids copy + const auto& z3 = v[3]; // const and avoids copy + auto h = t.future(); + auto q = make_unique(s); + auto f = [](int x) { return x + 10; }; + +In each case, we save writing a longish, hard-to-remember type that the compiler already knows but a programmer could get wrong. + +##### Example + + template + auto Container::first() -> Iterator; // Container::Iterator + +##### Exception + +Avoid `auto` for initializer lists and in cases where you know exactly which type you want and where an initializer might require conversion. + +##### Example + + auto lst = { 1, 2, 3 }; // lst is an initializer list + auto x{1}; // x is an int (in C++17; initializer_list in C++11) + +##### Note + +As of C++20, we can (and should) use concepts to be more specific about the type we are deducing: + + // ... + forward_iterator auto p = algo(x, y, z); + +##### Example (C++17) + + std::set values; + // ... + auto [ position, newly_inserted ] = values.insert(5); // break out the members of the std::pair + +##### Enforcement + +Flag redundant repetition of type names in a declaration. + +### ES.12: Do not reuse names in nested scopes + +##### Reason + +It is easy to get confused about which variable is used. +Can cause maintenance problems. + +##### Example, bad + + int d = 0; + // ... + if (cond) { + // ... + d = 9; + // ... + } + else { + // ... + int d = 7; + // ... + d = value_to_be_returned; + // ... + } + + return d; + +If this is a large `if`-statement, it is easy to overlook that a new `d` has been introduced in the inner scope. +This is a known source of bugs. +Sometimes such reuse of a name in an inner scope is called "shadowing". + +##### Note + +Shadowing is primarily a problem when functions are too large and too complex. + +##### Example + +Shadowing of function arguments in the outermost block is disallowed by the language: + + void f(int x) + { + int x = 4; // error: reuse of function argument name + + if (x) { + int x = 7; // allowed, but bad + // ... + } + } + +##### Example, bad + +Reuse of a member name as a local variable can also be a problem: + + struct S { + int m; + void f(int x); + }; + + void S::f(int x) + { + m = 7; // assign to member + if (x) { + int m = 9; + // ... + m = 99; // assign to local variable + // ... + } + } + +##### Exception + +We often reuse function names from a base class in a derived class: + + struct B { + void f(int); + }; + + struct D : B { + void f(double); + using B::f; + }; + +This is error-prone. +For example, had we forgotten the using declaration, a call `d.f(1)` would not have found the `int` version of `f`. + +??? Do we need a specific rule about shadowing/hiding in class hierarchies? + +##### Enforcement + +* Flag reuse of a name in nested local scopes +* Flag reuse of a member name as a local variable in a member function +* Flag reuse of a global name as a local variable or a member name +* Flag reuse of a base class member name in a derived class (except for function names) + +### ES.20: Always initialize an object + +##### Reason + +Avoid used-before-set errors and their associated undefined behavior. +Avoid problems with comprehension of complex initialization. +Simplify refactoring. + +##### Example + + void use(int arg) + { + int i; // bad: uninitialized variable + // ... + i = 7; // initialize i + } + +No, `i = 7` does not initialize `i`; it assigns to it. Also, `i` can be read in the `...` part. Better: + + void use(int arg) // OK + { + int i = 7; // OK: initialized + string s; // OK: default initialized + // ... + } + +##### Note + +The *always initialize* rule is deliberately stronger than the *an object must be set before used* language rule. +The latter, more relaxed rule, catches the technical bugs, but: + +* It leads to less readable code +* It encourages people to declare names in greater than necessary scopes +* It leads to harder to read code +* It leads to logic bugs by encouraging complex code +* It hampers refactoring + +The *always initialize* rule is a style rule aimed to improve maintainability as well as a rule protecting against used-before-set errors. + +##### Example + +Here is an example that is often considered to demonstrate the need for a more relaxed rule for initialization + + widget i; // "widget" a type that's expensive to initialize, possibly a large trivial type + widget j; + + if (cond) { // bad: i and j are initialized "late" + i = f1(); + j = f2(); + } + else { + i = f3(); + j = f4(); + } + +This cannot trivially be rewritten to initialize `i` and `j` with initializers. +Note that for types with a default constructor, attempting to postpone initialization simply leads to a default initialization followed by an assignment. +A popular reason for such examples is "efficiency", but a compiler that can detect whether we made a used-before-set error can also eliminate any redundant double initialization. + +Assuming that there is a logical connection between `i` and `j`, that connection should probably be expressed in code: + + pair make_related_widgets(bool x) + { + return (x) ? {f1(), f2()} : {f3(), f4()}; + } + + auto [i, j] = make_related_widgets(cond); // C++17 + +If the `make_related_widgets` function is otherwise redundant, +we can eliminate it by using a lambda [ES.28](#Res-lambda-init): + + auto [i, j] = [x] { return (x) ? pair{f1(), f2()} : pair{f3(), f4()} }(); // C++17 + +Using a value representing "uninitialized" is a symptom of a problem and not a solution: + + widget i = uninit; // bad + widget j = uninit; + + // ... + use(i); // possibly used before set + // ... + + if (cond) { // bad: i and j are initialized "late" + i = f1(); + j = f2(); + } + else { + i = f3(); + j = f4(); + } + +Now the compiler cannot even simply detect a used-before-set. Further, we've introduced complexity in the state space for widget: which operations are valid on an `uninit` widget and which are not? + +##### Note + +Complex initialization has been popular with clever programmers for decades. +It has also been a major source of errors and complexity. +Many such errors are introduced during maintenance years after the initial implementation. + +##### Example + +This rule covers data members. + + class X { + public: + X(int i, int ci) : m2{i}, cm2{ci} {} + // ... + + private: + int m1 = 7; + int m2; + int m3; + + const int cm1 = 7; + const int cm2; + const int cm3; + }; + +The compiler will flag the uninitialized `cm3` because it is a `const`, but it will not catch the lack of initialization of `m3`. +Usually, a rare spurious member initialization is worth the absence of errors from lack of initialization and often an optimizer +can eliminate a redundant initialization (e.g., an initialization that occurs immediately before an assignment). + +##### Exception + +If you are declaring an object that is just about to be initialized from input, initializing it would cause a double initialization. +However, beware that this might leave uninitialized data beyond the input -- and that has been a fertile source of errors and security breaches: + + constexpr int max = 8 * 1024; + int buf[max]; // OK, but suspicious: uninitialized + f.read(buf, max); + +The cost of initializing that array could be significant in some situations. +However, such examples do tend to leave uninitialized variables accessible, so they should be treated with suspicion. + + constexpr int max = 8 * 1024; + int buf[max] = {}; // zero all elements; better in some situations + f.read(buf, max); + +Because of the restrictive initialization rules for arrays and `std::array`, they offer the most compelling examples of the need for this exception. + +When feasible use a library function that is known not to overflow. For example: + + string s; // s is default initialized to "" + cin >> s; // s expands to hold the string + +Don't consider simple variables that are targets for input operations exceptions to this rule: + + int i; // bad + // ... + cin >> i; + +In the not uncommon case where the input target and the input operation get separated (as they should not) the possibility of used-before-set opens up. + + int i2 = 0; // better, assuming that zero is an acceptable value for i2 + // ... + cin >> i2; + +A good optimizer should know about input operations and eliminate the redundant operation. + + +##### Note + +Sometimes, a lambda can be used as an initializer to avoid an uninitialized variable: + + error_code ec; + Value v = [&] { + auto p = get_value(); // get_value() returns a pair + ec = p.first; + return p.second; + }(); + +or maybe: + + Value v = [] { + auto p = get_value(); // get_value() returns a pair + if (p.first) throw Bad_value{p.first}; + return p.second; + }(); + +**See also**: [ES.28](#Res-lambda-init) + +##### Enforcement + +* Flag every uninitialized variable. + Don't flag variables of user-defined types with default constructors. +* Check that an uninitialized buffer is written into *immediately* after declaration. + Passing an uninitialized variable as a reference to non-`const` argument can be assumed to be a write into the variable. + +### ES.21: Don't introduce a variable (or constant) before you need to use it + +##### Reason + +Readability. To limit the scope in which the variable can be used. + +##### Example + + int x = 7; + // ... no use of x here ... + ++x; + +##### Enforcement + +Flag declarations that are distant from their first use. + +### ES.22: Don't declare a variable until you have a value to initialize it with + +##### Reason + +Readability. Limit the scope in which a variable can be used. Don't risk used-before-set. Initialization is often more efficient than assignment. + +##### Example, bad + + string s; + // ... no use of s here ... + s = "what a waste"; + +##### Example, bad + + SomeLargeType var; // Hard-to-read CaMeLcAsEvArIaBlE + + if (cond) // some non-trivial condition + Set(&var); + else if (cond2 || !cond3) { + var = Set2(3.14); + } + else { + var = 0; + for (auto& e : something) + var += e; + } + + // use var; that this isn't done too early can be enforced statically with only control flow + +This would be fine if there was a default initialization for `SomeLargeType` that wasn't too expensive. +Otherwise, a programmer might very well wonder if every possible path through the maze of conditions has been covered. +If not, we have a "use before set" bug. This is a maintenance trap. + +For initializers of moderate complexity, including for `const` variables, consider using a lambda to express the initializer; see [ES.28](#Res-lambda-init). + +##### Enforcement + +* Flag declarations with default initialization that are assigned to before they are first read. +* Flag any complicated computation after an uninitialized variable and before its use. + +### ES.23: Prefer the `{}`-initializer syntax + +##### Reason + +Prefer `{}`. The rules for `{}` initialization are simpler, more general, less ambiguous, and safer than for other forms of initialization. + +Use `=` only when you are sure that there can be no narrowing conversions. For built-in arithmetic types, use `=` only with `auto`. + +Avoid `()` initialization, which allows parsing ambiguities. + +##### Example + + int x {f(99)}; + int y = x; + vector v = {1, 2, 3, 4, 5, 6}; + +##### Exception + +For containers, there is a tradition for using `{...}` for a list of elements and `(...)` for sizes: + + vector v1(10); // vector of 10 elements with the default value 0 + vector v2{10}; // vector of 1 element with the value 10 + + vector v3(1, 2); // vector of 1 element with the value 2 + vector v4{1, 2}; // vector of 2 elements with the values 1 and 2 + +##### Note + +`{}`-initializers do not allow narrowing conversions (and that is usually a good thing) and allow explicit constructors (which is fine, we're intentionally initializing a new variable). + +##### Example + + int x {7.9}; // error: narrowing + int y = 7.9; // OK: y becomes 7. Hope for a compiler warning + int z {gsl::narrow_cast(7.9)}; // OK: you asked for it + auto zz = gsl::narrow_cast(7.9); // OK: you asked for it + +##### Note + +`{}` initialization can be used for nearly all initialization; other forms of initialization can't: + + auto p = new vector {1, 2, 3, 4, 5}; // initialized vector + D::D(int a, int b) :m{a, b} { // member initializer (e.g., m might be a pair) + // ... + }; + X var {}; // initialize var to be empty + struct S { + int m {7}; // default initializer for a member + // ... + }; + +For that reason, `{}`-initialization is often called "uniform initialization" +(though there unfortunately are a few irregularities left). + +##### Note + +Initialization of a variable declared using `auto` with a single value, e.g., `{v}`, had surprising results until C++17. +The C++17 rules are somewhat less surprising: + + auto x1 {7}; // x1 is an int with the value 7 + auto x2 = {7}; // x2 is an initializer_list with an element 7 + + auto x11 {7, 8}; // error: two initializers + auto x22 = {7, 8}; // x22 is an initializer_list with elements 7 and 8 + +Use `={...}` if you really want an `initializer_list` + + auto fib10 = {1, 1, 2, 3, 5, 8, 13, 21, 34, 55}; // fib10 is a list + +##### Note + +`={}` gives copy initialization whereas `{}` gives direct initialization. +Like the distinction between copy-initialization and direct-initialization itself, this can lead to surprises. +`{}` accepts `explicit` constructors; `={}` does not. For example: + + struct Z { explicit Z() {} }; + + Z z1{}; // OK: direct initialization, so we use explicit constructor + Z z2 = {}; // error: copy initialization, so we cannot use the explicit constructor + +Use plain `{}`-initialization unless you specifically want to disable explicit constructors. + +##### Example + + template + void f() + { + T x1(1); // T initialized with 1 + T x0(); // bad: function declaration (often a mistake) + + T y1 {1}; // T initialized with 1 + T y0 {}; // default initialized T + // ... + } + +**See also**: [Discussion](#???) + +##### Enforcement + +* Flag uses of `=` to initialize arithmetic types where narrowing occurs. +* Flag uses of `()` initialization syntax that are actually declarations. (Many compilers should warn on this already.) + +### ES.24: Use a `unique_ptr` to hold pointers + +##### Reason + +Using `std::unique_ptr` is the simplest way to avoid leaks. It is reliable, it +makes the type system do much of the work to validate ownership safety, it +increases readability, and it has zero or near zero run-time cost. + +##### Example + + void use(bool leak) + { + auto p1 = make_unique(7); // OK + int* p2 = new int{7}; // bad: might leak + // ... no assignment to p2 ... + if (leak) return; + // ... no assignment to p2 ... + vector v(7); + v.at(7) = 0; // exception thrown + delete p2; // too late to prevent leaks + // ... + } + +If `leak == true` the object pointed to by `p2` is leaked and the object pointed to by `p1` is not. +The same is the case when `at()` throws. In both cases, the `delete p2` statement is not reached. + +##### Enforcement + +Look for raw pointers that are targets of `new`, `malloc()`, or functions that might return such pointers. + +### ES.25: Declare an object `const` or `constexpr` unless you want to modify its value later on + +##### Reason + +That way you can't change the value by mistake. That way might offer the compiler optimization opportunities. + +##### Example + + void f(int n) + { + const int bufmax = 2 * n + 2; // good: we can't change bufmax by accident + int xmax = n; // suspicious: is xmax intended to change? + // ... + } + +##### Enforcement + +Look to see if a variable is actually mutated, and flag it if +not. Unfortunately, it might be impossible to detect when a non-`const` was not +*intended* to vary (vs when it merely did not vary). + +### ES.26: Don't use a variable for two unrelated purposes + +##### Reason + +Readability and safety. + +##### Example, bad + + void use() + { + int i; + for (i = 0; i < 20; ++i) { /* ... */ } + for (i = 0; i < 200; ++i) { /* ... */ } // bad: i recycled + } + +##### Note + +As an optimization, you might want to reuse a buffer as a scratch pad, but even then prefer to limit the variable's scope as much as possible and be careful not to cause bugs from data left in a recycled buffer as this is a common source of security bugs. + + void write_to_file() + { + std::string buffer; // to avoid reallocations on every loop iteration + for (auto& o : objects) { + // First part of the work. + generate_first_string(buffer, o); + write_to_file(buffer); + + // Second part of the work. + generate_second_string(buffer, o); + write_to_file(buffer); + + // etc... + } + } + +##### Enforcement + +Flag recycled variables. + +### ES.27: Use `std::array` or `stack_array` for arrays on the stack + +##### Reason + +They are readable and don't implicitly convert to pointers. +They are not confused with non-standard extensions of built-in arrays. + +##### Example, bad + + const int n = 7; + int m = 9; + + void f() + { + int a1[n]; + int a2[m]; // error: not ISO C++ + // ... + } + +##### Note + +The definition of `a1` is legal C++ and has always been. +There is a lot of such code. +It is error-prone, though, especially when the bound is non-local. +Also, it is a "popular" source of errors (buffer overflow, pointers from array decay, etc.). +The definition of `a2` is C but not C++ and is considered a security risk + +##### Example + + const int n = 7; + int m = 9; + + void f() + { + array a1; + stack_array a2(m); + // ... + } + +##### Enforcement + +* Flag arrays with non-constant bounds (C-style VLAs) +* Flag arrays with non-local constant bounds + +### ES.28: Use lambdas for complex initialization, especially of `const` variables + +##### Reason + +It nicely encapsulates local initialization, including cleaning up scratch variables needed only for the initialization, without needing to create a needless non-local yet non-reusable function. It also works for variables that should be `const` but only after some initialization work. + +##### Example, bad + + widget x; // should be const, but: + for (auto i = 2; i <= N; ++i) { // this could be some + x += some_obj.do_something_with(i); // arbitrarily long code + } // needed to initialize x + // from here, x should be const, but we can't say so in code in this style + +##### Example, good + + const widget x = [&] { + widget val; // assume that widget has a default constructor + for (auto i = 2; i <= N; ++i) { // this could be some + val += some_obj.do_something_with(i); // arbitrarily long code + } // needed to initialize x + return val; + }(); + +If at all possible, reduce the conditions to a simple set of alternatives (e.g., an `enum`) and don't mix up selection and initialization. + +##### Enforcement + +Hard. At best a heuristic. Look for an uninitialized variable followed by a loop assigning to it. + +### ES.30: Don't use macros for program text manipulation + +##### Reason + +Macros are a major source of bugs. +Macros don't obey the usual scope and type rules. +Macros ensure that the human reader sees something different from what the compiler sees. +Macros complicate tool building. + +##### Example, bad + + #define Case break; case /* BAD */ + +This innocuous-looking macro makes a single lower case `c` instead of a `C` into a bad flow-control bug. + +##### Note + +This rule does not ban the use of macros for "configuration control" use in `#ifdef`s, etc. + +In the future, modules are likely to eliminate the need for macros in configuration control. + +##### Note + +This rule is meant to also discourage use of `#` for stringification and `##` for concatenation. +As usual for macros, there are uses that are "mostly harmless", but even these can create problems for tools, +such as auto completers, static analyzers, and debuggers. +Often the desire to use fancy macros is a sign of an overly complex design. +Also, `#` and `##` encourages the definition and use of macros: + + #define CAT(a, b) a ## b + #define STRINGIFY(a) #a + + void f(int x, int y) + { + string CAT(x, y) = "asdf"; // BAD: hard for tools to handle (and ugly) + string sx2 = STRINGIFY(x); + // ... + } + +There are workarounds for low-level string manipulation using macros. For example: + + enum E { a, b }; + + template + constexpr const char* stringify() + { + switch (x) { + case a: return "a"; + case b: return "b"; + } + } + + void f() + { + string s1 = stringify(); + string s2 = stringify(); + // ... + } + +This is not as convenient as a macro to define, but as easy to use, has zero overhead, and is typed and scoped. + +In the future, static reflection is likely to eliminate the last needs for the preprocessor for program text manipulation. + +##### Enforcement + +Scream when you see a macro that isn't just used for source control (e.g., `#ifdef`) + +### ES.31: Don't use macros for constants or "functions" + +##### Reason + +Macros are a major source of bugs. +Macros don't obey the usual scope and type rules. +Macros don't obey the usual rules for argument passing. +Macros ensure that the human reader sees something different from what the compiler sees. +Macros complicate tool building. + +##### Example, bad + + #define PI 3.14 + #define SQUARE(a, b) (a * b) + +Even if we hadn't left a well-known bug in `SQUARE` there are much better behaved alternatives; for example: + + constexpr double pi = 3.14; + template T square(T a, T b) { return a * b; } + +##### Enforcement + +Scream when you see a macro that isn't just used for source control (e.g., `#ifdef`) + +### ES.32: Use `ALL_CAPS` for all macro names + +##### Reason + +Convention. Readability. Distinguishing macros. + +##### Example + + #define forever for (;;) /* very BAD */ + + #define FOREVER for (;;) /* Still evil, but at least visible to humans */ + +##### Enforcement + +Scream when you see a lower case macro. + +### ES.33: If you must use macros, give them unique names + +##### Reason + +Macros do not obey scope rules. + +##### Example + + #define MYCHAR /* BAD, will eventually clash with someone else's MYCHAR*/ + + #define ZCORP_CHAR /* Still evil, but less likely to clash */ + +##### Note + +Avoid macros if you can: [ES.30](#Res-macros), [ES.31](#Res-macros2), and [ES.32](#Res-ALL_CAPS). +However, there are billions of lines of code littered with macros and a long tradition for using and overusing macros. +If you are forced to use macros, use long names and supposedly unique prefixes (e.g., your organization's name) to lower the likelihood of a clash. + +##### Enforcement + +Warn against short macro names. + +### ES.34: Don't define a (C-style) variadic function + +##### Reason + +Not type safe. +Requires messy cast-and-macro-laden code to get working right. + +##### Example + + #include + + // "severity" followed by a zero-terminated list of char*s; write the C-style strings to cerr + void error(int severity ...) + { + va_list ap; // a magic type for holding arguments + va_start(ap, severity); // arg startup: "severity" is the first argument of error() + + for (;;) { + // treat the next var as a char*; no checking: a cast in disguise + char* p = va_arg(ap, char*); + if (!p) break; + cerr << p << ' '; + } + + va_end(ap); // arg cleanup (don't forget this) + + cerr << '\n'; + if (severity) exit(severity); + } + + void use() + { + error(7, "this", "is", "an", "error", nullptr); + error(7); // crash + error(7, "this", "is", "an", "error"); // crash + const char* is = "is"; + string an = "an"; + error(7, "this", is, an, "error"); // crash + } + +**Alternative**: Overloading. Templates. Variadic templates. + + #include + + void error(int severity) + { + std::cerr << '\n'; + std::exit(severity); + } + + template + constexpr void error(int severity, T head, Ts... tail) + { + std::cerr << head; + error(severity, tail...); + } + + void use() + { + error(7); // No crash! + error(5, "this", "is", "not", "an", "error"); // No crash! + + std::string an = "an"; + error(7, "this", "is", "not", an, "error"); // No crash! + + error(5, "oh", "no", nullptr); // Compile error! No need for nullptr. + } + + +##### Note + +This is basically the way `printf` is implemented. + +##### Enforcement + +* Flag definitions of C-style variadic functions. +* Flag `#include ` and `#include ` + + +## ES.expr: Expressions + +Expressions manipulate values. + +### ES.40: Avoid complicated expressions + +##### Reason + +Complicated expressions are error-prone. + +##### Example + + // bad: assignment hidden in subexpression + while ((c = getc()) != -1) + + // bad: two non-local variables assigned in sub-expressions + while ((cin >> c1, cin >> c2), c1 == c2) + + // better, but possibly still too complicated + for (char c1, c2; cin >> c1 >> c2 && c1 == c2;) + + // OK: if i and j are not aliased + int x = ++i + ++j; + + // OK: if i != j and i != k + v[i] = v[j] + v[k]; + + // bad: multiple assignments "hidden" in subexpressions + x = a + (b = f()) + (c = g()) * 7; + + // bad: relies on commonly misunderstood precedence rules + x = a & b + c * d && e ^ f == 7; + + // bad: undefined behavior + x = x++ + x++ + ++x; + +Some of these expressions are unconditionally bad (e.g., they rely on undefined behavior). Others are simply so complicated and/or unusual that even good programmers could misunderstand them or overlook a problem when in a hurry. + +##### Note + +C++17 tightens up the rules for the order of evaluation +(left-to-right except right-to-left in assignments, and the order of evaluation of function arguments is unspecified; [see ES.43](#Res-order)), +but that doesn't change the fact that complicated expressions are potentially confusing. + +##### Note + +A programmer should know and use the basic rules for expressions. + +##### Example + + x = k * y + z; // OK + + auto t1 = k * y; // bad: unnecessarily verbose + x = t1 + z; + + if (0 <= x && x < max) // OK + + auto t1 = 0 <= x; // bad: unnecessarily verbose + auto t2 = x < max; + if (t1 && t2) // ... + +##### Enforcement + +Tricky. How complicated must an expression be to be considered complicated? Writing computations as statements with one operation each is also confusing. Things to consider: + +* side effects: side effects on multiple non-local variables (for some definition of non-local) can be suspect, especially if the side effects are in separate subexpressions +* writes to aliased variables +* more than N operators (and what should N be?) +* reliance of subtle precedence rules +* uses undefined behavior (can we catch all undefined behavior?) +* implementation defined behavior? +* ??? + +### ES.41: If in doubt about operator precedence, parenthesize + +##### Reason + +Avoid errors. Readability. Not everyone has the operator table memorized. + +##### Example + + const unsigned int flag = 2; + unsigned int a = flag; + + if (a & flag != 0) // bad: means a&(flag != 0) + +Note: We recommend that programmers know their precedence table for the arithmetic operations, the logical operations, but consider mixing bitwise logical operations with other operators in need of parentheses. + + if ((a & flag) != 0) // OK: works as intended + +##### Note + +You should know enough not to need parentheses for: + + if (a < 0 || a <= max) { + // ... + } + +##### Enforcement + +* Flag combinations of bitwise-logical operators and other operators. +* Flag assignment operators not as the leftmost operator. +* ??? + +### ES.42: Keep use of pointers simple and straightforward + +##### Reason + +Complicated pointer manipulation is a major source of errors. + +##### Note + +Use `gsl::span` instead. +Pointers should [only refer to single objects](#Ri-array). +Pointer arithmetic is fragile and easy to get wrong, the source of many, many bad bugs and security violations. +`span` is a bounds-checked, safe type for accessing arrays of data. +Access into an array with known bounds using a constant as a subscript can be validated by the compiler. + +##### Example, bad + + void f(int* p, int count) + { + if (count < 2) return; + + int* q = p + 1; // BAD + + ptrdiff_t d; + int n; + d = (p - &n); // OK + d = (q - p); // OK + + int n = *p++; // BAD + + if (count < 6) return; + + p[4] = 1; // BAD + + p[count - 1] = 2; // BAD + + use(&p[0], 3); // BAD + } + +##### Example, good + + void f(span a) // BETTER: use span in the function declaration + { + if (a.size() < 2) return; + + int n = a[0]; // OK + + span q = a.subspan(1); // OK + + if (a.size() < 6) return; + + a[4] = 1; // OK + + a[a.size() - 1] = 2; // OK + + use(a.data(), 3); // OK + } + +##### Note + +Subscripting with a variable is difficult for both tools and humans to validate as safe. +`span` is a run-time bounds-checked, safe type for accessing arrays of data. +`at()` is another alternative that ensures single accesses are bounds-checked. +If iterators are needed to access an array, use the iterators from a `span` constructed over the array. + +##### Example, bad + + void f(array a, int pos) + { + a[pos / 2] = 1; // BAD + a[pos - 1] = 2; // BAD + a[-1] = 3; // BAD (but easily caught by tools) -- no replacement, just don't do this + a[10] = 4; // BAD (but easily caught by tools) -- no replacement, just don't do this + } + +##### Example, good + +Use a `span`: + + void f1(span a, int pos) // A1: Change parameter type to use span + { + a[pos / 2] = 1; // OK + a[pos - 1] = 2; // OK + } + + void f2(array arr, int pos) // A2: Add local span and use that + { + span a = {arr.data(), pos}; + a[pos / 2] = 1; // OK + a[pos - 1] = 2; // OK + } + +Use `at()`: + + void f3(array a, int pos) // ALTERNATIVE B: Use at() for access + { + at(a, pos / 2) = 1; // OK + at(a, pos - 1) = 2; // OK + } + +##### Example, bad + + void f() + { + int arr[COUNT]; + for (int i = 0; i < COUNT; ++i) + arr[i] = i; // BAD, cannot use non-constant indexer + } + +##### Example, good + +Use a `span`: + + void f1() + { + int arr[COUNT]; + span av = arr; + for (int i = 0; i < COUNT; ++i) + av[i] = i; + } + +Use a `span` and range-`for`: + + void f1a() + { + int arr[COUNT]; + span av = arr; + int i = 0; + for (auto& e : av) + e = i++; + } + +Use `at()` for access: + + void f2() + { + int arr[COUNT]; + for (int i = 0; i < COUNT; ++i) + at(arr, i) = i; + } + +Use a range-`for`: + + void f3() + { + int arr[COUNT]; + int i = 0; + for (auto& e : arr) + e = i++; + } + +##### Note + +Tooling can offer rewrites of array accesses that involve dynamic index expressions to use `at()` instead: + + static int a[10]; + + void f(int i, int j) + { + a[i + j] = 12; // BAD, could be rewritten as ... + at(a, i + j) = 12; // OK -- bounds-checked + } + +##### Example + +Turning an array into a pointer (as the language does essentially always) removes opportunities for checking, so avoid it + + void g(int* p); + + void f() + { + int a[5]; + g(a); // BAD: are we trying to pass an array? + g(&a[0]); // OK: passing one object + } + +If you want to pass an array, say so: + + void g(int* p, size_t length); // old (dangerous) code + + void g1(span av); // BETTER: get g() changed. + + void f2() + { + int a[5]; + span av = a; + + g(av.data(), av.size()); // OK, if you have no choice + g1(a); // OK -- no decay here, instead use implicit span ctor + } + +##### Enforcement + +* Flag any arithmetic operation on an expression of pointer type that results in a value of pointer type. +* Flag any indexing expression on an expression or variable of array type (either static array or `std::array`) where the indexer is not a compile-time constant expression with a value between `0` and the upper bound of the array. +* Flag any expression that would rely on implicit conversion of an array type to a pointer type. + +This rule is part of the [bounds-safety profile](#SS-bounds). + + +### ES.43: Avoid expressions with undefined order of evaluation + +##### Reason + +You have no idea what such code does. Portability. +Even if it does something sensible for you, it might do something different on another compiler (e.g., the next release of your compiler) or with a different optimizer setting. + +##### Note + +C++17 tightens up the rules for the order of evaluation: +left-to-right except right-to-left in assignments, and the order of evaluation of function arguments is unspecified. + +However, remember that your code might be compiled with a pre-C++17 compiler (e.g., through cut-and-paste) so don't be too clever. + +##### Example + + v[i] = ++i; // the result is undefined + +A good rule of thumb is that you should not read a value twice in an expression where you write to it. + +##### Enforcement + +Can be detected by a good analyzer. + +### ES.44: Don't depend on order of evaluation of function arguments + +##### Reason + +Because that order is unspecified. + +##### Note + +C++17 tightens up the rules for the order of evaluation, but the order of evaluation of function arguments is still unspecified. + +##### Example + + int i = 0; + f(++i, ++i); + +Before C++17, the behavior is undefined, so the behavior could be anything (e.g., `f(2, 2)`). +Since C++17, this code does not have undefined behavior, but it is still not specified which argument is evaluated first. The call will be `f(1, 2)` or `f(2, 1)`, but you don't know which. + +##### Example + +Overloaded operators can lead to order of evaluation problems: + + f1()->m(f2()); // m(f1(), f2()) + cout << f1() << f2(); // operator<<(operator<<(cout, f1()), f2()) + +In C++17, these examples work as expected (left to right) and assignments are evaluated right to left (just as ='s binding is right-to-left) + + f1() = f2(); // undefined behavior in C++14; in C++17, f2() is evaluated before f1() + +##### Enforcement + +Can be detected by a good analyzer. + +### ES.45: Avoid "magic constants"; use symbolic constants + +##### Reason + +Unnamed constants embedded in expressions are easily overlooked and often hard to understand: + +##### Example + + for (int m = 1; m <= 12; ++m) // don't: magic constant 12 + cout << month[m] << '\n'; + +No, we don't all know that there are 12 months, numbered 1..12, in a year. Better: + + // months are indexed 1..12 + constexpr int first_month = 1; + constexpr int last_month = 12; + + for (int m = first_month; m <= last_month; ++m) // better + cout << month[m] << '\n'; + +Better still, don't expose constants: + + for (auto m : month) + cout << m << '\n'; + +##### Enforcement + +Flag literals in code. Give a pass to `0`, `1`, `nullptr`, `\n`, `""`, and others on a positive list. + +### ES.46: Avoid lossy (narrowing, truncating) arithmetic conversions + +##### Reason + +A narrowing conversion destroys information, often unexpectedly so. + +##### Example, bad + +A key example is basic narrowing: + + double d = 7.9; + int i = d; // bad: narrowing: i becomes 7 + i = (int) d; // bad: we're going to claim this is still not explicit enough + + void f(int x, long y, double d) + { + char c1 = x; // bad: narrowing + char c2 = y; // bad: narrowing + char c3 = d; // bad: narrowing + } + +##### Note + +The guidelines support library offers a `narrow_cast` operation for specifying that narrowing is acceptable and a `narrow` ("narrow if") that throws an exception if a narrowing would throw away legal values: + + i = gsl::narrow_cast(d); // OK (you asked for it): narrowing: i becomes 7 + i = gsl::narrow(d); // OK: throws narrowing_error + +We also include lossy arithmetic casts, such as from a negative floating point type to an unsigned integral type: + + double d = -7.9; + unsigned u = 0; + + u = d; // bad: narrowing + u = gsl::narrow_cast(d); // OK (you asked for it): u becomes 4294967289 + u = gsl::narrow(d); // OK: throws narrowing_error + +##### Note + +This rule does not apply to [contextual conversions to bool](https://en.cppreference.com/w/cpp/language/implicit_conversion#Contextual_conversions): + + if (ptr) do_something(*ptr); // OK: ptr is used as a condition + bool b = ptr; // bad: narrowing + +##### Enforcement + +A good analyzer can detect all narrowing conversions. However, flagging all narrowing conversions will lead to a lot of false positives. Suggestions: + +* Flag all floating-point to integer conversions (maybe only `float`->`char` and `double`->`int`. Here be dragons! we need data). +* Flag all `long`->`char` (I suspect `int`->`char` is very common. Here be dragons! we need data). +* Consider narrowing conversions for function arguments especially suspect. + +### ES.47: Use `nullptr` rather than `0` or `NULL` + +##### Reason + +Readability. Minimize surprises: `nullptr` cannot be confused with an +`int`. `nullptr` also has a well-specified (very restrictive) type, and thus +works in more scenarios where type deduction might do the wrong thing on `NULL` +or `0`. + +##### Example + +Consider: + + void f(int); + void f(char*); + f(0); // call f(int) + f(nullptr); // call f(char*) + +##### Enforcement + +Flag uses of `0` and `NULL` for pointers. The transformation might be helped by simple program transformation. + +### ES.48: Avoid casts + +##### Reason + +Casts are a well-known source of errors and make some optimizations unreliable. + +##### Example, bad + + double d = 2; + auto p = (long*)&d; + auto q = (long long*)&d; + cout << d << ' ' << *p << ' ' << *q << '\n'; + +What would you think this fragment prints? The result is at best implementation defined. I got + + 2 0 4611686018427387904 + +Adding + + *q = 666; + cout << d << ' ' << *p << ' ' << *q << '\n'; + +I got + + 3.29048e-321 666 666 + +Surprised? It is actually undefined behavior, and so could also have crashed the program. + +##### Note + +Programmers who write casts typically assume that they know what they are doing, +or that writing a cast makes the program "easier to read". +In fact, they often disable the general rules for using values. +Overload resolution and template instantiation usually pick the right function if there is a right function to pick. +If there is not, maybe there ought to be, rather than applying a local fix (cast). + +##### Notes + +Casts are necessary in a systems programming language. For example, how else +would we get the address of a device register into a pointer? However, casts +are seriously overused as well as a major source of errors. + +If you feel the need for a lot of casts, there might be a fundamental design problem. + +The [type profile](#Pro-type-reinterpretcast) bans `reinterpret_cast` and C-style casts. + +Never cast to `(void)` to ignore a `[[nodiscard]]`return value. +If you deliberately want to discard such a result, first think hard about whether that is really a good idea (there is usually a good reason the author of the function or of the return type used `[[nodiscard]]` in the first place). +If you still think it's appropriate and your code reviewer agrees, use `std::ignore =` to turn off the warning which is simple, portable, and easy to grep. + +##### Alternatives + +Casts are widely (mis)used. Modern C++ has rules and constructs that eliminate the need for casts in many contexts, such as + +* Use templates +* Use `std::variant` +* Rely on the well-defined, safe, implicit conversions between pointer types +* Use `std::ignore =` to ignore `[[nodiscard]]` values. + +##### Enforcement + +* Flag all C-style casts, including to `void`. +* Flag functional style casts using `Type(value)`. Use `Type{value}` instead which is not narrowing. (See [ES.64](#Res-construct).) +* Flag [identity casts](#Pro-type-identitycast) between pointer types, where the source and target types are the same (#Pro-type-identitycast). +* Flag an explicit pointer cast that could be [implicit](#Pro-type-implicitpointercast). + +### ES.49: If you must use a cast, use a named cast + +##### Reason + +Readability. Error avoidance. +Named casts are more specific than a C-style or functional cast, allowing the compiler to catch some errors. + +The named casts are: + +* `static_cast` +* `const_cast` +* `reinterpret_cast` +* `dynamic_cast` +* `std::move` // `move(x)` is an rvalue reference to `x` +* `std::forward` // `forward(x)` is an rvalue or an lvalue reference to `x` depending on `T` +* `gsl::narrow_cast` // `narrow_cast(x)` is `static_cast(x)` +* `gsl::narrow` // `narrow(x)` is `static_cast(x)` if `static_cast(x) == x` or it throws `narrowing_error` + +##### Example + + class B { /* ... */ }; + class D { /* ... */ }; + + template D* upcast(B* pb) + { + D* pd0 = pb; // error: no implicit conversion from B* to D* + D* pd1 = (D*)pb; // legal, but what is done? + D* pd2 = static_cast(pb); // error: D is not derived from B + D* pd3 = reinterpret_cast(pb); // OK: on your head be it! + D* pd4 = dynamic_cast(pb); // OK: return nullptr + // ... + } + +The example was synthesized from real-world bugs where `D` used to be derived from `B`, but someone refactored the hierarchy. +The C-style cast is dangerous because it can do any kind of conversion, depriving us of any protection from mistakes (now or in the future). + +##### Note + +When converting between types with no information loss (e.g. from `float` to +`double` or from `int32` to `int64`), brace initialization might be used instead. + + double d {some_float}; + int64_t i {some_int32}; + +This makes it clear that the type conversion was intended and also prevents +conversions between types that might result in loss of precision. (It is a +compilation error to try to initialize a `float` from a `double` in this fashion, +for example.) + +##### Note + +`reinterpret_cast` can be essential, but the essential uses (e.g., turning a machine address into pointer) are not type safe: + + auto p = reinterpret_cast(0x800); // inherently dangerous + + +##### Enforcement + +* Flag all C-style casts, including to `void`. +* Flag functional style casts using `Type(value)`. Use `Type{value}` instead which is not narrowing. (See [ES.64](#Res-construct).) +* The [type profile](#Pro-type-reinterpretcast) bans `reinterpret_cast`. +* The [type profile](#Pro-type-arithmeticcast) warns when using `static_cast` between arithmetic types. + +### ES.50: Don't cast away `const` + +##### Reason + +It makes a lie out of `const`. +If the variable is actually declared `const`, modifying it results in undefined behavior. + +##### Example, bad + + void f(const int& x) + { + const_cast(x) = 42; // BAD + } + + static int i = 0; + static const int j = 0; + + f(i); // silent side effect + f(j); // undefined behavior + +##### Example + +Sometimes, you might be tempted to resort to `const_cast` to avoid code duplication, such as when two accessor functions that differ only in `const`-ness have similar implementations. For example: + + class Bar; + + class Foo { + public: + // BAD, duplicates logic + Bar& get_bar() + { + /* complex logic around getting a non-const reference to my_bar */ + } + + const Bar& get_bar() const + { + /* same complex logic around getting a const reference to my_bar */ + } + private: + Bar my_bar; + }; + +Instead, prefer to share implementations. Normally, you can just have the non-`const` function call the `const` function. However, when there is complex logic this can lead to the following pattern that still resorts to a `const_cast`: + + class Foo { + public: + // not great, non-const calls const version but resorts to const_cast + Bar& get_bar() + { + return const_cast(static_cast(*this).get_bar()); + } + const Bar& get_bar() const + { + /* the complex logic around getting a const reference to my_bar */ + } + private: + Bar my_bar; + }; + +Although this pattern is safe when applied correctly, because the caller must have had a non-`const` object to begin with, it's not ideal because the safety is hard to enforce automatically as a checker rule. + +Instead, prefer to put the common code in a common helper function -- and make it a template so that it deduces `const`. This doesn't use any `const_cast` at all: + + class Foo { + public: // good + Bar& get_bar() { return get_bar_impl(*this); } + const Bar& get_bar() const { return get_bar_impl(*this); } + private: + Bar my_bar; + + template // good, deduces whether T is const or non-const + static auto& get_bar_impl(T& t) + { /* the complex logic around getting a possibly-const reference to my_bar */ } + }; + +Note: Don't do large non-dependent work inside a template, which leads to code bloat. For example, a further improvement would be if all or part of `get_bar_impl` can be non-dependent and factored out into a common non-template function, for a potentially big reduction in code size. + +##### Exception + +You might need to cast away `const` when calling `const`-incorrect functions. +Prefer to wrap such functions in inline `const`-correct wrappers to encapsulate the cast in one place. + +##### Example + +Sometimes, "cast away `const`" is to allow the updating of some transient information of an otherwise immutable object. +Examples are caching, memoization, and precomputation. +Such examples are often handled as well or better using `mutable` or an indirection than with a `const_cast`. + +Consider keeping previously computed results around for a costly operation: + + int compute(int x); // compute a value for x; assume this to be costly + + class Cache { // some type implementing a cache for an int->int operation + public: + pair find(int x) const; // is there a value for x? + void set(int x, int v); // make y the value for x + // ... + private: + // ... + }; + + class X { + public: + int get_val(int x) + { + auto p = cache.find(x); + if (p.first) return p.second; + int val = compute(x); + cache.set(x, val); // insert value for x + return val; + } + // ... + private: + Cache cache; + }; + +Here, `get_val()` is logically constant, so we would like to make it a `const` member. +To do this we still need to mutate `cache`, so people sometimes resort to a `const_cast`: + + class X { // Suspicious solution based on casting + public: + int get_val(int x) const + { + auto p = cache.find(x); + if (p.first) return p.second; + int val = compute(x); + const_cast(cache).set(x, val); // ugly + return val; + } + // ... + private: + Cache cache; + }; + +Fortunately, there is a better solution: +State that `cache` is mutable even for a `const` object: + + class X { // better solution + public: + int get_val(int x) const + { + auto p = cache.find(x); + if (p.first) return p.second; + int val = compute(x); + cache.set(x, val); + return val; + } + // ... + private: + mutable Cache cache; + }; + +An alternative solution would be to store a pointer to the `cache`: + + class X { // OK, but slightly messier solution + public: + int get_val(int x) const + { + auto p = cache->find(x); + if (p.first) return p.second; + int val = compute(x); + cache->set(x, val); + return val; + } + // ... + private: + unique_ptr cache; + }; + +That solution is the most flexible, but requires explicit construction and destruction of `*cache` +(most likely in the constructor and destructor of `X`). + +In any variant, we must guard against data races on the `cache` in multi-threaded code, possibly using a `std::mutex`. + +##### Enforcement + +* Flag `const_cast`s. +* This rule is part of the [type-safety profile](#Pro-type-constcast) for the related Profile. + +### ES.55: Avoid the need for range checking + +##### Reason + +Constructs that cannot overflow do not overflow (and usually run faster): + +##### Example + + for (auto& x : v) // print all elements of v + cout << x << '\n'; + + auto p = find(v, x); // find x in v + +##### Enforcement + +Look for explicit range checks and heuristically suggest alternatives. + +### ES.56: Write `std::move()` only when you need to explicitly move an object to another scope + +##### Reason + +We move, rather than copy, to avoid duplication and for improved performance. + +A move typically leaves behind an empty object ([C.64](#Rc-move-semantic)), which can be surprising or even dangerous, so we try to avoid moving from lvalues (they might be accessed later). + +##### Notes + +Moving is done implicitly when the source is an rvalue (e.g., value in a `return` treatment or a function result), so don't pointlessly complicate code in those cases by writing `move` explicitly. Instead, write short functions that return values, and both the function's return and the caller's accepting of the return will be optimized naturally. + +In general, following the guidelines in this document (including not making variables' scopes needlessly large, writing short functions that return values, returning local variables) help eliminate most need for explicit `std::move`. + +Explicit `move` is needed to explicitly move an object to another scope, notably to pass it to a "sink" function and in the implementations of the move operations themselves (move constructor, move assignment operator) and swap operations. + +##### Example, bad + + void sink(X&& x); // sink takes ownership of x + + void user() + { + X x; + // error: cannot bind an lvalue to a rvalue reference + sink(x); + // OK: sink takes the contents of x, x must now be assumed to be empty + sink(std::move(x)); + + // ... + + // probably a mistake + use(x); + } + +Usually, a `std::move()` is used as an argument to a `&&` parameter. +And after you do that, assume the object has been moved from (see [C.64](#Rc-move-semantic)) and don't read its state again until you first set it to a new value. + + void f() + { + string s1 = "supercalifragilisticexpialidocious"; + + string s2 = s1; // ok, takes a copy + assert(s1 == "supercalifragilisticexpialidocious"); // ok + + // bad, if you want to keep using s1's value + string s3 = move(s1); + + // bad, assert will likely fail, s1 likely changed + assert(s1 == "supercalifragilisticexpialidocious"); + } + +##### Example + + void sink(unique_ptr p); // pass ownership of p to sink() + + void f() + { + auto w = make_unique(); + // ... + sink(std::move(w)); // ok, give to sink() + // ... + sink(w); // Error: unique_ptr is carefully designed so that you cannot copy it + } + +##### Notes + +`std::move()` is a cast to `&&` in disguise; it doesn't itself move anything, but marks a named object as a candidate that can be moved from. +The language already knows the common cases where objects can be moved from, especially when returning values from functions, so don't complicate code with redundant `std::move()`'s. + +Never write `std::move()` just because you've heard "it's more efficient." +In general, don't believe claims of "efficiency" without data (???). +In general, don't complicate your code without reason (??). +Never write `std::move()` on a const object, it is silently transformed into a copy (see Item 23 in [Meyers15](#Meyers15)) + +##### Example, bad + + vector make_vector() + { + vector result; + // ... load result with data + return std::move(result); // bad; just write "return result;" + } + +Never write `return move(local_variable);`, because the language already knows the variable is a move candidate. +Writing `move` in this code won't help, and can actually be detrimental because on some compilers it interferes with RVO (the return value optimization) by creating an additional reference alias to the local variable. + + +##### Example, bad + + vector v = std::move(make_vector()); // bad; the std::move is entirely redundant + +Never write `move` on a returned value such as `x = move(f());` where `f` returns by value. +The language already knows that a returned value is a temporary object that can be moved from. + +##### Example + + void mover(X&& x) + { + call_something(std::move(x)); // ok + call_something(std::forward(x)); // bad, don't std::forward an rvalue reference + call_something(x); // suspicious, why not std::move? + } + + template + void forwarder(T&& t) + { + call_something(std::move(t)); // bad, don't std::move a forwarding reference + call_something(std::forward(t)); // ok + call_something(t); // suspicious, why not std::forward? + } + +##### Enforcement + +* Flag use of `std::move(x)` where `x` is an rvalue or the language will already treat it as an rvalue, including `return std::move(local_variable);` and `std::move(f())` on a function that returns by value. +* Flag functions taking an `S&&` parameter if there is no `const S&` overload to take care of lvalues. +* Flag a `std::move`d argument passed to a parameter, except when the parameter type is an `X&&` rvalue reference or the type is move-only and the parameter is passed by value. +* Flag when `std::move` is applied to a forwarding reference (`T&&` where `T` is a template parameter type). Use `std::forward` instead. +* Flag when `std::move` is applied to other than an rvalue reference to non-const. (More general case of the previous rule to cover the non-forwarding cases.) +* Flag when `std::forward` is applied to an rvalue reference (`X&&` where `X` is a non-template parameter type). Use `std::move` instead. +* Flag when `std::forward` is applied to other than a forwarding reference. (More general case of the previous rule to cover the non-moving cases.) +* Flag when an object is potentially moved from and the next operation is a `const` operation; there should first be an intervening non-`const` operation, ideally assignment, to first reset the object's value. + +### ES.60: Avoid `new` and `delete` outside resource management functions + +##### Reason + +Direct resource management in application code is error-prone and tedious. + +##### Note + +This is also known as the rule of "No naked `new`!" + +##### Example, bad + + void f(int n) + { + auto p = new X[n]; // n default constructed Xs + // ... + delete[] p; + } + +There can be code in the `...` part that causes the `delete` never to happen. + +**See also**: [R: Resource management](#S-resource) + +##### Enforcement + +Flag naked `new`s and naked `delete`s. + +### ES.61: Delete arrays using `delete[]` and non-arrays using `delete` + +##### Reason + +That's what the language requires, and mismatches can lead to resource release errors and/or memory corruption. + +##### Example, bad + + void f(int n) + { + auto p = new X[n]; // n default constructed Xs + // ... + delete p; // error: just delete the object p, rather than delete the array p[] + } + +##### Note + +This example not only violates the [no naked `new` rule](#Res-new) as in the previous example, it has many more problems. + +##### Enforcement + +* Flag mismatched `new` and `delete` if they are in the same scope. +* Flag mismatched `new` and `delete` if they are in a constructor/destructor pair. + +### ES.62: Don't compare pointers into different arrays + +##### Reason + +The result of doing so is undefined. + +##### Example, bad + + void f() + { + int a1[7]; + int a2[9]; + if (&a1[5] < &a2[7]) {} // bad: undefined + if (0 < &a1[5] - &a2[7]) {} // bad: undefined + } + +##### Note + +This example has many more problems. + +##### Enforcement + +??? + +### ES.63: Don't slice + +##### Reason + +Slicing -- that is, copying only part of an object using assignment or initialization -- most often leads to errors because +the object was meant to be considered as a whole. +In the rare cases where the slicing was deliberate the code can be surprising. + +##### Example + + class Shape { /* ... */ }; + class Circle : public Shape { /* ... */ Point c; int r; }; + + Circle c { {0, 0}, 42 }; + Shape s {c}; // copy construct only the Shape part of Circle + s = c; // or copy assign only the Shape part of Circle + + void assign(const Shape& src, Shape& dest) + { + dest = src; + } + Circle c2 { {1, 1}, 43 }; + assign(c, c2); // oops, not the whole state is transferred + assert(c == c2); // if we supply copying, we should also provide comparison, + // but this will likely return false + +The result will be meaningless because the center and radius will not be copied from `c` into `s`. +The first defense against this is to [define the base class `Shape` not to allow this](#Rc-copy-virtual). + +##### Alternative + +If you mean to slice, define an explicit operation to do so. +This saves readers from confusion. +For example: + + class Smiley : public Circle { + public: + Circle copy_circle(); + // ... + }; + + Smiley sm { /* ... */ }; + Circle c1 {sm}; // ideally prevented by the definition of Circle + Circle c2 {sm.copy_circle()}; + +##### Enforcement + +Warn against slicing. + +### ES.64: Use the `T{e}`notation for construction + +##### Reason + +The `T{e}` construction syntax makes it explicit that construction is desired. +The `T{e}` construction syntax doesn't allow narrowing. +`T{e}` is the only safe and general expression for constructing a value of type `T` from an expression `e`. +The casts notations `T(e)` and `(T)e` are neither safe nor general. + +##### Example + +For built-in types, the construction notation protects against narrowing and reinterpretation + + void use(char ch, int i, double d, char* p, long long lng) + { + int x1 = int{ch}; // OK, but redundant + int x2 = int{d}; // error: double->int narrowing; use a cast if you need to + int x3 = int{p}; // error: pointer to->int; use a reinterpret_cast if you really need to + int x4 = int{lng}; // error: long long->int narrowing; use a cast if you need to + + int y1 = int(ch); // OK, but redundant + int y2 = int(d); // bad: double->int narrowing; use a cast if you need to + int y3 = int(p); // bad: pointer to->int; use a reinterpret_cast if you really need to + int y4 = int(lng); // bad: long long->int narrowing; use a cast if you need to + + int z1 = (int)ch; // OK, but redundant + int z2 = (int)d; // bad: double->int narrowing; use a cast if you need to + int z3 = (int)p; // bad: pointer to->int; use a reinterpret_cast if you really need to + int z4 = (int)lng; // bad: long long->int narrowing; use a cast if you need to + } + +The integer to/from pointer conversions are implementation defined when using the `T(e)` or `(T)e` notations, and non-portable +between platforms with different integer and pointer sizes. + +##### Note + +[Avoid casts](#Res-casts) (explicit type conversion) and if you must [prefer named casts](#Res-casts-named). + +##### Note + +When unambiguous, the `T` can be left out of `T{e}`. + + complex f(complex); + + auto z = f({2*pi, 1}); + +##### Note + +The construction notation is the most general [initializer notation](#Res-list). + +##### Exception + +`std::vector` and other containers were defined before we had `{}` as a notation for construction. +Consider: + + vector vs {10}; // ten empty strings + vector vi1 {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; // ten elements 1..10 + vector vi2 {10}; // one element with the value 10 + +How do we get a `vector` of 10 default initialized `int`s? + + vector v3(10); // ten elements with value 0 + +The use of `()` rather than `{}` for number of elements is conventional (going back to the early 1980s), hard to change, but still +a design error: for a container where the element type can be confused with the number of elements, we have an ambiguity that +must be resolved. +The conventional resolution is to interpret `{10}` as a list of one element and use `(10)` to distinguish a size. + +This mistake need not be repeated in new code. +We can define a type to represent the number of elements: + + struct Count { int n; }; + + template + class Vector { + public: + Vector(Count n); // n default-initialized elements + Vector(initializer_list init); // init.size() elements + // ... + }; + + Vector v1{10}; + Vector v2{Count{10}}; + Vector v3{Count{10}}; // yes, there is still a very minor problem + +The main problem left is to find a suitable name for `Count`. + +##### Enforcement + +Flag the C-style `(T)e` and functional-style `T(e)` casts. + + +### ES.65: Don't dereference an invalid pointer + +##### Reason + +Dereferencing an invalid pointer, such as `nullptr`, is undefined behavior, typically leading to immediate crashes, +wrong results, or memory corruption. + +##### Note + +By pointer here we mean any indirection to an object, including equivalently an iterator or view. + +##### Note + +This rule is an obvious and well-known language rule, but can be hard to follow. +It takes good coding style, library support, and static analysis to eliminate violations without major overhead. +This is a major part of the discussion of [C++'s model for type- and resource-safety](#Stroustrup15). + +**See also**: + +* Use [RAII](#Rr-raii) to avoid lifetime problems. +* Use [unique_ptr](#Rf-unique_ptr) to avoid lifetime problems. +* Use [shared_ptr](#Rf-shared_ptr) to avoid lifetime problems. +* Use [references](#Rf-ptr-ref) when `nullptr` isn't a possibility. +* Use [not_null](#Rf-nullptr) to catch unexpected `nullptr` early. +* Use the [bounds profile](#SS-bounds) to avoid range errors. + + +##### Example + + void f() + { + int x = 0; + int* p = &x; + + if (condition()) { + int y = 0; + p = &y; + } // invalidates p + + *p = 42; // BAD, p might be invalid if the branch was taken + } + +To resolve the problem, either extend the lifetime of the object the pointer is intended to refer to, or shorten the lifetime of the pointer (move the dereference to before the pointed-to object's lifetime ends). + + void f1() + { + int x = 0; + int* p = &x; + + int y = 0; + if (condition()) { + p = &y; + } + + *p = 42; // OK, p points to x or y and both are still in scope + } + +Unfortunately, most invalid pointer problems are harder to spot and harder to fix. + +##### Example + + void f(int* p) + { + int x = *p; // BAD: how do we know that p is valid? + } + +There is a huge amount of such code. +Most works -- after lots of testing -- but in isolation it is impossible to tell whether `p` could be the `nullptr`. +Consequently, this is also a major source of errors. +There are many approaches to dealing with this potential problem: + + void f1(int* p) // deal with nullptr + { + if (!p) { + // deal with nullptr (allocate, return, throw, make p point to something, whatever + } + int x = *p; + } + +There are two potential problems with testing for `nullptr`: + +* it is not always obvious what to do if we find `nullptr` +* the test can be redundant and/or relatively expensive +* it is not obvious if the test is to protect against a violation or part of the required logic. + + + void f2(int* p) // state that p is not supposed to be nullptr + { + assert(p); + int x = *p; + } + +This would carry a cost only when the assertion checking was enabled and would give a compiler/analyzer useful information. +This would work even better if/when C++ gets direct support for contracts: + + void f3(int* p) // state that p is not supposed to be nullptr + [[expects: p]] + { + int x = *p; + } + +Alternatively, we could use `gsl::not_null` to ensure that `p` is not the `nullptr`. + + void f(not_null p) + { + int x = *p; + } + +These remedies take care of `nullptr` only. +Remember that there are other ways of getting an invalid pointer. + +##### Example + + void f(int* p) // old code, doesn't use owner + { + delete p; + } + + void g() // old code: uses naked new + { + auto q = new int{7}; + f(q); + int x = *q; // BAD: dereferences invalid pointer + } + +##### Example + + void f() + { + vector v(10); + int* p = &v[5]; + v.push_back(99); // could reallocate v's elements + int x = *p; // BAD: dereferences potentially invalid pointer + } + +##### Enforcement + +This rule is part of the [lifetime safety profile](#SS-lifetime) + +* Flag a dereference of a pointer that points to an object that has gone out of scope +* Flag a dereference of a pointer that might have been invalidated by assigning a `nullptr` +* Flag a dereference of a pointer that might have been invalidated by a `delete` +* Flag a dereference to a pointer to a container element that might have been invalidated by dereference + + +## ES.stmt: Statements + +Statements control the flow of control (except for function calls and exception throws, which are expressions). + +### ES.70: Prefer a `switch`-statement to an `if`-statement when there is a choice + +##### Reason + +* Readability. +* Efficiency: A `switch` compares against constants and is usually better optimized than a series of tests in an `if`-`then`-`else` chain. +* A `switch` enables some heuristic consistency checking. For example, have all values of an `enum` been covered? If not, is there a `default`? + +##### Example + + void use(int n) + { + switch (n) { // good + case 0: + // ... + break; + case 7: + // ... + break; + default: + // ... + break; + } + } + +rather than: + + void use2(int n) + { + if (n == 0) // bad: if-then-else chain comparing against a set of constants + // ... + else if (n == 7) + // ... + } + +##### Enforcement + +Flag `if`-`then`-`else` chains that check against constants (only). + +### ES.71: Prefer a range-`for`-statement to a `for`-statement when there is a choice + +##### Reason + +Readability. Error prevention. Efficiency. + +##### Example + + for (gsl::index i = 0; i < v.size(); ++i) // bad + cout << v[i] << '\n'; + + for (auto p = v.begin(); p != v.end(); ++p) // bad + cout << *p << '\n'; + + for (auto& x : v) // OK + cout << x << '\n'; + + for (gsl::index i = 1; i < v.size(); ++i) // touches two elements: can't be a range-for + cout << v[i] + v[i - 1] << '\n'; + + for (gsl::index i = 0; i < v.size(); ++i) // possible side effect: can't be a range-for + cout << f(v, &v[i]) << '\n'; + + for (gsl::index i = 0; i < v.size(); ++i) { // body messes with loop variable: can't be a range-for + if (i % 2 != 0) + cout << v[i] << '\n'; // output odd elements + } + +A human or a good static analyzer might determine that there really isn't a side effect on `v` in `f(v, &v[i])` so that the loop can be rewritten. + +"Messing with the loop variable" in the body of a loop is typically best avoided. + +##### Note + +Don't use expensive copies of the loop variable of a range-`for` loop: + + for (string s : vs) // ... + +This will copy each element of `vs` into `s`. Better: + + for (string& s : vs) // ... + +Better still, if the loop variable isn't modified or copied: + + for (const string& s : vs) // ... + +##### Enforcement + +Look at loops, if a traditional loop just looks at each element of a sequence, and there are no side effects on what it does with the elements, rewrite the loop to a ranged-`for` loop. + +### ES.72: Prefer a `for`-statement to a `while`-statement when there is an obvious loop variable + +##### Reason + +Readability: the complete logic of the loop is visible "up front". The scope of the loop variable can be limited. + +##### Example + + for (gsl::index i = 0; i < vec.size(); i++) { + // do work + } + +##### Example, bad + + int i = 0; + while (i < vec.size()) { + // do work + i++; + } + +##### Enforcement + +??? + +### ES.73: Prefer a `while`-statement to a `for`-statement when there is no obvious loop variable + +##### Reason + +Readability. + +##### Example + + int events = 0; + for (; wait_for_event(); ++events) { // bad, confusing + // ... + } + +The "event loop" is misleading because the `events` counter has nothing to do with the loop condition (`wait_for_event()`). +Better + + int events = 0; + while (wait_for_event()) { // better + ++events; + // ... + } + +##### Enforcement + +Flag actions in `for`-initializers and `for`-increments that do not relate to the `for`-condition. + +### ES.74: Prefer to declare a loop variable in the initializer part of a `for`-statement + +See [ES.6](#Res-cond) + +### ES.75: Avoid `do`-statements + +##### Reason + +Readability, avoidance of errors. +The termination condition is at the end (where it can be overlooked) and the condition is not checked the first time through. + +##### Example + + int x; + do { + cin >> x; + // ... + } while (x < 0); + +##### Note + +Yes, there are genuine examples where a `do`-statement is a clear statement of a solution, but also many bugs. + +##### Enforcement + +Flag `do`-statements. + +### ES.76: Avoid `goto` + +##### Reason + +Readability, avoidance of errors. There are better control structures for humans; `goto` is for machine generated code. + +##### Exception + +Breaking out of a nested loop. +In that case, always jump forwards. + + for (int i = 0; i < imax; ++i) + for (int j = 0; j < jmax; ++j) { + if (a[i][j] > elem_max) goto finished; + // ... + } + finished: + // ... + +##### Example, bad + +There is a fair amount of use of the C goto-exit idiom: + + void f() + { + // ... + goto exit; + // ... + goto exit; + // ... + exit: + // ... common cleanup code ... + } + +This is an ad-hoc simulation of destructors. +Declare your resources with handles with destructors that clean up. +If for some reason you cannot handle all cleanup with destructors for the variables used, +consider `gsl::finally()` as a cleaner and more reliable alternative to `goto exit` + +##### Enforcement + +* Flag `goto`. Better still flag all `goto`s that do not jump from a nested loop to the statement immediately after a nest of loops. + +### ES.77: Minimize the use of `break` and `continue` in loops + +##### Reason + + In a non-trivial loop body, it is easy to overlook a `break` or a `continue`. + + A `break` in a loop has a dramatically different meaning than a `break` in a `switch`-statement + (and you can have `switch`-statement in a loop and a loop in a `switch`-case). + +##### Example + + switch(x) { + case 1 : + while (/* some condition */) { + // ... + break; + } // Oops! break switch or break while intended? + case 2 : + // ... + break; + } + +##### Alternative + +Often, a loop that requires a `break` is a good candidate for a function (algorithm), in which case the `break` becomes a `return`. + + //Original code: break inside loop + void use1() + { + std::vector vec = {/* initialized with some values */}; + T value; + for (const T item : vec) { + if (/* some condition*/) { + value = item; + break; + } + } + /* then do something with value */ + } + + //BETTER: create a function and return inside loop + T search(const std::vector &vec) + { + for (const T &item : vec) { + if (/* some condition*/) return item; + } + return T(); //default value + } + + void use2() + { + std::vector vec = {/* initialized with some values */}; + T value = search(vec); + /* then do something with value */ + } + +Often, a loop that uses `continue` can equivalently and as clearly be expressed by an `if`-statement. + + for (int item : vec) { // BAD + if (item%2 == 0) continue; + if (item == 5) continue; + if (item > 10) continue; + /* do something with item */ + } + + for (int item : vec) { // GOOD + if (item%2 != 0 && item != 5 && item <= 10) { + /* do something with item */ + } + } + +##### Note + +If you really need to break out a loop, a `break` is typically better than alternatives such as [modifying the loop variable](#Res-loop-counter) or a [`goto`](#Res-goto): + + +##### Enforcement + +??? + +### ES.78: Don't rely on implicit fallthrough in `switch` statements + +##### Reason + +Always end a non-empty `case` with a `break`. Accidentally leaving out a `break` is a fairly common bug. +A deliberate fallthrough can be a maintenance hazard and should be rare and explicit. + +##### Example + + switch (eventType) { + case Information: + update_status_bar(); + break; + case Warning: + write_event_log(); + // Bad - implicit fallthrough + case Error: + display_error_window(); + break; + } + +Multiple case labels of a single statement is OK: + + switch (x) { + case 'a': + case 'b': + case 'f': + do_something(x); + break; + } + +Return statements in a case label are also OK: + + switch (x) { + case 'a': + return 1; + case 'b': + return 2; + case 'c': + return 3; + } + +##### Exceptions + +In rare cases if fallthrough is deemed appropriate, be explicit and use the `[[fallthrough]]` annotation: + + switch (eventType) { + case Information: + update_status_bar(); + break; + case Warning: + write_event_log(); + [[fallthrough]]; + case Error: + display_error_window(); + break; + } + +##### Note + +##### Enforcement + +Flag all implicit fallthroughs from non-empty `case`s. + + +### ES.79: Use `default` to handle common cases (only) + +##### Reason + + Code clarity. + Improved opportunities for error detection. + +##### Example + + enum E { a, b, c, d }; + + void f1(E x) + { + switch (x) { + case a: + do_something(); + break; + case b: + do_something_else(); + break; + default: + take_the_default_action(); + break; + } + } + +Here it is clear that there is a default action and that cases `a` and `b` are special. + +##### Example + +But what if there is no default action and you mean to handle only specific cases? +In that case, have an empty default or else it is impossible to know if you meant to handle all cases: + + void f2(E x) + { + switch (x) { + case a: + do_something(); + break; + case b: + do_something_else(); + break; + default: + // do nothing for the rest of the cases + break; + } + } + +If you leave out the `default`, a maintainer and/or a compiler might reasonably assume that you intended to handle all cases: + + void f2(E x) + { + switch (x) { + case a: + do_something(); + break; + case b: + case c: + do_something_else(); + break; + } + } + +Did you forget case `d` or deliberately leave it out? +Forgetting a case typically happens when a case is added to an enumeration and the person doing so fails to add it to every +switch over the enumerators. + +##### Enforcement + +Flag `switch`-statements over an enumeration that don't handle all enumerators and do not have a `default`. +This might yield too many false positives in some code bases; if so, flag only `switch`es that handle most but not all cases +(that was the strategy of the very first C++ compiler). + +### ES.84: Don't try to declare a local variable with no name + +##### Reason + +There is no such thing. +What looks to a human like a variable without a name is to the compiler a statement consisting of a temporary that immediately goes out of scope. + +##### Example, bad + + void f() + { + lock_guard{mx}; // Bad + // ... + } + +This declares an unnamed `lock_guard` object that immediately goes out of scope at the point of the semicolon. +This is not an uncommon mistake. +In particular, this particular example can lead to hard-to find race conditions. + +##### Note + +Unnamed function arguments are fine. + +##### Enforcement + +Flag statements that are just a temporary. + +### ES.85: Make empty statements visible + +##### Reason + +Readability. + +##### Example + + for (i = 0; i < max; ++i); // BAD: the empty statement is easily overlooked + v[i] = f(v[i]); + + for (auto x : v) { // better + // nothing + } + v[i] = f(v[i]); + +##### Enforcement + +Flag empty statements that are not blocks and don't contain comments. + +### ES.86: Avoid modifying loop control variables inside the body of raw for-loops + +##### Reason + +The loop control up front should enable correct reasoning about what is happening inside the loop. Modifying loop counters in both the iteration-expression and inside the body of the loop is a perennial source of surprises and bugs. + +##### Example + + for (int i = 0; i < 10; ++i) { + // no updates to i -- ok + } + + for (int i = 0; i < 10; ++i) { + // + if (/* something */) ++i; // BAD + // + } + + bool skip = false; + for (int i = 0; i < 10; ++i) { + if (skip) { skip = false; continue; } + // + if (/* something */) skip = true; // Better: using two variables for two concepts. + // + } + +##### Enforcement + +Flag variables that are potentially updated (have a non-`const` use) in both the loop control iteration-expression and the loop body. + + +### ES.87: Don't add redundant `==` or `!=` to conditions + +##### Reason + +Doing so avoids verbosity and eliminates some opportunities for mistakes. +Helps make style consistent and conventional. + +##### Example + +By definition, a condition in an `if`-statement, `while`-statement, or a `for`-statement selects between `true` and `false`. +A numeric value is compared to `0` and a pointer value to `nullptr`. + + // These all mean "if p is not nullptr" + if (p) { ... } // good + if (p != 0) { ... } // redundant !=0, bad: don't use 0 for pointers + if (p != nullptr) { ... } // redundant !=nullptr, not recommended + +Often, `if (p)` is read as "if `p` is valid" which is a direct expression of the programmers intent, +whereas `if (p != nullptr)` would be a long-winded workaround. + +##### Example + +This rule is especially useful when a declaration is used as a condition + + if (auto pc = dynamic_cast(ps)) { ... } // execute if ps points to a kind of Circle, good + + if (auto pc = dynamic_cast(ps); pc != nullptr) { ... } // not recommended + +##### Example + +Note that implicit conversions to bool are applied in conditions. +For example: + + for (string s; cin >> s; ) v.push_back(s); + +This invokes `istream`'s `operator bool()`. + +##### Note + +Explicit comparison of an integer to `0` is in general not redundant. +The reason is that (as opposed to pointers and Booleans) an integer often has more than two reasonable values. +Furthermore `0` (zero) is often used to indicate success. +Consequently, it is best to be specific about the comparison. + + void f(int i) + { + if (i) // suspect + // ... + if (i == success) // possibly better + // ... + } + +Always remember that an integer can have more than two values. + +##### Example, bad + +It has been noted that + + if(strcmp(p1, p2)) { ... } // are the two C-style strings equal? (mistake!) + +is a common beginners error. +If you use C-style strings, you must know the `` functions well. +Being verbose and writing + + if(strcmp(p1, p2) != 0) { ... } // are the two C-style strings equal? (mistake!) + +would not in itself save you. + +##### Note + +The opposite condition is most easily expressed using a negation: + + // These all mean "if p is nullptr" + if (!p) { ... } // good + if (p == 0) { ... } // redundant == 0, bad: don't use 0 for pointers + if (p == nullptr) { ... } // redundant == nullptr, not recommended + +##### Enforcement + +Easy, just check for redundant use of `!=` and `==` in conditions. + + + +## Arithmetic + +### ES.100: Don't mix signed and unsigned arithmetic + +##### Reason + +Avoid wrong results. + +##### Example + + int x = -3; + unsigned int y = 7; + + cout << x - y << '\n'; // unsigned result, possibly 4294967286 + cout << x + y << '\n'; // unsigned result: 4 + cout << x * y << '\n'; // unsigned result, possibly 4294967275 + +It is harder to spot the problem in more realistic examples. + +##### Note + +Unfortunately, C++ uses signed integers for array subscripts and the standard library uses unsigned integers for container subscripts. +This precludes consistency. Use `gsl::index` for subscripts; [see ES.107](#Res-subscripts). + +##### Enforcement + +* Compilers already know and sometimes warn. +* (To avoid noise) Do not flag on a mixed signed/unsigned comparison where one of the arguments is `sizeof` or a call to container `.size()` and the other is `ptrdiff_t`. + + +### ES.101: Use unsigned types for bit manipulation + +##### Reason + +Unsigned types support bit manipulation without surprises from sign bits. + +##### Example + + unsigned char x = 0b1010'1010; + unsigned char y = ~x; // y == 0b0101'0101; + +##### Note + +Unsigned types can also be useful for modular arithmetic. +However, if you want modular arithmetic add +comments as necessary noting the reliance on wraparound behavior, as such code +can be surprising for many programmers. + +##### Enforcement + +* Just about impossible in general because of the use of unsigned subscripts in the standard library +* ??? + +### ES.102: Use signed types for arithmetic + +##### Reason + +Because most arithmetic is assumed to be signed; +`x - y` yields a negative number when `y > x` except in the rare cases where you really want modular arithmetic. + +##### Example + +Unsigned arithmetic can yield surprising results if you are not expecting it. +This is even more true for mixed signed and unsigned arithmetic. + + template + T subtract(T x, T2 y) + { + return x - y; + } + + void test() + { + int s = 5; + unsigned int us = 5; + cout << subtract(s, 7) << '\n'; // -2 + cout << subtract(us, 7u) << '\n'; // 4294967294 + cout << subtract(s, 7u) << '\n'; // -2 + cout << subtract(us, 7) << '\n'; // 4294967294 + cout << subtract(s, us + 2) << '\n'; // -2 + cout << subtract(us, s + 2) << '\n'; // 4294967294 + } + +Here we have been very explicit about what's happening, +but if you had seen `us - (s + 2)` or `s += 2; ...; us - s`, would you reliably have suspected that the result would print as `4294967294`? + +##### Exception + +Use unsigned types if you really want modular arithmetic - add +comments as necessary noting the reliance on overflow behavior, as such code +is going to be surprising for many programmers. + +##### Example + +The standard library uses unsigned types for subscripts. +The built-in array uses signed types for subscripts. +This makes surprises (and bugs) inevitable. + + int a[10]; + for (int i = 0; i < 10; ++i) a[i] = i; + vector v(10); + // compares signed to unsigned; some compilers warn, but we should not + for (gsl::index i = 0; i < v.size(); ++i) v[i] = i; + + int a2[-2]; // error: negative size + + // OK, but the number of ints (4294967294) is so large that we should get an exception + vector v2(-2); + + Use `gsl::index` for subscripts; [see ES.107](#Res-subscripts). + +##### Enforcement + +* Flag mixed signed and unsigned arithmetic +* Flag results of unsigned arithmetic assigned to or printed as signed. +* Flag negative literals (e.g. `-2`) used as container subscripts. +* (To avoid noise) Do not flag on a mixed signed/unsigned comparison where one of the arguments is `sizeof` or a call to container `.size()` and the other is `ptrdiff_t`. + + +### ES.103: Don't overflow + +##### Reason + +Overflow usually makes your numeric algorithm meaningless. +Incrementing a value beyond a maximum value can lead to memory corruption and undefined behavior. + +##### Example, bad + + int a[10]; + a[10] = 7; // bad, array bounds overflow + + for (int n = 0; n <= 10; ++n) + a[n] = 9; // bad, array bounds overflow + +##### Example, bad + + int n = numeric_limits::max(); + int m = n + 1; // bad, numeric overflow + +##### Example, bad + + int area(int h, int w) { return h * w; } + + auto a = area(10'000'000, 100'000'000); // bad, numeric overflow + +##### Exception + +Use unsigned types if you really want modular arithmetic. + +**Alternative**: For critical applications that can afford some overhead, use a range-checked integer and/or floating-point type. + +##### Enforcement + +??? + +### ES.104: Don't underflow + +##### Reason + +Decrementing a value beyond a minimum value can lead to memory corruption and undefined behavior. + +##### Example, bad + + int a[10]; + a[-2] = 7; // bad + + int n = 101; + while (n--) + a[n - 1] = 9; // bad (twice) + +##### Exception + +Use unsigned types if you really want modular arithmetic. + +##### Enforcement + +??? + +### ES.105: Don't divide by integer zero + +##### Reason + +The result is undefined and probably a crash. + +##### Note + +This also applies to `%`. + +##### Example, bad + + int divide(int a, int b) + { + // BAD, should be checked (e.g., in a precondition) + return a / b; + } + +##### Example, good + + int divide(int a, int b) + { + // good, address via precondition (and replace with contracts once C++ gets them) + Expects(b != 0); + return a / b; + } + + double divide(double a, double b) + { + // good, address via using double instead + return a / b; + } + +**Alternative**: For critical applications that can afford some overhead, use a range-checked integer and/or floating-point type. + +##### Enforcement + +* Flag division by an integral value that could be zero + + +### ES.106: Don't try to avoid negative values by using `unsigned` + +##### Reason + +Choosing `unsigned` implies many changes to the usual behavior of integers, including modular arithmetic, +can suppress warnings related to overflow, +and opens the door for errors related to signed/unsigned mixes. +Using `unsigned` doesn't actually eliminate the possibility of negative values. + +##### Example + + unsigned int u1 = -2; // Valid: the value of u1 is 4294967294 + int i1 = -2; + unsigned int u2 = i1; // Valid: the value of u2 is 4294967294 + int i2 = u2; // Valid: the value of i2 is -2 + +These problems with such (perfectly legal) constructs are hard to spot in real code and are the source of many real-world errors. +Consider: + + unsigned area(unsigned height, unsigned width) { return height*width; } // [see also](#Ri-expects) + // ... + int height; + cin >> height; + auto a = area(height, 2); // if the input is -2 a becomes 4294967292 + +Remember that `-1` when assigned to an `unsigned int` becomes the largest `unsigned int`. +Also, since unsigned arithmetic is modular arithmetic the multiplication didn't overflow, it wrapped around. + +##### Example + + unsigned max = 100000; // "accidental typo", I mean to say 10'000 + unsigned short x = 100; + while (x < max) x += 100; // infinite loop + +Had `x` been a signed `short`, we could have warned about the undefined behavior upon overflow. + +##### Alternatives + +* use signed integers and check for `x >= 0` +* use a positive integer type +* use an integer subrange type +* `Assert(-1 < x)` + +For example + + struct Positive { + int val; + Positive(int x) :val{x} { Assert(0 < x); } + operator int() { return val; } + }; + + int f(Positive arg) { return arg; } + + int r1 = f(2); + int r2 = f(-2); // throws + +##### Note + +??? + +##### Enforcement + +See ES.100 Enforcements. + + +### ES.107: Don't use `unsigned` for subscripts, prefer `gsl::index` + +##### Reason + +To avoid signed/unsigned confusion. +To enable better optimization. +To enable better error detection. +To avoid the pitfalls with `auto` and `int`. + +##### Example, bad + + vector vec = /*...*/; + + for (int i = 0; i < vec.size(); i += 2) // might not be big enough + cout << vec[i] << '\n'; + for (unsigned i = 0; i < vec.size(); i += 2) // risk wraparound + cout << vec[i] << '\n'; + for (auto i = 0; i < vec.size(); i += 2) // might not be big enough + cout << vec[i] << '\n'; + for (vector::size_type i = 0; i < vec.size(); i += 2) // verbose + cout << vec[i] << '\n'; + for (auto i = vec.size()-1; i >= 0; i -= 2) // bug + cout << vec[i] << '\n'; + for (int i = vec.size()-1; i >= 0; i -= 2) // might not be big enough + cout << vec[i] << '\n'; + +##### Example, good + + vector vec = /*...*/; + + for (gsl::index i = 0; i < vec.size(); i += 2) // ok + cout << vec[i] << '\n'; + for (gsl::index i = vec.size()-1; i >= 0; i -= 2) // ok + cout << vec[i] << '\n'; + +##### Note + +The built-in array allows signed subscripts. +The standard-library containers use unsigned subscripts. +Thus, no perfect and fully compatible solution is possible (unless and until the standard-library containers change to use signed subscripts someday in the future). +Given the known problems with unsigned and signed/unsigned mixtures, better stick to (signed) integers of a sufficient size, which is guaranteed by `gsl::index`. + +##### Example + + template + struct My_container { + public: + // ... + T& operator[](gsl::index i); // not unsigned + // ... + }; + +##### Example + + ??? demonstrate improved code generation and potential for error detection ??? + +##### Alternatives + +Alternatives for users + +* use algorithms +* use range-for +* use iterators/pointers + +##### Enforcement + +* Very tricky as long as the standard-library containers get it wrong. +* (To avoid noise) Do not flag on a mixed signed/unsigned comparison where one of the arguments is `sizeof` or a call to container `.size()` and the other is `ptrdiff_t`. + + + + +# Per: Performance + +??? should this section be in the main guide??? + +This section contains rules for people who need high performance or low-latency. +That is, these are rules that relate to how to use as little time and as few resources as possible to achieve a task in a predictably short time. +The rules in this section are more restrictive and intrusive than what is needed for many (most) applications. +Do not naïvely try to follow them in general code: achieving the goals of low latency requires extra work. + +Performance rule summary: + +* [Per.1: Don't optimize without reason](#Rper-reason) +* [Per.2: Don't optimize prematurely](#Rper-Knuth) +* [Per.3: Don't optimize something that's not performance critical](#Rper-critical) +* [Per.4: Don't assume that complicated code is necessarily faster than simple code](#Rper-simple) +* [Per.5: Don't assume that low-level code is necessarily faster than high-level code](#Rper-low) +* [Per.6: Don't make claims about performance without measurements](#Rper-measure) +* [Per.7: Design to enable optimization](#Rper-efficiency) +* [Per.10: Rely on the static type system](#Rper-type) +* [Per.11: Move computation from run time to compile time](#Rper-Comp) +* [Per.12: Eliminate redundant aliases](#Rper-alias) +* [Per.13: Eliminate redundant indirections](#Rper-indirect) +* [Per.14: Minimize the number of allocations and deallocations](#Rper-alloc) +* [Per.15: Do not allocate on a critical branch](#Rper-alloc0) +* [Per.16: Use compact data structures](#Rper-compact) +* [Per.17: Declare the most used member of a time-critical struct first](#Rper-struct) +* [Per.18: Space is time](#Rper-space) +* [Per.19: Access memory predictably](#Rper-access) +* [Per.30: Avoid context switches on the critical path](#Rper-context) + +### Per.1: Don't optimize without reason + +##### Reason + +If there is no need for optimization, the main result of the effort will be more errors and higher maintenance costs. + +##### Note + +Some people optimize out of habit or because it's fun. + +??? + +### Per.2: Don't optimize prematurely + +##### Reason + +Elaborately optimized code is usually larger and harder to change than unoptimized code. + +??? + +### Per.3: Don't optimize something that's not performance critical + +##### Reason + +Optimizing a non-performance-critical part of a program has no effect on system performance. + +##### Note + +If your program spends most of its time waiting for the web or for a human, optimization of in-memory computation is probably useless. + +Put another way: If your program spends 4% of its processing time doing +computation A and 40% of its time doing computation B, a 50% improvement on A is +only as impactful as a 5% improvement on B. (If you don't even know how much +time is spent on A or B, see Per.1 and Per.2.) + +### Per.4: Don't assume that complicated code is necessarily faster than simple code + +##### Reason + +Simple code can be very fast. Optimizers sometimes do marvels with simple code + +##### Example, good + + // clear expression of intent, fast execution + + vector v(100000); + + for (auto& c : v) + c = ~c; + +##### Example, bad + + // intended to be faster, but is often slower + + vector v(100000); + + for (size_t i = 0; i < v.size(); i += sizeof(uint64_t)) { + uint64_t& quad_word = *reinterpret_cast(&v[i]); + quad_word = ~quad_word; + } + +##### Note + +??? + +??? + +### Per.5: Don't assume that low-level code is necessarily faster than high-level code + +##### Reason + +Low-level code sometimes inhibits optimizations. Optimizers sometimes do marvels with high-level code. + +##### Note + +??? + +??? + +### Per.6: Don't make claims about performance without measurements + +##### Reason + +The field of performance is littered with myth and bogus folklore. +Modern hardware and optimizers defy naive assumptions; even experts are regularly surprised. + +##### Note + +Getting good performance measurements can be hard and require specialized tools. + +##### Note + +A few simple microbenchmarks using Unix `time` or the standard-library `` can help dispel the most obvious myths. +If you can't measure your complete system accurately, at least try to measure a few of your key operations and algorithms. +A profiler can help tell you which parts of your system are performance critical. +Often, you will be surprised. + +??? + +### Per.7: Design to enable optimization + +##### Reason + +Because we often need to optimize the initial design. +Because a design that ignores the possibility of later improvement is hard to change. + +##### Example + +From the C (and C++) standard: + + void qsort (void* base, size_t num, size_t size, int (*compar)(const void*, const void*)); + +When did you even want to sort memory? +Really, we sort sequences of elements, typically stored in containers. +A call to `qsort` throws away much useful information (e.g., the element type), forces the user to repeat information +already known (e.g., the element size), and forces the user to write extra code (e.g., a function to compare `double`s). +This implies added work for the programmer, is error-prone, and deprives the compiler of information needed for optimization. + + double data[100]; + // ... fill a ... + + // 100 chunks of memory of sizeof(double) starting at + // address data using the order defined by compare_doubles + qsort(data, 100, sizeof(double), compare_doubles); + +From the point of view of interface design, `qsort` throws away useful information. + +We can do better (in C++98) + + template + void sort(Iter b, Iter e); // sort [b:e) + + sort(data, data + 100); + +Here, we use the compiler's knowledge about the size of the array, the type of elements, and how to compare `double`s. + +With C++20, we can do better still + + // sortable specifies that c must be a + // random-access sequence of elements comparable with < + void sort(sortable auto& c); + + sort(c); + +The key is to pass sufficient information for a good implementation to be chosen. +In this, the `sort` interfaces shown here still have a weakness: +They implicitly rely on the element type having less-than (`<`) defined. +To complete the interface, we need a second version that accepts a comparison criterion: + + // compare elements of c using r + template requires sortable + void sort(R&& r, C c); + +The standard-library specification of `sort` offers those two versions, and more. + +##### Note + +Premature optimization is said to be [the root of all evil](#Rper-Knuth), but that's not a reason to despise performance. +It is never premature to consider what makes a design amenable to improvement, and improved performance is a commonly desired improvement. +Aim to build a set of habits that by default results in efficient, maintainable, and optimizable code. +In particular, when you write a function that is not a one-off implementation detail, consider + +* Information passing: +Prefer clean [interfaces](#S-interfaces) carrying sufficient information for later improvement of implementation. +Note that information flows into and out of an implementation through the interfaces we provide. +* Compact data: By default, [use compact data](#Rper-compact), such as `std::vector` and [access it in a systematic fashion](#Rper-access). +If you think you need a linked structure, try to craft the interface so that this structure isn't seen by users. +* Function argument passing and return: +Distinguish between mutable and non-mutable data. +Don't impose a resource management burden on your users. +Don't impose spurious run-time indirections on your users. +Use [conventional ways](#Rf-conventional) of passing information through an interface; +unconventional and/or "optimized" ways of passing data can seriously complicate later reimplementation. +* Abstraction: +Don't overgeneralize; a design that tries to cater for every possible use (and misuse) and defers every design decision for later +(using compile-time or run-time indirections) is usually a complicated, bloated, hard-to-understand mess. +Generalize from concrete examples, preserving performance as we generalize. +Do not generalize based on mere speculation about future needs. +The ideal is zero-overhead generalization. +* Libraries: +Use libraries with good interfaces. +If no library is available build one yourself and imitate the interface style from a good library. +The [standard library](#sl-the-standard-library) is a good first place to look for inspiration. +* Isolation: +Isolate your code from messy and/or old-style code by providing an interface of your choosing to it. +This is sometimes called "providing a wrapper" for the useful/necessary but messy code. +Don't let bad designs "bleed into" your code. + +##### Example + +Consider: + + template + bool binary_search(ForwardIterator first, ForwardIterator last, const T& val); + +`binary_search(begin(c), end(c), 7)` will tell you whether `7` is in `c` or not. +However, it will not tell you where that `7` is or whether there are more than one `7`. + +Sometimes, just passing the minimal amount of information back (here, `true` or `false`) is sufficient, but a good interface passes +needed information back to the caller. Therefore, the standard library also offers + + template + ForwardIterator lower_bound(ForwardIterator first, ForwardIterator last, const T& val); + +`lower_bound` returns an iterator to the first match if any, otherwise to the first element greater than `val`, or `last` if no such element is found. + +However, `lower_bound` still doesn't return enough information for all uses, so the standard library also offers + + template + pair + equal_range(ForwardIterator first, ForwardIterator last, const T& val); + +`equal_range` returns a `pair` of iterators specifying the first and one beyond last match. + + auto r = equal_range(begin(c), end(c), 7); + for (auto p = r.first; p != r.second; ++p) + cout << *p << '\n'; + +Obviously, these three interfaces are implemented by the same basic code. +They are simply three ways of presenting the basic binary search algorithm to users, +ranging from the simplest ("make simple things simple!") +to returning complete, but not always needed, information ("don't hide useful information"). +Naturally, crafting such a set of interfaces requires experience and domain knowledge. + +##### Note + +Do not simply craft the interface to match the first implementation and the first use case you think of. +Once your first initial implementation is complete, review it; once you deploy it, mistakes will be hard to remedy. + +##### Note + +A need for efficiency does not imply a need for [low-level code](#Rper-low). +High-level code isn't necessarily slow or bloated. + +##### Note + +Things have costs. +Don't be paranoid about costs (modern computers really are very fast), +but have a rough idea of the order of magnitude of cost of what you use. +For example, have a rough idea of the cost of +a memory access, +a function call, +a string comparison, +a system call, +a disk access, +and a message through a network. + +##### Note + +If you can only think of one implementation, you probably don't have something for which you can devise a stable interface. +Maybe, it is just an implementation detail - not every piece of code needs a stable interface - but pause and consider. +One question that can be useful is +"what interface would be needed if this operation should be implemented using multiple threads? be vectorized?" + +##### Note + +This rule does not contradict the [Don't optimize prematurely](#Rper-Knuth) rule. +It complements it, encouraging developers to enable later - appropriate and non-premature - optimization, if and where needed. + +##### Enforcement + +Tricky. +Maybe looking for `void*` function arguments will find examples of interfaces that hinder later optimization. + +### Per.10: Rely on the static type system + +##### Reason + +Type violations, weak types (e.g. `void*`s), and low-level code (e.g., manipulation of sequences as individual bytes) make the job of the optimizer much harder. Simple code often optimizes better than hand-crafted complex code. + +??? + +### Per.11: Move computation from run time to compile time + +##### Reason + +To decrease code size and run time. +To avoid data races by using constants. +To catch errors at compile time (and thus eliminate the need for error-handling code). + +##### Example + + double square(double d) { return d*d; } + static double s2 = square(2); // old-style: dynamic initialization + + constexpr double ntimes(double d, int n) // assume 0 <= n + { + double m = 1; + while (n--) m *= d; + return m; + } + constexpr double s3 {ntimes(2, 3)}; // modern-style: compile-time initialization + +Code like the initialization of `s2` isn't uncommon, especially for initialization that's a bit more complicated than `square()`. +However, compared to the initialization of `s3` there are two problems: + +* we suffer the overhead of a function call at run time +* `s2` just might be accessed by another thread before the initialization happens. + +Note: you can't have a data race on a constant. + +##### Example + +Consider a popular technique for providing a handle for storing small objects in the handle itself and larger ones on the heap. + + constexpr int on_stack_max = 20; + + template + struct Scoped { // store a T in Scoped + // ... + T obj; + }; + + template + struct On_heap { // store a T on the free store + // ... + T* objp; + }; + + template + using Handle = typename std::conditional<(sizeof(T) <= on_stack_max), + Scoped, // first alternative + On_heap // second alternative + >::type; + + void f() + { + Handle v1; // the double goes on the stack + Handle> v2; // the array goes on the free store + // ... + } + +Assume that `Scoped` and `On_heap` provide compatible user interfaces. +Here we compute the optimal type to use at compile time. +There are similar techniques for selecting the optimal function to call. + +##### Note + +The ideal is *not* to try to execute everything at compile time. +Obviously, most computations depend on inputs, so they can't be moved to compile time, +but beyond that logical constraint is the fact that complex compile-time computation can seriously increase compile times +and complicate debugging. +It is even possible to slow down code by compile-time computation. +This is admittedly rare, but by factoring out a general computation into separate optimal sub-calculations, it is possible to render the instruction cache less effective. + +##### Enforcement + +* Look for simple functions that might be constexpr (but are not). +* Look for functions called with all constant-expression arguments. +* Look for macros that could be constexpr. + +### Per.12: Eliminate redundant aliases + +??? + +### Per.13: Eliminate redundant indirections + +??? + +### Per.14: Minimize the number of allocations and deallocations + +??? + +### Per.15: Do not allocate on a critical branch + +??? + +### Per.16: Use compact data structures + +##### Reason + +Performance is typically dominated by memory access times. + +??? + +### Per.17: Declare the most used member of a time-critical struct first + +??? + +### Per.18: Space is time + +##### Reason + +Performance is typically dominated by memory access times. + +??? + +### Per.19: Access memory predictably + +##### Reason + +Performance is very sensitive to cache performance, and cache algorithms favor simple (usually linear) access to adjacent data. + +##### Example + + int matrix[rows][cols]; + + // bad + for (int c = 0; c < cols; ++c) + for (int r = 0; r < rows; ++r) + sum += matrix[r][c]; + + // good + for (int r = 0; r < rows; ++r) + for (int c = 0; c < cols; ++c) + sum += matrix[r][c]; + +### Per.30: Avoid context switches on the critical path + +??? + +# CP: Concurrency and parallelism + +We often want our computers to do many tasks at the same time (or at least appear to do them at the same time). +The reasons for doing so vary (e.g., waiting for many events using only a single processor, processing many data streams simultaneously, or utilizing many hardware facilities) +and so do the basic facilities for expressing concurrency and parallelism. +Here, we articulate principles and rules for using the ISO standard C++ facilities for expressing basic concurrency and parallelism. + +Threads are the machine-level foundation for concurrent and parallel programming. +Threads allow running multiple sections of a program independently, while sharing +the same memory. Concurrent programming is tricky, +because protecting shared data between threads is easier said than done. +Making existing single-threaded code execute concurrently can be +as trivial as adding `std::async` or `std::thread` strategically, or it can +necessitate a full rewrite, depending on whether the original code was written +in a thread-friendly way. + +The concurrency/parallelism rules in this document are designed with three goals +in mind: + +* To help in writing code that is amenable to being used in a threaded + environment +* To show clean, safe ways to use the threading primitives offered by the + standard library +* To offer guidance on what to do when concurrency and parallelism aren't giving + the performance gains needed + +It is also important to note that concurrency in C++ is an unfinished +story. C++11 introduced many core concurrency primitives, C++14 and C++17 improved on +them, and there is much interest in making the writing of +concurrent programs in C++ even easier. We expect some of the library-related +guidance here to change significantly over time. + +This section needs a lot of work (obviously). +Please note that we start with rules for relative non-experts. +Real experts must wait a bit; +contributions are welcome, +but please think about the majority of programmers who are struggling to get their concurrent programs correct and performant. + +Concurrency and parallelism rule summary: + +* [CP.1: Assume that your code will run as part of a multi-threaded program](#Rconc-multi) +* [CP.2: Avoid data races](#Rconc-races) +* [CP.3: Minimize explicit sharing of writable data](#Rconc-data) +* [CP.4: Think in terms of tasks, rather than threads](#Rconc-task) +* [CP.8: Don't try to use `volatile` for synchronization](#Rconc-volatile) +* [CP.9: Whenever feasible use tools to validate your concurrent code](#Rconc-tools) + +**See also**: + +* [CP.con: Concurrency](#SScp-con) +* [CP.coro: Coroutines](#SScp-coro) +* [CP.par: Parallelism](#SScp-par) +* [CP.mess: Message passing](#SScp-mess) +* [CP.vec: Vectorization](#SScp-vec) +* [CP.free: Lock-free programming](#SScp-free) +* [CP.etc: Etc. concurrency rules](#SScp-etc) + +### CP.1: Assume that your code will run as part of a multi-threaded program + +##### Reason + +It's hard to be certain that concurrency isn't used now or won't be used sometime in the future. +Code gets reused. +Libraries not using threads might be used from some other part of a program that does use threads. +Note that this rule applies most urgently to library code and least urgently to stand-alone applications. +However, over time, code fragments can turn up in unexpected places. + +##### Example, bad + + double cached_computation(int x) + { + // bad: these statics cause data races in multi-threaded usage + static int cached_x = 0.0; + static double cached_result = COMPUTATION_OF_ZERO; + + if (cached_x != x) { + cached_x = x; + cached_result = computation(x); + } + return cached_result; + } + +Although `cached_computation` works perfectly in a single-threaded environment, in a multi-threaded environment the two `static` variables result in data races and thus undefined behavior. + +##### Example, good + + struct ComputationCache { + int cached_x = 0; + double cached_result = COMPUTATION_OF_ZERO; + + double compute(int x) { + if (cached_x != x) { + cached_x = x; + cached_result = computation(x); + } + return cached_result; + } + }; + +Here the cache is stored as member data of a `ComputationCache` object, rather than as shared static state. +This refactoring essentially delegates the concern upward to the caller: a single-threaded program +might still choose to have one global `ComputationCache`, while a multi-threaded program might +have one `ComputationCache` instance per thread, or one per "context" for any definition of "context." +The refactored function no longer attempts to manage the allocation of `cached_x`. In that sense, +this is an application of the Single Responsibility Principle. + +In this specific example, refactoring for thread-safety also improved reusability in single-threaded +programs. It's not hard to imagine that a single-threaded program might want two `ComputationCache` instances +for use in different parts of the program, without having them overwrite each other's cached data. + +There are several other ways one might add thread-safety to code written for a standard multi-threaded environment +(that is, one where the only form of concurrency is `std::thread`): + +* Mark the state variables as `thread_local` instead of `static`. +* Implement concurrency control, for example, protecting access to the two `static` variables with a `static std::mutex`. +* Refuse to build and/or run in a multi-threaded environment. +* Provide two implementations: one for single-threaded environments and another for multi-threaded environments. + +##### Exception + +Code that is never run in a multi-threaded environment. + +Be careful: there are many examples where code that was "known" to never run in a multi-threaded program +was run as part of a multi-threaded program, often years later. +Typically, such programs lead to a painful effort to remove data races. +Therefore, code that is never intended to run in a multi-threaded environment should be clearly labeled as such and ideally come with compile or run-time enforcement mechanisms to catch those usage bugs early. + +### CP.2: Avoid data races + +##### Reason + +Unless you do, nothing is guaranteed to work and subtle errors will persist. + +##### Note + +In a nutshell, if two threads can access the same object concurrently (without synchronization), and at least one is a writer (performing a non-`const` operation), you have a data race. +For further information of how to use synchronization well to eliminate data races, please consult a good book about concurrency (See [Carefully study the literature](#Rconc-literature)). + +##### Example, bad + +There are many examples of data races that exist, some of which are running in +production software at this very moment. One very simple example: + + int get_id() + { + static int id = 1; + return id++; + } + +The increment here is an example of a data race. This can go wrong in many ways, +including: + +* Thread A loads the value of `id`, the OS context switches A out for some + period, during which other threads create hundreds of IDs. Thread A is then + allowed to run again, and `id` is written back to that location as A's read of + `id` plus one. +* Thread A and B load `id` and increment it simultaneously. They both get the + same ID. + +Local static variables are a common source of data races. + +##### Example, bad: + + void f(fstream& fs, regex pattern) + { + array buf; + int sz = read_vec(fs, buf, max); // read from fs into buf + gsl::span s {buf}; + // ... + auto h1 = async([&] { sort(std::execution::par, s); }); // spawn a task to sort + // ... + auto h2 = async([&] { return find_all(buf, sz, pattern); }); // spawn a task to find matches + // ... + } + +Here, we have a (nasty) data race on the elements of `buf` (`sort` will both read and write). +All data races are nasty. +Here, we managed to get a data race on data on the stack. +Not all data races are as easy to spot as this one. + +##### Example, bad: + + // code not controlled by a lock + + unsigned val; + + if (val < 5) { + // ... other thread can change val here ... + switch (val) { + case 0: // ... + case 1: // ... + case 2: // ... + case 3: // ... + case 4: // ... + } + } + +Now, a compiler that does not know that `val` can change will most likely implement that `switch` using a jump table with five entries. +Then, a `val` outside the `[0..4]` range will cause a jump to an address that could be anywhere in the program, and execution would proceed there. +Really, "all bets are off" if you get a data race. +Actually, it can be worse still: by looking at the generated code you might be able to determine where the stray jump will go for a given value; +this can be a security risk. + +##### Enforcement + +Some is possible, do at least something. +There are commercial and open-source tools that try to address this problem, +but be aware that solutions have costs and blind spots. +Static tools often have many false positives and run-time tools often have a significant cost. +We hope for better tools. +Using multiple tools can catch more problems than a single one. + +There are other ways you can mitigate the chance of data races: + +* Avoid global data +* Avoid `static` variables +* More use of concrete types on the stack (and don't pass pointers around too much) +* More use of immutable data (literals, `constexpr`, and `const`) + +### CP.3: Minimize explicit sharing of writable data + +##### Reason + +If you don't share writable data, you can't have a data race. +The less sharing you do, the less chance you have to forget to synchronize access (and get data races). +The less sharing you do, the less chance you have to wait on a lock (so performance can improve). + +##### Example + + bool validate(const vector&); + Graph temperature_gradients(const vector&); + Image altitude_map(const vector&); + // ... + + void process_readings(const vector& surface_readings) + { + auto h1 = async([&] { if (!validate(surface_readings)) throw Invalid_data{}; }); + auto h2 = async([&] { return temperature_gradients(surface_readings); }); + auto h3 = async([&] { return altitude_map(surface_readings); }); + // ... + h1.get(); + auto v2 = h2.get(); + auto v3 = h3.get(); + // ... + } + +Without those `const`s, we would have to review every asynchronously invoked function for potential data races on `surface_readings`. +Making `surface_readings` be `const` (with respect to this function) allow reasoning using only the function body. + +##### Note + +Immutable data can be safely and efficiently shared. +No locking is needed: You can't have a data race on a constant. +See also [CP.mess: Message Passing](#SScp-mess) and [CP.31: prefer pass by value](#Rconc-data-by-value). + +##### Enforcement + +??? + + +### CP.4: Think in terms of tasks, rather than threads + +##### Reason + +A `thread` is an implementation concept, a way of thinking about the machine. +A task is an application notion, something you'd like to do, preferably concurrently with other tasks. +Application concepts are easier to reason about. + +##### Example + + void some_fun(const std::string& msg) + { + std::thread publisher([=] { std::cout << msg; }); // bad: less expressive + // and more error-prone + auto pubtask = std::async([=] { std::cout << msg; }); // OK + // ... + publisher.join(); + } + +##### Note + +With the exception of `async()`, the standard-library facilities are low-level, machine-oriented, threads-and-lock level. +This is a necessary foundation, but we have to try to raise the level of abstraction: for productivity, for reliability, and for performance. +This is a potent argument for using higher level, more applications-oriented libraries (if possible, built on top of standard-library facilities). + +##### Enforcement + +??? + +### CP.8: Don't try to use `volatile` for synchronization + +##### Reason + +In C++, unlike some other languages, `volatile` does not provide atomicity, does not synchronize between threads, +and does not prevent instruction reordering (neither compiler nor hardware). +It simply has nothing to do with concurrency. + +##### Example, bad: + + int free_slots = max_slots; // current source of memory for objects + + Pool* use() + { + if (int n = free_slots--) return &pool[n]; + } + +Here we have a problem: +This is perfectly good code in a single-threaded program, but have two threads execute this and +there is a race condition on `free_slots` so that two threads might get the same value and `free_slots`. +That's (obviously) a bad data race, so people trained in other languages might try to fix it like this: + + volatile int free_slots = max_slots; // current source of memory for objects + + Pool* use() + { + if (int n = free_slots--) return &pool[n]; + } + +This has no effect on synchronization: The data race is still there! + +The C++ mechanism for this is `atomic` types: + + atomic free_slots = max_slots; // current source of memory for objects + + Pool* use() + { + if (int n = free_slots--) return &pool[n]; + } + +Now the `--` operation is atomic, +rather than a read-increment-write sequence where another thread might get in-between the individual operations. + +##### Alternative + +Use `atomic` types where you might have used `volatile` in some other language. +Use a `mutex` for more complicated examples. + +##### See also + +[(rare) proper uses of `volatile`](#Rconc-volatile2) + +### CP.9: Whenever feasible use tools to validate your concurrent code + +Experience shows that concurrent code is exceptionally hard to get right +and that compile-time checking, run-time checks, and testing are less effective at finding concurrency errors +than they are at finding errors in sequential code. +Subtle concurrency errors can have dramatically bad effects, including memory corruption, deadlocks, and security vulnerabilities. + +##### Example + + ??? + +##### Note + +Thread safety is challenging, often getting the better of experienced programmers: tooling is an important strategy to mitigate those risks. +There are many tools "out there", both commercial and open-source tools, both research and production tools. +Unfortunately people's needs and constraints differ so dramatically that we cannot make specific recommendations, +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 data member 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, +absolutely identifying data races in a given execution of your binary. +The cost for this is both memory (5-10x in most cases) and CPU slowdown (2-20x). +Dynamic tools like this are best when applied to integration tests, canary pushes, or unit tests that operate on multiple threads. +Workload matters: When TSAN identifies a problem, it is effectively always an actual data race, +but it can only identify races seen in a given execution. + +##### Enforcement + +It is up to an application builder to choose which support tools are valuable for a particular application. + +## CP.con: Concurrency + +This section focuses on relatively ad-hoc uses of multiple threads communicating through shared data. + +* For parallel algorithms, see [parallelism](#SScp-par) +* For inter-task communication without explicit sharing, see [messaging](#SScp-mess) +* For vector parallel code, see [vectorization](#SScp-vec) +* For lock-free programming, see [lock free](#SScp-free) + +Concurrency rule summary: + +* [CP.20: Use RAII, never plain `lock()`/`unlock()`](#Rconc-raii) +* [CP.21: Use `std::lock()` or `std::scoped_lock` to acquire multiple `mutex`es](#Rconc-lock) +* [CP.22: Never call unknown code while holding a lock (e.g., a callback)](#Rconc-unknown) +* [CP.23: Think of a joining `thread` as a scoped container](#Rconc-join) +* [CP.24: Think of a `thread` as a global container](#Rconc-detach) +* [CP.25: Prefer `gsl::joining_thread` over `std::thread`](#Rconc-joining_thread) +* [CP.26: Don't `detach()` a thread](#Rconc-detached_thread) +* [CP.31: Pass small amounts of data between threads by value, rather than by reference or pointer](#Rconc-data-by-value) +* [CP.32: To share ownership between unrelated `thread`s use `shared_ptr`](#Rconc-shared) +* [CP.40: Minimize context switching](#Rconc-switch) +* [CP.41: Minimize thread creation and destruction](#Rconc-create) +* [CP.42: Don't `wait` without a condition](#Rconc-wait) +* [CP.43: Minimize time spent in a critical section](#Rconc-time) +* [CP.44: Remember to name your `lock_guard`s and `unique_lock`s](#Rconc-name) +* [CP.50: Define a `mutex` together with the data it guards. Use `synchronized_value` where possible](#Rconc-mutex) +* ??? when to use a spinlock +* ??? when to use `try_lock()` +* ??? when to prefer `lock_guard` over `unique_lock` +* ??? Time multiplexing +* ??? when/how to use `new thread` + +### CP.20: Use RAII, never plain `lock()`/`unlock()` + +##### Reason + +Avoids nasty errors from unreleased locks. + +##### Example, bad + + mutex mtx; + + void do_stuff() + { + mtx.lock(); + // ... do stuff ... + mtx.unlock(); + } + +Sooner or later, someone will forget the `mtx.unlock()`, place a `return` in the `... do stuff ...`, throw an exception, or something. + + mutex mtx; + + void do_stuff() + { + unique_lock lck {mtx}; + // ... do stuff ... + } + +##### Enforcement + +Flag calls of member `lock()` and `unlock()`. ??? + + +### CP.21: Use `std::lock()` or `std::scoped_lock` to acquire multiple `mutex`es + +##### Reason + +To avoid deadlocks on multiple `mutex`es. + +##### Example + +This is asking for deadlock: + + // thread 1 + lock_guard lck1(m1); + lock_guard lck2(m2); + + // thread 2 + lock_guard lck2(m2); + lock_guard lck1(m1); + +Instead, use `lock()`: + + // thread 1 + lock(m1, m2); + lock_guard lck1(m1, adopt_lock); + lock_guard lck2(m2, adopt_lock); + + // thread 2 + lock(m2, m1); + lock_guard lck2(m2, adopt_lock); + lock_guard lck1(m1, adopt_lock); + +or (better, but C++17 only): + + // thread 1 + scoped_lock lck1(m1, m2); + + // thread 2 + scoped_lock lck2(m2, m1); + +Here, the writers of `thread1` and `thread2` are still not agreeing on the order of the `mutex`es, but order no longer matters. + +##### Note + +In real code, `mutex`es are rarely named to conveniently remind the programmer of an intended relation and intended order of acquisition. +In real code, `mutex`es are not always conveniently acquired on consecutive lines. + +##### Note + +In C++17 it's possible to write plain + + lock_guard lck1(m1, adopt_lock); + +and have the `mutex` type deduced. + +##### Enforcement + +Detect the acquisition of multiple `mutex`es. +This is undecidable in general, but catching common simple examples (like the one above) is easy. + + +### CP.22: Never call unknown code while holding a lock (e.g., a callback) + +##### Reason + +If you don't know what a piece of code does, you are risking deadlock. + +##### Example + + void do_this(Foo* p) + { + lock_guard lck {my_mutex}; + // ... do something ... + p->act(my_data); + // ... + } + +If you don't know what `Foo::act` does (maybe it is a virtual function invoking a derived class member of a class not yet written), +it might call `do_this` (recursively) and cause a deadlock on `my_mutex`. +Maybe it will lock on a different mutex and not return in a reasonable time, causing delays to any code calling `do_this`. + +##### Example + +A common example of the "calling unknown code" problem is a call to a function that tries to gain locked access to the same object. +Such problem can often be solved by using a `recursive_mutex`. For example: + + recursive_mutex my_mutex; + + template + void do_something(Action f) + { + unique_lock lck {my_mutex}; + // ... do something ... + f(this); // f will do something to *this + // ... + } + +If, as it is likely, `f()` invokes operations on `*this`, we must make sure that the object's invariant holds before the call. + +##### Enforcement + +* Flag calling a virtual function with a non-recursive `mutex` held +* Flag calling a callback with a non-recursive `mutex` held + + +### CP.23: Think of a joining `thread` as a scoped container + +##### Reason + +To maintain pointer safety and avoid leaks, we need to consider what pointers are used by a `thread`. +If a `thread` joins, we can safely pass pointers to objects in the scope of the `thread` and its enclosing scopes. + +##### Example + + void f(int* p) + { + // ... + *p = 99; + // ... + } + int glob = 33; + + void some_fct(int* p) + { + int x = 77; + joining_thread t0(f, &x); // OK + joining_thread t1(f, p); // OK + joining_thread t2(f, &glob); // OK + auto q = make_unique(99); + joining_thread t3(f, q.get()); // OK + // ... + } + +A `gsl::joining_thread` is a `std::thread` with a destructor that joins and that cannot be `detached()`. +By "OK" we mean that the object will be in scope ("live") for as long as a `thread` can use the pointer to it. +The fact that `thread`s run concurrently doesn't affect the lifetime or ownership issues here; +these `thread`s can be seen as just a function object called from `some_fct`. + +##### Enforcement + +Ensure that `joining_thread`s don't `detach()`. +After that, the usual lifetime and ownership (for local objects) enforcement applies. + +### CP.24: Think of a `thread` as a global container + +##### Reason + +To maintain pointer safety and avoid leaks, we need to consider what pointers are used by a `thread`. +If a `thread` is detached, we can safely pass pointers to static and free store objects (only). + +##### Example + + void f(int* p) + { + // ... + *p = 99; + // ... + } + + int glob = 33; + + void some_fct(int* p) + { + int x = 77; + std::thread t0(f, &x); // bad + std::thread t1(f, p); // bad + std::thread t2(f, &glob); // OK + auto q = make_unique(99); + std::thread t3(f, q.get()); // bad + // ... + t0.detach(); + t1.detach(); + t2.detach(); + t3.detach(); + // ... + } + +By "OK" we mean that the object will be in scope ("live") for as long as a `thread` can use the pointers to it. +By "bad" we mean that a `thread` might use a pointer after the pointed-to object is destroyed. +The fact that `thread`s run concurrently doesn't affect the lifetime or ownership issues here; +these `thread`s can be seen as just a function object called from `some_fct`. + +##### Note + +Even objects with static storage duration can be problematic if used from detached threads: if the +thread continues until the end of the program, it might be running concurrently with the destruction +of objects with static storage duration, and thus accesses to such objects might race. + +##### Note + +This rule is redundant if you [don't `detach()`](#Rconc-detached_thread) and [use `gsl::joining_thread`](#Rconc-joining_thread). +However, converting code to follow those guidelines could be difficult and even impossible for third-party libraries. +In such cases, the rule becomes essential for lifetime safety and type safety. + + +In general, it is undecidable whether a `detach()` is executed for a `thread`, but simple common cases are easily detected. +If we cannot prove that a `thread` does not `detach()`, we must assume that it does and that it outlives the scope in which it was constructed; +After that, the usual lifetime and ownership (for global objects) enforcement applies. + +##### Enforcement + +Flag attempts to pass local variables to a thread that might `detach()`. + +### CP.25: Prefer `gsl::joining_thread` over `std::thread` + +##### Reason + +A `joining_thread` is a thread that joins at the end of its scope. +Detached threads are hard to monitor. +It is harder to ensure absence of errors in detached threads (and potentially detached threads). + +##### Example, bad + + void f() { std::cout << "Hello "; } + + struct F { + void operator()() const { std::cout << "parallel world "; } + }; + + int main() + { + std::thread t1{f}; // f() executes in separate thread + std::thread t2{F()}; // F()() executes in separate thread + } // spot the bugs + +##### Example + + void f() { std::cout << "Hello "; } + + struct F { + void operator()() const { std::cout << "parallel world "; } + }; + + int main() + { + std::thread t1{f}; // f() executes in separate thread + std::thread t2{F()}; // F()() executes in separate thread + + t1.join(); + t2.join(); + } // one bad bug left + +##### Note + +Make "immortal threads" globals, put them in an enclosing scope, or put them on the free store rather than `detach()`. +[Don't `detach`](#Rconc-detached_thread). + +##### Note + +Because of old code and third party libraries using `std::thread`, this rule can be hard to introduce. + +##### Enforcement + +Flag uses of `std::thread`: + +* Suggest use of `gsl::joining_thread` or C++20 `std::jthread`. +* Suggest ["exporting ownership"](#Rconc-detached_thread) to an enclosing scope if it detaches. +* Warn if it is not obvious whether a thread joins or detaches. + +### CP.26: Don't `detach()` a thread + +##### Reason + +Often, the need to outlive the scope of its creation is inherent in the `thread`s task, +but implementing that idea by `detach` makes it harder to monitor and communicate with the detached thread. +In particular, it is harder (though not impossible) to ensure that the thread completed as expected or lives for as long as expected. + +##### Example + + void heartbeat(); + + void use() + { + std::thread t(heartbeat); // don't join; heartbeat is meant to run forever + t.detach(); + // ... + } + +This is a reasonable use of a thread, for which `detach()` is commonly used. +There are problems, though. +How do we monitor the detached thread to see if it is alive? +Something might go wrong with the heartbeat, and losing a heartbeat can be very serious in a system for which it is needed. +So, we need to communicate with the heartbeat thread +(e.g., through a stream of messages or notification events using a `condition_variable`). + +An alternative, and usually superior solution is to control its lifetime by placing it in a scope outside its point of creation (or activation). +For example: + + void heartbeat(); + + gsl::joining_thread t(heartbeat); // heartbeat is meant to run "forever" + +This heartbeat will (barring error, hardware problems, etc.) run for as long as the program does. + +Sometimes, we need to separate the point of creation from the point of ownership: + + void heartbeat(); + + unique_ptr tick_tock {nullptr}; + + void use() + { + // heartbeat is meant to run as long as tick_tock lives + tick_tock = make_unique(heartbeat); + // ... + } + +#### Enforcement + +Flag `detach()`. + + +### CP.31: Pass small amounts of data between threads by value, rather than by reference or pointer + +##### Reason + +A small amount of data is cheaper to copy and access than to share it using some locking mechanism. +Copying naturally gives unique ownership (simplifies code) and eliminates the possibility of data races. + +##### Note + +Defining "small amount" precisely is impossible. + +##### Example + + string modify1(string); + void modify2(string&); + + void fct(string& s) + { + auto res = async(modify1, s); + async(modify2, s); + } + +The call of `modify1` involves copying two `string` values; the call of `modify2` does not. +On the other hand, the implementation of `modify1` is exactly as we would have written it for single-threaded code, +whereas the implementation of `modify2` will need some form of locking to avoid data races. +If the string is short (say 10 characters), the call of `modify1` can be surprisingly fast; +essentially all the cost is in the `thread` switch. If the string is long (say 1,000,000 characters), copying it twice +is probably not a good idea. + +Note that this argument has nothing to do with `async` as such. It applies equally to considerations about whether to use +message passing or shared memory. + +##### Enforcement + +??? + + +### CP.32: To share ownership between unrelated `thread`s use `shared_ptr` + +##### Reason + +If threads are unrelated (that is, not known to be in the same scope or one within the lifetime of the other) +and they need to share free store memory that needs to be deleted, a `shared_ptr` (or equivalent) is the only +safe way to ensure proper deletion. + +##### Example + + ??? + +##### Note + +* A static object (e.g. a global) can be shared because it is not owned in the sense that some thread is responsible for its deletion. +* An object on free store that is never to be deleted can be shared. +* An object owned by one thread can be safely shared with another as long as that second thread doesn't outlive the owner. + +##### Enforcement + +??? + + +### CP.40: Minimize context switching + +##### Reason + +Context switches are expensive. + +##### Example + + ??? + +##### Enforcement + +??? + + +### CP.41: Minimize thread creation and destruction + +##### Reason + +Thread creation is expensive. + +##### Example + + void worker(Message m) + { + // process + } + + void dispatcher(istream& is) + { + for (Message m; is >> m; ) + run_list.push_back(new thread(worker, m)); + } + +This spawns a `thread` per message, and the `run_list` is presumably managed to destroy those tasks once they are finished. + +Instead, we could have a set of pre-created worker threads processing the messages + + Sync_queue work; + + void dispatcher(istream& is) + { + for (Message m; is >> m; ) + work.put(m); + } + + void worker() + { + for (Message m; m = work.get(); ) { + // process + } + } + + void workers() // set up worker threads (specifically 4 worker threads) + { + joining_thread w1 {worker}; + joining_thread w2 {worker}; + joining_thread w3 {worker}; + joining_thread w4 {worker}; + } + +##### Note + +If your system has a good thread pool, use it. +If your system has a good message queue, use it. + +##### Enforcement + +??? + + +### CP.42: Don't `wait` without a condition + +##### Reason + +A `wait` without a condition can miss a wakeup or wake up simply to find that there is no work to do. + +##### Example, bad + + std::condition_variable cv; + std::mutex mx; + + void thread1() + { + while (true) { + // do some work ... + std::unique_lock lock(mx); + cv.notify_one(); // wake other thread + } + } + + void thread2() + { + while (true) { + std::unique_lock lock(mx); + cv.wait(lock); // might block forever + // do work ... + } + } + +Here, if some other `thread` consumes `thread1`'s notification, `thread2` can wait forever. + +##### Example + + template + class Sync_queue { + public: + void put(const T& val); + void put(T&& val); + void get(T& val); + private: + mutex mtx; + condition_variable cond; // this controls access + list q; + }; + + template + void Sync_queue::put(const T& val) + { + lock_guard lck(mtx); + q.push_back(val); + cond.notify_one(); + } + + template + void Sync_queue::get(T& val) + { + unique_lock lck(mtx); + cond.wait(lck, [this] { return !q.empty(); }); // prevent spurious wakeup + val = q.front(); + q.pop_front(); + } + +Now if the queue is empty when a thread executing `get()` wakes up (e.g., because another thread has gotten to `get()` before it), +it will immediately go back to sleep, waiting. + +##### Enforcement + +Flag all `wait`s without conditions. + + +### CP.43: Minimize time spent in a critical section + +##### Reason + +The less time is spent with a `mutex` taken, the less chance that another `thread` has to wait, +and `thread` suspension and resumption are expensive. + +##### Example + + void do_something() // bad + { + unique_lock lck(my_lock); + do0(); // preparation: does not need lock + do1(); // transaction: needs locking + do2(); // cleanup: does not need locking + } + +Here, we are holding the lock for longer than necessary: +We should not have taken the lock before we needed it and should have released it again before starting the cleanup. +We could rewrite this to + + void do_something() // bad + { + do0(); // preparation: does not need lock + my_lock.lock(); + do1(); // transaction: needs locking + my_lock.unlock(); + do2(); // cleanup: does not need locking + } + +But that compromises safety and violates the [use RAII](#Rconc-raii) rule. +Instead, add a block for the critical section: + + void do_something() // OK + { + do0(); // preparation: does not need lock + { + unique_lock lck(my_lock); + do1(); // transaction: needs locking + } + do2(); // cleanup: does not need locking + } + +##### Enforcement + +Impossible in general. +Flag "naked" `lock()` and `unlock()`. + + +### CP.44: Remember to name your `lock_guard`s and `unique_lock`s + +##### Reason + +An unnamed local object is a temporary that immediately goes out of scope. + +##### Example + + // global mutexes + mutex m1; + mutex m2; + + void f() + { + unique_lock(m1); // (A) + lock_guard {m2}; // (B) + // do work in critical section ... + } + +This looks innocent enough, but it isn't. At (A), `m1` is a default-constructed +local `unique_lock`, which shadows the global `::m1` (and does not lock it). +At (B) an unnamed temporary `lock_guard` is constructed and locks `::m2`, +but immediately goes out of scope and unlocks `::m2` again. +For the rest of the function `f()` neither mutex is locked. + +##### Enforcement + +Flag all unnamed `lock_guard`s and `unique_lock`s. + + + +### CP.50: Define a `mutex` together with the data it guards. Use `synchronized_value` where possible + +##### Reason + +It should be obvious to a reader that the data is to be guarded and how. This decreases the chance of the wrong mutex being locked, or the mutex not being locked. + +Using a `synchronized_value` ensures that the data has a mutex, and the right mutex is locked when the data is accessed. +See the [WG21 proposal](http://wg21.link/p0290) to add `synchronized_value` to a future TS or revision of the C++ standard. + +##### Example + + struct Record { + std::mutex m; // take this mutex before accessing other members + // ... + }; + + class MyClass { + struct DataRecord { + // ... + }; + synchronized_value data; // Protect the data with a mutex + }; + +##### Enforcement + +??? Possible? + + +## CP.coro: Coroutines + +This section focuses on uses of coroutines. + +Coroutine rule summary: + +* [CP.51: Do not use capturing lambdas that are coroutines](#Rcoro-capture) +* [CP.52: Do not hold locks or other synchronization primitives across suspension points](#Rcoro-locks) +* [CP.53: Parameters to coroutines should not be passed by reference](#Rcoro-reference-parameters) + +### CP.51: Do not use capturing lambdas that are coroutines + +##### Reason + +Usage patterns that are correct with normal lambdas are hazardous with coroutine lambdas. The obvious pattern of capturing variables will result in accessing freed memory after the first suspension point, even for refcounted smart pointers and copyable types. + +A lambda results in a closure object with storage, often on the stack, that will go out of scope at some point. When the closure object goes out of scope the captures will also go out of scope. Normal lambdas will have finished executing by this time so it is not a problem. Coroutine lambdas may resume from suspension after the closure object has destructed and at that point all captures will be use-after-free memory access. + +##### Example, Bad + + int value = get_value(); + std::shared_ptr sharedFoo = get_foo(); + { + const auto lambda = [value, sharedFoo]() -> std::future + { + co_await something(); + // "sharedFoo" and "value" have already been destroyed + // the "shared" pointer didn't accomplish anything + }; + lambda(); + } // the lambda closure object has now gone out of scope + +##### Example, Better + + int value = get_value(); + std::shared_ptr sharedFoo = get_foo(); + { + // take as by-value parameter instead of as a capture + const auto lambda = [](auto sharedFoo, auto value) -> std::future + { + co_await something(); + // sharedFoo and value are still valid at this point + }; + lambda(sharedFoo, value); + } // the lambda closure object has now gone out of scope + +##### Example, Best + +Use a function for coroutines. + + std::future Class::do_something(int value, std::shared_ptr sharedFoo) + { + co_await something(); + // sharedFoo and value are still valid at this point + } + + void SomeOtherFunction() + { + int value = get_value(); + std::shared_ptr sharedFoo = get_foo(); + do_something(value, sharedFoo); + } + +##### Enforcement + +Flag a lambda that is a coroutine and has a non-empty capture list. + + +### CP.52: Do not hold locks or other synchronization primitives across suspension points + +##### Reason + +This pattern creates a significant risk of deadlocks. Some types of waits will allow the current thread to perform additional work until the asynchronous operation has completed. If the thread holding the lock performs work that requires the same lock then it will deadlock because it is trying to acquire a lock that it is already holding. + +If the coroutine completes on a different thread from the thread that acquired the lock then that is undefined behavior. Even with an explicit return to the original thread an exception might be thrown before coroutine resumes and the result will be that the lock guard is not destructed. + +##### Example, Bad + + std::mutex g_lock; + + std::future Class::do_something() + { + std::lock_guard guard(g_lock); + co_await something(); // DANGER: coroutine has suspended execution while holding a lock + co_await somethingElse(); + } + +##### Example, Good + + std::mutex g_lock; + + std::future Class::do_something() + { + { + std::lock_guard guard(g_lock); + // modify data protected by lock + } + co_await something(); // OK: lock has been released before coroutine suspends + co_await somethingElse(); + } + + +##### Note + +This pattern is also bad for performance. When a suspension point is reached, such as co_await, execution of the current function stops and other code begins to run. It may be a long period of time before the coroutine resumes. For that entire duration the lock will be held and cannot be acquired by other threads to perform work. + +##### Enforcement + +Flag all lock guards that are not destructed before a coroutine suspends. + +### CP.53: Parameters to coroutines should not be passed by reference + +##### Reason + +Once a coroutine reaches the first suspension point, such as a co_await, the synchronous portion returns. After that point any parameters passed by reference are dangling. Any usage beyond that is undefined behavior which may include writing to freed memory. + +##### Example, Bad + + std::future Class::do_something(const std::shared_ptr& input) + { + co_await something(); + + // DANGER: the reference to input may no longer be valid and may be freed memory + co_return *input + 1; + } + +##### Example, Good + + std::future Class::do_something(std::shared_ptr input) + { + co_await something(); + co_return *input + 1; // input is a copy that is still valid here + } + +##### Note + +This problem does not apply to reference parameters that are only accessed before the first suspension point. Subsequent changes to the function may add or move suspension points which would reintroduce this class of bug. Some types of coroutines have the suspension point before the first line of code in the coroutine executes, in which case reference parameters are always unsafe. It is safer to always pass by value because the copied parameter will live in the coroutine frame that is safe to access throughout the coroutine. + +##### Note + +The same danger applies to output parameters. [F.20: For "out" output values, prefer return values to output parameters](#Rf-out) discourages output parameters. Coroutines should avoid them entirely. + +##### Enforcement + +Flag all reference parameters to a coroutine. + +## CP.par: Parallelism + +By "parallelism" we refer to performing a task (more or less) simultaneously ("in parallel with") on many data items. + +Parallelism rule summary: + +* ??? +* ??? +* Where appropriate, prefer the standard-library parallel algorithms +* Use algorithms that are designed for parallelism, not algorithms with unnecessary dependency on linear evaluation + + + +## CP.mess: Message passing + +The standard-library facilities are quite low-level, focused on the needs of close-to the hardware critical programming using `thread`s, `mutex`es, `atomic` types, etc. +Most people shouldn't work at this level: it's error-prone and development is slow. +If possible, use a higher level facility: messaging libraries, parallel algorithms, and vectorization. +This section looks at passing messages so that a programmer doesn't have to do explicit synchronization. + +Message passing rules summary: + +* [CP.60: Use a `future` to return a value from a concurrent task](#Rconc-future) +* [CP.61: Use `async()` to spawn concurrent tasks](#Rconc-async) +* message queues +* messaging libraries + +???? should there be a "use X rather than `std::async`" where X is something that would use a better specified thread pool? + +??? Is `std::async` worth using in light of future (and even existing, as libraries) parallelism facilities? What should the guidelines recommend if someone wants to parallelize, e.g., `std::accumulate` (with the additional precondition of commutativity), or merge sort? + + +### CP.60: Use a `future` to return a value from a concurrent task + +##### Reason + +A `future` preserves the usual function call return semantics for asynchronous tasks. +There is no explicit locking and both correct (value) return and error (exception) return are handled simply. + +##### Example + + ??? + +##### Note + +??? + +##### Enforcement + +??? + +### CP.61: Use `async()` to spawn concurrent tasks + +##### Reason + +Similar to [R.12](#Rr-immediate-alloc), which tells you to avoid raw owning pointers, you should +also avoid raw threads and raw promises where possible. Use a factory function such as `std::async`, +which handles spawning or reusing a thread without exposing raw threads to your own code. + +##### Example + + int read_value(const std::string& filename) + { + std::ifstream in(filename); + in.exceptions(std::ifstream::failbit); + int value; + in >> value; + return value; + } + + void async_example() + { + try { + std::future f1 = std::async(read_value, "v1.txt"); + std::future f2 = std::async(read_value, "v2.txt"); + std::cout << f1.get() + f2.get() << '\n'; + } catch (const std::ios_base::failure& fail) { + // handle exception here + } + } + +##### Note + +Unfortunately, `std::async` is not perfect. For example, it doesn't use a thread pool, +which means that it might fail due to resource exhaustion, rather than queuing up your tasks +to be executed later. However, even if you cannot use `std::async`, you should prefer to +write your own `future`-returning factory function, rather than using raw promises. + +##### Example (bad) + +This example shows two different ways to succeed at using `std::future`, but to fail +at avoiding raw `std::thread` management. + + void async_example() + { + std::promise p1; + std::future f1 = p1.get_future(); + std::thread t1([p1 = std::move(p1)]() mutable { + p1.set_value(read_value("v1.txt")); + }); + t1.detach(); // evil + + std::packaged_task pt2(read_value, "v2.txt"); + std::future f2 = pt2.get_future(); + std::thread(std::move(pt2)).detach(); + + std::cout << f1.get() + f2.get() << '\n'; + } + +##### Example (good) + +This example shows one way you could follow the general pattern set by +`std::async`, in a context where `std::async` itself was unacceptable for +use in production. + + void async_example(WorkQueue& wq) + { + std::future f1 = wq.enqueue([]() { + return read_value("v1.txt"); + }); + std::future f2 = wq.enqueue([]() { + return read_value("v2.txt"); + }); + std::cout << f1.get() + f2.get() << '\n'; + } + +Any threads spawned to execute the code of `read_value` are hidden behind +the call to `WorkQueue::enqueue`. The user code deals only with `future` +objects, never with raw `thread`, `promise`, or `packaged_task` objects. + +##### Enforcement + +??? + + +## CP.vec: Vectorization + +Vectorization is a technique for executing a number of tasks concurrently without introducing explicit synchronization. +An operation is simply applied to elements of a data structure (a vector, an array, etc.) in parallel. +Vectorization has the interesting property of often requiring no non-local changes to a program. +However, vectorization works best with simple data structures and with algorithms specifically crafted to enable it. + +Vectorization rule summary: + +* ??? +* ??? + +## CP.free: Lock-free programming + +Synchronization using `mutex`es and `condition_variable`s can be relatively expensive. +Furthermore, it can lead to deadlock. +For performance and to eliminate the possibility of deadlock, we sometimes have to use the tricky low-level "lock-free" facilities +that rely on briefly gaining exclusive ("atomic") access to memory. +Lock-free programming is also used to implement higher-level concurrency mechanisms, such as `thread`s and `mutex`es. + +Lock-free programming rule summary: + +* [CP.100: Don't use lock-free programming unless you absolutely have to](#Rconc-lockfree) +* [CP.101: Distrust your hardware/compiler combination](#Rconc-distrust) +* [CP.102: Carefully study the literature](#Rconc-literature) +* how/when to use atomics +* avoid starvation +* use a lock-free data structure rather than hand-crafting specific lock-free access +* [CP.110: Do not write your own double-checked locking for initialization](#Rconc-double) +* [CP.111: Use a conventional pattern if you really need double-checked locking](#Rconc-double-pattern) +* how/when to compare and swap + + +### CP.100: Don't use lock-free programming unless you absolutely have to + +##### Reason + +It's error-prone and requires expert level knowledge of language features, machine architecture, and data structures. + +##### Example, bad + + extern atomic head; // the shared head of a linked list + + Link* nh = new Link(data, nullptr); // make a link ready for insertion + Link* h = head.load(); // read the shared head of the list + + do { + if (h->data <= data) break; // if so, insert elsewhere + nh->next = h; // next element is the previous head + } while (!head.compare_exchange_weak(h, nh)); // write nh to head or to h + +Spot the bug. +It would be really hard to find through testing. +Read up on the ABA problem. + +##### Exception + +[Atomic variables](#???) can be used simply and safely, as long as you are using the sequentially consistent memory model (memory_order_seq_cst), which is the default. + +##### Note + +Higher-level concurrency mechanisms, such as `thread`s and `mutex`es are implemented using lock-free programming. + +**Alternative**: Use lock-free data structures implemented by others as part of some library. + + +### CP.101: Distrust your hardware/compiler combination + +##### Reason + +The low-level hardware interfaces used by lock-free programming are among the hardest to implement well and among +the areas where the most subtle portability problems occur. +If you are doing lock-free programming for performance, you need to check for regressions. + +##### Note + +Instruction reordering (static and dynamic) makes it hard for us to think effectively at this level (especially if you use relaxed memory models). +Experience, (semi)formal models and model checking can be useful. +Testing - often to an extreme extent - is essential. +"Don't fly too close to the sun." + +##### Enforcement + +Have strong rules for re-testing in place that covers any change in hardware, operating system, compiler, and libraries. + + +### CP.102: Carefully study the literature + +##### Reason + +With the exception of atomics and a few other standard patterns, lock-free programming is really an expert-only topic. +Become an expert before shipping lock-free code for others to use. + +##### References + +* Anthony Williams: C++ concurrency in action. Manning Publications. +* Boehm, Adve, You Don't Know Jack About Shared Variables or Memory Models , Communications of the ACM, Feb 2012. +* Boehm, "Threads Basics", HPL TR 2009-259. +* Adve, Boehm, "Memory Models: A Case for Rethinking Parallel Languages and Hardware", Communications of the ACM, August 2010. +* Boehm, Adve, "Foundations of the C++ Concurrency Memory Model", PLDI 08. +* Mark Batty, Scott Owens, Susmit Sarkar, Peter Sewell, and Tjark Weber, "Mathematizing C++ Concurrency", POPL 2011. +* Damian Dechev, Peter Pirkelbauer, and Bjarne Stroustrup: Understanding and Effectively Preventing the ABA Problem in Descriptor-based Lock-free Designs. 13th IEEE Computer Society ISORC 2010 Symposium. May 2010. +* Damian Dechev and Bjarne Stroustrup: Scalable Non-blocking Concurrent Objects for Mission Critical Code. ACM OOPSLA'09. October 2009 +* Damian Dechev, Peter Pirkelbauer, Nicolas Rouquette, and Bjarne Stroustrup: Semantically Enhanced Containers for Concurrent Real-Time Systems. Proc. 16th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (IEEE ECBS). April 2009. +* Maurice Herlihy, Nir Shavit, Victor Luchangco, Michael Spear, "The Art of Multiprocessor Programming", 2nd ed. September 2020 + +### CP.110: Do not write your own double-checked locking for initialization + +##### Reason + +Since C++11, static local variables are now initialized in a thread-safe way. When combined with the RAII pattern, static local variables can replace the need for writing your own double-checked locking for initialization. std::call_once can also achieve the same purpose. Use either static local variables of C++11 or std::call_once instead of writing your own double-checked locking for initialization. + +##### Example + +Example with std::call_once. + + void f() + { + static std::once_flag my_once_flag; + std::call_once(my_once_flag, []() + { + // do this only once + }); + // ... + } + +Example with thread-safe static local variables of C++11. + + void f() + { + // Assuming the compiler is compliant with C++11 + static My_class my_object; // Constructor called only once + // ... + } + + class My_class + { + public: + My_class() + { + // do this only once + } + }; + +##### Enforcement + +??? Is it possible to detect the idiom? + + +### CP.111: Use a conventional pattern if you really need double-checked locking + +##### Reason + +Double-checked locking is easy to mess up. If you really need to write your own double-checked locking, in spite of the rules [CP.110: Do not write your own double-checked locking for initialization](#Rconc-double) and [CP.100: Don't use lock-free programming unless you absolutely have to](#Rconc-lockfree), then do it in a conventional pattern. + +The uses of the double-checked locking pattern that are not in violation of [CP.110: Do not write your own double-checked locking for initialization](#Rconc-double) arise when a non-thread-safe action is both hard and rare, and there exists a fast thread-safe test that can be used to guarantee that the action is not needed, but cannot be used to guarantee the converse. + +##### Example, bad + +The use of volatile does not make the first check thread-safe, see also [CP.200: Use `volatile` only to talk to non-C++ memory](#Rconc-volatile2) + + mutex action_mutex; + volatile bool action_needed; + + if (action_needed) { + std::lock_guard lock(action_mutex); + if (action_needed) { + take_action(); + action_needed = false; + } + } + +##### Example, good + + mutex action_mutex; + atomic action_needed; + + if (action_needed) { + std::lock_guard lock(action_mutex); + if (action_needed) { + take_action(); + action_needed = false; + } + } + +Fine-tuned memory order might be beneficial where acquire load is more efficient than sequentially-consistent load + + mutex action_mutex; + atomic action_needed; + + if (action_needed.load(memory_order_acquire)) { + lock_guard lock(action_mutex); + if (action_needed.load(memory_order_relaxed)) { + take_action(); + action_needed.store(false, memory_order_release); + } + } + +##### Enforcement + +??? Is it possible to detect the idiom? + + +## CP.etc: Etc. concurrency rules + +These rules defy simple categorization: + +* [CP.200: Use `volatile` only to talk to non-C++ memory](#Rconc-volatile2) +* [CP.201: ??? Signals](#Rconc-signal) + +### CP.200: Use `volatile` only to talk to non-C++ memory + +##### Reason + +`volatile` is used to refer to objects that are shared with "non-C++" code or hardware that does not follow the C++ memory model. + +##### Example + + const volatile long clock; + +This describes a register constantly updated by a clock circuit. +`clock` is `volatile` because its value will change without any action from the C++ program that uses it. +For example, reading `clock` twice will often yield two different values, so the optimizer had better not optimize away the second read in this code: + + long t1 = clock; + // ... no use of clock here ... + long t2 = clock; + +`clock` is `const` because the program should not try to write to `clock`. + +##### Note + +Unless you are writing the lowest level code manipulating hardware directly, consider `volatile` an esoteric feature that is best avoided. + +##### Example + +Usually C++ code receives `volatile` memory that is owned elsewhere (hardware or another language): + + int volatile* vi = get_hardware_memory_location(); + // note: we get a pointer to someone else's memory here + // volatile says "treat this with extra respect" + +Sometimes C++ code allocates the `volatile` memory and shares it with "elsewhere" (hardware or another language) by deliberately escaping a pointer: + + static volatile long vl; + please_use_this(&vl); // escape a reference to this to "elsewhere" (not C++) + +##### Example, bad + +`volatile` local variables are nearly always wrong -- how can they be shared with other languages or hardware if they're ephemeral? +The same applies almost as strongly to data members, for the same reason. + + void f() + { + volatile int i = 0; // bad, volatile local variable + // etc. + } + + class My_type { + volatile int i = 0; // suspicious, volatile data member + // etc. + }; + +##### Note + +In C++, unlike in some other languages, `volatile` has [nothing to do with synchronization](#Rconc-volatile). + +##### Enforcement + +* Flag `volatile T` local and data members; almost certainly you intended to use `atomic` instead. +* ??? + +### CP.201: ??? Signals + +???UNIX signal handling???. Might be worth reminding how little is async-signal-safe, and how to communicate with a signal handler (best is probably "not at all") + + +# E: Error handling + +Error handling involves: + +* Detecting an error +* Transmitting information about an error to some handler code +* Preserving a valid state of the program +* Avoiding resource leaks + +It is not possible to recover from all errors. If recovery from an error is not possible, it is important to quickly "get out" in a well-defined way. A strategy for error handling must be simple, or it becomes a source of even worse errors. Untested and rarely executed error-handling code is itself the source of many bugs. + +The rules are designed to help avoid several kinds of errors: + +* Type violations (e.g., misuse of `union`s and casts) +* Resource leaks (including memory leaks) +* Bounds errors +* Lifetime errors (e.g., accessing an object after it has been `delete`d) +* Complexity errors (logical errors made likely by overly complex expression of ideas) +* Interface errors (e.g., an unexpected value is passed through an interface) + +Error-handling rule summary: + +* [E.1: Develop an error-handling strategy early in a design](#Re-design) +* [E.2: Throw an exception to signal that a function can't perform its assigned task](#Re-throw) +* [E.3: Use exceptions for error handling only](#Re-errors) +* [E.4: Design your error-handling strategy around invariants](#Re-design-invariants) +* [E.5: Let a constructor establish an invariant, and throw if it cannot](#Re-invariant) +* [E.6: Use RAII to prevent leaks](#Re-raii) +* [E.7: State your preconditions](#Re-precondition) +* [E.8: State your postconditions](#Re-postcondition) + +* [E.12: Use `noexcept` when exiting a function because of a `throw` is impossible or unacceptable](#Re-noexcept) +* [E.13: Never throw while being the direct owner of an object](#Re-never-throw) +* [E.14: Use purpose-designed user-defined types as exceptions (not built-in types)](#Re-exception-types) +* [E.15: Throw by value, catch exceptions from a hierarchy by reference](#Re-exception-ref) +* [E.16: Destructors, deallocation, `swap`, and exception type copy/move construction must never fail](#Re-never-fail) +* [E.17: Don't try to catch every exception in every function](#Re-not-always) +* [E.18: Minimize the use of explicit `try`/`catch`](#Re-catch) +* [E.19: Use a `final_action` object to express cleanup if no suitable resource handle is available](#Re-finally) + +* [E.25: If you can't throw exceptions, simulate RAII for resource management](#Re-no-throw-raii) +* [E.26: If you can't throw exceptions, consider failing fast](#Re-no-throw-crash) +* [E.27: If you can't throw exceptions, use error codes systematically](#Re-no-throw-codes) +* [E.28: Avoid error handling based on global state (e.g. `errno`)](#Re-no-throw) + +* [E.30: Don't use exception specifications](#Re-specifications) +* [E.31: Properly order your `catch`-clauses](#Re_catch) + +### E.1: Develop an error-handling strategy early in a design + +##### Reason + +A consistent and complete strategy for handling errors and resource leaks is hard to retrofit into a system. + +### E.2: Throw an exception to signal that a function can't perform its assigned task + +##### Reason + +To make error handling systematic, robust, and non-repetitive. + +##### Example + + struct Foo { + vector v; + File_handle f; + string s; + }; + + void use() + { + Foo bar { {Thing{1}, Thing{2}, Thing{monkey} }, {"my_file", "r"}, "Here we go!"}; + // ... + } + +Here, `vector` and `string`s constructors might not be able to allocate sufficient memory for their elements, `vector`s constructor might not be able to copy the `Thing`s in its initializer list, and `File_handle` might not be able to open the required file. +In each case, they throw an exception for `use()`'s caller to handle. +If `use()` could handle the failure to construct `bar` it can take control using `try`/`catch`. +In either case, `Foo`'s constructor correctly destroys constructed members before passing control to whatever tried to create a `Foo`. +Note that there is no return value that could contain an error code. + +The `File_handle` constructor might be defined like this: + + File_handle::File_handle(const string& name, const string& mode) + : f{fopen(name.c_str(), mode.c_str())} + { + if (!f) + throw runtime_error{"File_handle: could not open " + name + " as " + mode}; + } + +##### Note + +It is often said that exceptions are meant to signal exceptional events and failures. +However, that's a bit circular because "what is exceptional?" +Examples: + +* A precondition that cannot be met +* A constructor that cannot construct an object (failure to establish its class's [invariant](#Rc-struct)) +* An out-of-range error (e.g., `v[v.size()] = 7`) +* Inability to acquire a resource (e.g., the network is down) + +In contrast, termination of an ordinary loop is not exceptional. +Unless the loop was meant to be infinite, termination is normal and expected. + +##### Note + +Don't use a `throw` as simply an alternative way of returning a value from a function. + +##### Exception + +Some systems, such as hard-real-time systems require a guarantee that an action is taken in a (typically short) constant maximum time known before execution starts. Such systems can use exceptions only if there is tool support for accurately predicting the maximum time to recover from a `throw`. + +**See also**: [RAII](#Re-raii) + +**See also**: [discussion](#Sd-noexcept) + +##### Note + +Before deciding that you cannot afford or don't like exception-based error handling, have a look at the [alternatives](#Re-no-throw-raii); +they have their own complexities and problems. +Also, as far as possible, measure before making claims about efficiency. + +### E.3: Use exceptions for error handling only + +##### Reason + +To keep error handling separated from "ordinary code." +C++ implementations tend to be optimized based on the assumption that exceptions are rare. + +##### Example, don't + + // don't: exception not used for error handling + int find_index(vector& vec, const string& x) + { + try { + for (gsl::index i = 0; i < vec.size(); ++i) + if (vec[i] == x) throw i; // found x + } + catch (int i) { + return i; + } + return -1; // not found + } + +This is more complicated and most likely runs much slower than the obvious alternative. +There is nothing exceptional about finding a value in a `vector`. + +##### Enforcement + +Would need to be heuristic. +Look for exception values "leaked" out of `catch` clauses. + +### E.4: Design your error-handling strategy around invariants + +##### Reason + +To use an object it must be in a valid state (defined formally or informally by an invariant) and to recover from an error every object not destroyed must be in a valid state. + +##### Note + +An [invariant](#Rc-struct) is a logical condition for the members of an object that a constructor must establish for the public member functions to assume. + +##### Enforcement + +??? + +### E.5: Let a constructor establish an invariant, and throw if it cannot + +##### Reason + +Leaving an object without its invariant established is asking for trouble. +Not all member functions can be called. + +##### Example + + class Vector { // very simplified vector of doubles + // if elem != nullptr then elem points to sz doubles + public: + Vector() : elem{nullptr}, sz{0}{} + Vector(int s) : elem{new double[s]}, sz{s} { /* initialize elements */ } + ~Vector() { delete [] elem; } + double& operator[](int s) { return elem[s]; } + // ... + private: + owner elem; + int sz; + }; + +The class invariant - here stated as a comment - is established by the constructors. +`new` throws if it cannot allocate the required memory. +The operators, notably the subscript operator, rely on the invariant. + +**See also**: [If a constructor cannot construct a valid object, throw an exception](#Rc-throw) + +##### Enforcement + +Flag classes with `private` state without a constructor (public, protected, or private). + +### E.6: Use RAII to prevent leaks + +##### Reason + +Leaks are typically unacceptable. +Manual resource release is error-prone. +RAII ("Resource Acquisition Is Initialization") is the simplest, most systematic way of preventing leaks. + +##### Example + + void f1(int i) // Bad: possible leak + { + int* p = new int[12]; + // ... + if (i < 17) throw Bad{"in f()", i}; + // ... + } + +We could carefully release the resource before the throw: + + void f2(int i) // Clumsy and error-prone: explicit release + { + int* p = new int[12]; + // ... + if (i < 17) { + delete[] p; + throw Bad{"in f()", i}; + } + // ... + } + +This is verbose. In larger code with multiple possible `throw`s explicit releases become repetitive and error-prone. + + void f3(int i) // OK: resource management done by a handle (but see below) + { + auto p = make_unique(12); + // ... + if (i < 17) throw Bad{"in f()", i}; + // ... + } + +Note that this works even when the `throw` is implicit because it happened in a called function: + + void f4(int i) // OK: resource management done by a handle (but see below) + { + auto p = make_unique(12); + // ... + helper(i); // might throw + // ... + } + +Unless you really need pointer semantics, use a local resource object: + + void f5(int i) // OK: resource management done by local object + { + vector v(12); + // ... + helper(i); // might throw + // ... + } + +That's even simpler and safer, and often more efficient. + +##### Note + +If there is no obvious resource handle and for some reason defining a proper RAII object/handle is infeasible, +as a last resort, cleanup actions can be represented by a [`final_action`](#Re-finally) object. + +##### Note + +But what do we do if we are writing a program where exceptions cannot be used? +First challenge that assumption; there are many anti-exceptions myths around. +We know of only a few good reasons: + +* We are on a system so small that the exception support would eat up most of our 2K memory. +* We are in a hard-real-time system and we don't have tools that guarantee us that an exception is handled within the required time. +* We are in a system with tons of legacy code using lots of pointers in difficult-to-understand ways + (in particular without a recognizable ownership strategy) so that exceptions could cause leaks. +* Our implementation of the C++ exception mechanisms is unreasonably poor +(slow, memory consuming, failing to work correctly for dynamically linked libraries, etc.). +Complain to your implementation purveyor; if no user complains, no improvement will happen. +* We get fired if we challenge our manager's ancient wisdom. + +Only the first of these reasons is fundamental, so whenever possible, use exceptions to implement RAII, or design your RAII objects to never fail. +When exceptions cannot be used, simulate RAII. +That is, systematically check that objects are valid after construction and still release all resources in the destructor. +One strategy is to add a `valid()` operation to every resource handle: + + void f() + { + vector vs(100); // not std::vector: valid() added + if (!vs.valid()) { + // handle error or exit + } + + ifstream fs("foo"); // not std::ifstream: valid() added + if (!fs.valid()) { + // handle error or exit + } + + // ... + } // destructors clean up as usual + +Obviously, this increases the size of the code, doesn't allow for implicit propagation of "exceptions" (`valid()` checks), and `valid()` checks can be forgotten. +Prefer to use exceptions. + +**See also**: [Use of `noexcept`](#Re-noexcept) + +##### Enforcement + +??? + +### E.7: State your preconditions + +##### Reason + +To avoid interface errors. + +**See also**: [precondition rule](#Ri-pre) + +### E.8: State your postconditions + +##### Reason + +To avoid interface errors. + +**See also**: [postcondition rule](#Ri-post) + +### E.12: Use `noexcept` when exiting a function because of a `throw` is impossible or unacceptable + +##### Reason + +To make error handling systematic, robust, and efficient. + +##### Example + + double compute(double d) noexcept + { + return log(sqrt(d <= 0 ? 1 : d)); + } + +Here, we know that `compute` will not throw because it is composed out of operations that don't throw. +By declaring `compute` to be `noexcept`, we give the compiler and human readers information that can make it easier for them to understand and manipulate `compute`. + +##### Note + +Many standard-library functions are `noexcept` including all the standard-library functions "inherited" from the C Standard Library. + +##### Example + + vector munge(const vector& v) noexcept + { + vector v2(v.size()); + // ... do something ... + } + +The `noexcept` here states that I am not willing or able to handle the situation where I cannot construct the local `vector`. +That is, I consider memory exhaustion a serious design error (on par with hardware failures) so that I'm willing to crash the program if it happens. + +##### Note + +Do not use traditional [exception-specifications](#Re-specifications). + +##### See also + +[discussion](#Sd-noexcept). + +### E.13: Never throw while being the direct owner of an object + +##### Reason + +That would be a leak. + +##### Example + + void leak(int x) // don't: might leak + { + auto p = new int{7}; + if (x < 0) throw Get_me_out_of_here{}; // might leak *p + // ... + delete p; // we might never get here + } + +One way of avoiding such problems is to use resource handles consistently: + + void no_leak(int x) + { + auto p = make_unique(7); + if (x < 0) throw Get_me_out_of_here{}; // will delete *p if necessary + // ... + // no need for delete p + } + +Another solution (often better) would be to use a local variable to eliminate explicit use of pointers: + + void no_leak_simplified(int x) + { + vector v(7); + // ... + } + +##### Note + +If you have a local "thing" that requires cleanup, but is not represented by an object with a destructor, such cleanup must +also be done before a `throw`. +Sometimes, [`finally()`](#Re-finally) can make such unsystematic cleanup a bit more manageable. + +### E.14: Use purpose-designed user-defined types as exceptions (not built-in types) + +##### Reason + +A user-defined type can better transmit information about an error to a handler. Information +can be encoded into the type itself and the type is unlikely to clash with other people's exceptions. + +##### Example + + throw 7; // bad + + throw "something bad"; // bad + + throw std::exception{}; // bad - no info + +Deriving from `std::exception` gives the flexibility to catch the specific exception or handle generally through `std::exception`: + + class MyException : public std::runtime_error + { + public: + MyException(const string& msg) : std::runtime_error{msg} {} + // ... + }; + + // ... + + throw MyException{"something bad"}; // good + +Exceptions do not need to be derived from `std::exception`: + + class MyCustomError final {}; // not derived from std::exception + + // ... + + throw MyCustomError{}; // good - handlers must catch this type (or ...) + +Library types derived from `std::exception` can be used as generic exceptions if +no useful information can be added at the point of detection: + + throw std::runtime_error("someting bad"); // good + + // ... + + throw std::invalid_argument("i is not even"); // good + +`enum` classes are also allowed: + + enum class alert {RED, YELLOW, GREEN}; + + throw alert::RED; // good + +##### Enforcement + +Catch `throw` of built-in types and `std::exception`. + +### E.15: Throw by value, catch exceptions from a hierarchy by reference + +##### Reason + +Throwing by value (not by pointer) and catching by reference prevents copying, especially slicing base subobjects. + +##### Example; bad + + void f() + { + try { + // ... + throw new widget{}; // don't: throw by value not by raw pointer + // ... + } + catch (base_class e) { // don't: might slice + // ... + } + } + +Instead, use a reference: + + catch (base_class& e) { /* ... */ } + +or - typically better still - a `const` reference: + + catch (const base_class& e) { /* ... */ } + +Most handlers do not modify their exception and in general we [recommend use of `const`](#Res-const). + +##### Note + +Catch by value can be appropriate for a small value type such as an `enum` value. + +##### Note + +To rethrow a caught exception use `throw;` not `throw e;`. Using `throw e;` would throw a new copy of `e` (sliced to the static type `std::exception`, when the exception is caught by `catch (const std::exception& e)`) instead of rethrowing the original exception of type `std::runtime_error`. (But keep [Don't try to catch every exception in every function](#Re-not-always) and [Minimize the use of explicit `try`/`catch`](#Re-catch) in mind.) + +##### Enforcement + +* Flag catching by value of a type that has a virtual function. +* Flag throwing raw pointers. + +### E.16: Destructors, deallocation, `swap`, and exception type copy/move construction must never fail + +##### Reason + +We don't know how to write reliable programs if a destructor, a swap, a memory deallocation, or attempting to copy/move-construct an exception object fails; that is, if it exits by an exception or simply doesn't perform its required action. + +##### Example, don't + + class Connection { + // ... + public: + ~Connection() // Don't: very bad destructor + { + if (cannot_disconnect()) throw I_give_up{information}; + // ... + } + }; + +##### Note + +Many have tried to write reliable code violating this rule for examples, such as a network connection that "refuses to close". +To the best of our knowledge nobody has found a general way of doing this. +Occasionally, for very specific examples, you can get away with setting some state for future cleanup. +For example, we might put a socket that does not want to close on a "bad socket" list, +to be examined by a regular sweep of the system state. +Every example we have seen of this is error-prone, specialized, and often buggy. - -### R.15: Always overload matched allocation/deallocation pairs +##### Note -**Reason**. Otherwise you get mismatched operations and chaos. +The standard library assumes that destructors, deallocation functions (e.g., `operator delete`), and `swap` do not throw. If they do, basic standard-library invariants are broken. -**Example**: +##### Note - class X { - // ... - void* operator new(size_t s); - void operator delete(void*); - // ... - }; - -**Note**: If you want memory that cannot be deallocated, `=delete` the deallocation operation. -Don't leave it undeclared. +* Deallocation functions, including `operator delete`, must be `noexcept`. +* `swap` functions must be `noexcept`. +* Most destructors are implicitly `noexcept` by default. +* Also, [make move operations `noexcept`](#Rc-move-noexcept). +* If writing a type intended to be used as an exception type, ensure its copy constructor is `noexcept`. In general we cannot mechanically enforce this, because we do not know whether a type is intended to be used as an exception type. +* Try not to `throw` a type whose copy constructor is not `noexcept`. In general we cannot mechanically enforce this, because even `throw std::string(...)` could throw but does not in practice. -**Enforcement**: Flag incomplate pairs. +##### Enforcement +* Catch destructors, deallocation operations, and `swap`s that `throw`. +* Catch such operations that are not `noexcept`. - -## R.smart: Smart pointers +**See also**: [discussion](#Sd-never-fail) +### E.17: Don't try to catch every exception in every function - -### Rule R.20: Use `unique_ptr` or `shared_ptr` to represent ownership +##### Reason -**Reason**: They can prevent resource leaks. +Catching an exception in a function that cannot take a meaningful recovery action leads to complexity and waste. +Let an exception propagate until it reaches a function that can handle it. +Let cleanup actions on the unwinding path be handled by [RAII](#Re-raii). -**Example**: Consider +##### Example, don't - void f() - { - X x; - X* p1 { new X }; // see also ??? - unique_ptr p2 { new X }; // unique ownership; see also ??? - shared_ptr p3 { new X }; // shared ownership; see also ??? - } + void f() // bad + { + try { + // ... + } + catch (...) { + // no action + throw; // propagate exception + } + } -This will leak the object used to initialize `p1` (only). +##### Enforcement -**Enforcement:** (Simple) Warn if the return value of `new` or a function call with return value of pointer type is assigned to a raw pointer. +* Flag nested try-blocks. +* Flag source code files with a too high ratio of try-blocks to functions. (??? Problem: define "too high") +### E.18: Minimize the use of explicit `try`/`catch` - -### Rule R.21: Prefer `unique_ptr` over `shared_ptr` unless you need to share ownership +##### Reason -**Reason**: a `unique_ptr` is conceptually simpler and more predictable (you know when destruction happens) and faster (you don't implicitly maintain a use count). + `try`/`catch` is verbose and non-trivial uses are error-prone. + `try`/`catch` can be a sign of unsystematic and/or low-level resource management or error handling. -**Example, bad**: This needlessly adds and maintains a reference count +##### Example, Bad - void f() + void f(zstring s) { - shared_ptr base = make_shared(); - // use base locally, without copying it -- refcount never exceeds 1 - } // destroy base + Gadget* p; + try { + p = new Gadget(s); + // ... + delete p; + } + catch (Gadget_construction_failure) { + delete p; + throw; + } + } -**Example**: This is more efficient +This code is messy. +There could be a leak from the naked pointer in the `try` block. +Not all exceptions are handled. +`deleting` an object that failed to construct is almost certainly a mistake. +Better: - void f() + void f2(zstring s) { - unique_ptr base = make_unique(); - // use base locall - } // destroy base + Gadget g {s}; + } +##### Alternatives -**Enforcement**: (Simple) Warn if a function uses a `Shared_ptr` with an object allocated within the function, but never returns the `Shared_ptr` or passes it to a function requiring a `Shared_ptr&`. Suggest using `unique_ptr` instead. +* proper resource handles and [RAII](#Re-raii) +* [`finally`](#Re-finally) +##### Enforcement - -### R.22: Use `make_shared()` to make `shared_ptr`s +??? hard, needs a heuristic -**Reason**: If you first make an object and then gives it to a `shared_ptr` constructor, you (most likely) do one more allocation (and later deallocation) than if you use `make_shared()` because the reference counts must be allocated separately from the object. +### E.19: Use a `final_action` object to express cleanup if no suitable resource handle is available -**Example**: Consider +##### Reason - shared_ptr p1 { new X{2} }; // bad - auto p = make_shared(2); // good +`finally` from the [GSL](#gsl-guidelines-support-library) is less verbose and harder to get wrong than `try`/`catch`. -The `make_shared()` version mentions `X` only once, so it is usually shorter (as well as faster) than the version with the explicit `new`. +##### Example -**Enforcement**: (Simple) Warn if a `shared_ptr` is constructed from the result of `new` rather than `make_shared`. + void f(int n) + { + void* p = malloc(n); + auto _ = gsl::finally([p] { free(p); }); + // ... + } +##### Note - -### Rule R.23: Use `make_unique()` to make `unique_ptr`s +`finally` is not as messy as `try`/`catch`, but it is still ad-hoc. +Prefer [proper resource management objects](#Re-raii). +Consider `finally` a last resort. -**Reason**: for convenience and consistency with `shared_ptr`. +##### Note -**Note**: `make_unique()` is C++14, but widely available (as well as simple to write). +Use of `finally` is a systematic and reasonably clean alternative to the old [`goto exit;` technique](#Re-no-throw-codes) +for dealing with cleanup where resource management is not systematic. -**Enforcement**: (Simple) Warn if a `Shared_ptr` is constructed from the result of `new` rather than `make_unique`. +##### Enforcement +Heuristic: Detect `goto exit;` - -### R.30: Use `std::weak_ptr` to break cycles of `shared_ptr`s +### E.25: If you can't throw exceptions, simulate RAII for resource management -**Reason**: `shared_ptr's rely on use counting and the use count for a cyclic structure never goes to zero, so we need a mechanism to -be able to destroy a cyclic structure. +##### Reason -**Example**: +Even without exceptions, [RAII](#Re-raii) is usually the best and most systematic way of dealing with resources. - ??? +##### Note -**Note**: ??? [[HS: A lot of people say "to break cycles", while I think "temporary shared ownership" is more to the point.]] -???[[BS: breaking cycles is what you must do; temporarily sharing ownership is how you do it. -You could "temporarily share ownership simply by using another `stared_ptr`.]] +Error handling using exceptions is the only complete and systematic way of handling non-local errors in C++. +In particular, non-intrusively signaling failure to construct an object requires an exception. +Signaling errors in a way that cannot be ignored requires exceptions. +If you can't use exceptions, simulate their use as best you can. -**Enforcement**: ???probably impossible. If we could statically detect cycles, we wouldn't need `weak_ptr` +A lot of fear of exceptions is misguided. +When used for exceptional circumstances in code that is not littered with pointers and complicated control structures, +exception handling is almost always affordable (in time and space) and almost always leads to better code. +This, of course, assumes a good implementation of the exception handling mechanisms, which is not available on all systems. +There are also cases where the problems above do not apply, but exceptions cannot be used for other reasons. +Some hard-real-time systems are an example: An operation has to be completed within a fixed time with an error or a correct answer. +In the absence of appropriate time estimation tools, this is hard to guarantee for exceptions. +Such systems (e.g. flight control software) typically also ban the use of dynamic (heap) memory. +So, the primary guideline for error handling is "use exceptions and [RAII](#Re-raii)." +This section deals with the cases where you either do not have an efficient implementation of exceptions, +or have such a rat's nest of old-style code +(e.g., lots of pointers, ill-defined ownership, and lots of unsystematic error handling based on tests of error codes) +that it is infeasible to introduce simple and systematic exception handling. - -### R.31: If you have non-`std` smart pointers, follow the basic pattern from `std` +Before condemning exceptions or complaining too much about their cost, consider examples of the use of [error codes](#Re-no-throw-codes). +Consider the cost and complexity of the use of error codes. +If performance is your worry, measure. -**Reason**: The rules in the following section also work for other kinds of third-party and custom smart pointers and are very useful for diagnosing common smart pointer errors that cause performance and correctness problems. -You want the rules to work on all the smart pointers you use. +##### Example -Any type (including primary template or specialization) that overloads unary `*` and `->` is considered a smart pointer: +Assume you wanted to write -* If it is copyable, it is recognized as a reference-counted `Shared_ptr`. -* If it not copyable, it is recognized as a unique `Unique_ptr`. + void func(zstring arg) + { + Gadget g {arg}; + // ... + } -**Example**: +If the `gadget` isn't correctly constructed, `func` exits with an exception. +If we cannot throw an exception, we can simulate this RAII style of resource handling by adding a `valid()` member function to `Gadget`: - // use Boost's intrusive_ptr - #include - void f(boost::intrusive_ptr p) { // error under rule 'sharedptrparam' - p->foo(); + error_indicator func(zstring arg) + { + Gadget g {arg}; + if (!g.valid()) return gadget_construction_error; + // ... + return 0; // zero indicates "good" } - // use Microsoft's CComPtr - #include - void f(CComPtr p) { // error under rule 'sharedptrparam' - p->foo(); - } +The problem is of course that the caller now has to remember to test the return value. To encourage doing so, consider adding a `[[nodiscard]]`. -Both cases are an error under the [`sharedptrparam` guideline](#Rr-smartptrparam): -`p` is a `Shared_ptr`, but nothing about its sharedness is used here and passing it by value is a silent pessimization; -these functions should accept a smart pointer only if they need to participate in the widget's lifetime management. Otherwise they should accept a `widget*`, if it can be `nullptr`. Otherwise, and ideally, the function should accept a `widget&`. -These smart pointers match the `Shared_ptr` concept, -so these guideline enforcement rules work on them out of the box and expose this common pessimization. +**See also**: [Discussion](#Sd-???) +##### Enforcement - -### R.32: Take smart pointers as parameters only to explicitly express lifetime semantics +Possible (only) for specific versions of this idea: e.g., test for systematic test of `valid()` after resource handle construction -**Reason**: Accepting a smart pointer to a `widget` is wrong if the function just needs the `widget` itself. -It should be able to accept any `widget` object, not just ones whose lifetimes are managed by a particular kind of smart pointer. -A function that does not manipulate lifetime should take raw pointers or references instead. +### E.26: If you can't throw exceptions, consider failing fast -**Example; bad**: +##### Reason - // callee - void f( shared_ptr& w ) { +If you can't do a good job at recovering, at least you can get out before too much consequential damage is done. + +**See also**: [Simulating RAII](#Re-no-throw-raii) + +##### Note + +If you cannot be systematic about error handling, consider "crashing" as a response to any error that cannot be handled locally. +That is, if you cannot recover from an error in the context of the function that detected it, call `abort()`, `quick_exit()`, +or a similar function that will trigger some sort of system restart. + +In systems where you have lots of processes and/or lots of computers, you need to expect and handle fatal crashes anyway, +say from hardware failures. +In such cases, "crashing" is simply leaving error handling to the next level of the system. + +##### Example + + void f(int n) + { // ... - use( *w ); // only use of w -- the lifetime is not used at all + p = static_cast(malloc(n * sizeof(X))); + if (!p) abort(); // abort if memory is exhausted // ... - }; + } - // caller - shared_ptr my_widget = /*...*/; - f( my_widget ); +Most programs cannot handle memory exhaustion gracefully anyway. This is roughly equivalent to - widget stack_widget; - f( stack_widget ); // error + void f(int n) + { + // ... + p = new X[n]; // throw if memory is exhausted (by default, terminate) + // ... + } -**Example; good**: +Typically, it is a good idea to log the reason for the "crash" before exiting. - // callee - void f( widget& w ) { +##### Enforcement + +Awkward + +### E.27: If you can't throw exceptions, use error codes systematically + +##### Reason + +Systematic use of any error-handling strategy minimizes the chance of forgetting to handle an error. + +**See also**: [Simulating RAII](#Re-no-throw-raii) + +##### Note + +There are several issues to be addressed: + +* How do you transmit an error indicator from out of a function? +* How do you release all resources from a function before doing an error exit? +* What do you use as an error indicator? + +In general, returning an error indicator implies returning two values: The result and an error indicator. +The error indicator can be part of the object, e.g. an object can have a `valid()` indicator +or a pair of values can be returned. + +##### Example + + Gadget make_gadget(int n) + { // ... - use( w ); + } + + void user() + { + Gadget g = make_gadget(17); + if (!g.valid()) { + // error handling + } // ... - }; + } - // caller - shared_ptr my_widget = /*...*/; - f( *my_widget ); +This approach fits with [simulated RAII resource management](#Re-no-throw-raii). +The `valid()` function could return an `error_indicator` (e.g. a member of an `error_indicator` enumeration). - widget stack_widget; - f( stack_widget ); // ok -- now this works +##### Example + +What if we cannot or do not want to modify the `Gadget` type? +In that case, we must return a pair of values. +For example: + + std::pair make_gadget(int n) + { + // ... + } + + void user() + { + auto r = make_gadget(17); + if (!r.second) { + // error handling + } + Gadget& g = r.first; + // ... + } -**Enforcement**: +As shown, `std::pair` is a possible return type. +Some people prefer a specific type. +For example: + + Gval make_gadget(int n) + { + // ... + } -* (Simple) Warn if a function takes a parameter of a type that is a `Unique_ptr` or `Shared_ptr` and the function only calls any of: `operator*`, `operator->` or `get()`). - Suggest using a `T*` or `T&` instead. + void user() + { + auto r = make_gadget(17); + if (!r.err) { + // error handling + } + Gadget& g = r.val; + // ... + } +One reason to prefer a specific return type is to have names for its members, rather than the somewhat cryptic `first` and `second` +and to avoid confusion with other uses of `std::pair`. - -### R.33: Take a `unique_ptr` parameter to express that a function assumes ownership of a `widget` +##### Example -**Reason**: Using `unique_ptr` in this way both documents and enforces the function call's ownership transfer. +In general, you must clean up before an error exit. +This can be messy: -**Example**: + std::pair user() + { + Gadget g1 = make_gadget(17); + if (!g1.valid()) { + return {0, g1_error}; + } - void sink(unique_ptr); // consumes the widget + Gadget g2 = make_gadget(31); + if (!g2.valid()) { + cleanup(g1); + return {0, g2_error}; + } - void sink(widget*); // just uses the widget + // ... -**Example; bad**: + if (all_foobar(g1, g2)) { + cleanup(g2); + cleanup(g1); + return {0, foobar_error}; + } - void thinko(const unique_ptr&); // usually not what you want - + // ... -**Enforcement**: + cleanup(g2); + cleanup(g1); + return {res, 0}; + } -* (Simple) Warn if a function takes a `Unique_ptr` parameter by lvalue reference and does not either assign to it or call `reset()` on it on at least one code path. Suggest taking a `T*` or `T&` instead. -* (Simple) ((Foundation)) Warn if a function takes a `Unique_ptr` parameter by reference to `const`. Suggest taking a `const T*` or `const T&` instead. -* (Simple) ((Foundation)) Warn if a function takes a `Unique_ptr` parameter by rvalue reference. Suggest using pass by value instead. +Simulating RAII can be non-trivial, especially in functions with multiple resources and multiple possible errors. +A not uncommon technique is to gather cleanup at the end of the function to avoid repetition (note that the extra scope around `g2` is undesirable but necessary to make the `goto` version compile): + std::pair user() + { + error_indicator err = 0; + int res = 0; - -### R.34: Take a `unique_ptr&` parameter to express that a function reseats the`widget` + Gadget g1 = make_gadget(17); + if (!g1.valid()) { + err = g1_error; + goto g1_exit; + } -**Reason**: Using `unique_ptr` in this way both documents and enforces the function call's reseating semantics. + { + Gadget g2 = make_gadget(31); + if (!g2.valid()) { + err = g2_error; + goto g2_exit; + } -**Note**: "reseat" means "making a reference or a smart pointer refer to a different object." + if (all_foobar(g1, g2)) { + err = foobar_error; + goto g2_exit; + } -**Example**: + // ... - void reseat( unique_ptr& ); // "will" or "might" reseat pointer + g2_exit: + if (g2.valid()) cleanup(g2); + } -**Example; bad**: + g1_exit: + if (g1.valid()) cleanup(g1); + return {res, err}; + } - void thinko( const unique_ptr& ); // usually not what you want - +The larger the function, the more tempting this technique becomes. +`finally` can [ease the pain a bit](#Re-finally). +Also, the larger the program becomes the harder it is to apply an error-indicator-based error-handling strategy systematically. -**Enforcement**: +We [prefer exception-based error handling](#Re-throw) and recommend [keeping functions short](#Rf-single). -* (Simple) Warn if a function takes a `Unique_ptr` parameter by lvalue reference and does not either assign to it or call `reset()` on it on at least one code path. Suggest taking a `T*` or `T&` instead. -* (Simple) ((Foundation)) Warn if a function takes a `Unique_ptr` parameter by reference to `const`. Suggest taking a `const T*` or `const T&` instead. -* (Simple) ((Foundation)) Warn if a function takes a `Unique_ptr` parameter by rvalue reference. Suggest using pass by value instead. +**See also**: [Discussion](#Sd-???) +**See also**: [Returning multiple values](#Rf-out-multi) - -### R.35: Take a `shared_ptr` parameter to express that a function is part owner +##### Enforcement -**Reason**: This makes the function's ownership sharing explicit. +Awkward. -**Example; good**: +### E.28: Avoid error handling based on global state (e.g. `errno`) - void share( shared_ptr ); // share – “will” retain refcount +##### Reason - void reseat( shared_ptr& ); // “might” reseat ptr +Global state is hard to manage and it is easy to forget to check it. +When did you last test the return value of `printf()`? - void may_share( const shared_ptr& ); // “might” retain refcount +**See also**: [Simulating RAII](#Re-no-throw-raii) -**Enforcement**: +##### Example, bad -* (Simple) Warn if a function takes a `Shared_ptr` parameter by lvalue reference and does not either assign to it or call `reset()` on it on at least one code path. Suggest taking a `T*` or `T&` instead. -* (Simple) ((Foundation)) Warn if a function takes a `Shared_ptr` by value or by reference to `const` and does not copy or move it to another `Shared_ptr` on at least one code path. Suggest taking a `T*` or `T&` instead. -* (Simple) ((Foundation)) Warn if a function takes a `Shared_ptr` by rvalue reference. Suggesting taking it by value instead. + int last_err; + void f(int n) + { + // ... + p = static_cast(malloc(n * sizeof(X))); + if (!p) last_err = -1; // error if memory is exhausted + // ... + } - -### R.36: Take a `shared_ptr&` parameter to express that a function might reseat the shared pointer +##### Note -**Reason**: This makes the function's reseating explicit. +C-style error handling is based on the global variable `errno`, so it is essentially impossible to avoid this style completely. -**Note**: "reseat" means "making a reference or a smart pointer refer to a different object." +##### Enforcement -**Example; good**: +Awkward. - void share( shared_ptr ); // share – “will” retain refcount - void reseat( shared_ptr& ); // “might” reseat ptr +### E.30: Don't use exception specifications - void may_share( const shared_ptr& ); // “might” retain refcount +##### Reason -**Enforcement**: +Exception specifications make error handling brittle, impose a run-time cost, and have been removed from the C++ standard. -* (Simple) Warn if a function takes a `Shared_ptr` parameter by lvalue reference and does not either assign to it or call `reset()` on it on at least one code path. Suggest taking a `T*` or `T&` instead. -* (Simple) ((Foundation)) Warn if a function takes a `Shared_ptr` by value or by reference to `const` and does not copy or move it to another `Shared_ptr` on at least one code path. Suggest taking a `T*` or `T&` instead. -* (Simple) ((Foundation)) Warn if a function takes a `Shared_ptr` by rvalue reference. Suggesting taking it by value instead. +##### Example + int use(int arg) + throw(X, Y) + { + // ... + auto x = f(arg); + // ... + } - -### R.37: Take a `const shared_ptr&` parameter to express that it might retain a reference count to the object ??? +If `f()` throws an exception different from `X` and `Y` the unexpected handler is invoked, which by default terminates. +That's OK, but say that we have checked that this cannot happen and `f` is changed to throw a new exception `Z`, +we now have a crash on our hands unless we change `use()` (and re-test everything). +The snag is that `f()` might be in a library we do not control and the new exception is not anything that `use()` can do +anything about or is in any way interested in. +We can change `use()` to pass `Z` through, but now `use()`'s callers probably need to be modified. +This quickly becomes unmanageable. +Alternatively, we can add a `try`-`catch` to `use()` to map `Z` into an acceptable exception. +This too, quickly becomes unmanageable. +Note that changes to the set of exceptions often happens at the lowest level of a system +(e.g., because of changes to a network library or some middleware), so changes "bubble up" through long call chains. +In a large code base, this could mean that nobody could update to a new version of a library until the last user was modified. +If `use()` is part of a library, it might not be possible to update it because a change could affect unknown clients. -**Reason**: This makes the function's ??? explicit. +The policy of letting exceptions propagate until they reach a function that potentially can handle it has proven itself over the years. -**Example; good**: +##### Note - void share( shared_ptr ); // share – “will” retain refcount +No. This would not be any better had exception specifications been statically enforced. +For example, see [Stroustrup94](#Stroustrup94). - void reseat( shared_ptr& ); // “might” reseat ptr +##### Note - void may_share( const shared_ptr& ); // “might” retain refcount +If no exception can be thrown, use [`noexcept`](#Re-noexcept). -**Enforcement**: +##### Enforcement -* (Simple) Warn if a function takes a `Shared_ptr` parameter by lvalue reference and does not either assign to it or call `reset()` on it on at least one code path. Suggest taking a `T*` or `T&` instead. -* (Simple) ((Foundation)) Warn if a function takes a `Shared_ptr` by value or by reference to `const` and does not copy or move it to another `Shared_ptr` on at least one code path. Suggest taking a `T*` or `T&` instead. -* (Simple) ((Foundation)) Warn if a function takes a `Shared_ptr` by rvalue reference. Suggesting taking it by value instead. - +Flag every exception specification. - -### R.38: Do not pass a pointer or reference obtained from an aliased smart pointer - -**Reason**: Violating this rule is the number one cause of losing reference counts and finding yourself with a dangling pointer. -Functions should prefer to pass raw pointers and references down call chains. -At the top of the call tree where you obtain the raw pointer or reference from a smart pointer that keeps the object alive. -You need to be sure that smart pointer cannot be inadvertently be reset or reassigned from within the call tree below +### E.31: Properly order your `catch`-clauses -**Note**: To do this, sometimes you need to take a local copy of a smart pointer, which firmly keeps the object alive for the duration of the function and the call tree. +##### Reason -**Example**: Consider this code: +`catch`-clauses are evaluated in the order they appear and one clause can hide another. - // global (static or heap), or aliased local... - shared_ptr g_p = ...; +##### Example, bad - void f( widget& w ) { - g(); - use(w); // A + void f() + { + // ... + try { + // ... + } + catch (Base& b) { /* ... */ } + catch (Derived& d) { /* ... */ } + catch (...) { /* ... */ } + catch (std::exception& e) { /* ... */ } } - void g() { - g_p = ... ; // oops, if this was the last shared_ptr to that widget, destroys the widget - } +If `Derived`is derived from `Base` the `Derived`-handler will never be invoked. +The "catch everything" handler ensured that the `std::exception`-handler will never be invoked. -The following should not pass code review: +##### Enforcement - void my_code() { - f( *g_p ); // BAD: passing pointer or reference obtained from a nonlocal smart pointer - // that could be inadvertently reset somewhere inside f or it callees - g_p->func(); // BAD: same reason, just passing it as a "this" pointer - } +Flag all "hiding handlers". -The fix is simple -- take a local copy of the pointer to "keep a ref count" for your call tree: +# Con: Constants and immutability - void my_code() { - auto pin = g_p; // cheap: 1 increment covers this entire function and all the call trees below us - f( *pin ); // GOOD: passing pointer or reference obtained from a local unaliased smart pointer - pin->func(); // GOOD: same reason - } +You can't have a race condition on a constant. +It is easier to reason about a program when many of the objects cannot change their values. +Interfaces that promise "no change" of objects passed as arguments greatly increase readability. -**Enforcement**: +Constant rule summary: -* (Simple) Warn if a pointer or reference obtained from a smart pointer variable (`Unique_ptr` or `Shared_ptr`) that is nonlocal, or that is local but potentially aliased, is used in a function call. If the smart pointer is a `Shared_ptr` then suggest taking a local copy of the smart pointer and obtain a pointer or reference from that instead. +* [Con.1: By default, make objects immutable](#Rconst-immutable) +* [Con.2: By default, make member functions `const`](#Rconst-fct) +* [Con.3: By default, pass pointers and references to `const`s](#Rconst-ref) +* [Con.4: Use `const` to define objects with values that do not change after construction](#Rconst-const) +* [Con.5: Use `constexpr` for values that can be computed at compile time](#Rconst-constexpr) +### Con.1: By default, make objects immutable +##### Reason +Immutable objects are easier to reason about, so make objects non-`const` only when there is a need to change their value. +Prevents accidental or hard-to-notice change of value. - -# ES: Expressions and Statements +##### Example -Expressions and statements are the lowest and most direct way of expressing actions and computation. Declarations in local scopes are statements. + for (const int i : c) cout << i << '\n'; // just reading: const -For naming, commenting, and indentation rules, see [NL: Naming and layout](#S-naming). + for (int i : c) cout << i << '\n'; // BAD: just reading -General rules: +##### Exceptions -* [ES.1: Prefer the standard library to other libraries and to "handcrafted code"](#Res-lib) -* [ES.2: Prefer suitable abstractions to direct use of language features](#Res-abstr) +A local variable that is returned by value and is cheaper to move than copy should not be declared `const` +because it can force an unnecessary copy. + std::vector f(int i) + { + std::vector v{ i, i, i }; // const not needed + return v; + } -Declaration rules: +Function parameters passed by value are rarely mutated, but also rarely declared `const`. +To avoid confusion and lots of false positives, don't enforce this rule for function parameters. -* [ES.5: Keep scopes small](#Res-scope) -* [ES.6: Declare names in for-statement initializers and conditions to limit scope](#Res-cond) -* [ES.7: Keep common and local names short, and keep uncommon and nonlocal names longer](#Res-name-length) -* [ES.8: Avoid similar-looking names](#Res-name-similar) -* [ES.9: Avoid `ALL_CAPS` names](#Res-!CAPS) -* [ES.10: Declare one name (only) per declaration](#Res-name-one) -* [ES.11: Use `auto` to avoid redundant repetition of type names](#Res-auto) -* [ES.20: Always initialize an object](#Res-always) -* [ES.21: Don't introduce a variable (or constant) before you need to use it](#Res-introduce) -* [ES.22: Don't declare a variable until you have a value to initialize it with](#Res-init) -* [ES.23: Prefer the `{}`-initializer syntax](#Res-list) -* [ES.24: Use a `unique_ptr` to hold pointers in code that may throw](#Res-unique) -* [ES.25: Declare an object `const` or `constexpr` unless you want to modify its value later on](#Res-const) -* [ES.26: Don't use a variable for two unrelated purposes](#Res-recycle) -* [ES.27: Use `std::array` or `stack_array` for arrays on the stack](#Res-stack) -* [ES.28: Use lambdas for complex initialization, especially of `const` variables](#Res-lambda-init) -* [ES.30: Don't use macros for program text manipulation](#Res-macros) -* [ES.31: Don't use macros for constants or "functions"](#Res-macros2) -* [ES.32: Use `ALL_CAPS` for all macro names](#Res-CAPS!) -* [ES.40: Don't define a (C-style) variadic function](#Res-ellipses) + void g(const int i) { ... } // pedantic +Note that a function parameter is a local variable so changes to it are local. -Expression rules: +##### Enforcement -* [ES.40: Avoid complicated expressions](#Res-complicated) -* [ES.41: If in doubt about operator precedence, parenthesize](#Res-parens) -* [ES.42: Keep use of pointers simple and straightforward](#Res-ptr) -* [ES.43: Avoid expressions with undefined order of evaluation](#Res-order) -* [ES.44: Don't depend on order of evaluation of function arguments](#Res-order-fct) -* [ES.45: Avoid narrowing conversions](#Res-narrowing) -* [ES.46: Avoid "magic constants"; use symbolic constants](#Res-magic) -* [ES.47: Use `nullptr` rather than `0` or `NULL`](#Res-nullptr) -* [ES.48: Avoid casts](#Res-casts) -* [ES.49: If you must use a cast, use a named cast](#Res-casts-named) -* [ES.50: Don't cast away `const`](#Res-casts-const) -* [ES.55: Avoid the need for range checking](#Res-range-checking) -* [ES.60: Avoid `new` and `delete[]` outside resource management functions](#Res-new) -* [ES.61: delete arrays using `delete[]` and non-arrays using `delete`](#Res-del) -* [ES.62: Don't compare pointers into different arrays](#Res-arr2) +* Flag non-`const` variables that are not modified (except for parameters to avoid many false positives +and returned local variables) +### Con.2: By default, make member functions `const` +##### Reason -Statement rules: +A member function should be marked `const` unless it changes the object's observable state. +This gives a more precise statement of design intent, better readability, more errors caught by the compiler, and sometimes more optimization opportunities. -* [ES.70: Prefer a `switch`-statement to an `if`-statement when there is a choice](#Res-switch-if) -* [ES.71: Prefer a range-`for`-statement to a `for`-statement when there is a choice](#Res-for-range) -* [ES.72: Prefer a `for`-statement to a `while`-statement when there is an obvious loop variable](#Res-for-while) -* [ES.73: Prefer a `while`-statement to a `for`-statement when there is no obvious loop variable](#Res-while-for) -* [ES.74: Prefer to declare a loop variable in the initializer part of as `for`-statement](#Res-for-init) -* [ES.75: Avoid `do`-statements](#Res-do) -* [ES.76: Avoid `goto`](#Res-goto) -* [ES.77: ??? `continue`](#Res-continue) -* [ES.78: ??? `break`](#Res-break) -* [ES.79: ??? `default`](#Res-default) -* [ES.85: Make empty statements visible](#Res-empty) +##### Example, bad -Arithmetic rules: + class Point { + int x, y; + public: + int getx() { return x; } // BAD, should be const as it doesn't modify the object's state + // ... + }; -* [ES.100: Don't mix signed and unsigned arithmetic](Res-mix) -* [ES.101: use unsigned types for bit manipulation](#Res-unsigned) -* [ES.102: Used signed types for arithmetic](#Res-signed) -* [ES.103: Don't overflow](#Res-overflow) -* [ES.104: Don't underflow](#Res-overflow) -* [ES.105: Don't divide by zero](#Res-zero) + void f(const Point& pt) + { + int x = pt.getx(); // ERROR, doesn't compile because getx was not marked const + } + +##### Note +It is not inherently bad to pass a pointer or reference to non-`const`, +but that should be done only when the called function is supposed to modify the object. +A reader of code must assume that a function that takes a "plain" `T*` or `T&` will modify the object referred to. +If it doesn't now, it might do so later without forcing recompilation. - -### ES.1: Prefer the standard library to other libraries and to "handcrafted code" +##### Note -**Reason**: Code using a library can be much easier to write than code working directly with language features, much shorter, tend to be of a higher level of abstraction, and the library code is presumably already tested. -The ISO C++ standard library is among the most widely know and best tested libraries. -It is available as part of all C++ Implementations. +There are code/libraries that offer functions that declare a `T*` even though +those functions do not modify that `T`. +This is a problem for people modernizing code. +You can -**Example**: +* update the library to be `const`-correct; preferred long-term solution +* "cast away `const`"; [best avoided](#Res-casts-const) +* provide a wrapper function - auto sum = accumulate(begin(a),end(a),0.0); // good +Example: -a range version of `accumulate` would be even better + void f(int* p); // old code: f() does not modify `*p` + void f(const int* p) { f(const_cast(p)); } // wrapper - auto sum = accumulate(v,0.0); // better +Note that this wrapper solution is a patch that should be used only when the declaration of `f()` cannot be modified, +e.g. because it is in a library that you cannot modify. + +##### Note + +A `const` member function can modify the value of an object that is `mutable` or accessed through a pointer member. +A common use is to maintain a cache rather than repeatedly do a complicated computation. +For example, here is a `Date` that caches (memoizes) its string representation to simplify repeated uses: + + class Date { + public: + // ... + const string& string_ref() const + { + if (string_val == "") compute_string_rep(); + return string_val; + } + // ... + private: + void compute_string_rep() const; // compute string representation and place it in string_val + mutable string string_val; + // ... + }; -but don't hand-code a well-known algorithm +Another way of saying this is that `const`ness is not transitive. +It is possible for a `const` member function to change the value of `mutable` members and the value of objects accessed +through non-`const` pointers. +It is the job of the class to ensure such mutation is done only when it makes sense according to the semantics (invariants) +it offers to its users. - int max = v.size(); // bad: verbose, purpose unstated - double sum = 0.0; - for (int i = 0; iCon.3: By default, pass pointers and references to `const`s - -### ES.2: Prefer suitable abstractions to direct use of language features +##### Reason -**Reason**: A "suitable abstraction" (e.g., library or class) is closer to the application concepts than the bare language, leads to shorter and clearer code, and is likely to be better tested. + To avoid a called function unexpectedly changing the value. + It's far easier to reason about programs when called functions don't modify state. +##### Example -**Example**: + void f(char* p); // does f modify *p? (assume it does) + void g(const char* p); // g does not modify *p - vector read1(istream& is) // good - { - vector res; - for (string s; is>>s; ) - res.push_back(s); - return res; - } +##### Note -The more traditional and lower-level near-equivalent is longer, messier, harder to get right, and most likely slower: +It is not inherently bad to pass a pointer or reference to non-`const`, +but that should be done only when the called function is supposed to modify the object. - char** read2(istream& is, int maxelem, int maxstring, int* nread) // bad: verbose and incomplete - { - auto res = new char*[maxelem]; - int elemcount = 0; - while (is && elemcountCon.4: Use `const` to define objects with values that do not change after construction -A declaration is a statement. a declaration introduces a name into a scope and may cause the construction of a named object. +##### Reason + Prevent surprises from unexpectedly changed object values. - -### ES.5: Keep scopes small +##### Example -**Reason**: Readability. Minimize resource retension. Avoid accidental misuse of value. + void f() + { + int x = 7; + const int y = 9; -**Alternative formulation**: Don't declare a name in an unnecessarily large scope. + for (;;) { + // ... + } + // ... + } -**Example**: - - void use() - { - int i; // bad: i is needlessly accessible after loop - for (i=0; i<20; ++i) { /* ... */ } - // no intended use of i here - for (int i=0; i<20; ++i) { /* ... */ } // good: i is local to for-loop - - if (auto pc = dynamic_cast(ps)) { // good: pc is local to if-statement - // ...deal with Circle ... - } - else { - // ... handle error ... - } - } - -**Example, bad**: - - void use(const string& name) - { - string fn = name+".txt"; - ifstream is {fn}; - Record r; - is >> r; - // ... 200 lines of code without intended use of fn or is ... - } - -This function is by most measure too long anyway, but the point is that the used by `fn` and the file handle held by `is` -are retained for much longer than needed and that unanticipated use of `is` and `fn` could happen later in the function. -In this case, it might be a good ide to factor out the read: - - void fill_record(Record& r, const string& name) - { - string fn = name+".txt"; - ifstream is {fn}; - Record r; - is >> r; - } - - void use(const string& name) - { - Record r; - fill_record(r,name); - // ... 200 lines of code ... - } - -I am assuming that `Record` is large and doesn't have a good move operation so that an out-parameter is preferable to returning a `Record`. - -**Enforcement**: +As `x` is not `const`, we must assume that it is modified somewhere in the loop. -* Flag loop variable declared outside a loop and not used after the loop -* Flag when expensive resources, such as file handles and locks are not used for N-lines (for some suitable N) +##### Enforcement +* Flag unmodified non-`const` variables. - -### ES.6: Declare names in for-statement initializers and conditions to limit scope +### Con.5: Use `constexpr` for values that can be computed at compile time -**Reason**: Readability. Minimize resource retension. +##### Reason -**Example**: +Better performance, better compile-time checking, guaranteed compile-time evaluation, no possibility of race conditions. - void use() - { - for (string s; cin>>s; ) - v.push_back(s); - - for (int i=0; i<20; ++i) { // good: i is local to for-loop - //* ... - } +##### Example - if (auto pc = dynamic_cast(ps)) { // good: pc is local to if-statement - // ...deal with Circle ... - } - else { - // ... handle error ... - } - } + double x = f(2); // possible run-time evaluation + const double y = f(2); // possible run-time evaluation + constexpr double z = f(2); // error unless f(2) can be evaluated at compile time -**Enforcement**: +##### Note -* Flag loop variables declared before the loop and not used after the loop -* (hard) Flag loop variables declared before the loop and used after the loop for an unrelated purpose. +See F.4. +##### Enforcement - -### ES.7: Keep common and local names short, and keep uncommon and nonlocal names longer +* Flag `const` definitions with constant expression initializers. -**Reason**: Readability. Lowering the chance of clashes between unrelated non-local names. +# T: Templates and generic programming -**Example**: Conventional short, local names increase readability: +Generic programming is programming using types and algorithms parameterized by types, values, and algorithms. +In C++, generic programming is supported by the `template` language mechanisms. - template // good - void print(ostream& os, const vector& v) - { - for (int i = 0; i // bad: verbose, hard to read - void print(ostream& target_stream, const vector& current_vector) - { - for (int current_element_index = 0; - current_element_index`) sparingly to express a minor difference](#Rt-???) +* [T.31: Use concept disjunction (`C1 || C2`) sparingly to express alternatives](#Rt-???) +* ??? - void complicated_algorithm(vector&vr, const vector& vi, map& out) - // read from events in vr (marking used Records) for the indices in vi placing (name,index) pairs into out - { - // ... 500 lines of code using vr, vi, and out ... - } +Template interface rule summary: -We recommend keeping functions short, but that rule isn't universally adhered to and naming should reflect that. +* [T.40: Use function objects to pass operations to algorithms](#Rt-fo) +* [T.41: Require only essential properties in a template's concepts](#Rt-essential) +* [T.42: Use template aliases to simplify notation and hide implementation details](#Rt-alias) +* [T.43: Prefer `using` over `typedef` for defining aliases](#Rt-using) +* [T.44: Use function templates to deduce class template argument types (where feasible)](#Rt-deduce) +* [T.46: Require template arguments to be at least semiregular](#Rt-regular) +* [T.47: Avoid highly visible unconstrained templates with common names](#Rt-visible) +* [T.48: If your compiler does not support concepts, fake them with `enable_if`](#Rt-concept-def) +* [T.49: Where possible, avoid type-erasure](#Rt-erasure) -**Enforcement**: Check length of local and non-local names. Also take function length into account. +Template definition rule summary: +* [T.60: Minimize a template's context dependencies](#Rt-depend) +* [T.61: Do not over-parameterize members (SCARY)](#Rt-scary) +* [T.62: Place non-dependent class template members in a non-templated base class](#Rt-nondependent) +* [T.64: Use specialization to provide alternative implementations of class templates](#Rt-specialization) +* [T.65: Use tag dispatch to provide alternative implementations of functions](#Rt-tag-dispatch) +* [T.67: Use specialization to provide alternative implementations for irregular types](#Rt-specialization2) +* [T.68: Use `{}` rather than `()` within templates to avoid ambiguities](#Rt-cast) +* [T.69: Inside a template, don't make an unqualified non-member function call unless you intend it to be a customization point](#Rt-customization) - -### ES.8: Avoid similar-looking names +Template and hierarchy rule summary: -**Reason**: Such names slow down comprehension and increase the likelihood of error. +* [T.80: Do not naively templatize a class hierarchy](#Rt-hier) +* [T.81: Do not mix hierarchies and arrays](#Rt-array) // ??? somewhere in "hierarchies" +* [T.82: Linearize a hierarchy when virtual functions are undesirable](#Rt-linear) +* [T.83: Do not declare a member function template virtual](#Rt-virtual) +* [T.84: Use a non-template core implementation to provide an ABI-stable interface](#Rt-abi) +* [T.??: ????](#Rt-???) -**Example**: +Variadic template rule summary: - if (readable(i1+l1+ol+o1+o0+ol+o1+I0+l0)) surprise(); +* [T.100: Use variadic templates when you need a function that takes a variable number of arguments of a variety of types](#Rt-variadic) +* [T.101: ??? How to pass arguments to a variadic template ???](#Rt-variadic-pass) +* [T.102: ??? How to process arguments to a variadic template ???](#Rt-variadic-process) +* [T.103: Don't use variadic templates for homogeneous argument lists](#Rt-variadic-not) +* [T.??: ????](#Rt-???) -**Enforcement**: Check names against a list of known confusing letter and digit combinations. +Metaprogramming rule summary: +* [T.120: Use template metaprogramming only when you really need to](#Rt-metameta) +* [T.121: Use template metaprogramming primarily to emulate concepts](#Rt-emulate) +* [T.122: Use templates (usually template aliases) to compute types at compile time](#Rt-tmp) +* [T.123: Use `constexpr` functions to compute values at compile time](#Rt-fct) +* [T.124: Prefer to use standard-library TMP facilities](#Rt-std-tmp) +* [T.125: If you need to go beyond the standard-library TMP facilities, use an existing library](#Rt-lib) +* [T.??: ????](#Rt-???) - -### ES.9: Avoid `ALL_CAPS` names +Other template rules summary: -**Reason**: Such names are commonly used for macros. Thus, ALL_CAPS name are vulnerable to unintended macro substitution. +* [T.140: If an operation can be reused, give it a name](#Rt-name) +* [T.141: Use an unnamed lambda if you need a simple function object in one place only](#Rt-lambda) +* [T.142: Use template variables to simplify notation](#Rt-var) +* [T.143: Don't write unintentionally non-generic code](#Rt-non-generic) +* [T.144: Don't specialize function templates](#Rt-specialize-function) +* [T.150: Check that a class matches a concept using `static_assert`](#Rt-check-class) +* [T.??: ????](#Rt-???) -**Example**: +## T.gp: Generic programming - // somewhere in some header: - #define NE != +Generic programming is programming using types and algorithms parameterized by types, values, and algorithms. - // somewhere else in some other header: - enum Coord { N, NE, NW, S, SE, SW, E, W }; - - // somewhere third in some poor programmer's .cpp: - switch (direction) { - case N: - // ... - case NE: - // ... - // ... - } +### T.1: Use templates to raise the level of abstraction of code -**Note**: Do not use `ALL_CAPS` for constants just because constants used to be macros. +##### Reason -**Enforcement**: Flag all uses of ALL CAPS. For older code, accept ALL CAPS for macro names and flag all non-ALL-CAPS macro names. +Generality. Reuse. Efficiency. Encourages consistent definition of user types. +##### Example, bad - -### ES.10: Declare one name (only) per declaration +Conceptually, the following requirements are wrong because what we want of `T` is more than just the very low-level concepts of "can be incremented" or "can be added": -**Reason**: One-declaration-per line increases readability and avoid mistake related to the C/C++ grammar. It leaves room for a `//`-comment + template + requires Incrementable + T sum1(vector& v, T s) + { + for (auto x : v) s += x; + return s; + } -**Example; bad**: + template + requires Simple_number + T sum2(vector& v, T s) + { + for (auto x : v) s = s + x; + return s; + } - char *p, c, a[7], *pp[7], **aa[10]; // yuck! +Assuming that `Incrementable` does not support `+` and `Simple_number` does not support `+=`, we have overconstrained implementers of `sum1` and `sum2`. +And, in this case, missed an opportunity for a generalization. -**Exception**: a function declaration can contain several function argument declarations. +##### Example -**Example**: - - template - bool any_of(InputIterator first, InputIterator last, Predicate pred); + template + requires Arithmetic + T sum(vector& v, T s) + { + for (auto x : v) s += x; + return s; + } -or better using concepts +Assuming that `Arithmetic` requires both `+` and `+=`, we have constrained the user of `sum` to provide a complete arithmetic type. +That is not a minimal requirement, but it gives the implementer of algorithms much needed freedom and ensures that any `Arithmetic` type +can be used for a wide variety of algorithms. - bool any_of(InputIterator first, InputIterator last, Predicate pred); +For additional generality and reusability, we could also use a more general `Container` or `Range` concept instead of committing to only one container, `vector`. -**Example**: +##### Note - double scalbn(double x, int n); // OK: x*pow(FLT_RADIX,n); FLT_RADIX is usually 2 +If we define a template to require exactly the operations required for a single implementation of a single algorithm +(e.g., requiring just `+=` rather than also `=` and `+`) and only those, we have overconstrained maintainers. +We aim to minimize requirements on template arguments, but the absolutely minimal requirements of an implementation is rarely a meaningful concept. -or +##### Note - double scalbn( // better: x*pow(FLT_RADIX,n); FLT_RADIX is usually 2 - double x; // base value - int n; // exponent - ); +Templates can be used to express essentially everything (they are Turing complete), but the aim of generic programming (as expressed using templates) +is to efficiently generalize operations/algorithms over a set of types with similar semantic properties. -or +##### Enforcement - double scalbn(double base, int exponent); // better: base*pow(FLT_RADIX,exponent); FLT_RADIX is usually 2 +* Flag algorithms with "overly simple" requirements, such as direct use of specific operators without a concept. +* Do not flag the definition of the "overly simple" concepts themselves; they might simply be building blocks for more useful concepts. -**Enforcement**: Flag non-function arguments with multiple declarators involving declarator operators (e.g., `int* p, q;`) +### T.2: Use templates to express algorithms that apply to many argument types +##### Reason - -### ES.11: Use `auto` to avoid redundant repetition of type names +Generality. Minimizing the amount of source code. Interoperability. Reuse. -**Reason**: +##### Example -* Simple repetition is tedious and error prone. -* When you us `auto`, the name of the declared entity is in a fixed position in the declaration, increasing readability. -* In a template function declaration the return type can be a member type. +That's the foundation of the STL. A single `find` algorithm easily works with any kind of input range: -**Example**: Consider + template + // requires Input_iterator + // && Equality_comparable, Val> + Iter find(Iter b, Iter e, Val v) + { + // ... + } - auto p = v.begin(); // vector::iterator - auto s = v.size(); - auto h = t.future(); - auto q = new int[s]; - auto f = [](int x){ return x+10; } +##### Note -In each case, we save writing a longish, hard-to-remember type that the compiler already knows but a programmer could get wrong. +Don't use a template unless you have a realistic need for more than one template argument type. +Don't overabstract. -**Example**: +##### Enforcement - template - auto Container::first() -> Iterator; // Container::Iterator +??? tough, probably needs a human -**Exception**: Avoid `auto` for initializer lists and in cases where you know exactly which type you want and where an inititializer might require conversion. +### T.3: Use templates to express containers and ranges -**Example**: +##### Reason - auto lst = { 1, 2, 3 }; // lst is an initializer list (obviously) - auto x = {1}; // x is an int (after correction of the C++14 standard; initializer_list in C++11) +Containers need an element type, and expressing that as a template argument is general, reusable, and type safe. +It also avoids brittle or inefficient workarounds. Convention: That's the way the STL does it. -**Note**: When concepts become available, we can (and should) be more specific about the type we are deducing: +##### Example - // ... - ForwardIterator p = algo(x,y,z); + template + // requires Regular + class Vector { + // ... + T* elem; // points to sz Ts + int sz; + }; -**Enforcement**: Flag redundant repetition of type names in a declaration. + Vector v(10); + v[7] = 9.9; +##### Example, bad - -### ES.20: Always initialize an object + class Container { + // ... + void* elem; // points to size elements of some type + int sz; + }; -**Reason**: Avoid used-before-set errors and their associated undefined behavior. + Container c(10, sizeof(double)); + ((double*) c.elem)[7] = 9.9; -**Example**: +This doesn't directly express the intent of the programmer and hides the structure of the program from the type system and optimizer. - void use(int arg) // bad: uninitialized variable - { - int i; - // ... - i = 7; // initialize i - } +Hiding the `void*` behind macros simply obscures the problems and introduces new opportunities for confusion. -No, `i=7` does not initialize `i`; it assigns to it. Also, `i` can be read in the `...` part. Better: +**Exceptions**: If you need an ABI-stable interface, you might have to provide a base implementation and express the (type-safe) template in terms of that. +See [Stable base](#Rt-abi). - void use(int arg) // OK - { - int i = 7; // OK: initialized - string s; // OK: default initialized - // ... - } +##### Enforcement -**Exception**: It you are declaring an object that is just about to be initialized from input, initializing it would cause a double initialization. -However, beware that this may leave uninitialized data beyond the input - and that has been a fertile source of errors and security breaches: +* Flag uses of `void*`s and casts outside low-level implementation code - constexpr int max = 8*1024; - int buf[max]; // OK, but suspicious - f.read(buf,max); +### T.4: Use templates to express syntax tree manipulation -The cost of initializing that array could be significant in some situations. -However, such examples do tend to leave uninitialized variables accessible, so they should be treated with suspicion. - - constexpr int max = 8*1024; - int buf[max] = {0}; // better in some situations - f.read(buf,max); +##### Reason -When feasible use a library function that is know not to overflow. For example: + ??? - string s; // s is default initialized to "" - cin>>s; // s expands to hold the string +##### Example -Don't consider simple variables that are targets for input operations exceptions to this rule: + ??? - int i; // bad - // ... - cin>>i; +**Exceptions**: ??? -In the not uncommon case where the input target and the input operation get separated (as they should not) the possibility of used-before-set opens up. +### T.5: Combine generic and OO techniques to amplify their strengths, not their costs - int i2 = 0; // better - // ... - cin>>i; +##### Reason -A good optimizer should know about input operations and eliminate the redundant operation. +Generic and OO techniques are complementary. -**Exception**: Sometimes, we want to initialize a set of variables with a call to a function that returns several values. -That can lead to uninitialized variables (exceptly as for input operations): - - error_code ec; - Value v; - tie(ec,v) = get_value(); // get_value() returns a pair - -**Note**: Sometimes, a lambda can be used as an initializer to avoid an uninitialized variable. - - error_code ec; - Value v = [&]() { - auto p = get_value(); // get_value() returns a pair - ec = p.first; - return p.second; - }; - -or maybe - - Value v = []() { - auto p = get_value(); // get_value() returns a pair - if (p.first) throw Bad_value{p.first}; - return p.second; - }; - -**See also**: [ES.28](#Res-lambda-init) - -**Enforcement**: +##### Example -* Flag every uninitialized variable. -Don't flag variables of user-defined types with default constructors. -* Check that the unitialized buffer is read into *immediately* after declaration. +Static helps dynamic: Use static polymorphism to implement dynamically polymorphic interfaces. + class Command { + // pure virtual functions + }; - -### ES.21: Don't introduce a variable (or constant) before you need to use it + // implementations + template + class ConcreteCommand : public Command { + // implement virtuals + }; -**Reason**: Readability. To limit the scope in which the variable can be used. +##### Example -**Example**: +Dynamic helps static: Offer a generic, comfortable, statically bound interface, but internally dispatch dynamically, so you offer a uniform object layout. +Examples include type erasure as with `std::shared_ptr`'s deleter (but [don't overuse type erasure](#Rt-erasure)). - int x = 7; - // ... no use of x here ... - ++x; + #include -**Enforcement**: Flag declaration that distant from their first use. + class Object { + public: + template + Object(T&& obj) + : concept_(std::make_shared>(std::forward(obj))) {} + int get_id() const { return concept_->get_id(); } - -### ES.22: Don't declare a variable until you have a value to initialize it with + private: + struct Command { + virtual ~Command() {} + virtual int get_id() const = 0; + }; -**Reason**: Readability. Limit the scope in which a variable can be used. Don't risk used-before-set. Initialization is often more efficient than assignment. + template + struct ConcreteCommand final : Command { + ConcreteCommand(T&& obj) noexcept : object_(std::forward(obj)) {} + int get_id() const final { return object_.get_id(); } -**Example, bad**: + private: + T object_; + }; - string s; - // ... no use of s here ... - s = "what a waste"; + std::shared_ptr concept_; + }; -**Example, bad**: + class Bar { + public: + int get_id() const { return 1; } + }; - SomeLargeType var; // ugly CaMeLcAsEvArIaBlE - - if( cond ) // some non-trivial condition - Set( &var ); - else if (cond2 || !cond3) { - var = Set2( 3.14 ); - } - else { - var = 0; - for (auto& e : something) - var += e; - } + struct Foo { + public: + int get_id() const { return 2; } + }; - // use var; that this isn't done too early can be enforced statically with only control flow + Object o(Bar{}); + Object o2(Foo{}); -This would be fine if there was a default initialization for `SomeLargeType` that wasn't too expensive. -Otherwise, a programmer might very well wonder if every possible path through the maze of conditions has been covered. -If not, we have a "use before set" bug. This is a maintenance trap. +##### Note -For initializers of moderate complexity, including for `const` variables, consider using a lambda to express the initializer; see [ES.28](#Res-lambda-init). +In a class template, non-virtual functions are only instantiated if they're used -- but virtual functions are instantiated every time. +This can bloat code size, and might overconstrain a generic type by instantiating functionality that is never needed. +Avoid this, even though the standard-library facets made this mistake. -**Enforcement**: +##### See also -* Flag declarations with default initialization that are assigned to before they are first read. -* Flag any complicated computation after an uninitialized variable and before its use. +* ref ??? +* ref ??? +* ref ??? +##### Enforcement - -### ES.23: Prefer the `{}` initializer syntax +See the reference to more specific rules. -**Reason**: The rules for `{}` initialization is simpler, more general, and safer than for other forms of initialization, and unambiguous. +## T.concepts: Concept rules -**Example**: +Concepts is a C++20 facility for specifying requirements for template arguments. +They are crucial in the thinking about generic programming and the basis of much work on future C++ libraries +(standard and other). - int x {f(99)}; - vector v = {1,2,3,4,5,6}; +This section assumes concept support -**Exception**: For containers, there is a tradition for using `{...}` for a list of elements and `(...)` for sizes: +Concept use rule summary: - vector v1(10); // vector of 10 elements with the default value 0 - vector v2 {10}; // vector of 1 element with the value 10 +* [T.10: Specify concepts for all template arguments](#Rt-concepts) +* [T.11: Whenever possible use standard concepts](#Rt-std-concepts) +* [T.12: Prefer concept names over `auto`](#Rt-auto) +* [T.13: Prefer the shorthand notation for simple, single-type argument concepts](#Rt-shorthand) +* ??? -**Note**: `{}`-initializers do not allow narrowing conversions. +Concept definition rule summary: -**Example**: +* [T.20: Avoid "concepts" without meaningful semantics](#Rt-low) +* [T.21: Require a complete set of operations for a concept](#Rt-complete) +* [T.22: Specify axioms for concepts](#Rt-axiom) +* [T.23: Differentiate a refined concept from its more general case by adding new use patterns](#Rt-refine) +* [T.24: Use tag classes or traits to differentiate concepts that differ only in semantics](#Rt-tag) +* [T.25: Avoid complimentary constraints](#Rt-not) +* [T.26: Prefer to define concepts in terms of use-patterns rather than simple syntax](#Rt-use) +* ??? - int x {7.9}; // error: narrowing - int y = 7.9; // OK: y becomes 7. Hope for a compiler warning +## T.con-use: Concept use -**Note**: `{}` initialization can be used for all initialization; other forms of initialization can't: +### T.10: Specify concepts for all template arguments - auto p = new vector {1,2,3,4,5}; // initialized vector - D::D(int a, int b) :m{a,b} { // member initializer (e.g., m might be a pair) - // ... - }; - X var {}; // initialize var to be empty - struct S { - int m {7}; // default initializer for a member - // ... - }; +##### Reason -**Note**: Initialization of a variable declared `auto` with a single value `{v}` surprising results until recently: +Correctness and readability. +The assumed meaning (syntax and semantics) of a template argument is fundamental to the interface of a template. +A concept dramatically improves documentation and error handling for the template. +Specifying concepts for template arguments is a powerful design tool. - auto x1 {7}; // x1 is sn int with the value 7 - auto x2 = {7}; // x2 is and initializer_int with an element 7 +##### Example - auto x11 {7,8}; // error: two initializers - auto x22 = {7,8}; // x2 is and initializer_int with elements 7 and 8 + template + requires input_iterator + && equality_comparable_with, Val> + Iter find(Iter b, Iter e, Val v) + { + // ... + } -**Exception**: Use `={...}` if you really want an `initializer_list` +or equivalently and more succinctly: - auto fib10 = {0,1,2,3,5,8,13,25,38,63}; // fib10 is a list - -**Example**: + template + requires equality_comparable_with, Val> + Iter find(Iter b, Iter e, Val v) + { + // ... + } - template - void f() - { - T x1(1); // T initialized with 1 - T x0(); // bad: function declaration (often a mistake) - - T y1 {1}; // T initialized with 1 - T y0 {}; // default initialized T - // ... - } +##### Note -**See also**: [Discussion](#???) +Plain `typename` (or `auto`) is the least constraining concept. +It should be used only rarely when nothing more than "it's a type" can be assumed. +This is typically only needed when (as part of template metaprogramming code) we manipulate pure expression trees, postponing type checking. -**Enforcement**: Tricky. +**References**: TC++PL4 -* Don't flag uses of `=` for simple initializers. -* Look for `=` after `auto` has been seen. +##### Enforcement +Flag template type arguments without concepts - -### ES.24: Use a `unique_ptr` to hold pointers in code that may throw +### T.11: Whenever possible use standard concepts -**Reason**: Using `std::unique_ptr` is the simplest way to avoid leaks. And it is free compared to alternatives +##### Reason -**Example**: + "Standard" concepts (as provided by the [GSL](#gsl-guidelines-support-library) and the ISO standard itself) +save us the work of thinking up our own concepts, are better thought out than we can manage to do in a hurry, and improve interoperability. - void use(bool leak) - { - auto p1 = make_unique(7); // OK - int* p2 = new int{7}; // bad: might leak - // ... - if (leak) return; - // ... - } +##### Note -If `leak==true` the object pointer to by `p2` is leaked and the object pointed to by `p1` is not. +Unless you are creating a new generic library, most of the concepts you need will already be defined by the standard library. -**Enforcement**: Look for raw pointers that are targets of `new`, `malloc()`, or functions that may return such pointers. +##### Example + template + // don't define this: sortable is in + concept Ordered_container = Sequence && Random_access> && Ordered>; - -### ES.25: Declare an objects `const` or `constexpr` unless you want to modify its value later on + void sort(Ordered_container auto& s); -**Reason**: That way you can't change the value by mistake. That way may offer the compiler optimization opportunities. +This `Ordered_container` is quite plausible, but it is very similar to the `sortable` concept in the standard library. +Is it better? Is it right? Does it accurately reflect the standard's requirements for `sort`? +It is better and simpler just to use `sortable`: -**Example**: + void sort(sortable auto& s); // better - void f(int n) - { - const int bufmax = 2*n+2; // good: we can't change bufmax by accident - int xmax = n; // suspicious: is xmax intended to change? - // ... - } +##### Note -**Enforcement**: Look to see if a variable is actually mutated, and flag it if not. Unfortunately, it may be impossible to detect when a non-`const` was not intended to vary. +The set of "standard" concepts is evolving as we approach an ISO standard including concepts. +##### Note - -### ES.26: Don't use a variable for two unrelated purposes +Designing a useful concept is challenging. -**Reason**: Readability. +##### Enforcement -**Example, bad**: +Hard. - void use() - { - int i; - for (i=0; i<20; ++i) { /* ... */ } - for (i=0; i<200; ++) { /* ... */ } // bad: i recycled - } +* Look for unconstrained arguments, templates that use "unusual"/non-standard concepts, templates that use "homebrew" concepts without axioms. +* Develop a concept-discovery tool (e.g., see [an early experiment](http://www.stroustrup.com/sle2010_webversion.pdf)). -**Enforcement**: Flag recycled variables. +### T.12: Prefer concept names over `auto` for local variables +##### Reason - -### ES.27: Use `std::array` or `stack_array` for arrays on the stack + `auto` is the weakest concept. Concept names convey more meaning than just `auto`. -**Reason**: They are readable and don't impicitly convert to pointers. -They are not confused with non-standard extensions of built-in arrays. +##### Example -**Example, bad**: + vector v{ "abc", "xyz" }; + auto& x = v.front(); // bad + String auto& s = v.front(); // good (String is a GSL concept) - const int n = 7; - int m = 9; - - void f() - { - int a1[n]; - int a2[m]; // error: not ISO C++ - // ... - } +##### Enforcement -**Note**: The definition of `a1` is legal C++ and has always been. -There is a lot of such code. -It is error-prone, though, especially when the bound is non-local. -Also, it is a "popular" source of errors (buffer overflow, pointers from array decay, etc.). -The definition of `a2` is C but not C++ and is considered a security risk +* ??? -**Example**: +### T.13: Prefer the shorthand notation for simple, single-type argument concepts - const int n = 7; - int m = 9; - - void f() - { - array a1; - stack_array a2(m); - // ... - } - -**Enforcement**: +##### Reason -* Flag arrays with non-constant bounds (C-style VLAs) -* Flag arrays with non-local constant bounds +Readability. Direct expression of an idea. +##### Example - -### ES.28: Use lambdas for complex initialization, especially of `const` variables +To say "`T` is `sortable`": -**Reason**: It nicely encapsulates local initialization, including cleaning up scratch variables needed only for the initialization, without needing to create a needless nonlocal yet nonreusable function. It also works for variables that should be `const` but only after some initialization work. + template // Correct but verbose: "The parameter is + requires sortable // of type T which is the name of a type + void sort(T&); // that is sortable" -**Example; bad**: + template // Better: "The parameter is of type T + void sort(T&); // which is Sortable" - widget x; // should be const, but: - for(auto i=2; i <= N; ++i) { // this could be some - x += some_obj.do_something_with(i); // arbitrarily long code - } // needed to initialize x - // from here, x should be const, but we can’t say so in code in this style + void sort(sortable auto&); // Best: "The parameter is Sortable" -**Example; good**: +The shorter versions better match the way we speak. Note that many templates don't need to use the `template` keyword. - const widget x = [&]{ - widget val; // asume that widget has a default constructor - for(auto i=2; i <= N; ++i) { // this could be some - val += some_obj.do_something_with(i);// arbitrarily long code - } // needed to initialize x - return val; - }(); +##### Enforcement -**Example**: +* Not feasible in the short term when people convert from the `` and ` notation. +* Later, flag declarations that first introduce a typename and then constrain it with a simple, single-type-argument concept. - string var = [&]{ - if (!in) return ""; // default - string s; - for (char c : in>>c) - s += toupper(c); - return s; - }(); // note () +## T.concepts.def: Concept definition rules -If at all possible, reduce the conditions to a simple set of alternatives (e.g., an `enum`) and don't mix up selection and initialization. +Defining good concepts is non-trivial. +Concepts are meant to represent fundamental concepts in an application domain (hence the name "concepts"). +Similarly throwing together a set of syntactic constraints to be used for the arguments for a single class or algorithm is not what concepts were designed for +and will not give the full benefits of the mechanism. -**Example**: - - owner in = [&]{ - switch (source) { - case default: owned=false; return cin; - case command_line: owned=true; return *new istringstream{argv[2]}; - case file: owned=true; return *new ifstream{argv[2]}; - }(); +Obviously, defining concepts is most useful for code that can use an implementation (e.g., C++20 or later) +but defining concepts is in itself a useful design technique and help catch conceptual errors and clean up the concepts (sic!) of an implementation. -**Enforcement:** Hard. At best a heuristic. Look for an unitialized variable followed by a loop assigning to it. +### T.20: Avoid "concepts" without meaningful semantics +##### Reason - -### ES.30: Don't use macros for program text manipulation +Concepts are meant to express semantic notions, such as "a number", "a range" of elements, and "totally ordered." +Simple constraints, such as "has a `+` operator" and "has a `>` operator" cannot be meaningfully specified in isolation +and should be used only as building blocks for meaningful concepts, rather than in user code. -**Reason**: Macros are a major source of bugs. -Macros don't obey the usual scope and type rules. -Macros ensure that the human reader see something different from whet the compiler sees. -Macros complicates tool building. +##### Example, bad -**Example, bad** + template + // bad; insufficient + concept Addable = requires(T a, T b) { a + b; }; - #define Case break; case /* BAD */ + template + auto algo(const N& a, const N& b) // use two numbers + { + // ... + return a + b; + } -This innocuous-looking macro makes a single lower case `c` instead of a `C` into a bad flow-control bug. - -**Note**: This rule does not ban the use of macros for "configuration control" use in `#ifdef`s, etc. - -**Enforcement**: Scream when you see a macro that isn't just use for source control (e.g., `#ifdef`) + int x = 7; + int y = 9; + auto z = algo(x, y); // z = 16 + string xx = "7"; + string yy = "9"; + auto zz = algo(xx, yy); // zz = "79" - -### ES.31: Don't use macros for constants or "functions" +Maybe the concatenation was expected. More likely, it was an accident. Defining minus equivalently would give dramatically different sets of accepted types. +This `Addable` violates the mathematical rule that addition is supposed to be commutative: `a+b == b+a`. -**Reason**: Macros are a major source of bugs. -Macros don't obey the usual scope and type rules. -Macros don't obey the usual rules for argument passing. -Macros ensure that the human reader see something different from whet the compiler sees. -Macros complicates tool building. +##### Note -**Example, bad**: +The ability to specify meaningful semantics is a defining characteristic of a true concept, as opposed to a syntactic constraint. - #define PI 3.14 - #define SQUARE(a,b) (a*b) - -Even if we hadn't left a well-know bug in `SQUARE` there are much better behaved alternatives; for example: +##### Example - constexpr double pi = 3.14; - template T square(T a, T b) { return a*b; } + template + // The operators +, -, *, and / for a number are assumed to follow the usual mathematical rules + concept Number = requires(T a, T b) { a + b; a - b; a * b; a / b; }; -**Enforcement**: Scream when you see a macro that isn't just use for source control (e.g., `#ifdef`) + template + auto algo(const N& a, const N& b) + { + // ... + return a + b; + } + int x = 7; + int y = 9; + auto z = algo(x, y); // z = 16 - -### ES.32: Use `ALL_CAPS` for all macro names + string xx = "7"; + string yy = "9"; + auto zz = algo(xx, yy); // error: string is not a Number -**Reason**: Convention. Readability. Distinguishing macros. +##### Note -**Example**: +Concepts with multiple operations have far lower chance of accidentally matching a type than a single-operation concept. - #define forever for(;;) /* very BAD */ - - #define FOREVER for(;;) /* Still evil, but at least visible to humans */ - -**Enforcement**: Scream when you see a lower case macro. +##### Enforcement +* Flag single-operation `concepts` when used outside the definition of other `concepts`. +* Flag uses of `enable_if` that appear to simulate single-operation `concepts`. - -### ES.40: Don't define a (C-style) variadic function -**Reason**: Not type safe. Requires messy cast-and-macro-laden code to get working right. +### T.21: Require a complete set of operations for a concept -**Example**: +##### Reason - ??? +Ease of comprehension. +Improved interoperability. +Helps implementers and maintainers. -**Alternative**: Overloading. Templates. Veriadic templates. +##### Note -**Note**: There are rare used of variadic functions in SFINAE code, but those don't actually run and don't need the `` implementation mess. +This is a specific variant of the general rule that [a concept must make semantic sense](#Rt-low). -**Enforcement**: Flag definitions of C-style variadic functions. +##### Example, bad + template concept Subtractable = requires(T a, T b) { a - b; }; +This makes no semantic sense. +You need at least `+` to make `-` meaningful and useful. -## ES.stmt: Statements +Examples of complete sets are -Statements control the flow of control (except for function calls and exception throws, which are expressions). +* `Arithmetic`: `+`, `-`, `*`, `/`, `+=`, `-=`, `*=`, `/=` +* `Comparable`: `<`, `>`, `<=`, `>=`, `==`, `!=` +##### Note - -### ES.70: Prefer a `switch`-statement to an `if`-statement when there is a choice +This rule applies whether we use direct language support for concepts or not. +It is a general design rule that even applies to non-templates: -**Reason**: + class Minimal { + // ... + }; -* Readability. -* Efficiency: A `switch` compares against constants and is usually better optimized than a series of tests in an `if`-`then`-`else` chain. -* a `switch` is enables some heuristic consistency checking. For example, has all values of an `enum` been covered? If not, is there a `default`? + bool operator==(const Minimal&, const Minimal&); + bool operator<(const Minimal&, const Minimal&); -**Example**: + Minimal operator+(const Minimal&, const Minimal&); + // no other operators - void use(int n) - { - switch (n) { // good - case 0: // ... - case 7: // ... - } - } + void f(const Minimal& x, const Minimal& y) + { + if (!(x == y)) { /* ... */ } // OK + if (x != y) { /* ... */ } // surprise! error -rather than + while (!(x < y)) { /* ... */ } // OK + while (x >= y) { /* ... */ } // surprise! error - void use2(int n) - { - if (n==0) // bad: if-then-else chain comparing against a set of constants - // ... - else if (n==7) - // ... - } + x = x + y; // OK + x += y; // surprise! error + } -**Enforcement**: Flag if-then-else chains that check against constants (only). +This is minimal, but surprising and constraining for users. +It could even be less efficient. +The rule supports the view that a concept should reflect a (mathematically) coherent set of operations. - -### ES.71: Prefer a range-`for`-statement to a `for`-statement when there is a choice +##### Example -**Reason**: Readability. Error prevention. Efficiency. + class Convenient { + // ... + }; -**Example**: + bool operator==(const Convenient&, const Convenient&); + bool operator<(const Convenient&, const Convenient&); + // ... and the other comparison operators ... - for(int i=0; i= y) { /* ... */ } // OK - for(int i=1; iT.22: Specify axioms for concepts -This will copy each elements of `vs` into `s`. Better +##### Reason - for (string& s : vs) // ... +A meaningful/useful concept has a semantic meaning. +Expressing these semantics in an informal, semi-formal, or formal way makes the concept comprehensible to readers and the effort to express it can catch conceptual errors. +Specifying semantics is a powerful design tool. +##### Example -**Enforcement**: Look at loops, if a traditional loop just looks at each element of a sequence, and there are no side-effects on what it does with the elements, rewrite the loop to a for loop. + template + // The operators +, -, *, and / for a number are assumed to follow the usual mathematical rules + // axiom(T a, T b) { a + b == b + a; a - a == 0; a * (b + c) == a * b + a * c; /*...*/ } + concept Number = requires(T a, T b) { + { a + b } -> convertible_to; + { a - b } -> convertible_to; + { a * b } -> convertible_to; + { a / b } -> convertible_to; + }; +##### Note - -### ES.72: Prefer a `for`-statement to a `while`-statement when there is an obvious loop variable +This is an axiom in the mathematical sense: something that can be assumed without proof. +In general, axioms are not provable, and when they are the proof is often beyond the capability of a compiler. +An axiom might not be general, but the template writer can assume that it holds for all inputs actually used (similar to a precondition). -**Reason**: Readability: the complete logic of the loop is visible "up front". The scope of the loop variable can be limited. +##### Note -**Example**: +In this context axioms are Boolean expressions. +See the [Palo Alto TR](#S-references) for examples. +Currently, C++ does not support axioms (even the ISO Concepts TS), so we have to make do with comments for a longish while. +Once language support is available, the `//` in front of the axiom can be removed - ??? +##### Note -**Enforcement**: ??? +The GSL concepts have well-defined semantics; see the Palo Alto TR and the Ranges TS. +##### Exception - -### ES.73: Prefer a `while`-statement to a `for`-statement when there is no obvious loop variable +Early versions of a new "concept" still under development will often just define simple sets of constraints without a well-specified semantics. +Finding good semantics can take effort and time. +An incomplete set of constraints can still be very useful: -**Reason**: ??? + // balancer for a generic binary tree + template concept Balancer = requires(Node* p) { + add_fixup(p); + touch(p); + detach(p); + }; -**Example**: +So a `Balancer` must supply at least these operations on a tree `Node`, +but we are not yet ready to specify detailed semantics because a new kind of balanced tree might require more operations +and the precise general semantics for all nodes is hard to pin down in the early stages of design. - ??? +A "concept" that is incomplete or without a well-specified semantics can still be useful. +For example, it allows for some checking during initial experimentation. +However, it should not be assumed to be stable. +Each new use case might require such an incomplete concept to be improved. -**Enforcement**: ??? +##### Enforcement +* Look for the word "axiom" in concept definition comments - -### ES.74: Prefer to declare a loop variable in the initializer part of as `for`-statement +### T.23: Differentiate a refined concept from its more general case by adding new use patterns. -**Reason**: ??? +##### Reason -**Example**: +Otherwise they cannot be distinguished automatically by the compiler. - ??? +##### Example -**Enforcement**: ??? + template + // Note: input_iterator is defined in + concept Input_iter = requires(I iter) { ++iter; }; + template + // Note: forward_iterator is defined in + concept Fwd_iter = Input_iter && requires(I iter) { iter++; }; - -### ES.75: Avoid `do`-statements +The compiler can determine refinement based on the sets of required operations (here, suffix `++`). +This decreases the burden on implementers of these types since +they do not need any special declarations to "hook into the concept". +If two concepts have exactly the same requirements, they are logically equivalent (there is no refinement). -**Reason**: Readability, avoidance of errors. -The termination conditions is at the end (where it can be overlooked) and the condition is not checked the first time through. ??? +##### Enforcement -**Example**: +* Flag a concept that has exactly the same requirements as another already-seen concept (neither is more refined). +To disambiguate them, see [T.24](#Rt-tag). - int x; - do { - cin >> x; - x - } while (x<0); +### T.24: Use tag classes or traits to differentiate concepts that differ only in semantics. -**Enforcement**: ??? +##### Reason - -### ES.76: Avoid `goto` +Two concepts requiring the same syntax but having different semantics leads to ambiguity unless the programmer differentiates them. -**Reason**: Readability, avoidance of errors. There are better control structures for humans; `goto` is for machine generated code. +##### Example -**Exception**: Breaking out of a nested loop. In that case, always jump forwards. + template // iterator providing random access + // Note: random_access_iterator is defined in + concept RA_iter = ...; -**Example**: + template // iterator providing random access to contiguous data + // Note: contiguous_iterator is defined in + concept Contiguous_iter = + RA_iter && is_contiguous_v; // using is_contiguous trait - ??? +The programmer (in a library) must define `is_contiguous` (a trait) appropriately. -**Example**: There is a fair amount of use of the C goto-exit idiom: +Wrapping a tag class into a concept leads to a simpler expression of this idea: - void f() - { - // ... - goto exit; - // ... - goto exit; - // ... - exit: - ... common cleanup code ... - } + template concept Contiguous = is_contiguous_v; -This is an ad-hoc simulation of destructors. Declare your resources with handles with destructors that clean up. + template + concept Contiguous_iter = RA_iter && Contiguous; -**Enforcement**: +The programmer (in a library) must define `is_contiguous` (a trait) appropriately. -* Flag `goto`. Better still flag all `goto`s that do not jump from a nested loop to the statement immediately after a nest of loops. +##### Note +Traits can be trait classes or type traits. +These can be user-defined or standard-library ones. +Prefer the standard-library ones. +##### Enforcement - -### ES.77: ??? `continue` +* The compiler flags ambiguous use of identical concepts. +* Flag the definition of identical concepts. -**Reason**: ??? +### T.25: Avoid complementary constraints -**Example**: +##### Reason - ??? +Clarity. Maintainability. +Functions with complementary requirements expressed using negation are brittle. -**Enforcement**: ??? +##### Example +Initially, people will try to define functions with complementary requirements: - -### ES.78: Always end a `case` with a `break` + template + requires !C // bad + void f(); -**Reason**: ??? loop, switch ??? + template + requires C + void f(); -**Example**: +This is better: - ??? - -**Note**: Multiple case labels of a single statement is OK: + template // general template + void f(); - switch (x) { - case 'a': - case 'b': - case 'f': - do_something(x); - break; - } + template // specialization by concept + requires C + void f(); -**Enforcement**: ??? +The compiler will choose the unconstrained template only when `C` is +unsatisfied. If you do not want to (or cannot) define an unconstrained +version of `f()`, then delete it. + template + void f() = delete; - -### ES.79: ??? `default` +The compiler will select the overload, or emit an appropriate error. -**Reason**: ??? +##### Note -**Example**: +Complementary constraints are unfortunately common in `enable_if` code: - ??? + template + enable_if, void> // bad + f(); -**Enforcement**: ??? + template + enable_if, void> + f(); - -### ES.85: Make empty statements visible +##### Note -**Reason**: Readability. +Complementary requirements on one requirement is sometimes (wrongly) considered manageable. +However, for two or more requirements the number of definitions needs can go up exponentially (2,4,8,16,...): -**Example**: + C1 && C2 + !C1 && C2 + C1 && !C2 + !C1 && !C2 - for (i=0; i` and `!C` constraints -## ES.expr: Expresssions +### T.26: Prefer to define concepts in terms of use-patterns rather than simple syntax -Expressions manipulate values. +##### Reason - -### ES.40: Avoid complicated expressions +The definition is more readable and corresponds directly to what a user has to write. +Conversions are taken into account. You don't have to remember the names of all the type traits. -**Reason**: Complicated expressions are error-prone. +##### Example -**Example**: +You might be tempted to define a concept `Equality` like this: - while ((c=getc())!=-1) // bad: assignment hidded in subexpression + template concept Equality = has_equal && has_not_equal; - while ((cin>>c1, cin>>c2),c1==c2) // bad: two non-local variables assigned in a sub-expressions +Obviously, it would be better and easier just to use the standard `equality_comparable`, +but - just as an example - if you had to define such a concept, prefer: - for (char c1,c2; cin>>c1>>c2 && c1==c2; ) // better, but possibly still too complicated + template concept Equality = requires(T a, T b) { + { a == b } -> std::convertible_to; + { a != b } -> std::convertible_to; + // axiom { !(a == b) == (a != b) } + // axiom { a = b; => a == b } // => means "implies" + }; - int x = ++i + ++j; // OK: iff i and j are not aliased +as opposed to defining two meaningless concepts `has_equal` and `has_not_equal` just as helpers in the definition of `Equality`. +By "meaningless" we mean that we cannot specify the semantics of `has_equal` in isolation. - v[i] = v[j]+v[k]; // OK: iff i!=j and i!=k +##### Enforcement - x = a+(b=f())+(c=g())*7; // bad: multiple assignments "hidden" in subexpressions +??? - x = a&b+c*d&&e^f==7; // bad: relies on commonly misunderstood precedence rules +## Template interfaces - x = x++ + x++ + ++x; // bad: undefined behavior +Over the years, programming with templates have suffered from a weak distinction between the interface of a template +and its implementation. +Before concepts, that distinction had no direct language support. +However, the interface to a template is a critical concept - a contract between a user and an implementer - and should be carefully designed. -Some of these expressions are unconditionally bad (e.g., they rely on undefined behavior). Others are simply so complicated and/or unusual that even good programmers could misunderstand them or overlook a problem when in a hurry. +### T.40: Use function objects to pass operations to algorithms -**Note**: A programmer should know and use the basic rules for expressions. +##### Reason -**Example**: +Function objects can carry more information through an interface than a "plain" pointer to function. +In general, passing function objects gives better performance than passing pointers to functions. - x=k*y+z; // OK +##### Example - auto t1 = k*y; // bad: unnecessarily verbose - x = t1+z; + bool greater(double x, double y) { return x > y; } + sort(v, greater); // pointer to function: potentially slow + sort(v, [](double x, double y) { return x > y; }); // function object + sort(v, std::greater{}); // function object - if(0<=x && x 7; } + auto x = find_if(v, greater_than_7); // pointer to function: inflexible + auto y = find_if(v, [](double x) { return x > 7; }); // function object: carries the needed data + auto z = find_if(v, Greater_than(7)); // function object: carries the needed data - auto t1 = 0<=x; // bad: unnecessarily verbose - aoto t2 = x 7; }); // require an ordered type + auto z1 = find_if(v, [](auto x) { return x > 7; }); // hope that the type has a > -* side effects: side effects on multiple non-local variables (for some definition of non-local) can be suspect, especially if the side effects are in separate subexpressions -* writes to aliased variables -* more than N operators (and what should N be?) -* reliance of subtle precedence rules -* uses undefined behavior (can we catch all undefined behavior?) -* implementation defined behavior? -* ??? +##### Note +Lambdas generate function objects. - -### ES.41: If in doubt about operator precedence, parenthesize +##### Note -**Reason**: Avoid errors. Readability. Not everyone has the operator table memorized. +The performance argument depends on compiler and optimizer technology. -**Example**: +##### Enforcement - if (a && b==1) // OK? - if (a & b==1) // OK? +* Flag pointer to function template arguments. +* Flag pointers to functions passed as arguments to a template (risk of false positives). -Note: We recommend that programmers know their precedence table for the arithmetic operations, the logical operations, -but consider mixing bitwise logical operations with other operators in need of parentheses. - if (a && b==1) // OK: means a&&(b==1) - if (a & b==1) // bad: means (a&b)==1 - -**Note**: You should know enough not to need parentheses for +### T.41: Require only essential properties in a template's concepts - if (a<0 || a<=max) { - // ... - } +##### Reason -**Enforcement**: +Keep interfaces simple and stable. -* Flag combinations of bitwise-logical operators and other operators. -* Flag assignment operators not as the leftmost operator. -* ??? +##### Example +Consider, a `sort` instrumented with (oversimplified) simple debug support: - -### ES.42: Keep use of pointers simple and straightforward + void sort(sortable auto& s) // sort sequence s + { + if (debug) cerr << "enter sort( " << s << ")\n"; + // ... + if (debug) cerr << "exit sort( " << s << ")\n"; + } -**Reason**: Complicated pointer manipulation is a major source of errors. +Should this be rewritten to: -* Do all pointer arithmetic on an `array_view` (exception ++p in simple loop???) -* Avoid pointers to pointers -* ??? + template + requires Streamable + void sort(S& s) // sort sequence s + { + if (debug) cerr << "enter sort( " << s << ")\n"; + // ... + if (debug) cerr << "exit sort( " << s << ")\n"; + } -**Example**: +After all, there is nothing in `sortable` that requires `iostream` support. +On the other hand, there is nothing in the fundamental idea of sorting that says anything about debugging. - ??? +##### Note -**Enforcement**: We need a heuristic limiting the complexity of pointer arithmetic statement. +If we require every operation used to be listed among the requirements, the interface becomes unstable: +Every time we change the debug facilities, the usage data gathering, testing support, error reporting, etc., +the definition of the template would need change and every use of the template would have to be recompiled. +This is cumbersome, and in some environments infeasible. +Conversely, if we use an operation in the implementation that is not guaranteed by concept checking, +we might get a late compile-time error. - -### ES.43: Avoid expressions with undefined order of evaluation +By not using concept checking for properties of a template argument that is not considered essential, +we delay checking until instantiation time. +We consider this a worthwhile tradeoff. -**Reason**: You have no idea what such code does. Portability. -Even if it does something sensible for you, it may do something different on another compiler (e.g., the next release of your compiler) or with a different optimizer setting. +Note that using non-local, non-dependent names (such as `debug` and `cerr`) also introduces context dependencies that might lead to "mysterious" errors. -**Example**: +##### Note - v[i]=++i; // the result is undefined +It can be hard to decide which properties of a type are essential and which are not. -A good rule of thumb is that you should not read a value twice in an expression where you write to it. +##### Enforcement -**Example**: +??? - ??? +### T.42: Use template aliases to simplify notation and hide implementation details -**Note**: What is safe? +##### Reason -**Enforcement**: Can be detected by a good analyzer. +Improved readability. +Implementation hiding. +Note that template aliases replace many uses of traits to compute a type. +They can also be used to wrap a trait. +##### Example - -### ES.44: Don't depend on order of evaluation of function arguments + template + class Matrix { + // ... + using Iterator = typename std::vector::iterator; + // ... + }; -**Reason**: that order is unspecified +This saves the user of `Matrix` from having to know that its elements are stored in a `vector` and also saves the user from repeatedly typing `typename std::vector::`. -**Example**: +##### Example - int i=0; - f(++i,++i); + template + void user(T& c) + { + // ... + typename container_traits::value_type x; // bad, verbose + // ... + } -The call will most likely be `f(0,1)` or `f(1,0)`, but you don't know which. Technically, the behavior is undefined. + template + using Value_type = typename container_traits::value_type; -**Example**: ??? oveloaded operators can lead to order of evaluation problems (shouldn't :-() - f1()->m(f2()); // m(f1(),f2()) - cout << f1() << f2(); // operator<<(operator<<(cout,f1()),f2()) +This saves the user of `Value_type` from having to know the technique used to implement `value_type`s. + template + void user2(T& c) + { + // ... + Value_type x; + // ... + } -**Enforcement**: Can be detected by a good analyzer. +##### Note +A simple, common use could be expressed: "Wrap traits!" - -### ES.45: Avoid "`magic constants"; use symbolic constants +##### Enforcement -**Reason**: Unnamed constants embedded in expressions are easily overlooked and often hard to understand: +* Flag use of `typename` as a disambiguator outside `using` declarations. +* ??? -**Example**: +### T.43: Prefer `using` over `typedef` for defining aliases - for (int m = 1; m<=12; ++m) // don't: magic constant 12 - cout << month[m] << '\n'; +##### Reason -No, we don't all know that there a 12 month, numbered 1..12, in a year. Better: +Improved readability: With `using`, the new name comes first rather than being embedded somewhere in a declaration. +Generality: `using` can be used for template aliases, whereas `typedef`s can't easily be templates. +Uniformity: `using` is syntactically similar to `auto`. - constexp int last_month = 12; // months are numbered 1..12 +##### Example - for (int m = first_month; m<=last_month; ++m) // better - cout << month[m] << '\n'; + typedef int (*PFI)(int); // OK, but convoluted -Better still, don't expose constants: + using PFI2 = int (*)(int); // OK, preferred - for(auto m : month) - cout << m <<'\n'; + template + typedef int (*PFT)(T); // error -**Enforcement**: Flag literals in code. Give a pass to `0`, `1`, `nullptr`, `\n`, `""`, and others on a positive list. + template + using PFT2 = int (*)(T); // OK +##### Enforcement - -### ES.46: Avoid lossy (narrowing, truncating) arithmetic conversions +* Flag uses of `typedef`. This will give a lot of "hits" :-( -**Reason**: A narrowing conversion destroys information, often unexpectedly so. +### T.44: Use function templates to deduce class template argument types (where feasible) -**Example**: +##### Reason -A key example is basic narrowing: +Writing the template argument types explicitly can be tedious and unnecessarily verbose. - double d = 7.9; - int i = d; // bad: narrowing: i becomes 7 - i = (int)d; // bad: we're going to claim this is still not explicit enough - - void f(int x, long y, double d) - { - char c1 = x; // bad: narrowing - char c2 = y; // bad: narrowing - char c3 = d; // bad: narrowing - } +##### Example -**Note**: The guideline support library offers a `narrow` operation for specifying that narrowing is acceptable and a `narrow` ("narrow if") that throws an exception if a narrowing would throw away information: + tuple t1 = {1, "Hamlet", 3.14}; // explicit type + auto t2 = make_tuple(1, "Ophelia"s, 3.14); // better; deduced type - i = narrow_cast(d); // OK (you asked for it): narrowing: i becomes 7 - i = narrow(d); // OK: throws narrowing_error +Note the use of the `s` suffix to ensure that the string is a `std::string`, rather than a C-style string. -We also include lossy arithmetic casts, such as from a negative floating point type to an unsigned integral type: +##### Note - double d = -7.9; - unsigned u = 0; - - u = d; // BAD - u = narrow_cast(d); // OK (you asked for it): u becomes 0 - u = narrow(d); // OK: throws narrowing_error +Since you can trivially write a `make_T` function, so could the compiler. Thus, `make_T` functions might become redundant in the future. +##### Exception -**Enforcement**: A good analyzer can detect all narrowing conversions. However, flagging all narrowing conversions will lead to a lot of false positives. Suggestions: +Sometimes there isn't a good way of getting the template arguments deduced and sometimes, you want to specify the arguments explicitly: -* flag all floating-point to integer conversions (maybe only float->char and double->int. Here be dragons! we need data) -* flag all long->char (I suspect int->char is very common. Here be dragons! we need data) -* consider narrowing conversions for function arguments especially suspect + vector v = { 1, 2, 3, 7.9, 15.99 }; + list lst; +##### Note - -### ES.47: Use `nullptr` rather than `0` or `NULL` +Note that C++17 will make this rule redundant by allowing the template arguments to be deduced directly from constructor arguments: +[Template parameter deduction for constructors (Rev. 3)](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0091r1.html). +For example: -**Reason**: Readability. Minimize surprises: `nullptr` cannot be confused with an `int`. + tuple t1 = {1, "Hamlet"s, 3.14}; // deduced: tuple -**Example**: Consider +##### Enforcement - void f(int); - void f(char*); - f(0); // call f(int) - f(nullptr); // call f(char*) +Flag uses where an explicitly specialized type exactly matches the types of the arguments used. -**Enforcement**: Flag uses of `0` and `NULL` for pointers. The transformation may be helped by simple program transformation. +### T.46: Require template arguments to be at least semiregular +##### Reason - -### ES.48: Avoid casts +Readability. +Preventing surprises and errors. +Most uses support that anyway. -**Reason**: Casts are a well-known source of errors. Makes some optimizations unreliable. +##### Example -**Example**: + class X { + public: + explicit X(int); + X(const X&); // copy + X operator=(const X&); + X(X&&) noexcept; // move + X& operator=(X&&) noexcept; + ~X(); + // ... no more constructors ... + }; - ??? + X x {1}; // fine + X y = x; // fine + std::vector v(10); // error: no default constructor -**Note**: Programmer who write casts typically assumes that they know what they are doing. -In fact, they often disable the general rules for using values. -Overload resolution and template instantiation usually pick the right function if there is a right function to pick. -If there is not, maybe there ought to be, rather than applying a local fix (cast). +##### Note -**Note**: Casts are necessary in a systems programming language. -For example, how else would we get the address of a device register into a pointer. -However, casts are seriously overused as well as a major source of errors. +Semiregular requires default constructible. -**Note**: If you feel the need for a lot of casts, there may be a fundamental design problem. +##### Enforcement -**Enforcement**: +* Flag types used as template arguments that are not at least semiregular. -* Force the elimination of C-style casts -* Warn against named casts -* Warn if there are many functional stye casts (there is an obvious problem in quantifying 'many'). +### T.47: Avoid highly visible unconstrained templates with common names +##### Reason - -### ES.49: If you must use a cast, use a named cast + An unconstrained template argument is a perfect match for anything so such a template can be preferred over more specific types that require minor conversions. + This is particularly annoying/dangerous when ADL is used. + Common names make this problem more likely. -**Reason**: Readability. Error avoidance. -Named casts are more specific than a C-style or functional cast, allowing the compiler to catch some errors. +##### Example -The named casts are: + namespace Bad { + struct S { int m; }; + template + bool operator==(T1, T2) { cout << "Bad\n"; return true; } + } -* `static_cast` -* `const_cast` -* `reinterpret_cast` -* `dynamic_cast` -* `std::move` // `move(x)` is an rvalue reference to `x` -* `std::forward` // `forward(x)` is an rvalue reference to `x` -* `gsl::narrow_cast` // `narrow_cast(x)` is `static_cast(x)` -* `gsl::narrow` // `narrow(x)` is `static_cast(x)` if `static_cast(x)==x` or it throws `narrowing_error` + namespace T0 { + bool operator==(int, Bad::S) { cout << "T0\n"; return true; } // compare to int -**Example**: + void test() + { + Bad::S bad{ 1 }; + vector v(10); + bool b = 1 == bad; + bool b2 = v.size() == bad; + } + } - ??? +This prints `T0` and `Bad`. -**Note**: ??? +Now the `==` in `Bad` was designed to cause trouble, but would you have spotted the problem in real code? +The problem is that `v.size()` returns an `unsigned` integer so that a conversion is needed to call the local `==`; +the `==` in `Bad` requires no conversions. +Realistic types, such as the standard-library iterators can be made to exhibit similar anti-social tendencies. -**Enforcement**: Flag C-style and functional casts. +##### Note +If an unconstrained template is defined in the same namespace as a type, +that unconstrained template can be found by ADL (as happened in the example). +That is, it is highly visible. - -## ES.50: Don't cast away `const` +##### Note -**Reason**: It makes a lie out of `const` +This rule should not be necessary, but the committee cannot agree to exclude unconstrained templates from ADL. -**Note**: Usually the reason to "cast away `const`" is to allow the updating of some transient information of an otherwise immutable object. -Examples are cashing, mnemorization, and precomputation. -Such examples are often handled as well or better using `mutable` or an indirection than with a `const_cast`. +Unfortunately this will get many false positives; the standard library violates this widely, by putting many unconstrained templates and types into the single namespace `std`. -**Example**: - ??? +##### Enforcement -**Enforcement**: Flag `const_cast`s. +Flag templates defined in a namespace where concrete types are also defined (maybe not feasible until we have concepts). - -### ES.55: Avoid the need for range checking +### T.48: If your compiler does not support concepts, fake them with `enable_if` -**Reason**: Constructs that cannot overflow, don't, and usually runs faster: +##### Reason -**Example**: +Because that's the best we can do without direct concept support. +`enable_if` can be used to conditionally define functions and to select among a set of functions. - for (auto& x : v) // print all elements of v - cout << x << '\n'; - - auto p = find(v,x); // find x in v +##### Example -**Enforcement**: Look for explicit range checks and heuristically suggest alternatives. + template + enable_if_t> + f(T v) + { + // ... + } + // Equivalent to: + template + void f(T v) + { + // ... + } - -### ES.60: Avoid `new` and `delete[]` outside resource management functions +##### Note -**Reason**: Direct resource management in application code is error-prone and tedious. +Beware of [complementary constraints](#Rt-not). +Faking concept overloading using `enable_if` sometimes forces us to use that error-prone design technique. -**Note**: also known as "No naked `new`!" +##### Enforcement -**Example, bad**: +??? - void f(int n) - { - auto p = new X[n]; // n default constructed Xs - // ... - delete[] p; - } +### T.49: Where possible, avoid type-erasure -There can be code in the `...` part that causes the `delete` never to happen. +##### Reason -**See also**: [R: Resource management](#S-resource). +Type erasure incurs an extra level of indirection by hiding type information behind a separate compilation boundary. -**Enforcement**: Flag naked `new`s and naked `delete`s. +##### Example + ??? - -### ES.61: delete arrays using `delete[]` and non-arrays using `delete` +**Exceptions**: Type erasure is sometimes appropriate, such as for `std::function`. -**Reason**: That's what the language requires and mistakes can lead to resource release errors and/or memory corruption. +##### Enforcement -**Example, bad**: +??? - void f(int n) - { - auto p = new X[n]; // n default constructed Xs - // ... - delete p; // error: just delete the object p, rather than delete the array p[] - } - -**Note**: This example not only violates the [no naked `new` rule](#Res-new) as in the previous example, it has many more problems. -**Enforcement**: +##### Note -* if the `new` and the `delete` is in the same scope, mistakes can be flagged. -* if the `new` and the `delete` are in a constructor/destructor pair, mistakes can be flagged. +## T.def: Template definitions - -### ES.62: Don't compare pointers into different arrays +A template definition (class or function) can contain arbitrary code, so only a comprehensive review of C++ programming techniques would cover this topic. +However, this section focuses on what is specific to template implementation. +In particular, it focuses on a template definition's dependence on its context. -**Reason**: The result of doing so is undefined. +### T.60: Minimize a template's context dependencies -**Example, bad**: +##### Reason - void f(int n) - { - int a1[7]; - int a2[9]; - if (&a1[5]<&a2[7]) // bad: undefined - if (0<&a1[5]-&a2[7]) // bad: undefined - } - -**Note**: This example has many more problems. +Eases understanding. +Minimizes errors from unexpected dependencies. +Eases tool creation. -**Enforcement**: +##### Example + template + void sort(C& c) + { + std::sort(begin(c), end(c)); // necessary and useful dependency + } - -## Arithmetic + template + Iter algo(Iter first, Iter last) + { + for (; first != last; ++first) { + auto x = sqrt(*first); // potentially surprising dependency: which sqrt()? + helper(first, x); // potentially surprising dependency: + // helper is chosen based on first and x + TT var = 7; // potentially surprising dependency: which TT? + } + } - -### ES.100: Don't mix signed and unsigned arithmetic +##### Note -**Reason**: Avoid wrong results. +Templates typically appear in header files so their context dependencies are more vulnerable to `#include` order dependencies than functions in `.cpp` files. -**Example**: +##### Note - ??? - -**Note** Unfortunately, C++ uses signed integers for array subscripts and the standard library uses unsigned integers for container subscripts. -This precludes consistency. +Having a template operate only on its arguments would be one way of reducing the number of dependencies to a minimum, but that would generally be unmanageable. +For example, algorithms usually use other algorithms and invoke operations that do not exclusively operate on arguments. +And don't get us started on macros! -**Enforcement**: Compilers already know and sometimes warn. +**See also**: [T.69](#Rt-customization) +##### Enforcement - -### ES.101: use unsigned types for bit manipulation +??? Tricky -**Reason**: Unsigned types support bit manipulation without surprises from sign bits. +### T.61: Do not over-parameterize members (SCARY) -**Example**: +##### Reason - ??? - -**Exception**: Use unsigned types if you really want modulo arithmetic. +A member that does not depend on a template parameter cannot be used except for a specific template argument. +This limits use and typically increases code size. -**Enforcement**: ??? - +##### Example, bad - -### ES.102: Used signed types for arithmetic + template> + // requires Regular && Allocator + class List { + public: + struct Link { // does not depend on A + T elem; + Link* pre; + Link* suc; + }; -**Reason**: Unsigned types support bit manipulation without surprises from sign bits. + using iterator = Link*; -**Example**: + iterator first() const { return head; } - ??? - -**Exception**: Use unsigned types if you really want modulo arithmetic. + // ... + private: + Link* head; + }; -**Enforcement**: ??? + List lst1; + List lst2; +This looks innocent enough, but now `Link` formally depends on the allocator (even though it doesn't use the allocator). This forces redundant instantiations that can be surprisingly costly in some real-world scenarios. +Typically, the solution is to make what would have been a nested class non-local, with its own minimal set of template parameters. - -### ES.103: Don't overflow + template + struct Link { + T elem; + Link* pre; + Link* suc; + }; -**Reason**: Overflow usually makes your numeric algorithm meaningless. -Incrementing a value beyond a maximum value can lead to memory corruption and undefined behavior. + template> + // requires Regular && Allocator + class List2 { + public: + using iterator = Link*; -**Example, bad**: + iterator first() const { return head; } - int a[10]; - a[10] = 7; // bad - - int n = 0; - while (n++<10) - a[n-1] = 9; // bad (twice) - -**Example, bad**: + // ... + private: + Link* head; + }; - int n = numeric_limits::max(); - int m = n+1; // bad - -**Example, bad**: + List2 lst1; + List2 lst2; - int area(int h, int w) { return h*w; } - - auto a = area(10'000'000*100'000'000); // bad - -**Exception**: Use unsigned types if you really want modulo arithmetic. +Some people found the idea that the `Link` no longer was hidden inside the list scary, so we named the technique +[SCARY](http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2009/n2911.pdf). From that academic paper: +"The acronym SCARY describes assignments and initializations that are Seemingly erroneous (appearing Constrained by conflicting generic parameters), but Actually work with the Right implementation (unconstrained bY the conflict due to minimized dependencies)." -**Alternative**: For critical applications that can afford some overhead, use a range-checked integer and/or floating-point type. +##### Note -**Enforcement**: ??? +This also applies to lambdas that don't depend on all of the template parameters. +##### Enforcement - -### ES.104: Don't underflow +* Flag member types that do not depend on every template parameter +* Flag member functions that do not depend on every template parameter +* Flag lambdas or variable templates that do not depend on every template parameter -**Reason**: Decrementing a value beyond a maximum value can lead to memory corruption and undefined behavior. +### T.62: Place non-dependent class template members in a non-templated base class -**Example, bad**: +##### Reason - int a[10]; - a[-2] = 7; // bad - - int n = 101; - while (n--) - a[n-1] = 9; // bad (twice) - -**Exception**: Use unsigned types if you really want modulo arithmetic. + Allow the base class members to be used without specifying template arguments and without template instantiation. -**Enforcement**: ??? +##### Example + template + class Foo { + public: + enum { v1, v2 }; + // ... + }; - -### ES.105: Don't divide by zero +??? -**Reason**: The result is undefined and probably a crash. + struct Foo_base { + enum { v1, v2 }; + // ... + }; -**Note**: this also applies to `%`. + template + class Foo : public Foo_base { + public: + // ... + }; -**Example**: +##### Note - ??? +A more general version of this rule would be +"If a class template member depends on only N template parameters out of M, place it in a base class with only N parameters." +For N == 1, we have a choice of a base class of a class in the surrounding scope as in [T.61](#Rt-scary). -**Alternative**: For critical applications that can afford some overhead, use a range-checked integer and/or floating-point type. +??? What about constants? class statics? -**Enforcement**: ??? +##### Enforcement +* Flag ??? - -# PER: Performance +### T.64: Use specialization to provide alternative implementations of class templates -???should this section be in the main guide??? +##### Reason -This section contains rules for people who needs high performance or low-latency. -That is, rules that relates to how to use as little time and as few resources as possible to achieve a task in a predictably short time. -The rules in this section are more restrictive and intrusive than what is needed for many (most) applications. -Do not blindly try to follow them in general code because achieving the goals of low latency requires extra work. +A template defines a general interface. +Specialization offers a powerful mechanism for providing alternative implementations of that interface. -Performance rule summary: +##### Example -* [PER.1: Don't optimize without reason](#Rper-reason) -* [PER.2: Don't optimize prematurely](#Rper-Knuth) -* [PER.3: Don't optimize something that's not performance critical](#Rper-critical) -* [PER.4: Don't assume that complicated code is necessarily faster than simple code](#Rper-simple) -* [PER.5: Don't assume that low-level code is necessarily faster than high-level code](#Rper-low) -* [PER.6: Don't make claims about performance without measurements](#Rper-measure) -* [PER.10: Rely on the static type system](#Rper-type) -* [PER.11: Move computation from run time to compile time](#Rper-Comp) -* [PER.12: Eliminate redundant aliases](#Rper-alias) -* [PER.13: Eliminate redundant indirections](#Rper-indirect) -* [PER.14: Minimize the number of allocations and deallocations](#Rper-alloc) -* [PER.15: Do not allocate on a critical branch](#Rper-alloc0) -* [PER.16: Use compact data structures](#Rper-compact) -* [PER.17: Declare the most used member of a time critical struct first](#Rper-struct) -* [PER.18: Space is time](#Rper-space) -* [PER.19: Access memory predictably](#Rper-access) -* [PER.30: Avoid context switches on the critical path](#Rper-context) + ??? string specialization (==) + ??? representation specialization ? - -### PER.1: Don't optimize without reason +##### Note -**Reason**: If there is no need for optimization, the main result of the effort will be more errors and higher maintenance costs. +??? -**Note**: Some people optimize out of habit or because it's fun. +##### Enforcement ??? +### T.65: Use tag dispatch to provide alternative implementations of a function - -### PER.2: Don't optimize prematurely +##### Reason -**Reason**: Elaborately optimized code is usually larger and harder to change than unoptimized code. +* A template defines a general interface. +* Tag dispatch allows us to select implementations based on specific properties of an argument type. +* Performance. -??? +##### Example +This is a simplified version of `std::copy` (ignoring the possibility of non-contiguous sequences) - -### PER.3: Don't optimize something that's not performance critical + struct trivially_copyable_tag {}; + struct non_trivially_copyable_tag {}; -**Reason**: Optimizing a non-performance-critical part of a program has no effect on system performance. + // T is not trivially copyable + template struct copy_trait { using tag = non_trivially_copyable_tag; }; + // int is trivially copyable + template<> struct copy_trait { using tag = trivially_copyable_tag; }; -**Note**: If your program spends most of its time waiting for the web or for a human, optimization of in-memory computation is problably useless. + template + Out copy_helper(Iter first, Iter last, Iter out, trivially_copyable_tag) + { + // use memmove + } -??? + template + Out copy_helper(Iter first, Iter last, Iter out, non_trivially_copyable_tag) + { + // use loop calling copy constructors + } + template + Out copy(Iter first, Iter last, Iter out) + { + using tag_type = typename copy_trait>; + return copy_helper(first, last, out, tag_type{}) + } + void use(vector& vi, vector& vi2, vector& vs, vector& vs2) + { + copy(vi.begin(), vi.end(), vi2.begin()); // uses memmove + copy(vs.begin(), vs.end(), vs2.begin()); // uses a loop calling copy constructors + } - -### PER.4: Don't assume that complicated code is necessarily faster than simple code +This is a general and powerful technique for compile-time algorithm selection. -**Reason**: Simple code can be very fast. Optimizers sometimes do marvels with simple code +##### Note -**Note**: ??? +With C++20 constraints, such alternatives can be distinguished directly: -??? + template + requires std::is_trivially_copyable_v> + Out copy_helper(In, first, In last, Out out) + { + // use memmove + } + template + Out copy_helper(In, first, In last, Out out) + { + // use loop calling copy constructors + } - -### PER.5: Don't assume that low-level code is necessarily faster than high-level code +##### Enforcement -**Reason**: Low-level code sometimes inhibits optimizations. Optimizers sometimes do marvels with high-level code +??? -**Note**: ??? -??? +### T.67: Use specialization to provide alternative implementations for irregular types +##### Reason - -### PER.6: Don't make claims about performance without measurements + ??? -**Reason**: The field of performance is littered with myth and bogus folklore. -Modern hardware and optimizers defy naive assumptions; even experts are regularly surprised. +##### Example -**Note**: Getting good performance measurements can be hard and require specialized tools. + ??? -**Note**: A few simple microbenchmarks using Unix `time` or the standard library `` can help dispell the most obvious myths. -If you can't measure your complete system accurately, at least try to measure a few of your key operations and algorithms. -A profiler can help tell you which parts of your system are performance critical. -Often, you will be surprised. +##### Enforcement ??? +### T.68: Use `{}` rather than `()` within templates to avoid ambiguities - -### PER.10: Rely on the static type system +##### Reason -**Reason**: Type violations, weak types (e.g. `void*`s), and low level code (e.g., manipulation of sequences as individual bytes) -make the job of the optimizer much harder. Simple code often optimizes better than hand-crafted complex code. +`()` is vulnerable to grammar ambiguities. -??? +##### Example + template + void f(T t, U u) + { + T v1(T(u)); // mistake: oops, v1 is a function not a variable + T v2{u}; // clear: obviously a variable + auto x = T(u); // unclear: construction or cast? + } - -### PER.11: Move computation from run time to compile time + f(1, "asdf"); // bad: cast from const char* to int -??? +##### Enforcement +* flag `()` initializers +* flag function-style casts - -### PER.12: Eliminate redundant aliases -??? +### T.69: Inside a template, don't make an unqualified non-member function call unless you intend it to be a customization point +##### Reason - -### PER.13: Eliminate redundant indirections +* Provide only intended flexibility. +* Avoid vulnerability to accidental environmental changes. -??? +##### Example +There are three major ways to let calling code customize a template. - -### PER.14: Minimize the number of allocations and deallocations + template + // Call a member function + void test1(T t) + { + t.f(); // require T to provide f() + } -??? + template + void test2(T t) + // Call a non-member function without qualification + { + f(t); // require f(/*T*/) be available in caller's scope or in T's namespace + } + template + void test3(T t) + // Invoke a "trait" + { + test_traits::f(t); // require customizing test_traits<> + // to get non-default functions/types + } - -### PER.15: Do not allocate on a critical branch +A trait is usually a type alias to compute a type, +a `constexpr` function to compute a value, +or a traditional traits template to be specialized on the user's type. -??? +##### Note +If you intend to call your own helper function `helper(t)` with a value `t` that depends on a template type parameter, +put it in a `::detail` namespace and qualify the call as `detail::helper(t);`. +An unqualified call becomes a customization point where any function `helper` in the namespace of `t`'s type can be invoked; +this can cause problems like [unintentionally invoking unconstrained function templates](#Rt-visible). - -### PER.16: Use compact data structures -**Reason**: Performance is typically dominated by memory access times. +##### Enforcement -??? +* In a template, flag an unqualified call to a non-member function that passes a variable of dependent type when there is a non-member function of the same name in the template's namespace. - -### PER.17: Declare the most used member of a time critical struct first +## T.temp-hier: Template and hierarchy rules: -??? +Templates are the backbone of C++'s support for generic programming and class hierarchies the backbone of its support +for object-oriented programming. +The two language mechanisms can be used effectively in combination, but a few design pitfalls must be avoided. +### T.80: Do not naively templatize a class hierarchy - -### PER.18: Space is time +##### Reason -**Reason**: Performance is typically dominated by memory access times. +Templating a class hierarchy that has many functions, especially many virtual functions, can lead to code bloat. -??? +##### Example, bad + template + struct Container { // an interface + virtual T* get(int i); + virtual T* first(); + virtual T* next(); + virtual void sort(); + }; - -### PER.19: Access memory predictably + template + class Vector : public Container { + public: + // ... + }; -**Reason**: Performance is very sensitive to cache performance and cache algorithms favor simple (usually linear) access to adjacent data. + Vector vi; + Vector vs; -??? +It is probably a bad idea to define a `sort` as a member function of a container, but it is not unheard of and it makes a good example of what not to do. +Given this, the compiler cannot know if `vector::sort()` is called, so it must generate code for it. +Similar for `vector::sort()`. +Unless those two functions are called that's code bloat. +Imagine what this would do to a class hierarchy with dozens of member functions and dozens of derived classes with many instantiations. - -### PER.30: Avoid context switches on the critical path +##### Note -??? +In many cases you can provide a stable interface by not parameterizing a base; +see ["stable base"](#Rt-abi) and [OO and GP](#Rt-generic-oo) +##### Enforcement - -# CP: Concurrency and Parallelism +* Flag virtual functions that depend on a template argument. ??? False positives -??? +### T.81: Do not mix hierarchies and arrays -Concurrency and parallism rule summary: +##### Reason -* [CP.1: Assume that your code will run as part of a multi-threaded program](#Rconc-multi) -* [CP.2: Avoid data races](#Rconc-races) +An array of derived classes can implicitly "decay" to a pointer to a base class with potential disastrous results. -See also: +##### Example -* [CP.con: Concurrency](#SScp-con) -* [CP.par: Parallelism](#SScp-par) -* [CP.simd: SIMD](#SScp-simd) -* [CP.free: Lock-free programming](#SScp-free) +Assume that `Apple` and `Pear` are two kinds of `Fruit`s. + void maul(Fruit* p) + { + *p = Pear{}; // put a Pear into *p + p[1] = Pear{}; // put a Pear into p[1] + } - -### CP.1: Assume that your code will run as part of a multi-threaded program + Apple aa [] = { an_apple, another_apple }; // aa contains Apples (obviously!) -**Reason**: It is hard to be certain that concurrency isn't used now or sometime in the future. -Code gets re-used. -Libraries using threads my be used from some other part of the program. + maul(aa); + Apple& a0 = &aa[0]; // a Pear? + Apple& a1 = &aa[1]; // a Pear? -**Example**: +Probably, `aa[0]` will be a `Pear` (without the use of a cast!). +If `sizeof(Apple) != sizeof(Pear)` the access to `aa[1]` will not be aligned to the proper start of an object in the array. +We have a type violation and possibly (probably) a memory corruption. +Never write such code. - ??? +Note that `maul()` violates the a [`T*` points to an individual object rule](#Rf-ptr). -**Exception**: There are examples where code will never be run in a multi-threaded environment. -However, here are also many examples where code that was "known" to never run in a multi-threaded program -was run as part of a multi-threaded program. Often years later. -Typically, such programs leads to a painful effort to remove data races. +**Alternative**: Use a proper (templatized) container: - -### CP.2: Avoid data races + void maul2(Fruit* p) + { + *p = Pear{}; // put a Pear into *p + } -**Reason**: Unless you do, nothing is guaranteed to work and subtle errors will persist. + vector va = { an_apple, another_apple }; // va contains Apples (obviously!) -**Note**: If you have any doubts about what this means, go read a book. + maul2(va); // error: cannot convert a vector to a Fruit* + maul2(&va[0]); // you asked for it -**Enforcement**: Some is possible, do at least something. + Apple& a0 = &va[0]; // a Pear? +Note that the assignment in `maul2()` violated the [no-slicing rule](#Res-slice). - -## CP.con: Concurrency +##### Enforcement -??? +* Detect this horror! -Concurrency rule summary: +### T.82: Linearize a hierarchy when virtual functions are undesirable -* ??? -* ??? +##### Reason -???? should there be a "use X rather than std::async" where X is something that would use a better specified thread pool? -  -Speaking of concurrency, should there be a note about the dangers of std::atomic (weapons)? -A lot of people, myself included, like to experiment with std::memory_order, but it is perhaps best to keep a close watch on those things in production code. -Even vendors mess this up: Microsoft had to fix their `shared_ptr` -(weak refcount decrement wasn't synchronized-with the destructor, if I recall correctly, although it was only a problem on ARM, not Intel) -and everyone (gcc, clang, Microsoft, and intel) had to fix their `compare_exchange_*` this year, -after an implementation bug caused losses to some finance company and they were kind enough to let the community know. - -It should definitely mention that `volatile` does not provide atomicity, does not synchronize between threads, and does not prevent instruction reordering (neither compiler nor hardware), and simply has nothing to do with concurrency. - - if(source->pool != YARROW_FAST_POOL && source->pool != YARROW_SLOW_POOL) { - THROW( YARROW_BAD_SOURCE ); - } - -??? Is `std::async` worth using in light of future (and even existing, as libraries) parallelism facilities? What should the guidelines recommend if someone wants to parallelize, e.g., `std::accumulate` (with the additional precondition of commutativity), or merge sort? + ??? -???UNIX signal handling???. May be worth reminding how little is async-signal-safe, and how to communicate with a signal handler (best is probably "not at all") +##### Example + ??? - -## CP.par: Parallelism +##### Enforcement ??? -Parallelism rule summary: - -* ??? -* ??? - +### T.83: Do not declare a member function template virtual - -## CP.simd: SIMD +##### Reason -??? +C++ does not support that. +If it did, vtbls could not be generated until link time. +And in general, implementations must deal with dynamic linking. -SIMD rule summary: +##### Example, don't -* ??? -* ??? + class Shape { + // ... + template + virtual bool intersect(T* p); // error: template cannot be virtual + }; - -## CP.free: Lock-free programming +##### Note -??? +We need a rule because people keep asking about this -Lock-free programming rule summary: +##### Alternative -* ??? -* ??? +Double dispatch, visitors, calculate which function to call -### Don't use lock-free programming unless you absolutely have to +##### Enforcement -**Reason**: It's error-prone and requires expert level knowledge of language features, machine architecture, and data structures. +The compiler handles that. -**Alternative**: Use lock-free data structures implemented by others as part of some library. +### T.84: Use a non-template core implementation to provide an ABI-stable interface - -# E: Error handling +##### Reason -Error handling involves: +Improve stability of code. +Avoid code bloat. -* Detecting an error -* Transmitting information about an error to some handler code -* Preserve the state of a program in a valid state -* Avoid resource leaks +##### Example -It is not possible to recover from all errors. If recovery from an error is not possible, it is important to quickly "get out" in a well-defined way. A strategy for error handling must be simple, or it becomes a source of even worse errors. +It could be a base class: -The rules are designed to help avoid several kinds of errors: + struct Link_base { // stable + Link_base* suc; + Link_base* pre; + }; -* Type violations (e.g., misuse of `union`s and casts) -* Resource leaks (including memory leaks) -* Bounds errors -* Lifetime errors (e.g., accessing an object after is has been `delete`d) -* Complexity errors (logical errors make likely by overly complex expression of ideas) -* Interface errors (e.g., an unexpected value is passed through an interface) + template // templated wrapper to add type safety + struct Link : Link_base { + T val; + }; -Error-handling rule summary: + struct List_base { + Link_base* first; // first element (if any) + int sz; // number of elements + void add_front(Link_base* p); + // ... + }; -* [E.1: Develop an error-handling strategy early in a design](#Re-design) -* [E.2: Throw an exception to signal that a function can't perform its assigned task](#Re-throw) -* [E.3: Use exceptions for error handling only](#Re-errors) -* [E.4: Design your error-handling strategy around invariants](#Re-design-invariant) -* [E.5: Let a constructor establish an invariant, and throw if it cannot](#Re-invariant) -* [E.6: Use RAII to prevent leaks](#Re-raii) -* [E.7: State your preconditions](#Re-precondition) -* [E.8: State your postconditions](#Re-postcondition) + template + class List : List_base { + public: + void put_front(const T& e) { add_front(new Link{e}); } // implicit cast to Link_base + T& front() { static_cast*>(first).val; } // explicit cast back to Link + // ... + }; -* [E.12: Use `noexcept` when exiting a function because of a `throw` is impossible or unacceptable](#Re-noexcept) -* [E.13: Never throw while being the direct owner of an object](#Re-never-throw) -* [E.14: Use purpose-designed user-defined types as exceptions (not built-in types)](#Re-exception-types) -* [E.15: Catch exceptions from a hierarchy by reference](#Re-exception-ref) -* [E.16: Destructors, deallocation, and `swap` must never fail](#Re-never-fail) -* [E.17: Don't try to catch every exception in every function](#Re-not-always) -* [E.18: Minimize the use of explicit `try`/`catch`](#Re-catch) -* [E.19: Use a `Final_action` object to express cleanup if no suitable resource handle is available](#Re-finally) + List li; + List ls; -* [E.25: ??? What to do in programs where exceptions cannot be thrown](#Re-no-throw) -* ??? +Now there is only one copy of the operations linking and unlinking elements of a `List`. +The `Link` and `List` classes do nothing but type manipulation. +Instead of using a separate "base" type, another common technique is to specialize for `void` or `void*` and have the general template for `T` be just the safely-encapsulated casts to and from the core `void` implementation. - -### E.1: Develop an error-handling strategy early in a design +**Alternative**: Use a [Pimpl](#Ri-pimpl) implementation. -**Reason**: a consistent and complete strategy for handling errors and resource leaks is hard to retrofit into a system. +##### Enforcement - -### E.2: Throw an exception to signal that a function can't perform its assigned task +??? -**Reason**: To make error handling systematic, robust, and non-repetitive. +## T.var: Variadic template rules -**Example**: +??? - struct Foo { - vector v; - File_handle f; - string s; - }; +### T.100: Use variadic templates when you need a function that takes a variable number of arguments of a variety of types - void use() - { - Foo bar { {Thing{1}, Thing{2}, Thing{monkey}}, {"my_file","r"}, "Here we go!"}; - // ... - } +##### Reason -Here, `vector` and `string`s constructors may not be able to allocate sufficient memory for their elements, -`vector`s constructor may not be able copy the `Thing`s in its initializer list, and `File_handle` may not be able to open the required file. -In each case, they throw an exception for `use()`'s caller to handle. -If `use()` could handle the failure to construct `bar` it can take control using `try`/`catch`. -In either case, `Foo`'s constructor correctly destroys constructed members before passing control to whatever tried to create a `Foo`. -Note that there is no return value that could contain an error code. +Variadic templates is the most general mechanism for that, and is both efficient and type-safe. Don't use C varargs. -The `File_handle` constructor might defined like this +##### Example - File_handle::File_handle(const string& name, const string& mode) - :f{fopen(name.c_str(),mode.c_str()} - { - if (!f) - throw runtime_error{"File_handle: could not open "S-+ name + " as " + mode"} - } + ??? printf -**Note**: It is often said that exceptions are meant to signal exceptional events and failures. -However, that's a bit circular because "what is exceptional?" -Examples: +##### Enforcement -* A precondition that cannot be met -* A constructor that cannot construct an object (failure to establish its class's [invariant](#Rc-struct)) -* An out-of-range error (e.g., `v[v.size()]=7`) -* Inability to acquire a resource (e.g., the network is down) +* Flag uses of `va_arg` in user code. -In contrast, termination of an ordinary loop is not exceptional. -Unless the loop was meant to be infinite, termination is normal and expected. +### T.101: ??? How to pass arguments to a variadic template ??? -**Note**: Don't use a `throw` as simply an alternative way of returning a value from a function. +##### Reason -**Exception**: Some systems, such as hard-real time systems require a guarantee that an action is taken in a (typically short) constant maximum time known before execution starts. Such systems can use exceptions only if there is tool support for accurately predicting the maximum time to recover from a `throw`. + ??? -**See also**: [RAII](#Re-raii) +##### Example -**See also**: [discussion](#Sd-noexcept) + ??? beware of move-only and reference arguments +##### Enforcement - -### E.3: Use exceptions for error handling only +??? -**Reason**. To keep error handling separated from "ordinary code." -C++ implementations tend to be optimized based on the assumption that exceptions are rare. +### T.102: How to process arguments to a variadic template -**Example; don't**: +##### Reason - int find_index(vector& vec, const string& x) // don't: exception not used for error handling - { - try { - for (int i =0; i -### E.4: Design your error-handling strategy around invariants +##### Enforcement -**Reason**: To use an objects it must be in a valid state (defined formally or informally by an invariant) -and to recover from an error every object not destroyed must be in a valid state. +??? -**Note**: An [invariant](#Rc-struct) is logical condition for the members of an object that a constructor must establish for the public member functions to assume. +### T.103: Don't use variadic templates for homogeneous argument lists +##### Reason - -### E.5: Let a constructor establish an invariant, and throw if it cannot +There are more precise ways of specifying a homogeneous sequence, such as an `initializer_list`. -**Reason**: Leaving an object without its invariant established is asking for trouble. -Not all member function can be called. +##### Example -**Example**: + ??? - ??? +##### Enforcement -**See also**: [If a constructor cannot construct a valid object, throw an exception](#Rc-throw) +??? -**Enforcement**: ??? +## T.meta: Template metaprogramming (TMP) +Templates provide a general mechanism for compile-time programming. - -### E.6: Use RAII to prevent leaks +Metaprogramming is programming where at least one input or one result is a type. +Templates offer Turing-complete (modulo memory capacity) duck typing at compile time. +The syntax and techniques needed are pretty horrendous. -**Reason**: Leaks are typically unacceptable. RAII ("Resource Acquisition Is Initialization") is the simplest, most systematic way of preventing leaks. +### T.120: Use template metaprogramming only when you really need to -**Example**: +##### Reason - void f1(int i) // Bad: possibly leak - { - int* p = new int[12]; - // ... - if (i<17) throw Bad {"in f()",i}; - // ... - } +Template metaprogramming is hard to get right, slows down compilation, and is often very hard to maintain. +However, there are real-world examples where template metaprogramming provides better performance than any alternative short of expert-level assembly code. +Also, there are real-world examples where template metaprogramming expresses the fundamental ideas better than run-time code. +For example, if you really need AST manipulation at compile time (e.g., for optional matrix operation folding) there might be no other way in C++. -We could carefully release the resource before the throw +##### Example, bad - void f2(int i) // Clumsy: explicit release - { - int* p = new int[12]; - // ... - if (i<17) { - delete p; - throw Bad {"in f()",i}; - } - // ... - } + ??? -This is verbose. In larger code with multiple possible `throw`s explicit releases become repetitive and error-prone. +##### Example, bad - void f3(int i) // OK: resource management done by a handle - { - auto p = make_unique(); - // ... - if (i<17) throw Bad {"in f()",i}; - // ... - } + enable_if -Note that this works even when the `throw` is implicit because it happened in a called function: +Instead, use concepts. But see [How to emulate concepts if you don't have language support](#Rt-emulate). - void f4(int i) // OK: resource management done by a handle - { - auto p = make_unique(); - // ... - helper(i); // may throw - // ... - } +##### Example -Unless you really need pointer semantics, use a local resource object: + ??? good - void f5(int i) // OK: resource management done by local object - { - vector v(12); - // ... - helper(i); // may throw - // ... - } +**Alternative**: If the result is a value, rather than a type, use a [`constexpr` function](#Rt-fct). -**Note**: If there is no obvious resource handle, cleanup actions can be represented by a [`Finally` object](#Re-finally) +##### Note -**Note**: But what do we do if we are writing a program where exceptions cannot be used? -First challenge that assumption; there are many anti-exceptions myths around. -We know of only a few good reasons: +If you feel the need to hide your template metaprogramming in macros, you have probably gone too far. -* We are on a system so small that the exception support would eat up most of our 2K or memory. -* We are in a hard-real-time system and we don't have tools that allows us that an exception is handled withon the required time. -* We are in a system with tons of legacy code using lots of pointers in difficult-to-understand ways -(in particular without a recognizable ownership strategy) so that exceptions could cause leaks. -* We get fired if we challenge our manager's ancient wisdom. +### T.121: Use template metaprogramming primarily to emulate concepts -Only the first of these reasons is fundamental, -so whenever possible, use exception to implement RAII. -When exceptions cannot be used, simulate RAII. -That is, systematically check that objects are valid after construction and still release all resources in the destructor. -One strategy is to add a `valid()` operation to every resource handle: +##### Reason - void f() - { - Vector vs(100); // not std::vector: valid() added - if (!vs.valid()) { - // handle error or exit - } - - Ifstream fs("foo"); // not std::ifstream: valid() added - if (!fs.valid()) { - // handle error or exit - } - - // ... - } // destructors clean up as usual - -Obviously, this increases the size of the code, -doesn't allow for implicit propagation of "exceptions" (`valid()` checks), -and `valid()` checks can be forgotten. -Prefer to use exceptions. +Where C++20 is not available, we need to emulate them using TMP. +Use cases that require concepts (e.g. overloading based on concepts) are among the most common (and simple) uses of TMP. -**See also**: [discussion](##Sd-noexcept). +##### Example -**Enforcement**: ??? + template + /*requires*/ enable_if, void> + advance(Iter p, int n) { p += n; } + template + /*requires*/ enable_if, void> + advance(Iter p, int n) { assert(n >= 0); while (n--) ++p;} - -### E.7: State your preconditions +##### Note -**Reason**: To avoid interface errors. +Such code is much simpler using concepts: -**See also**: [precondition rule](#Ri-???). + void advance(random_access_iterator auto p, int n) { p += n; } + void advance(forward_iterator auto p, int n) { assert(n >= 0); while (n--) ++p;} - -### E.8: State your postconditions +##### Enforcement -**Reason**: To avoid interface errors. +??? -**See also**: [postcondition rule](#Ri-???). +### T.122: Use templates (usually template aliases) to compute types at compile time +##### Reason - -### E.12: Use `noexcept` when exiting a function because of a `throw` is impossible or unacceptable +Template metaprogramming is the only directly supported and half-way principled way of generating types at compile time. -**Reason**: To make error handling systematic, robust, and efficient. +##### Note -**Example**: +"Traits" techniques are mostly replaced by template aliases to compute types and `constexpr` functions to compute values. - double compute(double d) noexcept - { - return log(sqrt(d<=0? 1 : d)); - } +##### Example -Here, I know that `compute` will not throw because it is composed out of operations that don't throw. By declaring `compute` to be `noexcept` I give the compiler and human readers information that can make it easier for them to understand and manipulate 'compute`. + ??? big object / small object optimization -**Note**: Many standard library functions are `noexcept` including all the standard library functions "inherited" from the C standard library. +##### Enforcement -**Example**: +??? - vector munge(const vector& v) noexcept - { - vector v2(v.size()); - // ... do something ... - } +### T.123: Use `constexpr` functions to compute values at compile time -The `noexcept` here states that I am not willing or able to handle the situation where I cannot construct the local `vector`. That is, I consider memory exhaustion a serious design error (on line with hardware failures) so that I'm willing to crash the program if it happens. +##### Reason -**See also**: [discussion](#Sd-noexcept). +A function is the most obvious and conventional way of expressing the computation of a value. +Often a `constexpr` function implies less compile-time overhead than alternatives. +##### Note - -### E.13: Never throw while being the direct owner of an object +"Traits" techniques are mostly replaced by template aliases to compute types and `constexpr` functions to compute values. -**Reason**: That would be a leak. +##### Example -**Example**: + template + // requires Number + constexpr T pow(T v, int n) // power/exponential + { + T res = 1; + while (n--) res *= v; + return res; + } - void leak(int x) // don't: may leak - { - auto p = new int{7}; - if (x<0) throw Get_me_out_of_here{}; // may leak *p - // ... - delete p; // we may never get here - } + constexpr auto f7 = pow(pi, 7); -One way of avoiding such problems is to use resource handles consistently: +##### Enforcement - void no_leak(int x) - { - auto p = make_unique(7); - if (x<0) throw Get_me_out_of_here{}; // will delete *p if necessary - // ... - // no need for delete p - } - -**See also**: ???resource rule ??? - - - -### E.14: Use purpose-designed user-defined types as exceptions (not built-in types) - -**Reason**: A user-defined type is unlikely to clash with other people's exceptions. - -**Example**: - - void my_code() - { - // ... - throw Moonphase_error{}; - // ... - } - - void your_code() - { - try { - // ... - my_code(); - // ... - } - catch(Bufferpool_exhausted) { - // ... - } - } - -**Example; don't**: - - void my_code() // Don't - { - // ... - throw 7; // 7 means "moon in the 4th quarter" - // ... - } - - void your_code() // Don't - { - try { - // ... - my_code(); - // ... - } - catch(int i) { // i==7 means "input buffer too small" - // ... - } - } - -**Note**: The standard-library classes derived from `exception` should be used only as base classes or for exceptions that require only "generic" handling. Like built-in types, their use could class with other people's use of them. - -**Example; don't**: - - void my_code() // Don't - { - // ... - throw runtime_error{"moon in the 4th quarter"}; - // ... - } - - void your_code() // Don't - { - try { - // ... - my_code(); - // ... - } - catch(runtime_error) { // runtime_error means "input buffer too small" - // ... - } - } +* Flag template metaprograms yielding a value. These should be replaced with `constexpr` functions. +### T.124: Prefer to use standard-library TMP facilities -**See also**: [Discussion](#Sd-???) +##### Reason -**Enforcement**: Catch `throw` and `catch` of a built-in type. Maybe warn about `throw` and `catch` using an standard-library `exception` type. Obviously, exceptions derived from the `std::exception` hierarchy is fine. +Facilities defined in the standard, such as `conditional`, `enable_if`, and `tuple`, are portable and can be assumed to be known. +##### Example - -### E.15: Catch exceptions from a hierarchy by reference + ??? -**Reason**: To prevent slicing. +##### Enforcement -**Example**: +??? - void f() - try { - // ... - } - catch (exception e) { // don't: may slice - // ... - } +### T.125: If you need to go beyond the standard-library TMP facilities, use an existing library -Instead, use +##### Reason - catch (exception& e) { /* ... */ } +Getting advanced TMP facilities is not easy and using a library makes you part of a (hopefully supportive) community. +Write your own "advanced TMP support" only if you really have to. -**Enforcement**: Flag by-value exceptions if their type are part of a hierarchy (could require whole-program analysis to be perfect). +##### Example + ??? - -### E.16: Destructors, deallocation, and `swap` must never fail +##### Enforcement -**Reason**: We don't know how to write reliable programs if a destructor, a swap, or a memory deallocation fails; that is, if it exits by an exception or simply doesn't perform its required action. +??? -**Example; don't**: +## Other template rules - class Connection { - // ... - public: - ~Connection() // Don't: very bad destructor - { - if (cannot_disconnect()) throw I_give_up{information}; - // ... - } - }; +### T.140: If an operation can be reused, give it a name -**Note**: Many have tried to write reliable code violating this rule for examples such as a network connection that "refuses to close". To the best of our knowledge nobody has found a general way of doing this though occasionally, for very specific examples, you can get away with setting some state for future cleanup. Every example, we have seen of this is error-prone, specialized, and usually buggy. +See [F.10](#Rf-name) -**Note**: The standard library assumes that destructors, deallocation functions (e.g., `operator delete`), and `swap` do not throw. If they do, basic standard library invariants are broken. +### T.141: Use an unnamed lambda if you need a simple function object in one place only -**Note**: Deallocation functions, including `operator delete`, must be `noexcept`. `swap` functions must be `noexcept`. Most destructors are implicitly `noexcept` by default. destructors, make them `noexcept`. +See [F.11](#Rf-lambda) -**Enforcement**: Catch destructors, deallocation operations, and `swap`s that `throw`. Catch such operations that are not `noexcept`. +### T.142?: Use template variables to simplify notation -**See also**: [discussion](#Sd-never-fail) +##### Reason +Improved readability. - -### E.17: Don't try to catch every exception in every function +##### Example -**Reason**: Catching an exception in a function that cannot take a meaningful recovery action leads to complexity and waste. -Let an exception propagate until it reaches a function that can handle it. -Let cleanup actions on the unwinding path be handles by [RAII](#Re-raii). + ??? -**Example; don't**: +##### Enforcement - void f() // bad - { - try { - // ... - } - catch (...) { - throw; // propagate exception - } - } +??? -**Enforcement**: +### T.143: Don't write unintentionally non-generic code -* Flag nested try-blocks. -* Flag source code files with a too high ratio of try-blocks to functions. (??? Problem: define "too high") +##### Reason +Generality. Reusability. Don't gratuitously commit to details; use the most general facilities available. - -### E.18: Minimize the use of explicit `try`/`catch` +##### Example -**Reason**: `try`/`catch` is verbose and non-trivial uses error-prone. +Use `!=` instead of `<` to compare iterators; `!=` works for more objects because it doesn't rely on ordering. -**Example**: + for (auto i = first; i < last; ++i) { // less generic + // ... + } - ??? + for (auto i = first; i != last; ++i) { // good; more generic + // ... + } -**Enforcement**: ??? +Of course, range-`for` is better still where it does what you want. +##### Example - -### E.19: Use a `Final_action` object to express cleanup if no suitable resource handle is available +Use the least-derived class that has the functionality you need. -**Reason**: `finally` is less verbose and harder to get wrong than `try`/`catch`. + class Base { + public: + Bar f(); + Bar g(); + }; -**Example**: + class Derived1 : public Base { + public: + Bar h(); + }; - void f(int n) - { - void* p = malloc(1,n); - auto __ = finally([] { free(p); }); - // ... - } + class Derived2 : public Base { + public: + Bar j(); + }; -**See also** ???? - + // bad, unless there is a specific reason for limiting to Derived1 objects only + void my_func(Derived1& param) + { + use(param.f()); + use(param.g()); + } - -### E.25: ??? What to do in programs where exceptions cannot be thrown + // good, uses only Base interface so only commit to that + void my_func(Base& param) + { + use(param.f()); + use(param.g()); + } -**Note**: ??? mostly, you can afford exceptions and code gets simpler with exceptions ??? +##### Enforcement +* Flag comparison of iterators using `<` instead of `!=`. +* Flag `x.size() == 0` when `x.empty()` or `x.is_empty()` is available. Emptiness works for more containers than size(), because some containers don't know their size or are conceptually of unbounded size. +* Flag functions that take a pointer or reference to a more-derived type but only use functions declared in a base type. -**See also**: [Discussion](#Sd-???). +### T.144: Don't specialize function templates +##### Reason - -# Con: Constants and Immutability +You can't partially specialize a function template per language rules. You can fully specialize a function template but you almost certainly want to overload instead -- because function template specializations don't participate in overloading, they don't act as you probably wanted. Rarely, you should actually specialize by delegating to a class template that you can specialize properly. -You can't have a race condition on a constant. -it is easier to reason about a program when many of the objects cannot change threir values. -Interfaces that promises "no change" of objects passed as arguments greatly increase readability. +##### Example -Constant rule summary: + ??? -* [Con.1: By default, make objects immutable](#Rconst-immutable) -* [Con.2: By default, make member functions `const`](#Rconst-fct) -* [Con.3: By default, pass pointers and references to `const`s](#Rconst-ref) -* [Con.4: Use `const` to define objects with values that do not change after construction](#Rconst-const) -* [Con.5: Use `constexpr` for values that can be computed at compile time](#Rconst-constexpr) +**Exceptions**: If you do have a valid reason to specialize a function template, just write a single function template that delegates to a class template, then specialize the class template (including the ability to write partial specializations). +##### Enforcement - -### Con.1: By default, make objects immutable +* Flag all specializations of a function template. Overload instead. -**Reason**: Immutable objects are easier to reason about, so make object non-`const` only when there is a need to change their value. -**Example**: +### T.150: Check that a class matches a concept using `static_assert` - for ( - container - ??? +##### Reason -**Enforcement**: ??? +If you intend for a class to match a concept, verifying that early saves users' pain. +##### Example - -### Con.2: By default, make member functions `const` + class X { + public: + X() = delete; + X(const X&) = default; + X(X&&) = default; + X& operator=(const X&) = default; + // ... + }; -**Reason**: ??? +Somewhere, possibly in an implementation file, let the compiler check the desired properties of `X`: -**Example**: + static_assert(Default_constructible); // error: X has no default constructor + static_assert(Copyable); // error: we forgot to define X's move constructor - ??? -**Enforcement**: ??? +##### Enforcement +Not feasible. - -### Con.3: By default, pass pointers and references to `const`s +# CPL: C-style programming -**Reason**: ??? +C and C++ are closely related languages. +They both originate in "Classic C" from 1978 and have evolved in ISO committees since then. +Many attempts have been made to keep them compatible, but neither is a subset of the other. -**Example**: +C rule summary: - ??? +* [CPL.1: Prefer C++ to C](#Rcpl-C) +* [CPL.2: If you must use C, use the common subset of C and C++, and compile the C code as C++](#Rcpl-subset) +* [CPL.3: If you must use C for interfaces, use C++ in the calling code using such interfaces](#Rcpl-interface) -**Enforcement**: ??? +### CPL.1: Prefer C++ to C +##### Reason - -### Con.4: Use `const` to define objects with values that do not change after construction +C++ provides better type checking and more notational support. +It provides better support for high-level programming and often generates faster code. -**Reason**: ??? +##### Example -**Example**: + char ch = 7; + void* pv = &ch; + int* pi = pv; // not C++ + *pi = 999; // overwrite sizeof(int) bytes near &ch - ??? +The rules for implicit casting to and from `void*` in C are subtle and unenforced. +In particular, this example violates a rule against converting to a type with stricter alignment. -**Enforcement**: ??? +##### Enforcement +Use a C++ compiler. - -### Con.5: Use `constexpr` for values that can be computed at compile time +### CPL.2: If you must use C, use the common subset of C and C++, and compile the C code as C++ -**Reason**: ??? +##### Reason -**Example**: +That subset can be compiled with both C and C++ compilers, and when compiled as C++ is better type checked than "pure C." - ??? +##### Example -**Enforcement**: ??? + int* p1 = malloc(10 * sizeof(int)); // not C++ + int* p2 = static_cast(malloc(10 * sizeof(int))); // not C, C-style C++ + int* p3 = new int[10]; // not C + int* p4 = (int*) malloc(10 * sizeof(int)); // both C and C++ +##### Enforcement - -# T: Templates and generic programming +* Flag if using a build mode that compiles code as C. -Generic programming is programming using types and algorithms parameterized by types, values, and algorithms. -In C++, generic programming is supported by the `template` language mechanisms. + * The C++ compiler will enforce that the code is valid C++ unless you use C extension options. -Arguments to generic functions are characterized by sets of requirements on the argument types and values involved. -In C++, these requirements are expressed by compile-time predicates called concepts. +### CPL.3: If you must use C for interfaces, use C++ in the calling code using such interfaces -Templates can also be used for meta-programming; that is, programs that compose code at compile time. +##### Reason -Template use rule summary: +C++ is more expressive than C and offers better support for many types of programming. -* [T.1: Use templates to raise the level of abstraction of code](#Rt-raise) -* [T.2: Use templates to express algorithms that apply to many argument types](#Rt-algo) -* [T.3: Use templates to express containers and ranges](#Rt-cont) -* [T.4: Use templates to express syntax tree manipulation](#Rt-expr) -* [T.5: Combine generic and OO techniques to amplify their strengths, not their costs](#Rt-generic-oo) +##### Example -Concept use rule summary: +For example, to use a 3rd party C library or C systems interface, define the low-level interface in the common subset of C and C++ for better type checking. +Whenever possible encapsulate the low-level interface in an interface that follows the C++ guidelines (for better abstraction, memory safety, and resource safety) and use that C++ interface in C++ code. -* [T.10: Specify concepts for all template arguments](#Rt-concepts) -* [T.11: Whenever possible use standard concepts](#Rt-std) -* [T.12: Prefer concept names over `auto` for local variables](#Rt-auto) -* [T.13: Prefer the shorthand notation for simple, single-type argument concepts](#Rt-shorthand) -* ??? +##### Example -Concept definition rule summary: +You can call C from C++: -* [T.20: Avoid "concepts" without meaningful semantics](#Rt-low) -* [T.21: Define concepts to define complete sets of operations](#Rt-complete) -* [T.22: Specify axioms for concepts](#Rt-axiom) -* [T.23: Differentiate a refined concept from its more general case by adding new use patterns](#Rt-refine) -* [T.24: Use tag classes or traits to differentiate concepts that differ only in semantics](#Rt-tag) -* [T.25: Avoid negating constraints](#Rt-not) -* [T.26: Prefer to define concepts in terms of use-patterns rather than simple syntax](#Rt-use) -* ??? + // in C: + double sqrt(double); -Template interface rule summary: + // in C++: + extern "C" double sqrt(double); -* [T.40: Use function objects to pass operations to algorithms](#Rt-fo) -* [T.41: Require complete sets of operations for a concept](#Rt-operations) -* [T.42: Use template aliases to simplify notation and hide implementation details](#Rt-alias) -* [T.43: Prefer `using` over `typedef` for defining aliases](#Rt-using) -* [T.44: Use function templates to deduce class template argument types (where feasible)](#Rt-deduce) -* [T.46: Require template arguments to be at least `Regular` or `SemiRegular`](#Rt-regular) -* [T.47: Avoid highly visible unconstrained templates with common names](#Rt-visible) -* [T.48: If your compiler does not support concepts, fake them with `enable_if`](#Rt-concept-def) -* [T.49: Where possible, avoid type-erasure](#Rt-erasure) -* [T.50: Avoid writing an unconstrained template in the same namespace as a type](#Rt-unconstrained-adl) + sqrt(2); -Template definition rule summary: +##### Example -* [T.60: Minimize a template's context dependencies](#Rt-depend) -* [T.61: Do not over-parameterize members (SCARY)](#Rt-scary) -* [T.62: Place non-dependent template members in a non-templated base class](#Rt-nondependent) -* [T.64: Use specialization to provide alternative implementations of class templates](#Rt-specialization) -* [T.65: Use tag dispatch to provide alternative implementations of functions](#Rt-tag-dispatch) -* [T.66: Use selection using `enable_if` to optionally define a function](#Rt-enable_if) -* [T.67: Use specialization to provide alternative implementations for irregular types](#Rt-specialization2) -* [T.68: Use `{}` rather than `()` within templates to avoid ambiguities](#Rt-cast) -* [T.69: Inside a template, don't make an unqualified nonmember function call unless you intend it to be a customization point](#Rt-customization) +You can call C++ from C: -Template and hierarchy rule summary: + // in C: + X call_f(struct Y*, int); -* [T.80: Do not naively templatize a class hierarchy](#Rt-hier) -* [T.81: Do not mix hierarchies and arrays](#Rt-array) // ??? somewhere in "hierarchies" -* [T.82: Linearize a hierarchy when virtual functions are undesirable](#Rt-linear) -* [T.83: Do not declare a member function template virtual](#Rt-virtual) -* [T.84: Use a non-template core implementation to provide an ABI-stable interface](#Rt-abi) -* [T.??: ????](#Rt-???) + // in C++: + extern "C" X call_f(Y* p, int i) + { + return p->f(i); // possibly a virtual function call + } -Variadic template rule summary: +##### Enforcement -* [T.100: Use variadic templates when you need a function that takes a variable number of arguments of a variety of types](#Rt-variadic) -* [T.101: ??? How to pass arguments to a variadic template ???](#Rt-variadic-pass) -* [T.102: ??? How to process arguments to a variadic template ???](#Rt-variadic-process) -* [T.103: Don't use variadic templates for homogeneous argument lists](#Rt-variadic-not) -* [T.??: ????](#Rt-???) +None needed -Metaprogramming rule summary: +# SF: Source files -* [T.120: Use template metaprogramming only when you really need to](#Rt-metameta) -* [T.121: Use template metaprogramming primarily to emulate concepts](#Rt-emulate) -* [T.122: Use templates (usually template aliases) to compute types at compile time](#Rt-tmp) -* [T.123: Use `constexpr` functions to compute values at compile time](#Rt-fct) -* [T.124: Prefer to use standard-library TMP facilities](#Rt-std) -* [T.125: If you need to go beyond the standard-library TMP facilities, use an existing library](#Rt-lib) -* [T.??: ????](#Rt-???) +Distinguish between declarations (used as interfaces) and definitions (used as implementations). +Use header files to represent interfaces and to emphasize logical structure. -Other template rules summary: +Source file rule summary: -* [T.140: Name all nontrivial operations](#Rt-name) -* [T.141: Use an unnamed lambda if you need a simple function object in one place only](#Rt-lambda) -* [T.142: Use template variables to simplify notation](#Rt-var) -* [T.143: Don't write unintentionally nongeneric code](#Rt-nongeneric) -* [T.144: Don't specialize function templates](#Rt-specialize-function) -* [T.??: ????](#Rt-???) +* [SF.1: Use a `.cpp` suffix for code files and `.h` for interface files if your project doesn't already follow another convention](#Rs-file-suffix) +* [SF.2: A header file must not contain object definitions or non-inline function definitions](#Rs-inline) +* [SF.3: Use header files for all declarations used in multiple source files](#Rs-declaration-header) +* [SF.4: Include header files before other declarations in a file](#Rs-include-order) +* [SF.5: A `.cpp` file must include the header file(s) that defines its interface](#Rs-consistency) +* [SF.6: Use `using namespace` directives for transition, for foundation libraries (such as `std`), or within a local scope (only)](#Rs-using) +* [SF.7: Don't write `using namespace` at global scope in a header file](#Rs-using-directive) +* [SF.8: Use `#include` guards for all header files](#Rs-guards) +* [SF.9: Avoid cyclic dependencies among source files](#Rs-cycles) +* [SF.10: Avoid dependencies on implicitly `#include`d names](#Rs-implicit) +* [SF.11: Header files should be self-contained](#Rs-contained) +* [SF.12: Prefer the quoted form of `#include` for files relative to the including file and the angle bracket form everywhere else](#Rs-incform) +* [SF.13: Use portable header identifiers in `#include` statements](#Rs-portable-header-id) +* [SF.20: Use `namespace`s to express logical structure](#Rs-namespace) +* [SF.21: Don't use an unnamed (anonymous) namespace in a header](#Rs-unnamed) +* [SF.22: Use an unnamed (anonymous) namespace for all internal/non-exported entities](#Rs-unnamed2) - -## T.gp: Generic programming +### SF.1: Use a `.cpp` suffix for code files and `.h` for interface files if your project doesn't already follow another convention -Generic programming is programming using types and algorithms parameterized by types, values, and algorithms. +See [NL.27](#Rl-file-suffix) +### SF.2: A header file must not contain object definitions or non-inline function definitions - -### T.1: Use templates to raise the level of abstraction of code +##### Reason -**Reason**: Generality. Re-use. Efficiency. Encourages consistent definition of user types. +Including entities subject to the one-definition rule leads to linkage errors. -**Example, bad**: Conceptually, the following requirements are wrong because what we want of `T` is more than just the very low-level concepts of "can be incremented" or "can be added": +##### Example - template - // requires Incrementable - A sum1(vector& v, A s) - { - for (auto x : v) s+=x; - return s; - } - - template - // requires Simple_number - A sum2(vector& v, A s) - { - for (auto x : v) s = s+x; - return s; - } + // file.h: + namespace Foo { + int x = 7; + int xx() { return x+x; } + } -Assuming that `Incrementable` does not support `+` and `Simple_number` does not support `+=`, we have overconstrained implementers of `sum1` and `sum2`. -And, in this case, missed an opportunity for a generalization. + // file1.cpp: + #include + // ... more ... -**Example**: + // file2.cpp: + #include + // ... more ... - template - // requires Arithmetic - A sum(vector& v, A s) - { - for (auto x : v) s+=x; - return s; - } +Linking `file1.cpp` and `file2.cpp` will give two linker errors. -Assuming that `Arithmetic` requires both `+` and `+=`, we have constrained the user of `sum` to provide a complete arithmetic type. -That is not a minimal requirement, but it gives the implementer of algorithms much needed freedom and ensures that any `Arithmetic` type -can be user for a wide variety of algorithms. +**Alternative formulation**: A header file must contain only: -For additional generality and reusability, we could also use a more general `Container` or `Range` concept instead of committing to only one container, `vector`. +* `#include`s of other header files (possibly with include guards) +* templates +* class definitions +* function declarations +* `extern` declarations +* `inline` function definitions +* `constexpr` definitions +* `const` definitions +* `using` alias definitions +* ??? -**Note**: If we define a template to require exactly the operations required for a single implementation of a single algorithm -(e.g., requiring just `+=` rather than also `=` and `+`) and only those, -we have overconstrained maintainers. -We aim to minimize requirements on template arguments, but the absolutely minimal requirements of an implementation is rarely a meaningful concept. +##### Enforcement -**Note**: Templates can be used to express essentially everything (they are Turing complete), but the aim of generic programming (as expressed using templates) -is to efficiently generalize operations/algorithms over a set of types with similar semantic properties. +Check the positive list above. -**Enforcement**: +### SF.3: Use header files for all declarations used in multiple source files -* Flag algorithms with "overly simple" requirements, such as direct use of specific operators without a concept. -* Do not flag the definition of the "overly simple" concepts themselves; they may simply be building blocks for more useful concepts. +##### Reason +Maintainability. Readability. - -### T.2: Use templates to express algorithms that apply to many argument types +##### Example, bad -**Reason**: Generality. Minimizing the amount of source code. Interoperability. Re-use. + // bar.cpp: + void bar() { cout << "bar\n"; } -**Example**: That's the foundation of the STL. A single `find` algorithm easily works with any kind of input range: + // foo.cpp: + extern void bar(); + void foo() { bar(); } - template - // requires Input_iterator - // && Equality_comparable,Val> - Iter find(Iter b, Iter e, Val v) - { - // ... - } +A maintainer of `bar` cannot find all declarations of `bar` if its type needs changing. +The user of `bar` cannot know if the interface used is complete and correct. At best, error messages come (late) from the linker. -**Note**: Don't use a template unless you have a realistic need for more than one template argument type. -Don't overabstract. +##### Enforcement -**Enforcement**: ??? tough, probably needs a human +* Flag declarations of entities in other source files not placed in a `.h`. +### SF.4: Include header files before other declarations in a file - -### T.3: Use templates to express containers and ranges +##### Reason -**Reason**: Containers need an element type, and expressing that as a template argument is general, reusable, and type safe. -It also avoids brittle or inefficient workarounds. Convention: That's the way the STL does it. +Minimize context dependencies and increase readability. -**Example**: - - template - // requires Regular - class Vector { - // ... - T* elem; // points to sz Ts - int sz; - }; - - Vector v(10); - v[7] = 9.9; - -**Example, bad**: - - class Container { - // ... - void* elem; // points to size elements of some type - int sz; - }; - - Container c(10,sizeof(double)); - ((double*)c.elem)[] = 9.9; - -This doesn't directly express the intent of the programmer and hides the structure of the program from the type system and optimizer. +##### Example -Hiding the `void*` behind macros simply obscures the problems and introduces new opportunities for confusion. + #include + #include + #include -**Exceptions**: If you need an ABI-stable interface, -you might have to provide a base implementation and express the (type-safe) template in terms of that. -See [Stable base](#Rt-abi). + // ... my code here ... -**Enforcement**: +##### Example, bad -* Flag uses of `void*`s and casts outside low-level implementation code + #include + // ... my code here ... - -### T.4: Use templates to express syntax tree manipulation + #include + #include -**Reason**: ??? +##### Note -**Example**: +This applies to both `.h` and `.cpp` files. - ??? +##### Note -**Exceptions**: ??? +There is an argument for insulating code from declarations and macros in header files by `#including` headers *after* the code we want to protect +(as in the example labeled "bad"). +However +* that only works for one file (at one level): Use that technique in a header included with other headers and the vulnerability reappears. +* a namespace (an "implementation namespace") can protect against many context dependencies. +* full protection and flexibility require modules. +**See also**: - -### T.5: Combine generic and OO techniques to amplify their strengths, not their costs +* [Working Draft, Extensions to C++ for Modules](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4592.pdf) +* [Modules, Componentization, and Transition](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0141r0.pdf) -**Reason**: Generic and OO techniques are complementary. +##### Enforcement -**Example**: Static helps dynamic: Use static polymorphism to implement dynamically polymorphic interfaces. +Easy. - class Command { - // pure virtual functions - }; - - // implementations - template - class ConcreteCommand : public Command { - // implement virtuals - }; +### SF.5: A `.cpp` file must include the header file(s) that defines its interface -**Example**: Dynamic helps static: Offer a generic, comfortable, statically bound interface, but internally dispatch dynamically, so you offer a uniform object layout. Examples include type erasure as with `std::shared_ptr`’s deleter. (But [don't overuse type erasure](#Rt-erasure).) +##### Reason -**Note**: In a class template, nonvirtual functions are only instantiated if they're used -- but virtual functions are instantiated every time. This can bloat code size, and may overconstrain a generic type by instantiating functionality that is never needed. Avoid this, even though the standard facets made this mistake. +This enables the compiler to do an early consistency check. -**Enforcement**: -* Flag a class template that declares new (non-inherited) virtual functions. +##### Example, bad + // foo.h: + void foo(int); + int bar(long); + int foobar(int); + // foo.cpp: + void foo(int) { /* ... */ } + int bar(double) { /* ... */ } + double foobar(int); - -## TPG.concepts: Concept rules +The errors will not be caught until link time for a program calling `bar` or `foobar`. -Concepts is a facility for specifying requirements for template arguments. -It is an [ISO technical specification](#Ref-conceptsTS), but not yet supported by currently shipping compilers. -Concepts are, however, crucial in the thinking about generic programming and the basis of much work on future C++ libraries -(standard and other). +##### Example -Concept use rule summary: + // foo.h: + void foo(int); + int bar(long); + int foobar(int); -* [T.10: Specify concepts for all template arguments](#Rt-concepts) -* [T.11: Whenever possible use standard concepts](#Rt-std) -* [T.14: Prefer concept names over `auto`](#Rt-auto) -* [T.15: Prefer the shorthand notation for simple, single-type argument concepts](Rt-shorthand) -* ??? + // foo.cpp: + #include "foo.h" -Concept definition rule summary: + void foo(int) { /* ... */ } + int bar(double) { /* ... */ } + double foobar(int); // error: wrong return type -* [T.20: Avoid "concepts" without meaningful semantics](#Rt-low) -* [T.21: Define concepts to define complete sets of operations](#Rt-complete) -* [T.22: Specify axioms for concepts](#Rt-axiom) -* [T.23: Differentiate a refined concept from its more general case by adding new use patterns](#Rt-refine) -* [T.24: Use tag classes or traits to differentiate concepts that differ only in semantics](#Rt-tag) -* [T.25: Avoid negating constraints](#Rt-not) -* [T.26: Prefer to define concepts in terms of use-patterns rather than simple syntax](#Rt-use) -* ??? +The return-type error for `foobar` is now caught immediately when `foo.cpp` is compiled. +The argument-type error for `bar` cannot be caught until link time because of the possibility of overloading, but systematic use of `.h` files increases the likelihood that it is caught earlier by the programmer. +##### Enforcement - -## T.con-use: Concept use +??? - -### T.10: Specify concepts for all template arguments +### SF.6: Use `using namespace` directives for transition, for foundation libraries (such as `std`), or within a local scope (only) -**Reason**: Correctness and readability. -The assumed meaning (syntax and semantics) of a template argument is fundamental to the interface of a template. -A concept dramatically improves documentation and error handling for the template. -Specifying concepts for template arguments is a powerful design tool. +##### Reason -**Example**: - - template - requires Input_iterator - && Equality_comparable,Val> - Iter find(Iter b, Iter e, Val v) - { - // ... - } - -or equivalently and more succinctly - - template - requires Equality_comparable,Val> - Iter find(Iter b, Iter e, Val v) - { - // ... - } - -**Note**: Until your compilers support the concepts language feature, leave the concepts in comments: - - template - // requires Input_iterator - // && Equality_comparable,Val> - Iter find(Iter b, Iter e, Val v) - { - // ... - } - -**Note**: Plain `typename` (or `auto`) is the least constraining concept. -It should be used only rarely when nothing more than "it's a type" can be assumed. -This is typically only needed when (as part of template metaprogramming code) we manipulate pure expression trees, postponing type checking. + `using namespace` can lead to name clashes, so it should be used sparingly. + However, it is not always possible to qualify every name from a namespace in user code (e.g., during transition) + and sometimes a namespace is so fundamental and prevalent in a code base, that consistent qualification would be verbose and distracting. -**References**: TC++PL4, Palo Alto TR, Sutton +##### Example -**Enforcement**: Flag template type arguments without concepts + #include + #include + #include + #include + #include + using namespace std; - -### T.11: Whenever possible use standard concepts + // ... -**Reason**: "Standard" concepts (as provided by the GSL, the ISO concepts TS, and hopefully soon the ISO standard itself) -saves us the work of thinking up our own concepts, are better thought out than we can manage to do in a hurry, and improves interoperability. +Here (obviously), the standard library is used pervasively and apparently no other library is used, so requiring `std::` everywhere +could be distracting. -**Note**: Unless you are creating a new generic library, most of the concepts you need will already be defined by the standard library. +##### Example -**Example**: +The use of `using namespace std;` leaves the programmer open to a name clash with a name from the standard library - concept - Ordered_container = Sequence && Random_access> && Ordered>; // don't define this: Sortable is in the GSL + #include + using namespace std; - void sort(Ordered_container& s); + int g(int x) + { + int sqrt = 7; + // ... + return sqrt(x); // error + } -This `Ordered_container` is quite plausible, but it is very similar to the `Sortable` concept in the GSL (and the Range TS). -Is it better? Is it right? Does it accurately reflect the standard's requirements for `sort`? -It is better and simpler just to use `Sortable`: +However, this is not particularly likely to lead to a resolution that is not an error and +people who use `using namespace std` are supposed to know about `std` and about this risk. - void sort(Sortable& s); // better +##### Note -**Note**: The set of "standard" concepts is evolving as we approaches real (ISO) standardization. +A `.cpp` file is a form of local scope. +There is little difference in the opportunities for name clashes in an N-line `.cpp` containing a `using namespace X`, +an N-line function containing a `using namespace X`, +and M functions each containing a `using namespace X`with N lines of code in total. -**Note**: Designing a useful concept is challenging. +##### Note -**Enforcement**: Hard. +[Don't write `using namespace` at global scope in a header file](#Rs-using-directive). -* Look for unconstrained arguments, templates that use "unusual"/non-standard concepts, templates that use "homebrew" concepts without axioms. -* Develop a concept-discovery tool (e.g., see [an early experiment](http://www.stroustrup.com/sle2010_webversion.pdf). +### SF.7: Don't write `using namespace` at global scope in a header file - - -### T.12: Prefer concept names over `auto` for local variables +##### Reason -**Reason**: `auto` is the weakest concept. Concept names convey more meaning than just `auto`. +Doing so takes away an `#include`r's ability to effectively disambiguate and to use alternatives. It also makes `#include`d headers order-dependent as they might have different meaning when included in different orders. -**Example**: +##### Example - vector v; - auto& x = v.front(); // bad - String& s = v.begin(); // good + // bad.h + #include + using namespace std; // bad -**Enforcement**: + // user.cpp + #include "bad.h" -* ??? + 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 + } - -### T.13: Prefer the shorthand notation for simple, single-type argument concepts +##### Note -**Reason**: Readability. Direct expression of an idea. +An exception is `using namespace std::literals;`. This is necessary to use string literals +in header files and given [the rules](http://eel.is/c++draft/over.literal) - users are required +to name their own UDLs `operator""_x` - they will not collide with the standard library. -**Example**: To say "`T` is `Sortable`": +##### Enforcement - template // Correct but verbose: "The parameter is - requires Sortable // of type T which is the name of a type - void sort(T&); // that is Sortable" +Flag `using namespace` at global scope in a header file. - template // Better: "The parameter is of type T - void sort(T&); // which is Sortable" +### SF.8: Use `#include` guards for all header files - void sort(Sortable&); // Best: "The parameter is Sortable" +##### Reason -The shorter versions better match the way we speak. Note that many templates don't need to use the `template` keyword. +To avoid files being `#include`d several times. -**Enforcement**: +In order to avoid include guard collisions, do not just name the guard after the filename. +Be sure to also include a key and good differentiator, such as the name of library or component +the header file is part of. -* Not feasible in the short term when people convert from the `` and ` notation. -* Later, flag declarations that first introduces a typename and then constrains it with a simple, single-type-argument concept. +##### Example + // file foobar.h: + #ifndef LIBRARY_FOOBAR_H + #define LIBRARY_FOOBAR_H + // ... declarations ... + #endif // LIBRARY_FOOBAR_H - -## T.con-def: Concept definition rules +##### Enforcement -??? +Flag `.h` files without `#include` guards. +##### Note - -### T.20: Avoid "concepts" without meaningful semantics +Some implementations offer vendor extensions like `#pragma once` as alternative to include guards. +It is not standard and it is not portable. It injects the hosting machine's filesystem semantics +into your program, in addition to locking you down to a vendor. +Our recommendation is to write in ISO C++: See [rule P.2](#Rp-Cplusplus). -**Reason**: Concepts are meant to express semantic notions, such as "a number", "a range" of elements, and "totally ordered." -Simple constraints, such as "has a `+` operator" and "has a `>` operator" cannot be meaningfully specified in isolation -and should be used only as building blocks for meaningful concepts, rather than in user code. +### SF.9: Avoid cyclic dependencies among source files -**Example, bad**: - - template - concept Addable = has_plus; // bad; insufficient - - template auto algo(const N& a, const N& b) // use two numbers - { - // ... - return a+b; - } - - int x = 7; - int y = 9; - auto z = plus(x,y); // z = 18 - - string xx = "7"; - string yy = "9"; - auto zz = plus(xx,yy); // zz = "79" +##### Reason -Maybe the concatenation was expected. More likely, it was an accident. Defining minus equivalently would give dramatically different sets of accepted types. -This `Addable` violates the mathematical rule that addition is supposed to be commutative: `a+b == b+a`, - -**Note**: The ability to specify a meaningful semantics is a defining characteristic of a true concept, as opposed to a syntactic constraint. - -**Example (using TS concepts)**: - - template - // The operators +, -, *, and / for a number are assumed to follow the usual mathematical rules - concept Number = has_plus - && has_minus - && has_multiply - && has_divide; - - template auto algo(const N& a, const N& b) // use two numbers - { - // ... - return a+b; - } - - int x = 7; - int y = 9; - auto z = plus(x,y); // z = 18 - - string xx = "7"; - string yy = "9"; - auto zz = plus(xx,yy); // error: string is not a Number - -**Note**: Concepts with multiple operations have far lower chance of accidentally matching a type than a single-operation concept. - -**Enforcement**: +Cycles complicate comprehension and slow down compilation. They also +complicate conversion to use language-supported modules (when they become +available). -* Flag single-operation `concepts` when used outside the definition of other `concepts`. -* Flag uses of `enable_if` that appears to simulate single-operation `concepts`. +##### Note +Eliminate cycles; don't just break them with `#include` guards. - -### T.21: Define concepts to define complete sets of operations +##### Example, bad -**Reason**: Improves interoperability. Helps implementers and maintainers. + // file1.h: + #include "file2.h" -**Example, bad**: + // file2.h: + #include "file3.h" - template Subtractable = requires(T a, T,b) { a-b; } // correct syntax? + // file3.h: + #include "file1.h" -This makes no semantic sense. You need at least `+` to make `-` meaningful and useful. +##### Enforcement -Examples of complete sets are +Flag all cycles. -* `Arithmetic`: `+`, `-`, `*`, `/`, `+=`, `-=`, `*=`, `/=` -* `Comparable`: `<`, `>`, `<=`, `>=`, `==`, `!=` -**Enforcement**: ??? +### SF.10: Avoid dependencies on implicitly `#include`d names +##### Reason - -### T.22: Specify axioms for concepts +Avoid surprises. +Avoid having to change `#include`s if an `#include`d header changes. +Avoid accidentally becoming dependent on implementation details and logically separate entities included in a header. -**Reason**: A meaningful/useful concept has a semantic meaning. -Expressing this semantics in a informal, semi-formal, or informal way makes the concept comprehensible to readers and the effort to express it can catch conceptual errors. -Specifying semantics is a powerful design tool. +##### Example, bad -**Example**: - - template - // The operators +, -, *, and / for a number are assumed to follow the usual mathematical rules - // axiom(T a, T b) { a+b == b+a; a-a == 0; a*(b+c)==a*b+a*c; /*...*/ } - concept Number = requires(T a, T b) { - {a+b} -> T; // the result of a+b is convertible to T - {a-b} -> T; - {a*b} -> T; - {a/b} -> T; - }; - -**Note** This is an axiom in the mathematical sense: something that may be assumed without proof. -In general, axioms are not provable, and when they are the proof is often beyond the capability of a compiler. -An axiom may not be general, but the template writer may assume that it holds for all inputs actually used (similar to a precondition). + #include + using namespace std; -**Note**: In this context axioms are Boolean expressions. -See the [Palo Alto TR](#S-references) for examples. -Currently, C++ does not support axioms (even the ISO Concepts TS), so we have to make do with comments for a longish while. -Once language support is available, the `//` in front of the axiom can be removed + void use() + { + string s; + cin >> s; // fine + getline(cin, s); // error: getline() not defined + if (s == "surprise") { // error == not defined + // ... + } + } -**Note**: The GSL concepts have well defined semantics; see the Palo Alto TR and the Ranges TS. +`` exposes the definition of `std::string` ("why?" makes for a fun trivia question), +but it is not required to do so by transitively including the entire `` header, +resulting in the popular beginner question "why doesn't `getline(cin,s);` work?" +or even an occasional "`string`s cannot be compared with `==`"). -**Exception**: Early versions of a new "concept" still under development will often just define simple sets of contraints without a well-specified semantics. -Finding good semantics can take effort and time. -An incomplete set of constraints can still be very useful: +The solution is to explicitly `#include `: - ??? binary tree: rotate(), ... - -A "concept" that is incomplete or without a well-specified semantics can still be useful. -However, it should not be assumed to be stable. Each new use case may require such an incomplete concepts to be improved. +##### Example, good -**Enforcement**: + #include + #include + using namespace std; -* Look for the word "axiom" in concept definition comments + void use() + { + string s; + cin >> s; // fine + getline(cin, s); // fine + if (s == "surprise") { // fine + // ... + } + } +##### Note - -### T.23: Differentiate a refined concept from its more general case by adding new use patterns. +Some headers exist exactly to collect a set of consistent declarations from a variety of headers. +For example: -**Reason**: Otherwise they cannot be distinguished automatically by the compiler. + // basic_std_lib.h: -**Example**: + #include + #include + #include + #include + #include - template - concept bool Input_iterator = requires (I iter) { ++iter; }; +a user can now get that set of declarations with a single `#include` - template - concept bool Fwd_iter = Input_iter && requires (I iter) { iter++; } + #include "basic_std_lib.h" -The compiler can determine refinement based on the sets of required operations. -If two concepts have exactly the same requirements, they are logically equivalent (there is no refinement). +This rule against implicit inclusion is not meant to prevent such deliberate aggregation. -This also decreases the burden on implementers of these types since -they do not need any special declarations to "hook into the concept". +##### Enforcement -**Enforcement**: -* Flag a concept that has exactly the same requirements as another already-seen concept (neither is more refined). To disambiguate them, see [T.24](#Rt-tag). +Enforcement would require some knowledge about what in a header is meant to be "exported" to users and what is there to enable implementation. +No really good solution is possible until we have modules. +### SF.11: Header files should be self-contained - -### T.24: Use tag classes or traits to differentiate concepts that differ only in semantics. +##### Reason -**Reason**: Two concepts requiring the same syntax but having different semantics leads to ambiguity unless the programmer differentiates them. +Usability, headers should be simple to use and work when included on their own. +Headers should encapsulate the functionality they provide. +Avoid clients of a header having to manage that header's dependencies. -**Example**: +##### Example - template // iterator providing random access - concept bool RA_iter = ...; + #include "helpers.h" + // helpers.h depends on std::string and includes - template // iterator providing random access to contiguous data - concept bool Contiguous_iter = - RA_iter && is_contiguous::value; // ??? why not is_contiguous() or is_contiguous_v? +##### Note -The programmer (in a library) must define `is_contiguous` (a trait) appropriately. +Failing to follow this results in difficult to diagnose errors for clients of a header. -**Note**: Traits can be trains classes or type traits. -These can be user-defined or standard-libray ones. -Prefer the standard-libray ones. +##### Note -**Enforcement**: +A header should include all its dependencies. Be careful about using relative paths because C++ implementations diverge on their meaning. -* The compiler flags ambiguous use of identical concepts. -* Flag the definition of identical concepts. +##### Enforcement +A test should verify that the header file itself compiles or that a cpp file which only includes the header file compiles. - -### T.25: Avoid negating constraints. +### SF.12: Prefer the quoted form of `#include` for files relative to the including file and the angle bracket form everywhere else -**Reason**: Clarity. Maintainability. -Functions with complementary requirements expressed using negation are brittle. +##### Reason -**Example**: Initially, people will try to define functions with complementary requirements: +The [standard](http://eel.is/c++draft/cpp.include) provides flexibility for compilers to implement +the two forms of `#include` selected using the angle (`<>`) or quoted (`""`) syntax. Vendors take +advantage of this and use different search algorithms and methods for specifying the include path. - template - requires !C // bad - void f(); +Nevertheless, the guidance is to use the quoted form for including files that exist at a relative path to the file containing the `#include` statement (from within the same component or project) and to use the angle bracket form everywhere else, where possible. This encourages being clear about the locality of the file relative to files that include it, or scenarios where the different search algorithm is required. It makes it easy to understand at a glance whether a header is being included from a local relative file versus a standard library header or a header from the alternate search path (e.g. a header from another library or a common set of includes). - template - requires C - void f(); +##### Example -This is better: + // foo.cpp: + #include // From the standard library, requires the <> form + #include // A file that is not locally relative, included from another library; use the <> form + #include "foo.h" // A file locally relative to foo.cpp in the same project, use the "" form + #include "util/util.h" // A file locally relative to foo.cpp in the same project, use the "" form + #include // A file in the same project located via a search path, use the <> form - template // general template - void f(); +##### Note - template // specialization by concept - requires C - void f(); +Failing to follow this results in difficult to diagnose errors due to picking up the wrong file by incorrectly specifying the scope when it is included. For example, in a typical case where the `#include ""` search algorithm might search for a file existing at a local relative path first, then using this form to refer to a file that is not locally relative could mean that if a file ever comes into existence at the local relative path (e.g. the including file is moved to a new location), it will now be found ahead of the previous include file and the set of includes will have been changed in an unexpected way. -The compiler will choose the unconstrained template only when `C` is -unsatisfied. If you do not want to (or cannot) define an unconstrained -version of `f()`, then delete it. +Library creators should put their headers in a folder and have clients include those files using the relative path `#include ` - template - void f() = delete; +##### Enforcement -The compiler will select the overload and emit an appropriate error. +A test should identify whether headers referenced via `""` could be referenced with `<>`. -**Enforcement**: -* Flag pairs of functions with `C` and `!C` constraints -* Flag all constraint negation +### SF.13: Use portable header identifiers in `#include` statements +##### Reason - -### T.27: Prefer to define concepts in terms of use-patterns rather than simple syntax +The [standard](http://eel.is/c++draft/cpp.include) does not specify how compilers uniquely locate headers from an identifier in an `#include` directive, nor does it specify what constitutes uniqueness. For example, whether the implementation considers the identifiers to be case-sensitive, or whether the identifiers are file system paths to a header file, and if so, how a hierarchical file system path is delimited. -**Reason**: The definition is more readable and corresponds directly to what a user has to write. -Conversions are taken into account. You don't have to remember the names of all the type traits. +To maximize the portability of `#include` directives across compilers, guidance is to: -**Example**: +* use case-sensitivity for the header identifier, matching how the header is defined by the standard, specification, implementation, or file that provides the header. +* when the header identifier is a hierarchical file path, use forward-slash `/` to delimit path components as this is the most widely-accepted path-delimiting character. - ??? +##### Example -**Enforcement**: ??? + // good examples + #include + #include + #include "util/util.h" + // bad examples + #include // bad: the standard library defines a header identified as , not + #include // bad: the standard library defines a header identified as , not + #include "Util/Util.H" // bad: the header file exists on the file system as "util/util.h" + #include "util\util.h" // bad: may not work if the implementation interprets `\u` as an escape sequence, or where '\' is not a valid path separator - -## Template interfaces +##### Enforcement -??? +It is only possible to enforce on implementations where header identifiers are case-sensitive and which only support `/` as a file path delimiter. - -### T.40: Use function objects to pass operations to algorithms +### SF.20: Use `namespace`s to express logical structure -**Reason**: Function objects can carry more information through an interface than a "plain" pointer to function. -In general, passing function objects give better performance than passing pointers to functions. +##### Reason -**Example**: + ??? - bool greater(double x, double y) { return x>y; } - sort(v,greater); // pointer to function: potentially slow - sort(v,[](double x, double y) { return x>y; }); // function object - sort(v,greater<>); // function object - - bool greater_than_7(double x) { return x>7; } - auto x = find(v,greater_than_7); // pointer to function: inflexible - auto y = find(v,[](double x) { return x>7; }); // function object: carries the needed data - auto y = find(v,Greater_than(7)); // function object: carries the needed data - - ??? these lambdas are crying out for auto parameters -- any objection to making the change? - -**Note**: Lambdas generate function objects. +##### Example -**Note**: The performance argument depends on compiler and optimizer technology. + ??? -**Enforcement**: +##### Enforcement -* Flag pointer to function template arguments. -* Flag pointers to functions passed as arguments to a template (risk of false positives). +??? +### SF.21: Don't use an unnamed (anonymous) namespace in a header - -### T.41: Require complete sets of operations for a concept +##### Reason -**Reason**: Ease of comprehension. -Improved interoperability. -Flexibility for template implementers. +It is almost always a bug to mention an unnamed namespace in a header file. -**Note**: The issue here is whether to require the minimal set of operations for a template argument -(e.g., `==` but not `!=` or `+` but not `+=`). -The rule supports the view that a concept should reflect a (mathematically) coherent set of operations. +##### Example -**Example**: + // file foo.h: + namespace + { + const double x = 1.234; // bad - ??? + double foo(double y) // bad + { + return y + x; + } + } -**Enforcement**: ??? + namespace Foo + { + const double x = 1.234; // good + inline double foo(double y) // good + { + return y + x; + } + } - -### T.42: Use template aliases to simplify notation and hide implementation details +##### Enforcement -**Reason**: Improved readability. Implementation hiding. Note that template aliases replace many uses of traits to compute a type. They can also be used to wrap a trait. +* Flag any use of an anonymous namespace in a header file. -**Example**: +### SF.22: Use an unnamed (anonymous) namespace for all internal/non-exported entities - template - class matrix { - // ... - using Iterator = typename std::vector::iterator; - // ... - }; +##### Reason -This saves the user of `Matrix` from having to know that its elements are stored in a `vector` and also saves the user from repeatedly typing `typename std::vector::`. +Nothing external can depend on an entity in a nested unnamed namespace. +Consider putting every definition in an implementation source file in an unnamed namespace unless that is defining an "external/exported" entity. -**Example**: +##### Example; bad - template - using Value_type = container_traits::value_type; + static int f(); + int g(); + static bool h(); + int k(); -This saves the user of `Value_type` from having to know the technique used to implement `value_type`s. +##### Example; good -**Enforcement**: + namespace { + int f(); + bool h(); + } + int g(); + int k(); -* Flag use of `typename` as a disambiguator outside `using` declarations. -* ??? +##### Example +An API class and its members can't live in an unnamed namespace; but any "helper" class or function that is defined in an implementation source file should be at an unnamed namespace scope. - -### T.43: Prefer `using` over `typedef` for defining aliases + ??? -**Reason**: Improved readability: With `using`, the new name comes first rather than being embedded somewhere in a declaration. -Generality: `using` can be used for template aliases, whereas `typedef`s can't easily be templates. -Uniformity: `using` is syntactically similar to `auto`. +##### Enforcement -**Example**: +* ??? - typedef int (*PFI)(int); // OK, but convoluted - - using PFI2 = int (*)(int); // OK, preferred - - template - typedef int (*PFT)(T); // error - - template - using PFT2 = int (*)(T); // OK +# SL: The Standard Library -**Enforcement**: +Using only the bare language, every task is tedious (in any language). +Using a suitable library any task can be reasonably simple. -* Flag uses of `typedef`. This will give a lot of "hits" :-( +The standard library has steadily grown over the years. +Its description in the standard is now larger than that of the language features. +So, it is likely that this library section of the guidelines will eventually grow in size to equal or exceed all the rest. +<< ??? We need another level of rule numbering ??? >> - -### T.44: Use function templates to deduce class template argument types (where feasible) +C++ Standard Library component summary: -**Reason**: Writing the template argument types explicitly can be tedious and unnecessarily verbose. +* [SL.con: Containers](#SS-con) +* [SL.str: String](#SS-string) +* [SL.io: Iostream](#SS-io) +* [SL.regex: Regex](#SS-regex) +* [SL.chrono: Time](#SS-chrono) +* [SL.C: The C Standard Library](#SS-clib) -**Example**: +Standard-library rule summary: - tuple t1 = {1,"Hamlet",3.14}; // explicit type - auto t2 = make_tuple(1,"Ophelia"s,3.14); // better; deduced type +* [SL.1: Use libraries wherever possible](#Rsl-lib) +* [SL.2: Prefer the standard library to other libraries](#Rsl-sl) +* [SL.3: Do not add non-standard entities to namespace `std`](#sl-std) +* [SL.4: Use the standard library in a type-safe manner](#sl-safe) +* ??? -Note the use of the `s` suffix to ensure that the string is a `std::string`, rather than a C-style string. +### SL.1: Use libraries wherever possible -**Note**: Since you can trivially write a `make_T` function, so could the compiler. Thus, `make_T` functions may become redundant in the future. +##### Reason -**Exception**: Sometimes there isn't a good way of getting the template arguments deduced and sometimes, you want to specify the arguments explicitly: +Save time. Don't re-invent the wheel. +Don't replicate the work of others. +Benefit from other people's work when they make improvements. +Help other people when you make improvements. - vector v = { 1, 2, 3, 7.9, 15.99 }; - list lst; +### SL.2: Prefer the standard library to other libraries -**Enforcement**: Flag uses where an explicitly specialized type exactly matches the types of the arguments used. +##### Reason +More people know the standard library. +It is more likely to be stable, well-maintained, and widely available than your own code or most other libraries. - -### T.46: Require template arguments to be at least `Regular` or `SemiRegular` +### SL.3: Do not add non-standard entities to namespace `std` -**Reason**: ??? +##### Reason -**Example**: +Adding to `std` might change the meaning of otherwise standards conforming code. +Additions to `std` might clash with future versions of the standard. - ??? +##### Example -**Enforcement**: ??? + namespace std { // BAD: violates standard + class My_vector { + // . . . + }; - -### T.47: Avoid highly visible unconstrained templates with common names + } -**Reason**: ??? + namespace Foo { // GOOD: user namespace is allowed -**Example**: + class My_vector { + // . . . + }; - ??? + } -**Enforcement**: ??? +##### Enforcement - -### T.48: If your compiler does not support concepts, fake them with `enable_if` +Possible, but messy and likely to cause problems with platforms. -**Reason**: ??? +### SL.4: Use the standard library in a type-safe manner -**Example**: +##### Reason - ??? +Because, obviously, breaking this rule can lead to undefined behavior, memory corruption, and all kinds of other bad errors. -**Enforcement**: ??? +##### Note +This is a semi-philosophical meta-rule, which needs many supporting concrete rules. +We need it as an umbrella for the more specific rules. - -### T.49: Where possible, avoid type-erasure +Summary of more specific rules: -**Reason**: Type erasure incurs an extra level of indirection by hiding type information behind a separate compilation boundary. +* [SL.4: Use the standard library in a type-safe manner](#sl-safe) -**Example**: - ??? +## SL.con: Containers -**Exceptions**: Type erasure is sometimes appropriate, such as for `std::function`. +??? -**Enforcement**: ??? +Container rule summary: +* [SL.con.1: Prefer using STL `array` or `vector` instead of a C array](#Rsl-arrays) +* [SL.con.2: Prefer using STL `vector` by default unless you have a reason to use a different container](#Rsl-vector) +* [SL.con.3: Avoid bounds errors](#Rsl-bounds) +* [SL.con.4: don't use `memset` or `memcpy` for arguments that are not trivially-copyable](#Rsl-copy) - -### T.50: Avoid writing an unconstrained template in the same namespace as a type +### SL.con.1: Prefer using STL `array` or `vector` instead of a C array -**Reason**: ADL will find the template even when you think it shouldn't. +##### Reason -**Example**: +C arrays are less safe, and have no advantages over `array` and `vector`. +For a fixed-length array, use `std::array`, which does not degenerate to a pointer when passed to a function and does know its size. +Also, like a built-in array, a stack-allocated `std::array` keeps its elements on the stack. +For a variable-length array, use `std::vector`, which additionally can change its size and handles memory allocation. - ??? +##### Example -**Note**: This rule should not be necessary; the committee cannot agree on how to fix ADL, but at least making it not consider unconstrained templates would solve many of the actual problems and remove the need for this rule. + int v[SIZE]; // BAD -**Enforcement**: ??? unfortunately this will get many false positives; the standard library violates this widely, by putting many unconstrained templates and types into the single namespace `std` + std::array w; // ok +##### Example + int* v = new int[initial_size]; // BAD, owning raw pointer + delete[] v; // BAD, manual delete - -## TCP.def: Template definitions + std::vector w(initial_size); // ok -??? +##### Note +Use `gsl::span` for non-owning references into a container. - -### T.60: Minimize a template's context dependencies +##### Note -**Reason**: Eases understanding. Minimizes errors from unexpected dependencies. Eases tool creation. +Comparing the performance of a fixed-sized array allocated on the stack against a `vector` with its elements on the free store is bogus. +You could just as well compare a `std::array` on the stack against the result of a `malloc()` accessed through a pointer. +For most code, even the difference between stack allocation and free-store allocation doesn't matter, but the convenience and safety of `vector` does. +People working with code for which that difference matters are quite capable of choosing between `array` and `vector`. -**Example**: +##### Enforcement - ??? - -**Note**: Having a template operate only on its arguments would be one way of reducing the number of dependencies to a minimum, -but that would generally be unmaneageable. For example, an algorithm usually uses other algorithms. +* Flag declaration of a C array inside a function or class that also declares an STL container (to avoid excessive noisy warnings on legacy non-STL code). To fix: At least change the C array to a `std::array`. -**Enforcement**: ??? Tricky +### SL.con.2: Prefer using STL `vector` by default unless you have a reason to use a different container +##### Reason - -### T.61: Do not over-parameterize members (SCARY) +`vector` and `array` are the only standard containers that offer the following advantages: -**Reason**: A member that does not depend on a template parameter cannot be used except for a specific template argument. -This limits use and typically increases code size. +* the fastest general-purpose access (random access, including being vectorization-friendly); +* the fastest default access pattern (begin-to-end or end-to-begin is prefetcher-friendly); +* the lowest space overhead (contiguous layout has zero per-element overhead, which is cache-friendly). -**Example, bad**: - - template - // requires Regular && Allocator - class List { - public: - struct Link { // does not depend on A - T elem; - T* pre; - T* suc; - }; - - using iterator = Link*; - - iterator first() const { return head; } - - // ... - private: - Node* head; - }; - - - List lst1; - List lst2; - - ??? - -This looks innocent enough, but ??? - - template - struct Link { - T elem; - T* pre; - T* suc; - }; - - template - // requires Regular && Allocator - class List2 { - public: - - using iterator = Link*; - - iterator first() const { return head; } - - // ... - private: - Node* head; - }; - - List lst1; - List lst2; - - ??? - -**Enforcement**: - -* Flag member types that do not depend on every template argument -* Flag member functions that do not depend on every template argument - - - -### T.62: Place non-dependent template members in a non-templated base class - -**Reason**: ??? - -**Example**: - - template - class Foo { - public: - enum { v1, v2 }; - // ... - }; - -??? +Usually you need to add and remove elements from the container, so use `vector` by default; if you don't need to modify the container's size, use `array`. - struct Foo_base { - enum { v1, v2 }; - // ... - }; - - template - class Foo : public Foo_base { - public: - // ... - }; - -**Note**: A more general version of this rule would be -"If a template class member depends on only N template parameters out of M, place it in a base class with only N parameters." -For N==1, we have a choice of a base class of a class in the surrounding scope as in [T.41](#Rt-scary). +Even when other containers seem more suited, such as `map` for O(log N) lookup performance or a `list` for efficient insertion in the middle, a `vector` will usually still perform better for containers up to a few KB in size. -??? What about constants? class statics? +##### Note -**Enforcement**: +`string` should not be used as a container of individual characters. A `string` is a textual string; if you want a container of characters, use `vector` or `array` instead. -* Flag ??? +##### Exceptions +If you have a good reason to use another container, use that instead. For example: - -### T.64: Use specialization to provide alternative implementations of class templates +* If `vector` suits your needs but you don't need the container to be variable size, use `array` instead. -**Reason**: A template defines a general interface. -Specialization offers a powerful mechanism for providing alternative implementations of that interface. +* If you want a dictionary-style lookup container that guarantees O(K) or O(log N) lookups, the container will be larger (more than a few KB) and you perform frequent inserts so that the overhead of maintaining a sorted `vector` is infeasible, go ahead and use an `unordered_map` or `map` instead. -**Example**: +##### Note - ??? string specialization (==) - - ??? representation specialization ? - -**Note**: ??? +To initialize a vector with a number of elements, use `()`-initialization. +To initialize a vector with a list of elements, use `{}`-initialization. -**Enforcement**: ??? + vector v1(20); // v1 has 20 elements with the value 0 (vector{}) + vector v2 {20}; // v2 has 1 element with the value 20 +[Prefer the {}-initializer syntax](#Res-list). - -### T.65: Use tag dispatch to provide alternative implementations of a function +##### Enforcement -**Reason**: A template defines a general interface. ??? +* Flag a `vector` whose size never changes after construction (such as because it's `const` or because no non-`const` functions are called on it). To fix: Use an `array` instead. -**Example**: +### SL.con.3: Avoid bounds errors - ??? that's how we get algorithms like `std::copy` which compiles into a `memmove` call if appropriate for the arguments. +##### Reason -**Note**: When `concept`s become available such alternatives can be distinguished directly. +Read or write beyond an allocated range of elements typically leads to bad errors, wrong results, crashes, and security violations. -**Enforcement**: ??? +##### Note +The standard-library functions that apply to ranges of elements all have (or could have) bounds-safe overloads that take `span`. +Standard types such as `vector` can be modified to perform bounds-checks under the bounds profile (in a compatible way, such as by adding contracts), or used with `at()`. - -### T.66: Use selection using `enable_if` to optionally define a function +Ideally, the in-bounds guarantee should be statically enforced. +For example: -**Reason**: ??? +* a range-`for` cannot loop beyond the range of the container to which it is applied +* a `v.begin(),v.end()` is easily determined to be bounds safe -**Example**: +Such loops are as fast as any unchecked/unsafe equivalent. - ??? +Often a simple pre-check can eliminate the need for checking of individual indices. +For example -**Enforcement**: ??? +* for `v.begin(),v.begin()+i` the `i` can easily be checked against `v.size()` +Such loops can be much faster than individually checked element accesses. - -### T.69: Inside a template, don't make an unqualified nonmember function call unless you intend it to be a customization point +##### Example, bad -**Reason**: To provide only intended flexibility, and avoid accidental environmental changes. + void f() + { + array a, b; + memset(a.data(), 0, 10); // BAD, and contains a length error (length = 10 * sizeof(int)) + memcmp(a.data(), b.data(), 10); // BAD, and contains a length error (length = 10 * sizeof(int)) + } -If you intend to call your own helper function `helper(t)` with a value `t` that depends on a template type parameter, put it in a `::detail` namespace and qualify the call as `detail::helper(t);`. Otherwise the call becomes a customization point where any function `helper` in the namespace of `t`'s type can be invoked instead -- falling into the second option below, and resulting in problems like [unintentionally invoking unconstrained function templates of that name that happen to be in the same namespace as `t`'s type](#Rt-unconstrained-adl). +Also, `std::array<>::fill()` or `std::fill()` or even an empty initializer are better candidates than `memset()`. -There are three major ways to let calling code customize a template. +##### Example, good -* Call a member function. Callers can provide any type with such a named member function. + void f() + { + array a, b, c{}; // c is initialized to zero + a.fill(0); + fill(b.begin(), b.end(), 0); // std::fill() + fill(b, 0); // std::ranges::fill() + + if ( a == b ) { + // ... + } + } - template - void test(T t) { - t.f(); // require T to provide f() - } +##### Example -* Call a nonmember function without qualification. Callers can provide any type for which there is such a function available in the caller's context or in the namespace of the type. +If code is using an unmodified standard library, then there are still workarounds that enable use of `std::array` and `std::vector` in a bounds-safe manner. Code can call the `.at()` member function on each class, which will result in an `std::out_of_range` exception being thrown. Alternatively, code can call the `at()` free function, which will result in fail-fast (or a customized action) on a bounds violation. - template - void test(T t) { - f(t); // require f(/*T*/) be available in caller's cope or in T's namespace - } - -* Invoke a "trait" -- usually a type alias to compute a type, or a `constexpr` function to compute a value, or in rarer cases a traditional traits template to be specialized on the user's type. + void f(std::vector& v, std::array a, int i) + { + v[0] = a[0]; // BAD + v.at(0) = a[0]; // OK (alternative 1) + at(v, 0) = a[0]; // OK (alternative 2) - template - void test(T t) { - test_traits::f(t); // require customizing test_traits<> to get non-default functions/types - test_traits::value_type x; - } + v.at(0) = a[i]; // BAD + v.at(0) = a.at(i); // OK (alternative 1) + v.at(0) = at(a, i); // OK (alternative 2) + } -**Enforcement**: -* In a template, flag an unqualified call to a nonmember function that passes a variable of dependent type when there is a nonmember function of the same name in the template's namespace. +##### Enforcement +* Issue a diagnostic for any call to a standard-library function that is not bounds-checked. +??? insert link to a list of banned functions - -## T.temp-hier: Template and hierarchy rules: +This rule is part of the [bounds profile](#SS-bounds). -Templates are the backbone of C++'s support for generic programming and class hierarchies the backbone of its support -for object-oriented programming. -The two language mechanisms can be use effectively in combination, but a few design pitfalls must be avoided. - - - -### T.80: Do not naively templatize a class hierarchy - -**Reason**: Templatizing a class hierarchy that has many functions, especially many virtual functions, can lead to code bloat. - -**Example, bad**: - - template - struct Container { // an interface - virtual T* get(int i); - virtual T* first(); - virtial T* next(); - virtual void sort(); - }; - - template - class Vector : public Container { - public: - // ... - }; - - Vector vi; - Vector vs; - -It is probably a dumb idea to define a `sort` as a member function of a container, -but it is not unheard of and it makes a good example of what not to do. - -Given this, the compiler cannot know if `Vector::sort()` is called, so it must generate code for it. -Similar for `Vector::sort()`. -Unless those two functions are called that's code bloat. -Imagine what this would do to a class hierarchy with dozens of member functions and dozens of derived classes with many instantiations. -**Note**: In many cases you can provide a stable interface by not parameterizing a base; see [???](#Rt-abi). +### SL.con.4: don't use `memset` or `memcpy` for arguments that are not trivially-copyable -**Enforcement**: +##### Reason -* Flag virtual functions that depend on a template argument. ??? False positives +Doing so messes the semantics of the objects (e.g., by overwriting a `vptr`). +##### Note - -### T.81: Do not mix hierarchies and arrays +Similarly for (w)memset, (w)memcpy, (w)memmove, and (w)memcmp -**Reason**: An array of derived classes can implicitly "decay" to a pointer to a base class with potential disastrous results. +##### Example -**Example**: Assume that `Apple` and `Pear` are two kinds of `Fruit`s. + struct base { + virtual void update() = 0; + }; - void maul(Fruit* p) - { - *p = Pear{}; // put a Pear into *p - p[1] = Pear{}; // put a Pear into p[2] - } - - Apple aa [] = { an_apple, another_apple }; // aa contains Apples (obviously!) - - maul(aa); - Apple& a0 = &aa[0]; // a Pear? - Apple& a1 = &aa[1]; // a Pear? + struct derived : public base { + void update() override {} + }; -Probably, `aa[0]` will be a `Pear` (without the use af a cast!). -If `sizeof(Apple)!=sizeof(Pear)` the access to `aa[1]` will not be aligned to the proper start of an object in the array. -We have a type violation and possibly (probably) a memory corruption. -Never write such code. -Note that `maul()` violates the a `T*` points to an individual object [Rule](#???). + void f(derived& a, derived& b) // goodbye v-tables + { + memset(&a, 0, sizeof(derived)); + memcpy(&a, &b, sizeof(derived)); + memcmp(&a, &b, sizeof(derived)); + } -**Alternative**: Use a proper container: +Instead, define proper default initialization, copy, and comparison functions - void maul2(Fruit* p) - { - *p = Pear{}; // put a Pear into *p - } - - vector va = { an_apple, another_apple }; // aa contains Apples (obviously!) - - maul2(aa); // error: cannot convert a vector to a Fruit* - maul2(&aa[0]); // you asked for it - - Apple& a0 = &aa[0]; // a Pear? + void g(derived& a, derived& b) + { + a = {}; // default initialize + b = a; // copy + if (a == b) do_something(a, b); + } -Note that the assignment in `maul2()` violated the no-slicing [Rule](#???). +##### Enforcement -**Enforcement**: +* Flag the use of those functions for types that are not trivially copyable -* Detect this horror! +**TODO Notes**: +* Impact on the standard library will require close coordination with WG21, if only to ensure compatibility even if never standardized. +* We are considering specifying bounds-safe overloads for stdlib (especially C stdlib) functions like `memcmp` and shipping them in the GSL. +* For existing stdlib functions and types like `vector` that are not fully bounds-checked, the goal is for these features to be bounds-checked when called from code with the bounds profile on, and unchecked when called from legacy code, possibly using contracts (concurrently being proposed by several WG21 members). - -### T.82: Linearize a hierarchy when virtual functions are undesirable -**Reason**: ??? -**Example**: +## SL.str: String - ??? +Text manipulation is a huge topic. +`std::string` doesn't cover all of it. +This section primarily tries to clarify `std::string`'s relation to `char*`, `zstring`, `string_view`, and `gsl::span`. +The important issue of non-ASCII character sets and encodings (e.g., `wchar_t`, Unicode, and UTF-8) will be covered elsewhere. -**Enforcement**: ??? +**See also**: [regular expressions](#SS-regex) +Here, we use "sequence of characters" or "string" to refer to a sequence of characters meant to be read as text (somehow, eventually). +We don't consider ??? - -### T.83: Do not declare a member function template virtual +String summary: -**Reason** C++ does not support that. -If it did, vtbls could not be generated until link time. -And in general, implementations must deal with dynamic linking. +* [SL.str.1: Use `std::string` to own character sequences](#Rstr-string) +* [SL.str.2: Use `std::string_view` or `gsl::span` to refer to character sequences](#Rstr-view) +* [SL.str.3: Use `zstring` or `czstring` to refer to a C-style, zero-terminated, sequence of characters](#Rstr-zstring) +* [SL.str.4: Use `char*` to refer to a single character](#Rstr-char*) +* [SL.str.5: Use `std::byte` to refer to byte values that do not necessarily represent characters](#Rstr-byte) -**Example; don't**: - - class Shape { - // ... - template - virtual bool intersect(T* p); // error: template cannot be virtual - }; - -**Alternative**: ??? double dispatch, visitor, calculate which function to call - -**Enforcement**: The compiler handles that. - - - - -### T.84: Use a non-template core implementation to provide an ABI-stable interface - -**Reason**: Improve stability of code. Avoids code bloat. - -**Example**: It could be a base class: - - struct Link_base { // stable - Link* suc; - Link* pre; - }; - - template // templated wrapper to add type safety - struct Link : Link_base { - T val; - }; - - struct List_base { - Link_base* first; // first element (if any) - int sz; // number of elements - void add_front(Link_base* p); - // ... - }; - - template - class List : List_base { - public: - void put_front(const T& e) { add_front(new Link{e}); } // implicit cast to Link_base - T& front() { static_cast*>(first).val; } // explicit cast back to Link - // ... - }; - - List li; - List ls; +* [SL.str.10: Use `std::string` when you need to perform locale-sensitive string operations](#Rstr-locale) +* [SL.str.11: Use `gsl::span` rather than `std::string_view` when you need to mutate a string](#Rstr-span) +* [SL.str.12: Use the `s` suffix for string literals meant to be standard-library `string`s](#Rstr-s) -Now there is only one copy of the operations linking and unlinking elements of a `List`. -The `Link` and `List` classes does nothing but type manipulation. +**See also**: -Instead of using a separate "base" type, another common technique is to specialize for `void` or `void*` and have the general template for `T` be just the safely-encapsulated casts to and from the core `void` implementation. - -**Alternative**: Use a [PIMPL](#???) implementation. +* [F.24 span](#Rf-range) +* [F.25 zstring](#Rf-zstring) -**Enforcement**: ??? +### SL.str.1: Use `std::string` to own character sequences - -## T.var: Variadic template rules +##### Reason -??? +`string` correctly handles allocation, ownership, copying, gradual expansion, and offers a variety of useful operations. +##### Example - -### T.100: Use variadic templates when you need a function that takes a variable number of arguments of a variety of types + vector read_until(const string& terminator) + { + vector res; + for (string s; cin >> s && s != terminator; ) // read a word + res.push_back(s); + return res; + } -**Reason**: Variadic templates is the most general mechanism for that, and is both efficient and type-safe. Don't use C varargs. +Note how `>>` and `!=` are provided for `string` (as examples of useful operations) and there are no explicit +allocations, deallocations, or range checks (`string` takes care of those). -**Example**: +In C++17, we might use `string_view` as the argument, rather than `const string&` to allow more flexibility to callers: - ??? printf + vector read_until(string_view terminator) // C++17 + { + vector res; + for (string s; cin >> s && s != terminator; ) // read a word + res.push_back(s); + return res; + } -**Enforcement**: +##### Example, bad - * Flag uses of `va_arg` in user code. +Don't use C-style strings for operations that require non-trivial memory management + char* cat(const char* s1, const char* s2) // beware! + // return s1 + '.' + s2 + { + int l1 = strlen(s1); + int l2 = strlen(s2); + char* p = (char*) malloc(l1 + l2 + 2); + strcpy(p, s1, l1); + p[l1] = '.'; + strcpy(p + l1 + 1, s2, l2); + p[l1 + l2 + 1] = 0; + return p; + } - -### T.101: ??? How to pass arguments to a variadic template ??? +Did we get that right? +Will the caller remember to `free()` the returned pointer? +Will this code pass a security review? -**Reason**: ??? +##### Note -**Example**: +Do not assume that `string` is slower than lower-level techniques without measurement and remember that not all code is performance critical. +[Don't optimize prematurely](#Rper-Knuth) - ??? beware of move-only and reference arguments +##### Enforcement -**Enforcement**: ??? +??? +### SL.str.2: Use `std::string_view` or `gsl::span` to refer to character sequences - -### T.102: How to process arguments to a variadic template +##### Reason -**Reason**: ??? +`std::string_view` or `gsl::span` provides simple and (potentially) safe access to character sequences independently of how +those sequences are allocated and stored. -**Example**: +##### Example - ??? forwarding, type checking, references + vector read_until(string_view terminator); -**Enforcement**: ??? + void user(zstring p, const string& s, string_view ss) + { + auto v1 = read_until(p); + auto v2 = read_until(s); + auto v3 = read_until(ss); + // ... + } +##### Note - -### T.103: Don't use variadic templates for homogeneous argument lists +`std::string_view` (C++17) is read-only. -**Reason** There are more precise ways of specifying a homogeneous sequence, such as an `initializer_list`. +##### Enforcement -**Example**: +??? - ??? +### SL.str.3: Use `zstring` or `czstring` to refer to a C-style, zero-terminated, sequence of characters -**Enforcement**: ??? +##### Reason +Readability. +Statement of intent. +A plain `char*` can be a pointer to a single character, a pointer to an array of characters, a pointer to a C-style (zero-terminated) string, or even to a small integer. +Distinguishing these alternatives prevents misunderstandings and bugs. - -## T.meta: Template metaprogramming (TMP) +##### Example -Templates provide a general mechanism for compile-time programming. + void f1(const char* s); // s is probably a string -Metaprogramming is programming where at least one input or one result is a type. -Templates offer Turing-complete (modulo memory capacity) duck typing at compile time. -The syntax and techniques needed are pretty horrendous. +All we know is that it is supposed to be the nullptr or point to at least one character + void f1(zstring s); // s is a C-style string or the nullptr + void f1(czstring s); // s is a C-style string constant or the nullptr + void f1(std::byte* s); // s is a pointer to a byte (C++17) - -### T.120: Use template metaprogramming only when you really need to +##### Note -**Reason**: Template metaprogramming is hard to get right, slows down compilation, and is often very hard to maintain. -However, there are real-world examples where template metaprogramming provides better performance that any alternative short of expert-level assembly code. -Also, there are real-world examples where template metaprogramming expresses the fundamental ideas better than run-time code. -For example, if you really need AST manipulation at compile time (e.g., for optional matrix operation folding) there may be no other way in C++. +Don't convert a C-style string to `string` unless there is a reason to. -**Example, bad**: +##### Note - ??? - -**Example, bad**: +Like any other "plain pointer", a `zstring` should not represent ownership. - enable_if +##### Note -Instead, use concepts. But see [How to emulate concepts if you don't have language support]("#Rt-emulate"). +There are billions of lines of C++ "out there", most use `char*` and `const char*` without documenting intent. +They are used in a wide variety of ways, including to represent ownership and as generic pointers to memory (instead of `void*`). +It is hard to separate these uses, so this guideline is hard to follow. +This is one of the major sources of bugs in C and C++ programs, so it is worthwhile to follow this guideline wherever feasible. -**Example**: +##### Enforcement - ??? good +* Flag uses of `[]` on a `char*` +* Flag uses of `delete` on a `char*` +* Flag uses of `free()` on a `char*` -**Alternative**: If the result is a value, rather than a type, use a [`constexpr` function](#Rt-fct). +### SL.str.4: Use `char*` to refer to a single character -**Note**: If you feel the need to hide your template metaprogramming in macros, you have probably gone too far. +##### Reason +The variety of uses of `char*` in current code is a major source of errors. - -### T.121: Use template metaprogramming primarily to emulate concepts +##### Example, bad -**Reason**: Until concepts become generally available, we need to emulate them using TMP. -Use cases that require concepts (e.g. overloading based on concepts) are among the most common (and simple) uses of TMP. + char arr[] = {'a', 'b', 'c'}; -**Example**: + void print(const char* p) + { + cout << p << '\n'; + } - template - /*requires*/ enable_if,void> - advance(Iter p, int n) { p += n; } + void use() + { + print(arr); // run-time error; potentially very bad + } - template - /*requires*/ enable_if,void> - advance(Iter p, int n) { assert(n>=0); while (n--) ++p;} - -**Note**: Such code is much simpler using concepts: +The array `arr` is not a C-style string because it is not zero-terminated. - void advance(RandomAccessIterator p, int n) { p += n; } +##### Alternative - void advance(ForwardIterator p, int n) { assert(n>=0); while (n--) ++p;} +See [`zstring`](#Rstr-zstring), [`string`](#Rstr-string), and [`string_view`](#Rstr-view). -**Enforcement**: ??? +##### Enforcement +* Flag uses of `[]` on a `char*` - -### T.122: Use templates (usually template aliases) to compute types at compile time +### SL.str.5: Use `std::byte` to refer to byte values that do not necessarily represent characters -**Reason**: Template metaprogramming is the only directly supported and half-way principled way of generating types at compile time. +##### Reason -**Note**: "Traits" techniques are mostly replaced by template aliases to compute types and `constexpr` functions to compute values. +Use of `char*` to represent a pointer to something that is not necessarily a character causes confusion +and disables valuable optimizations. -**Example**: +##### Example - ??? big object / small object optimization + ??? -**Enforcement**: ??? +##### Note +C++17 - -### T.123: Use `constexpr` functions to compute values at compile time +##### Enforcement -**Reason**: A function is the most obvious and conventional way of expressing the computation of a value. -Often a `constexpr` function implies less compile-time overhead than alternatives. +??? -**Note**: "Traits" techniques are mostly replaced by template aliases to compute types and `constexpr` functions to compute values. -**Example**: +### SL.str.10: Use `std::string` when you need to perform locale-sensitive string operations - template - // requires Number - constexpr T pow(T v, int n) // power/exponential - { - T res = 1; - while (n--) res *= v; - return res; - } - - constexpr auto f7 = pow(pi,7); +##### Reason -**Enforcement**: +`std::string` supports standard-library [`locale` facilities](#Rstr-locale) - * Flag template metaprograms yielding a value. These should be replaced with `constexpr` functions. +##### Example + ??? - -### T.124: Prefer to use standard-library TMP facilities +##### Note -**Reason**: Facilities defined in the standard, such as `conditional`, `enable_if`, and `tuple`, are portable and can be assumed to be known. +??? -**Example**: +##### Enforcement - ??? +??? -**Enforcement**: ??? +### SL.str.11: Use `gsl::span` rather than `std::string_view` when you need to mutate a string +##### Reason - -### T.125: If you need to go beyond the standard-library TMP facilities, use an existing library +`std::string_view` is read-only. -**Reason**: Getting advanced TMP facilities is not easy and using a library makes you part of a (hopefully supportive) community. -Write your own "advanced TMP support" only if you really have to. +##### Example -**Example**: +??? - ??? +##### Note -**Enforcement**: ??? +??? +##### Enforcement - -## Other template rules +The compiler will flag attempts to write to a `string_view`. +### SL.str.12: Use the `s` suffix for string literals meant to be standard-library `string`s - -### T.140: Name all nontrivial operations +##### Reason -**Reason**: Documentation, readability, opportunity for reuse. +Direct expression of an idea minimizes mistakes. -**Example**: +##### Example - ??? - -**Example; good**: + auto pp1 = make_pair("Tokyo", 9.00); // {C-style string,double} intended? + pair pp2 = {"Tokyo", 9.00}; // a bit verbose + auto pp3 = make_pair("Tokyo"s, 9.00); // {std::string,double} // C++14 + pair pp4 = {"Tokyo"s, 9.00}; // {std::string,double} // C++17 - ??? -**Note**: whether functions, lambdas, or operators. -**Exceptions**: +##### Enforcement -* Lambdas logically used only locally, such as an argument to `for_each` and similar control flow algorithms. -* Lambdas as [initializers](#???) +??? -**Enforcement**: ??? +## SL.io: Iostream - -### T.141: Use an unnamed lambda if you need a simple function object in one place only +`iostream`s is a type safe, extensible, formatted and unformatted I/O library for streaming I/O. +It supports multiple (and user extensible) buffering strategies and multiple locales. +It can be used for conventional I/O, reading and writing to memory (string streams), +and user-defined extensions, such as streaming across networks (asio: not yet standardized). -**Reason**: That makes the code concise and gives better locality than alternatives. +Iostream rule summary: -**Example**: +* [SL.io.1: Use character-level input only when you have to](#Rio-low) +* [SL.io.2: When reading, always consider ill-formed input](#Rio-validate) +* [SL.io.3: Prefer iostreams for I/O](#Rio-streams) +* [SL.io.10: Unless you use `printf`-family functions call `ios_base::sync_with_stdio(false)`](#Rio-sync) +* [SL.io.50: Avoid `endl`](#Rio-endl) +* [???](#???) - ??? for-loop equivalent +### SL.io.1: Use character-level input only when you have to -**Exception**: Naming a lambda can be useful for clarity even if it is used only once +##### Reason -**Enforcement**: +Unless you genuinely just deal with individual characters, using character-level input leads to the user code performing potentially error-prone +and potentially inefficient composition of tokens out of characters. -* Look for identical and near identical lambdas (to be replaced with named functions or named lambdas). +##### Example + char c; + char buf[128]; + int i = 0; + while (cin.get(c) && !isspace(c) && i < 128) + buf[i++] = c; + if (i == 128) { + // ... handle too long string .... + } - -### T.142?: Use template variables to simplify notation - -**Reason**: Improved readability. - -**Example**: - - ??? - -**Enforcement**: ??? - - - -### T.143: Don't write unintentionally nongeneric code - -**Reason**: Generality. Reusability. Don't gratuitously commit to details; use the most general facilities available. - -**Example**: Use `!=` instead of `<` to compare iterators; `!=` works for more objects because it doesn't rely on ordering. - - for(auto i = first; i < last; ++i) { // less generic - // ... - } - - for(auto i = first; i != last; ++i) { // good; more generic - // ... - } - -Of course, range-for is better still where it does what you want. - -**Example**: Use the least-derived class that has the functionality you need. - - class base { - public: - void f(); - void g(); - }; - - class derived1 : public base { - public: - void h(); - }; - - class derived2 : public base { - public: - void j(); - }; - - void myfunc(derived& param) { // bad, unless there is a specific reason for limiting to derived1 objects only - use(param.f()); - use(param.g()); - } - - void myfunc(base& param) { // good, uses only base interface so only commit to that - use(param.f()); - use(param.g()); - } - -**Enforcement**: -* Flag comparison of iterators using `<` instead of `!=`. -* Flag `x.size() == 0` when `x.empty()` or `x.is_empty()` is available. Emptiness works for more containers than size(), because some containers don't know their size or are conceptually of unbounded size. -* Flag functions that take a pointer or reference to a more-derived type but only use functions declared in a base type. +Better (much simpler and probably faster): + string s; + s.reserve(128); + cin >> s; - -### T.144: Don't specialize function templates +and the `reserve(128)` is probably not worthwhile. -**Reason**: You can't partially specialize a function template per language rules. You can fully specialize a function template but you almost certainly want to overload instead -- because function template specializations don't participate in overloading, they don't act as you probably wanted. Rarely, you should actually specialize by delegating to a class template that you can specialize properly. +##### Enforcement -**Example**: - - ??? +??? -**Exceptions**: If you do have a valid reason to specialize a function template, just write a single function template that delegates to a class template, then specialize the class template (including the ability to write partial specializations). - -**Enforcement**: -* Flag all specializations of a function template. Overload instead. +### SL.io.2: When reading, always consider ill-formed input +##### Reason +Errors are typically best handled as soon as possible. +If input isn't validated, every function must be written to cope with bad data (and that is not practical). +##### Example - -# CPL: C-style programming + ??? -C and C++ are closely related languages. -They both originate in "Classic C" from 1978 and have evolved in ISO committees since then. -Many attempts have been made to keep them compatible, but neither is a subset of the other. +##### Enforcement -C rule summary: +??? -* [CPL.1: Prefer C++ to C](Rcpl-C) -* [CPL.2: If you must use C, use the common subset of C and C++, and compile the C code as C++](#Rcpl-subset) -* [CPL.3: If you must use C for interfaces, use C++ in the code using such interfaces](#Rcpl-interface) +### SL.io.3: Prefer `iostream`s for I/O +##### Reason - -### CPL.1: Prefer C++ to C +`iostream`s are safe, flexible, and extensible. -**Reason**: C++ provides better type checking and more notational support. -It provides better support for high-level programming and often generates faster code. +##### Example -**Example**: + // write a complex number: + complex z{ 3, 4 }; + cout << z << '\n'; - char ch = 7; - void* pv = &ch; - int* pi = pv; // not C++ - *pi = 999; // overwrite sizeof(int) bytes near &ch +`complex` is a user-defined type and its I/O is defined without modifying the `iostream` library. -**Enforcement**: Use a C++ compiler. +##### Example + // read a file of complex numbers: + for (complex z; cin >> z; ) + v.push_back(z); - -### CPL.2: If you must use C, use the common subset of C and C++, and compile the C code as C++ +##### Exception -**Reason**: That subset can be compiled with both C and C++ compilers, and when compiled as C++ is better type checked than "pure C." +??? performance ??? -**Example**: +##### Discussion: `iostream`s vs. the `printf()` family - int* p1 = malloc(10*sizeof(int)); // not C++ - int* p2 = static_cast(malloc(10*sizeof(int))); // not C, C-style C++ - int* p3 = new int[10]; // not C - int* p4 = (int*)malloc(10*sizeof(int)); // both C and C++ +It is often (and often correctly) pointed out that the `printf()` family has two advantages compared to `iostream`s: +flexibility of formatting and performance. +This has to be weighed against `iostream`s advantages of extensibility to handle user-defined types, resilience against security violations, +implicit memory management, and `locale` handling. -**Enforcement**: +If you need I/O performance, you can almost always do better than `printf()`. - * Flag if using a build mode that compiles code as C. - * The C++ compiler will enforce that the code is valid C++ unless you use C extension options. +`gets()`, `scanf()` using `%s`, and `printf()` using `%s` are security hazards (vulnerable to buffer overflow and generally error-prone). +C11 defines some "optional extensions" that do extra checking of their arguments. +If present in your C library, `gets_s()`, `scanf_s()`, and `printf_s()` might be safer alternatives, but they are still not type safe. +##### Enforcement - -### CPL.3: If you must use C for interfaces, use C++ in the calling code using such interfaces +Optionally flag `` and ``. -**Reason**: C++ is more expressive than C and offer better support for many types of programming. +### SL.io.10: Unless you use `printf`-family functions call `ios_base::sync_with_stdio(false)` -**Example**: For example, to use a 3rd party C library or C systems interface, define the low-level interface in the common subset of C and C++ for better type checking. -Whenever possible encapsulate the low-level interface in an interface that follows the C++ guidelines (for better abstraction, memory safety, and resource safety) and use that C++ interface in C++ code. +##### Reason -**Example**: You can call C from C++: +Synchronizing `iostreams` with `printf-style` I/O can be costly. +`cin` and `cout` are by default synchronized with `printf`. - // in C: - double sqrt(double); +##### Example - // in C++: - extern "C" double sqrt(double); + int main() + { + ios_base::sync_with_stdio(false); + // ... use iostreams ... + } - sqrt(2); +##### Enforcement -**Example**: You can call C++ from C: +??? - // in C: - X call_f(struct Y*, int); +### SL.io.50: Avoid `endl` - // in C++: - extern "C" X call_f(Y* p, int i) - { - return p->f(i); // possibly a virtual function call - } +##### Reason -**Enforcement**: None needed +The `endl` manipulator is mostly equivalent to `'\n'` and `"\n"`; +as most commonly used it simply slows down output by doing redundant `flush()`s. +This slowdown can be significant compared to `printf`-style output. +##### Example - -#SF: Source files + cout << "Hello, World!" << endl; // two output operations and a flush + cout << "Hello, World!\n"; // one output operation and no flush -Distinguish between declarations (used as interfaces) and definitions (used as implementations) -Use header files to represent interfaces and to emphasize logical structure. +##### Note -Source file rule summary: +For `cin`/`cout` (and equivalent) interaction, there is no reason to flush; that's done automatically. +For writing to a file, there is rarely a need to `flush`. -* [SF.1: Use a `.cpp` suffix for code files and `.h` for interface files](#Rs-suffix) -* [SF.2: A `.h` file may not contain object definitions or non-inline function definitions](#Rs-inline) -* [SF.3: Use `.h` files for all declarations used in multiple sourcefiles](#Rs-suffix) -* [SF.4: Include `.h` files before other declarations in a file](#Rs-include-order) -* [SF.5: A `.cpp` file must include the `.h` file(s) that defines its interface](#Rs-consistency) -* [SF.6: Use `using`-directives for transition, for foundation libraries (such as `std`), or within a local scope](#Rs-using) -* [SF.7: Don't put a `using`-directive in a header file](#Rs-using-directive) -* [SF.8: Use `#include` guards for all `.h` files](#Rs-guards) -* [SF.9: Avoid cyclic dependencies among source files](#Rs-cycles) +##### Note -* [SF.20: Use `namespace`s to express logical structure](#Rs-namespace) -* [SF.21: Don't use an unnamed (anonymous) namespace in a header](#Rs-unnamed) -* [SF.22: Use an unnamed (anonymous) namespace for all internal/nonexported entities](#Rs-unnamed2) +For string streams (specifically `ostringstream`), the insertion of an `endl` is entirely equivalent +to the insertion of a `'\n'` character, but also in this case, `endl` might be significantly slower. +`endl` does *not* take care of producing a platform specific end-of-line sequence (like `"\r\n"` on +Windows). So for a string stream, `s << endl` just inserts a *single* character, `'\n'`. +##### Note - -### SF.1: Use a `.cpp` suffix for code files and `.h` for interface files +Apart from the (occasionally important) issue of performance, +the choice between `'\n'` and `endl` is almost completely aesthetic. -**Reason**: Convention +## SL.regex: Regex -**Note**: The specific names `.h` and `.cpp` are not required (but recommended) and other names are in widespread use. -Examples are `.hh` and `.cxx`. Use such names equivalently. +`` is the standard C++ regular expression library. +It supports a variety of regular expression pattern conventions. -**Example**: +## SL.chrono: Time - // foo.h: - extern int a; // a declaration - extern void foo(); - - // foo.cpp: - int a; // a definition - void foo() { ++a; } +`` (defined in namespace `std::chrono`) provides the notions of `time_point` and `duration` together with functions for +outputting time in various units. +It provides clocks for registering `time_points`. -`foo.h` provides the interface to `foo.cpp`. Global variables are best avoided. +## SL.C: The C Standard Library -**Example**, bad: +??? - // foo.h: - int a; // a definition - void foo() { ++a; } +C Standard Library rule summary: -`#include` twice in a program and you get a linker error for two one-definition-rule violations. - +* [SL.C.1: Don't use setjmp/longjmp](#Rclib-jmp) +* [???](#???) +* [???](#???) -**Enforcement**: +### SL.C.1: Don't use setjmp/longjmp -* Flag non-conventional file names. -* Check that `.h` and `.cpp`` (and equivalents) follow the rules below. +##### Reason +a `longjmp` ignores destructors, thus invalidating all resource-management strategies relying on RAII - -### SF.2: A `.h` file may not contain object definitions or non-inline function definitions +##### Enforcement -**Reason**: Including entities subject to the one-definition rule leads to linkage errors. +Flag all occurrences of `longjmp`and `setjmp` -**Example**: - ??? - -**Alternative formulation**: A `.h` file must contain only: -* `#include`s of other `.h` files (possibly with include guards -* templates -* class definitions -* function declarations -* `extern` declarations -* `inline` function definitions -* `constexpr` definitions -* `const` definitions -* `using` alias definitions -* ??? +# A: Architectural ideas -**Enforcement**: Check the positive list above. +This section contains ideas about higher-level architectural ideas and libraries. +Architectural rule summary: - -### SF.3: Use `.h` files for all declarations used in multiple sourcefiles +* [A.1: Separate stable code from less stable code](#Ra-stable) +* [A.2: Express potentially reusable parts as a library](#Ra-lib) +* [A.4: There should be no cycles among libraries](#Ra-dag) +* [???](#???) +* [???](#???) +* [???](#???) +* [???](#???) +* [???](#???) +* [???](#???) -**Reason**: Maintainability. Readability. +### A.1: Separate stable code from less stable code -**example, bad**: +Isolating less stable code facilitates its unit testing, interface improvement, refactoring, and eventual deprecation. - // bar.cpp: - void bar() { cout << "bar\n"; } +### A.2: Express potentially reusable parts as a library - // foo.cpp: - extern void bar(); - void foo() { bar(); } - -A maintainer of `bar` cannot find all declarations of `bar` if its type needs changing. -The user of `bar` cannot know if the interface used is complete and correct. At best, error messages come (late) from the linker. +##### Reason -**Enforcement**: +##### Note -* Flag declarations of entities in other source files not placed in a `.h`. +A library is a collection of declarations and definitions maintained, documented, and shipped together. +A library could be a set of headers (a "header-only library") or a set of headers plus a set of object files. +You can statically or dynamically link a library into a program, or you can `#include` a header-only library. - -### SF.4: Include `.h` files before other declarations in a file +### A.4: There should be no cycles among libraries -**Reason**: Minimize context dependencies and increase readability. +##### Reason -**Example**: +* A cycle complicates the build process. +* Cycles are hard to understand and might introduce indeterminism (unspecified behavior). - #include - #include - #include +##### Note - // ... my code here ... +A library can contain cyclic references in the definition of its components. +For example: -**Example, bad**: + ??? - #include - #include - #include +However, a library should not depend on another that depends on it. - // ... my code here ... -**Note**: This applies to both `.h` and `.cpp` files. +# NR: Non-Rules and myths -**Exception**: Are there any in good code? +This section contains rules and guidelines that are popular somewhere, but that we deliberately don't recommend. +We know perfectly well that there have been times and places where these rules made sense, and we have used them ourselves at times. +However, in the context of the styles of programming we recommend and support with the guidelines, these "non-rules" would do harm. -**Enforcement**: Easy. - +Even today, there can be contexts where the rules make sense. +For example, lack of suitable tool support can make exceptions unsuitable in hard-real-time systems, +but please don't naïvely trust "common wisdom" (e.g., unsupported statements about "efficiency"); +such "wisdom" might be based on decades-old information or experiences from languages with very different properties than C++ +(e.g., C or Java). - -### SF.5: A `.cpp` file must include the `.h` file(s) that defines its interface +The positive arguments for alternatives to these non-rules are listed in the rules offered as "Alternatives". -**Reason** This enables the compiler to do an early consistency check. +Non-rule summary: -**Example**, bad: +* [NR.1: Don't insist that all declarations should be at the top of a function](#Rnr-top) +* [NR.2: Don't insist on having only a single `return`-statement in a function](#Rnr-single-return) +* [NR.3: Don't avoid exceptions](#Rnr-no-exceptions) +* [NR.4: Don't insist on placing each class definition in its own source file](#Rnr-lots-of-files) +* [NR.5: Don't use two-phase initialization](#Rnr-two-phase-init) +* [NR.6: Don't place all cleanup actions at the end of a function and `goto exit`](#Rnr-goto-exit) +* [NR.7: Don't make data members `protected`](#Rnr-protected-data) +* ??? - // foo.h: - void foo(int); - int bar(long double); - int foobar(int); - - // foo.cpp: - void foo(int) { /* ... */ } - int bar(double) { /* ... */ } - double foobar(int); +### NR.1: Don't insist that all declarations should be at the top of a function -Thw errors will not be caught until link time for a program calling `bar` or `foobar`. +##### Reason -**Example**: +The "all declarations on top" rule is a legacy of old programming languages that didn't allow initialization of variables and constants after a statement. +This leads to longer programs and more errors caused by uninitialized and wrongly initialized variables. - // foo.h: - void foo(int); - int bar(long double); - int foobar(int); - - // foo.cpp: - #include - - void foo(int) { /* ... */ } - int bar(double) { /* ... */ } - double foobar(int); // error: wrong return type +##### Example, bad -The return-type error for `foobar` is now caught immediately when `foo.cpp` is compiled. -The argument-type error for `bar` cannot be caught until link time because of the possibility of overloading, -but systematic use of `.h` files increases the likelyhood that it is caught earlier by the programmer. + int use(int x) + { + int i; + char c; + double d; -**Enforcement**: ??? + // ... some stuff ... + if (x < i) { + // ... + i = f(x, d); + } + if (i < x) { + // ... + i = g(x, c); + } + return i; + } - -### SF.6: Use `using`-directives for transition, for foundation libraries (such as `std`), or within a local scope +The larger the distance between the uninitialized variable and its use, the larger the chance of a bug. +Fortunately, compilers catch many "used before set" errors. +Unfortunately, compilers cannot catch all such errors and unfortunately, the bugs aren't always as simple to spot as in this small example. -**Reason**: ??? -**Example**: +##### Alternative - ??? +* [Always initialize an object](#Res-always) +* [ES.21: Don't introduce a variable (or constant) before you need to use it](#Res-introduce) -**Enforcement**: ??? +### NR.2: Don't insist on having only a single `return`-statement in a function +##### Reason - -### SF.7: Don't put a `using`-directive in a header file +The single-return rule can lead to unnecessarily convoluted code and the introduction of extra state variables. +In particular, the single-return rule makes it harder to concentrate error checking at the top of a function. -**Reason** Doing so takes away an `#include`r's ability to effectively disambiguate and to use alternatives. +##### Example -**Example**: + template + // requires Number + string sign(T x) + { + if (x < 0) + return "negative"; + if (x > 0) + return "positive"; + return "zero"; + } - ??? +to use a single return only we would have to do something like -**Enforcement**: ??? + template + // requires Number + string sign(T x) // bad + { + string res; + if (x < 0) + res = "negative"; + else if (x > 0) + res = "positive"; + else + res = "zero"; + return res; + } +This is both longer and likely to be less efficient. +The larger and more complicated the function is, the more painful the workarounds get. +Of course many simple functions will naturally have just one `return` because of their simpler inherent logic. - -### SF.8: Use `#include` guards for all `.h` files +##### Example -**Reason**: To avoid files being `#include`d several times. + int index(const char* p) + { + if (!p) return -1; // error indicator: alternatively "throw nullptr_error{}" + // ... do a lookup to find the index for p + return i; + } -**Example**: +If we applied the rule, we'd get something like - // file foobar.h: - #ifndef FOOBAR_H - #define FOOBAR_H - // ... declarations ... - #endif // FOOBAR_H + int index2(const char* p) + { + int i; + if (!p) + i = -1; // error indicator + else { + // ... do a lookup to find the index for p + } + return i; + } -**Enforcement**: Flag `.h` files without `#include` guards +Note that we (deliberately) violated the rule against uninitialized variables because this style commonly leads to that. +Also, this style is a temptation to use the [goto exit](#Rnr-goto-exit) non-rule. +##### Alternative - -### SF.9: Avoid cyclic dependencies among source files +* Keep functions short and simple +* Feel free to use multiple `return` statements (and to throw exceptions). -**Reason**: Cycles complicates comprehension and slows down compilation. -Complicates conversion to use language-supported modules (when they become available). +### NR.3: Don't avoid exceptions -**Note**: Eliminate cycles; don't just break them with `#include` guards. +##### Reason -**Example, bad**: +There seem to be four main reasons given for not using exceptions: - // file1.h: - #include "file2.h" - - // file2.h: - #include "file3.h" - - // file3.h: - #include "file1.h" +* exceptions are inefficient +* exceptions lead to leaks and errors +* exception performance is not predictable +* the exception-handling run-time support takes up too much space -**Enforcement: Flag all cycles. +There is no way we can settle this issue to the satisfaction of everybody. +After all, the discussions about exceptions have been going on for 40+ years. +Some languages cannot be used without exceptions, but others do not support them. +This leads to strong traditions for the use and non-use of exceptions, and to heated debates. +However, we can briefly outline why we consider exceptions the best alternative for general-purpose programming +and in the context of these guidelines. +Simple arguments for and against are often inconclusive. +There are specialized applications where exceptions indeed can be inappropriate +(e.g., hard-real-time systems without support for reliable estimates of the cost of handling an exception). - -### SF.20: Use `namespace`s to express logical structure +Consider the major objections to exceptions in turn -**Reason**: ??? +* Exceptions are inefficient: +Compared to what? +When comparing make sure that the same set of errors are handled and that they are handled equivalently. +In particular, do not compare a program that immediately terminates on seeing an error to a program +that carefully cleans up resources before logging an error. +Yes, some systems have poor exception handling implementations; sometimes, such implementations force us to use +other error-handling approaches, but that's not a fundamental problem with exceptions. +When using an efficiency argument - in any context - be careful that you have good data that actually provides +insight into the problem under discussion. +* Exceptions lead to leaks and errors. +They do not. +If your program is a rat's nest of pointers without an overall strategy for resource management, +you have a problem whatever you do. +If your system consists of a million lines of such code, +you probably will not be able to use exceptions, +but that's a problem with excessive and undisciplined pointer use, rather than with exceptions. +In our opinion, you need RAII to make exception-based error handling simple and safe -- simpler and safer than alternatives. +* Exception performance is not predictable. +If you are in a hard-real-time system where you must guarantee completion of a task in a given time, +you need tools to back up such guarantees. +As far as we know such tools are not available (at least not to most programmers). +* The exception-handling run-time support takes up too much space. +This can be the case in small (usually embedded) systems. +However, before abandoning exceptions consider what space consistent error-handling using error-codes would require +and what failure to catch an error would cost. -**Example**: +Many, possibly most, problems with exceptions stem from historical needs to interact with messy old code. - ??? +The fundamental arguments for the use of exceptions are -**Enforcement**: ??? +* They clearly differentiate between erroneous return and ordinary return +* They cannot be forgotten or ignored +* They can be used systematically +Remember - -### SF.21: Don't use an unnamed (anonymous) namespace in a header +* Exceptions are for reporting errors (in C++; other languages can have different uses for exceptions). +* Exceptions are not for errors that can be handled locally. +* Don't try to catch every exception in every function (that's tedious, clumsy, and leads to slow code). +* Exceptions are not for errors that require instant termination of a module/system after a non-recoverable error. -**Reason**: It is almost always a bug to mention an unnamed namespace in a header file. +##### Example -**Example**: + ??? - ??? +##### Alternative -**Enforcement**: -* Flag any use of an anonymous namespace in a header file. +* [RAII](#Re-raii) +* Contracts/assertions: Use GSL's `Expects` and `Ensures` (until we get language support for contracts) +### NR.4: Don't insist on placing each class definition in its own source file +##### Reason - -### SF.22: Use an unnamed (anonymous) namespace for all internal/nonexported entities +The resulting number of files from placing each class in its own file are hard to manage and can slow down compilation. +Individual classes are rarely a good logical unit of maintenance and distribution. -**Reason**: -nothing external can depend on an entity in a nested unnamed namespace. -Consider putting every definition in an implementation source file should be in an unnamed namespace unless that is defining an "external/exported" entity. +##### Example -**Example**: An API class and its members can't live in an unnamed namespace; but any "helper" class or function that is defined in an implementation source file should be at an unnamed namespace scope. + ??? - ??? +##### Alternative -**Enforcement**: -* ??? +* Use namespaces containing logically cohesive sets of classes and functions. +### NR.5: Don't use two-phase initialization - -# STL: The Standard Library +##### Reason -Using only the bare language, every task is tedious (in any language). -Using a suitable library any task can be reasonably simple. +Splitting initialization into two leads to weaker invariants, +more complicated code (having to deal with semi-constructed objects), +and errors (when we didn't deal correctly with semi-constructed objects consistently). -Standard-library rule summary: +##### Note -* [STL.1: Use libraries wherever possible](#Rstl-lib) -* [STL2.: Prefer the standard library to other libraries](#Rstl-stl) -* ??? +Sometimes also called two-stage construction. +##### Example, bad - -### STL.1: Use libraries wherever possible + // Old conventional style: many problems -**Reason**: Save time. Don't re-invent the wheel. -Don't replicate the work of others. -Benefit from other people's work when they make improvements. -Help other people when you make improvements. + class Picture + { + int mx; + int my; + int * data; + public: + // main problem: constructor does not fully construct + Picture(int x, int y) + { + mx = x; // also bad: assignment in constructor body + // rather than in member initializer + my = y; + data = nullptr; // also bad: constant initialization in constructor + // rather than in member initializer + } -**References**: ??? + ~Picture() + { + Cleanup(); + } - -### STL2.: Prefer the standard library to other libraries + // ... -**Reason**. More people know the standard library. -It is more likely to be stable, well-maintained, and widely available than your own code or most other libraries. + // bad: two-phase initialization + bool Init() + { + // invariant checks + if (mx <= 0 || my <= 0) { + return false; + } + if (data) { + return false; + } + data = (int*) malloc(mx*my*sizeof(int)); // also bad: owning raw * and malloc + return data != nullptr; + } -## STL.con: Containers + // also bad: no reason to make cleanup a separate function + void Cleanup() + { + if (data) free(data); + data = nullptr; + } + }; -??? + Picture picture(100, 0); // not ready-to-use picture here + // this will fail.. + if (!picture.Init()) { + puts("Error, invalid picture"); + } + // now have an invalid picture object instance. -## STL.str: String +##### Example, good -??? + class Picture + { + int mx; + int my; + vector data; + + static int check_size(int size) + { + // invariant check + Expects(size > 0); + return size; + } -## STL.io: Iostream + public: + // even better would be a class for a 2D Size as one single parameter + Picture(int x, int y) + : mx(check_size(x)) + , my(check_size(y)) + // now we know x and y have a valid size + , data(mx * my) // will throw std::bad_alloc on error + { + // picture is ready-to-use + } -??? + // compiler generated dtor does the job. (also see C.21) -### STL.???: Use character-level input only when you have to; _expr.low_. + // ... + }; -### STL.???: When reading, always consider ill-formed input; _expr.low_. + Picture picture1(100, 100); + // picture1 is ready-to-use here... -## STL.regex: Regex + // not a valid size for y, + // default contract violation behavior will call std::terminate then + Picture picture2(100, 0); + // not reach here... -??? +##### Alternative -## STL:c: The C standard library +* Always establish a class invariant in a constructor. +* Don't define an object before it is needed. -### STL.???: C-style strings +### NR.6: Don't place all cleanup actions at the end of a function and `goto exit` -### STL.???: printf/scanf +##### Reason - -# A: Architectural Ideas +`goto` is error-prone. +This technique is a pre-exception technique for RAII-like resource and error handling. -This section contains ideas about ??? +##### Example, bad - -### A.1 Separate stable from less stable part of code + void do_something(int n) + { + if (n < 100) goto exit; + // ... + int* p = (int*) malloc(n); + // ... + if (some_error) goto_exit; + // ... + exit: + free(p); + } -??? +and spot the bug. - -### A.2 Express potentially reusable parts as a library +##### Alternative -??? +* Use exceptions and [RAII](#Re-raii) +* for non-RAII resources, use [`finally`](#Re-finally). - -### A.3 Express potentially separately maintained parts as a library +### NR.7: Don't make data members `protected` -??? +##### Reason +`protected` data is a source of errors. +`protected` data can be manipulated from an unbounded amount of code in various places. +`protected` data is the class hierarchy equivalent to global data. - -# Non-Rules and myths +##### Example -This section contains rules and guidelines that are popular somewhere, but that we deliberately don't recommend. -In the context of the styles of programming we recommend and support with the guidelines, these "non-rules" would do harm. + ??? -Non-rule summary: +##### Alternative -* all declarations on top of function -* single-return rule -* no exceptions -* one class per source file -* two-phase initialization -* goto exit +* [Avoid `protected` data](#Rh-protected) - -# RF: References +# RF: References Many coding standards, rules, and guidelines have been written for C++, and especially for specialized uses of C++. Many @@ -10677,9 +20929,9 @@ Many * see "stopping programmers from doing unusual things" as their primary aim * aim at portability across many compilers (some 10 years old) * are written to preserve decades old code bases -* aims at a single application domain +* aim at a single application domain * are downright counterproductive -* are ignored (must be ignored for programmers to get their work done well) +* are ignored (must be ignored by programmers to get their work done well) A bad coding standard is worse than no coding standard. However an appropriate set of guidelines are much better than no standards: "Form is liberating." @@ -10697,116 +20949,136 @@ Reference sections: * [RF.rules: Coding rules](#SS-rules) * [RF.books: Books with coding guidelines](#SS-books) -* [RF.C++: C++ Programming (C++11/C++14)](#SS-C++) +* [RF.C++: C++ Programming (C++11/C++14/C++17)](#SS-Cplusplus) * [RF.web: Websites](#SS-web) * [RS.video: Videos about "modern C++"](#SS-vid) * [RF.man: Manuals](#SS-man) +* [RF.core: Core Guidelines materials](#SS-core) +## RF.rules: Coding rules - -## RF.rules: Coding rules - -* [Boost Library Requirements and Guidelines](http://www.boost.org/development/requirements.html"). -???. -* [Bloomberg: BDE C++ Coding](https://raw.githubusercontent.com/wiki/bloomberg/bde/bdestds.pdf"). -Has a stong emphasis on code organization and layout. +* [AUTOSAR Guidelines for the use of the C++14 language in critical and safety-related systems v22.11](https://www.autosar.org/fileadmin/standards/R22-11/AP/AUTOSAR_RS_CPP14Guidelines.pdf) (obsolete, replaced by [MISRA C++:2023](https://misra.org.uk/product/misra-cpp2023/)) +* [Boost Library Requirements and Guidelines](http://www.boost.org/development/requirements.html). + ???. +* [Bloomberg: BDE C++ Coding](https://github.com/bloomberg/bde/wiki/CodingStandards.pdf). + Has a strong emphasis on code organization and layout. * Facebook: ??? * [GCC Coding Conventions](https://gcc.gnu.org/codingconventions.html). -C++03 and (reasonably) a bit backwards looking. -* [Google C++ Style Guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.html"). -Too timid and reflects its 1990s origins. -[A critique from 2014](https://www.linkedin.com/pulse/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker). -Google are busy updating their code base and we don't know how accurately the posted guideline reflects their actual code. -This set of recommendations is evolving. + C++03 and (reasonably) a bit backwards looking. +* [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html). + Geared toward C++17 and (also) older code bases. Google experts are now actively collaborating here on helping to improve these Guidelines, and hopefully to merge efforts so these can be a modern common set they could also recommend. * [JSF++: JOINT STRIKE FIGHTER AIR VEHICLE C++ CODING STANDARDS](http://www.stroustrup.com/JSF-AV-rules.pdf). -Document Number 2RDU00001 Rev C. December 2005. -For flight control software. -For hard real time. -This means that it is necessarily very restrictive ("if the program fails somebody dies"). -For example, no free store allocation or deallocation may occur after the plane takes off (no memory overflow and no fragmentation allowed). -No exception may be used (because there was no available tool for guaranteeing that an exception would be handled within a fixed short time). -Libraries used have to have been approved for mission critical applications. -Any similarities to this set of guidelines are unsurprising because Bjarne Stroustrup was an author of JSF++. -Recommended, but note its very specific focus. -* [Mozilla Portability Guide](https://developer.mozilla.org/en-US/docs/Mozilla/C%2B%2B_Portability_Guide). -As the name indicate, this aims for portability across many (old) compilers. -As such, it is restrictive. + Document Number 2RDU00001 Rev C. December 2005. + For flight control software. + For hard-real-time. + This means that it is necessarily very restrictive ("if the program fails somebody dies"). + For example, no free store allocation or deallocation is allowed to occur after the plane takes off (no memory overflow and no fragmentation allowed). + No exception is allowed to be used (because there was no available tool for guaranteeing that an exception would be handled within a fixed short time). + Libraries used have to have been approved for mission critical applications. + Any similarities to this set of guidelines are unsurprising because Bjarne Stroustrup was an author of JSF++. + Recommended, but note its very specific focus. +* [MISRA C++:2023 Guidelines for the use C++17 in critical systems](https://misra.org.uk/product/misra-cpp2023/). +* [Using C++ in Mozilla Code](https://firefox-source-docs.mozilla.org/code-quality/coding-style/using_cxx_in_firefox_code.html). + As the name indicates, this aims for portability across many (old) compilers. + As such, it is restrictive. * [Geosoft.no: C++ Programming Style Guidelines](http://geosoft.no/development/cppstyle.html). -???. + ???. * [Possibility.com: C++ Coding Standard](http://www.possibility.com/Cpp/CppCodingStandard.html). -???. -* [SEI CERT: Secure C++ Coding Standard](https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637). -A very nicely done set of rules (with examples and rationales) done for security-sensitive code. -Many of their rules apply generally. + ???. +* [SEI CERT: Secure C++ Coding Standard](https://wiki.sei.cmu.edu/confluence/x/Wnw-BQ). + A very nicely done set of rules (with examples and rationales) done for security-sensitive code. + Many of their rules apply generally. * [High Integrity C++ Coding Standard](http://www.codingstandard.com/). * [llvm](http://llvm.org/docs/CodingStandards.html). -Somewhat brief, pre-C++11, and (not unreasonably) adjusted to its domain. + Somewhat brief, based on C++14, and (not unreasonably) adjusted to its domain. * ??? - - -## RF.books: Books with coding guidelines - -* Scott Meyers: Effective C++ (???). Addison-Wesley 2014. Beware of overly technical and overly definite rules. -* Sutter and Alexandrescu: C++ Coding Standards. Addison-Wesley 2005. More a set of meta-rules than a set of rules. Pre-C++11. Recommended. -* -Bjarne Stroustrup: [A rationale for semantically enhanced library languages](http://www.stroustrup.com/SELLrationale.pdf). -LCSD05. October 2005. -* Stroustrup: [A Tour of C++](http://www.stroustrup.com/Tour.html). -Addison Wesley 2014. -Each chapter ends with an advice section consisting of a set of recommendations. -* Stroustrup: [The C++ Programming Language (4th Edition)](http://www.stroustrup.com/4th.html). -Addison Wesley 2013. -Each chapter ends with an advice section consisting of a set of recommendations. +## RF.books: Books with coding guidelines + +* [Meyers96](#Meyers96) Scott Meyers: *More Effective C++*. Addison-Wesley 1996. +* [Meyers97](#Meyers97) Scott Meyers: *Effective C++, Second Edition*. Addison-Wesley 1997. +* [Meyers01](#Meyers01) Scott Meyers: *Effective STL*. Addison-Wesley 2001. +* [Meyers05](#Meyers05) Scott Meyers: *Effective C++, Third Edition*. Addison-Wesley 2005. +* [Meyers15](#Meyers15) Scott Meyers: *Effective Modern C++*. O'Reilly 2015. +* [SuttAlex05](#SuttAlex05) Sutter and Alexandrescu: *C++ Coding Standards*. Addison-Wesley 2005. More a set of meta-rules than a set of rules. Pre-C++11. +* [Stroustrup05](#Stroustrup05) Bjarne Stroustrup: [A rationale for semantically enhanced library languages](http://www.stroustrup.com/SELLrationale.pdf). + LCSD05. October 2005. +* [Stroustrup14](#Stroustrup05) Stroustrup: [A Tour of C++](http://www.stroustrup.com/Tour.html). + Addison Wesley 2014. + Each chapter ends with an advice section consisting of a set of recommendations. +* [Stroustrup13](#Stroustrup13) Stroustrup: [The C++ Programming Language (4th Edition)](http://www.stroustrup.com/4th.html). + Addison Wesley 2013. + Each chapter ends with an advice section consisting of a set of recommendations. * Stroustrup: [Style Guide](http://www.stroustrup.com/Programming/PPP-style.pdf) -for [Programming: Principles and Practice using C++](http://www.stroustrup.com/programming.html). -Mostly low-level naming and layout rules. -Primarily a teaching tool. + for [Programming: Principles and Practice using C++](http://www.stroustrup.com/programming.html). + Mostly low-level naming and layout rules. + Primarily a teaching tool. +## RF.C++: C++ Programming (C++11/C++14) - -## RF.C++: C++ Programming (C++11/C++14) +* [TC++PL4](http://www.stroustrup.com/4th.html): +A thorough description of the C++ language and standard libraries for experienced programmers. +* [Tour++](http://www.stroustrup.com/Tour.html): +An overview of the C++ language and standard libraries for experienced programmers. +* [Programming: Principles and Practice using C++](http://www.stroustrup.com/programming.html): +A textbook for beginners and relative novices. -* TC++PL4 -* Tour++ -* Programming: Principles and Practice using C++ +## RF.web: Websites - - -## RF.web: Websites - -* [isocpp.org](http://www.isocpp.com) +* [isocpp.org](https://isocpp.org) * [Bjarne Stroustrup's home pages](http://www.stroustrup.com) * [WG21](http://www.open-std.org/jtc1/sc22/wg21/) -* [Boost](http://www.boost.org) -* [Adobe open source](http://www.adobe.com/open-source.html) +* [Boost](http://www.boost.org) +* [Adobe open source](https://opensource.adobe.com/) * [Poco libraries](http://pocoproject.org/) +* Sutter's Mill? +* ??? - - - -## RS.video: Videos about "modern C++" +## RS.video: Videos about "modern C++" * Bjarne Stroustrup: [C++11 Style](http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style). 2012. * Bjarne Stroustrup: [The Essence of C++: With Examples in C++84, C++98, C++11, and C++14](http://channel9.msdn.com/Events/GoingNative/2013/Opening-Keynote-Bjarne-Stroustrup). 2013 * All the talks from [CppCon '14](https://isocpp.org/blog/2014/11/cppcon-videos-c9) * Bjarne Stroustrup: [The essence of C++](https://www.youtube.com/watch?v=86xWVb4XIyE) at the University of Edinburgh. 2014. -* Sutter: ??? +* Bjarne Stroustrup: [The Evolution of C++ Past, Present and Future](https://www.youtube.com/watch?v=_wzc7a3McOs). CppCon 2016 keynote. +* Bjarne Stroustrup: [Make Simple Tasks Simple!](https://www.youtube.com/watch?v=nesCaocNjtQ). CppCon 2014 keynote. +* Bjarne Stroustrup: [Writing Good C++14](https://www.youtube.com/watch?v=1OEu9C51K2A). CppCon 2015 keynote about the Core Guidelines. +* Herb Sutter: [Writing Good C++14... By Default](https://www.youtube.com/watch?v=hEx5DNLWGgA). CppCon 2015 keynote about the Core Guidelines. +* CppCon 15 +* ??? C++ Next +* ??? Meting C++ * ??? more ??? +## RF.man: Manuals + +* ISO C++ Standard C++11. +* ISO C++ Standard C++14. +* [ISO C++ Standard C++17](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4606.pdf). Committee Draft. +* [Palo Alto "Concepts" TR](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf). +* [ISO C++ Concepts TS](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4553.pdf). +* [WG21 Ranges report](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4569.pdf). Draft. + + +## RF.core: Core Guidelines materials - -## RF.man: Manuals +This section contains materials that have been useful for presenting the core guidelines and the ideas behind them: -* ISO C++ Standard C++11 -* ISO C++ Standard C++14 -* Palo Alto "Concepts" TR -* ISO C++ Concepts TS -* WG21 Ranges report - - - -## Acknowledgements +* [Our documents directory](https://github.com/isocpp/CppCoreGuidelines/tree/master/docs) +* Stroustrup, Sutter, and Dos Reis: [A brief introduction to C++'s model for type- and resource-safety](http://www.stroustrup.com/resource-model.pdf). A paper with lots of examples. +* Sergey Zubkov: [a Core Guidelines talk](https://www.youtube.com/watch?v=DyLwdl_6vmU) +and here are the [slides](http://2017.cppconf.ru/talks/sergey-zubkov). In Russian. 2017. +* Neil MacIntosh: [The Guideline Support Library: One Year Later](https://www.youtube.com/watch?v=_GhNnCuaEjo). CppCon 2016. +* Bjarne Stroustrup: [Writing Good C++14](https://www.youtube.com/watch?v=1OEu9C51K2A). CppCon 2015 keynote. +* Herb Sutter: [Writing Good C++14... By Default](https://www.youtube.com/watch?v=hEx5DNLWGgA). CppCon 2015 keynote. +* Peter Sommerlad: [C++ Core Guidelines - Modernize your C++ Code Base](https://www.youtube.com/watch?v=fQ926v4ZzAM). ACCU 2017. +* Bjarne Stroustrup: [No Littering!](https://www.youtube.com/watch?v=01zI9kV4h8c). Bay Area ACCU 2016. +It gives some idea of the ambition level for the Core Guidelines. + +Note that slides for CppCon presentations are available (links with the posted videos). + +Contributions to this list would be most welcome. + +## Acknowledgements Thanks to the many people who contributed rules, suggestions, supporting information, references, etc.: @@ -10818,13 +21090,35 @@ Thanks to the many people who contributed rules, suggestions, supporting informa * Zhuang, Jiangang (Jeff) * Sergey Zubkov +and see the contributor list on the github. + +# Pro: Profiles - -# Profiles +Ideally, we would follow all of the guidelines. +That would give the cleanest, most regular, least error-prone, and often the fastest code. +Unfortunately, that is usually impossible because we have to fit our code into large code bases and use existing libraries. +Often, such code has been written over decades and does not follow these guidelines. +We must aim for [gradual adoption](#S-modernizing). -A "profile" is a set of deterministic and portably enforceable subset rules (i.e., restrictions) that are designed to achieve a specific guarantee. "Deterministic" means they require only local analysis and could be implemented in a compiler (though they don't need to be). "Portably enforceable" means they are like language rules, so programmers can count on enforcement tools giving the same answer for the same code. +Whatever strategy for gradual adoption we adopt, we need to be able to apply sets of related guidelines to address some set +of problems first and leave the rest until later. +A similar idea of "related guidelines" becomes important when some, but not all, guidelines are considered relevant to a code base +or if a set of specialized guidelines is to be applied for a specialized application area. +We call such a set of related guidelines a "profile". +We aim for such a set of guidelines to be coherent so that they together help us reach a specific goal, such as "absence of range errors" +or "static type safety." +Each profile is designed to eliminate a class of errors. +Enforcement of "random" rules in isolation is more likely to be disruptive to a code base than delivering a definite improvement. -Code written to be warning-free using such a language profile is considered to conform to the profile. Conforming code is considered to be safe by construction with regard to the safety properties targeted by that profile. Conforming code will not be the root cause of errors for that property, although such errors may be introduced into a program by other code, libraries or the external environment. A profile may also introduce additional library types to ease conformance and encourage correct code. +A "profile" is a set of deterministic and portably enforceable subset of rules (i.e., restrictions) that are designed to achieve a specific guarantee. +"Deterministic" means they require only local analysis and could be implemented in a compiler (though they don't need to be). +"Portably enforceable" means they are like language rules, so programmers can count on different enforcement tools giving the same answer for the same code. + +Code written to be warning-free using such a language profile is considered to conform to the profile. +Conforming code is considered to be safe by construction with regard to the safety properties targeted by that profile. +Conforming code will not be the root cause of errors for that property, +although such errors might be introduced into a program by other code, libraries or the external environment. +A profile might also introduce additional library types to ease conformance and encourage correct code. Profiles summary: @@ -10832,941 +21126,1077 @@ Profiles summary: * [Pro.bounds: Bounds safety](#SS-bounds) * [Pro.lifetime: Lifetime safety](#SS-lifetime) +In the future, we expect to define many more profiles and add more checks to existing profiles. +Candidates include: + +* narrowing arithmetic promotions/conversions (likely part of a separate safe-arithmetic profile) +* arithmetic cast from negative floating point to unsigned integral type (ditto) +* selected undefined behavior: Start with Gabriel Dos Reis's UB list developed for the WG21 study group +* selected unspecified behavior: Addressing portability concerns. +* `const` violations: Mostly done by compilers already, but we can catch inappropriate casting and underuse of `const`. +Enabling a profile is implementation defined; typically, it is set in the analysis tool used. - -## Type safety profile +To suppress enforcement of a profile check, place a `suppress` annotation on a language contract. For example: + + [[suppress("bounds")]] char* raw_find(char* p, int n, char x) // find x in p[0]..p[n - 1] + { + // ... + } -This profile makes it easier to construct code that uses types correctly and avoids inadvertent type punning. It does so by focusing on removing the primary sources of type violations, including unsafe uses of casts and unions. +Now `raw_find()` can scramble memory to its heart's content. +Obviously, suppression should be very rare. -For the purposes of this section, type-safety is defined to be the property that a program does not use a variable as a type it is not. Memory accessed as a type `T` should not be valid memory that actually contains an object of an unrelated type `U`. (Note that the safety is intended to be complete when combined also with [Bounds safety](#SS-bounds) and [Lifetime safety](#SS-lifetime).) +## Pro.safety: Type-safety profile -The following are under consideration but not yet in the rules below, and may be better in other profiles: +This profile makes it easier to construct code that uses types correctly and avoids inadvertent type punning. +It does so by focusing on removing the primary sources of type violations, including unsafe uses of casts and unions. - - narrowing arithmetic promotions/conversions (likely part of a separate safe-arithmetic profile) - - arithmetic cast from negative floating point to unsigned integral type (ditto) - - selected undefined behavior: ??? this is a big bucket, start with Gaby's UB list - - selected unspecified behavior: ??? would this really be about safety, or more a portability concern? - - constness violations? if we rely on it for safety +For the purposes of this section, +type-safety is defined to be the property that a variable is not used in a way that doesn't obey the rules for the type of its definition. +Memory accessed as a type `T` should not be valid memory that actually contains an object of an unrelated type `U`. +Note that the safety is intended to be complete when combined also with [Bounds safety](#SS-bounds) and [Lifetime safety](#SS-lifetime). An implementation of this profile shall recognize the following patterns in source code as non-conforming and issue a diagnostic. +Type safety profile summary: - -### Type.1: Don't use `reinterpret_cast`. +* Type.1: [Avoid casts](#Res-casts): -**Reason**: -Use of these casts can violate type safety and cause the program to access a variable that is actually of type `X` to be accessed as if it were of an unrelated type `Z`. + 1. Don't use `reinterpret_cast`; A strict version of [Avoid casts](#Res-casts) and [prefer named casts](#Res-casts-named). + 2. Don't use `static_cast` for arithmetic types; A strict version of [Avoid casts](#Res-casts) and [prefer named casts](#Res-casts-named). + 3. Don't cast between pointer types where the source type and the target type are the same; A strict version of [Avoid casts](#Res-casts). + 4. Don't cast between pointer types when the conversion could be implicit; A strict version of [Avoid casts](#Res-casts). +* Type.2: Don't use `static_cast` to downcast: +[Use `dynamic_cast` instead](#Rh-dynamic_cast). +* Type.3: Don't use `const_cast` to cast away `const` (i.e., at all): +[Don't cast away const](#Res-casts-const). +* Type.4: Don't use C-style `(T)expression` or functional `T(expression)` casts: +Prefer [construction](#Res-construct) or [named casts](#Res-casts-named) or `T{expression}`. +* Type.5: Don't use a variable before it has been initialized: +[always initialize](#Res-always). +* Type.6: Always initialize a data member: +[always initialize](#Res-always), +possibly using [default constructors](#Rc-default0) or +[default member initializers](#Rc-in-class-initializer). +* Type.7: Avoid naked union: +[Use `variant` instead](#Ru-naked). +* Type.8: Avoid varargs: +[Don't use `va_arg` arguments](#F-varargs). -**Example; bad**: +##### Impact - std::string s = "hello world"; - double* p = reinterpret_cast(&s); // BAD +With the type-safety profile you can trust that every operation is applied to a valid object. +An exception can be thrown to indicate errors that cannot be detected statically (at compile time). +Note that this type-safety can be complete only if we also have [Bounds safety](#SS-bounds) and [Lifetime safety](#SS-lifetime). +Without those guarantees, a region of memory could be accessed independent of which object, objects, or parts of objects are stored in it. -**Enforcement**: Issue a diagnostic for any use of `reinterpret_cast`. To fix: Consider using a `variant` instead. +## Pro.bounds: Bounds safety profile - -### Type.2: Don't use `static_cast` downcasts. Use `dynamic_cast` instead. +This profile makes it easier to construct code that operates within the bounds of allocated blocks of memory. +It does so by focusing on removing the primary sources of bounds violations: pointer arithmetic and array indexing. +One of the core features of this profile is to restrict pointers to only refer to single objects, not arrays. -**Reason**: -Use of these casts can violate type safety and cause the program to access a variable that is actually of type `X` to be accessed as if it were of an unrelated type `Z`. +We define bounds-safety to be the property that a program does not use an object to access memory outside of the range that was allocated for it. +Bounds safety is intended to be complete only when combined with [Type safety](#SS-type) and [Lifetime safety](#SS-lifetime), +which cover other unsafe operations that allow bounds violations. -**Example; bad**: +Bounds safety profile summary: - class base { public: virtual ~base() =0; }; +* Bounds.1: Don't use pointer arithmetic. Use `span` instead: +[Pass pointers to single objects (only)](#Ri-array) and [Keep pointer arithmetic simple](#Res-ptr). +* Bounds.2: Only index into arrays using constant expressions: +[Pass pointers to single objects (only)](#Ri-array) and [Keep pointer arithmetic simple](#Res-ptr). +* Bounds.3: No array-to-pointer decay: +[Pass pointers to single objects (only)](#Ri-array) and [Keep pointer arithmetic simple](#Res-ptr). +* Bounds.4: Don't use standard-library functions and types that are not bounds-checked: +[Use the standard library in a type-safe manner](#Rsl-bounds). - class derived1 : public base { }; +##### Impact - class derived2 : public base { - std::string s; - public: - std::string get_s() { return s; } - }; +Bounds safety implies that access to an object - notably arrays - does not access beyond the object's memory allocation. +This eliminates a large class of insidious and hard-to-find errors, including the (in)famous "buffer overflow" errors. +This closes security loopholes as well as a prominent source of memory corruption (when writing out of bounds). +Even if an out-of-bounds access is "just a read", it can lead to invariant violations (when the accessed isn't of the assumed type) +and "mysterious values." - derived1 d1; - base* p = &d1; // ok, implicit conversion to pointer to base is fine - derived2* p2 = static_cast(p); // BAD, tries to treat d1 as a derived2, which it is not - cout << p2.get_s(); // tries to access d1's nonexistent string member, instead sees arbitrary bytes near d1 +## Pro.lifetime: Lifetime safety profile -**Enforcement**: Issue a diagnostic for any use of `static_cast` to downcast, meaning to cast from a pointer or reference to `X` to a pointer or reference to a type that is not `X` or an accessible base of `X`. To fix: If this is a downcast or cross-cast then use a `dynamic_cast` instead, otherwise consider using a `variant` instead. +Accessing through a pointer that doesn't point to anything is a major source of errors, +and very hard to avoid in many traditional C or C++ styles of programming. +For example, a pointer might be uninitialized, the `nullptr`, point beyond the range of an array, or to a deleted object. +[See the current design specification here.](https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf) - -### Type.3: Don't use `const_cast` to cast away `const` (i.e., at all). +Lifetime safety profile summary: -**Reason**: -Casting away `const` is a lie. If the variable is actually declared `const`, it's a lie punishable by undefined behavior. +* Lifetime.1: Don't dereference a possibly invalid pointer: +[detect or avoid](#Res-deref). -**Example; bad**: +##### Impact - void f(const int& i) { - const_cast(i) = 42; // BAD - } +Once completely enforced through a combination of style rules, static analysis, and library support, this profile - static int i = 0; - static const int j = 0; +* eliminates one of the major sources of nasty errors in C++ +* eliminates a major source of potential security violations +* improves performance by eliminating redundant "paranoia" checks +* increases confidence in correctness of code +* avoids undefined behavior by enforcing a key C++ language rule - f(i); // silent side effect - f(j); // undefined behavior - -**Exception**: You may need to cast away `const` when calling `const`-incorrect functions. Prefer to wrap such functions in inline `const`-correct wrappers to encapsulate the cast in one place. +# GSL: Guidelines support library + +The GSL is a small library of facilities designed to support this set of guidelines. +Without these facilities, the guidelines would have to be far more restrictive on language details. + +The Core Guidelines support library is defined in namespace `gsl` and the names might be aliases for standard library or other well-known library names. Using the (compile-time) indirection through the `gsl` namespace allows for experimentation and for local variants of the support facilities. -**Enforcement**: Issue a diagnostic for any use of `const_cast`. To fix: Either don't use the variable in a non-`const` way, or don't make it `const`. +The GSL is header only, and can be found at [GSL: Guidelines support library](https://github.com/Microsoft/GSL). +The support library facilities are designed to be extremely lightweight (zero-overhead) so that they impose no overhead compared to using conventional alternatives. +Where desirable, they can be "instrumented" with additional functionality (e.g., checks) for tasks such as debugging. +These Guidelines use types from the standard (e.g., C++17) in addition to ones from the GSL. +For example, we assume a `variant` type, but this is not currently in GSL. +Eventually, use [the one voted into C++17](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0088r3.html). - -### Type.4: Don't use C-style `(T)expression` casts that would perform a `static_cast` downcast, `const_cast`, or `reinterpret_cast`. +Some of the GSL types listed below might not be supported in the library you use due to technical reasons such as limitations in the current versions of C++. +Therefore, please consult your GSL documentation to find out more. -**Reason**: -Use of these casts can violate type safety and cause the program to access a variable that is actually of type `X` to be accessed as if it were of an unrelated type `Z`. -Note that a C-style `(T)expression` cast means to perform the first of the following that is possible: a `const_cast`, a `static_cast`, a `static_cast` followed by a `const_cast`, a `reinterpret_cast`, or a `reinterpret_cast` followed by a `const_cast`. This rule bans `(T)expression` only when used to perform an unsafe cast. +For each GSL type below we state an invariant for that type. That invariant holds as long as user code only changes the state of a GSL object using the type's provided member/free functions (i.e., user code does not bypass the type's interface to change the object's value/bits by violating any other Guidelines rule). -**Example; bad**: +Summary of GSL components: - std::string s = "hello world"; - double* p = (double*)(&s); // BAD +* [GSL.view: Views](#SS-views) +* [GSL.owner: Ownership pointers](#SS-ownership) +* [GSL.assert: Assertions](#SS-assertions) +* [GSL.util: Utilities](#SS-utilities) +* [GSL.concept: Concepts](#SS-gsl-concepts) - class base { public: virtual ~base() = 0; }; +We plan for a "ISO C++ standard style" semi-formal specification of the GSL. - class derived1 : public base { }; +We rely on the ISO C++ Standard Library and hope for parts of the GSL to be absorbed into the standard library. - class derived2 : public base { - std::string s; - public: - std::string get_s() { return s; } - }; +## GSL.view: Views + +These types allow the user to distinguish between owning and non-owning pointers and between pointers to a single object and pointers to the first element of a sequence. + +These "views" are never owners. + +References are never owners (see [R.4](#Rr-ref)). Note: References have many opportunities to outlive the objects they refer to (returning a local variable by reference, holding a reference to an element of a vector and doing `push_back`, binding to `std::max(x, y + 1)`, etc). The Lifetime safety profile aims to address those things, but even so `owner` does not make sense and is discouraged. + +The names are mostly ISO standard-library style (lower case and underscore): + +* `T*` // The `T*` is not an owner, might be null; assumed to be pointing to a single element. +* `T&` // The `T&` is not an owner and can never be a "null reference"; references are always bound to objects. + +The "raw-pointer" notation (e.g. `int*`) is assumed to have its most common meaning; that is, a pointer points to an object, but does not own it. +Owners should be converted to resource handles (e.g., `unique_ptr` or `vector`) or marked `owner`. + +* `owner` // a `T*` that owns the object pointed/referred to; might be `nullptr`. + +`owner` is used to mark owning pointers in code that cannot be upgraded to use proper resource handles. +Reasons for that include: + +* Cost of conversion. +* The pointer is used with an ABI. +* The pointer is part of the implementation of a resource handle. + +An `owner` differs from a resource handle for a `T` by still requiring an explicit `delete`. + +An `owner` is assumed to refer to an object on the free store (heap). + +If something is not supposed to be `nullptr`, say so: + +* `not_null` // `T` is usually a pointer type (e.g., `not_null` and `not_null>`) that must not be `nullptr`. + `T` can be any type for which `==nullptr` is meaningful. + +* `span` // `[p:p+n)`, constructor from `{p, q}` and `{p, n}`; `T` is the pointer type +* `span_p` // `{p, predicate}` `[p:q)` where `q` is the first element for which `predicate(*p)` is true + +A `span` refers to zero or more mutable `T`s unless `T` is a `const` type. All accesses to elements of the span, notably via `operator[]`, are guaranteed to be bounds-checked by default. + +> Note: GSL's `span` (initially called `array_view`) was proposed for inclusion in the C++ standard library, and was adopted (with changes to its name and interface) except only that `std::span` does not provide for guaranteed bounds checking. Therefore GSL changed `span`'s name and interface to track `std::span` and should be exactly the same as `std::span`, and the only difference should be that GSL `span` is fully bounds-safe by default. If bounds-safety might affect its interface, then those change proposals should be brought back via the ISO C++ committee to keep `gsl::span` interface-compatible with `std::span`. If a future evolution of `std::span` adds bounds checking, `gsl::span` can be removed. + +"Pointer arithmetic" is best done within `span`s. +A `char*` that points to more than one `char` but is not a C-style string (e.g., a pointer into an input buffer) should be represented by a `span`. + +* `zstring` // a `char*` supposed to be a C-style string; that is, a zero-terminated sequence of `char` or `nullptr` +* `czstring` // a `const char*` supposed to be a C-style string; that is, a zero-terminated sequence of `const` `char` or `nullptr` + +Logically, those last two aliases are not needed, but we are not always logical, and they make the distinction between a pointer to one `char` and a pointer to a C-style string explicit. +A sequence of characters that is not assumed to be zero-terminated should be a `span`, or if that is impossible because of ABI issues a `char*`, rather than a `zstring`. + + +Use `not_null` for C-style strings that cannot be `nullptr`. ??? Do we need a name for `not_null`? or is its ugliness a feature? + +## GSL.owner: Ownership pointers + +* `unique_ptr` // unique ownership: `std::unique_ptr` +* `shared_ptr` // shared ownership: `std::shared_ptr` (a counted pointer) +* `stack_array` // A stack-allocated array. The number of elements is determined at construction and fixed thereafter. The elements are mutable unless `T` is a `const` type. +* `dyn_array` // A container, non-growing dynamically allocated array. The number of elements is determined at construction and fixed thereafter. + The elements are mutable unless `T` is a `const` type. Basically a `span` that allocates and owns its elements. + +## GSL.assert: Assertions + +* `Expects` // precondition assertion. Currently placed in function bodies. Later, should be moved to declarations. + // `Expects(p)` terminates the program unless `p == true` + // `Expects` is under control of some options (enforcement, error message, alternatives to terminate) +* `Ensures` // postcondition assertion. Currently placed in function bodies. Later, should be moved to declarations. + +These assertions are currently macros (yuck!) and must appear in function definitions (only) +pending standard committee decisions on contracts and assertion syntax. +See [the contract proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf); using the attribute syntax, +for example, `Expects(p)` will become `[[expects: p]]`. - derived1 d1; - base* p = &d1; // ok, implicit conversion to pointer to base is fine +## GSL.util: Utilities - derived2* p2 = (derived2*)(p); // BAD, tries to treat d1 as a derived2, which it is not - cout << p2.get_s(); // tries to access d1's nonexistent string member, instead sees arbitrary bytes near d1 +* `finally` // `finally(f)` makes a `final_action{f}` with a destructor that invokes `f` +* `narrow_cast` // `narrow_cast(x)` is `static_cast(x)` +* `narrow` // `narrow(x)` is `static_cast(x)` if `static_cast(x) == x` with no signedness promotions, or it throws `narrowing_error` (e.g., `narrow(-42)` throws) +* `[[implicit]]` // "Marker" to put on single-argument constructors to explicitly make them non-explicit. +* `move_owner` // `p = move_owner(q)` means `p = q` but ??? +* `joining_thread` // a RAII style version of `std::thread` that joins. +* `index` // a type to use for all container and array indexing (currently an alias for `ptrdiff_t`) - void f(const int& i) { - (int&)(i) = 42; // BAD +## GSL.concept: Concepts + +These concepts (type predicates) are borrowed from +Andrew Sutton's Origin library, +the Range proposal, +and the ISO WG21 Palo Alto TR. +Many of them are very similar to what became part of the ISO C++ standard in C++20. + +* `String` +* `Number` +* `Boolean` +* `Range` // in C++20, `std::ranges::range` +* `Sortable` // in C++20, `std::sortable` +* `EqualityComparable` // in C++20, `std::equality_comparable` +* `Convertible` // in C++20, `std::convertible_to` +* `Common` // in C++20, `std::common_with` +* `Integral` // in C++20, `std::integral` +* `SignedIntegral` // in C++20, `std::signed_integral` +* `SemiRegular` // in C++20, `std::semiregular` +* `Regular` // in C++20, `std::regular` +* `TotallyOrdered` // in C++20, `std::totally_ordered` +* `Function` // in C++20, `std::invocable` +* `RegularFunction` // in C++20, `std::regular_invocable` +* `Predicate` // in C++20, `std::predicate` +* `Relation` // in C++20, `std::relation` +* ... + +### GSL.ptr: Smart pointer concepts + +* `Pointer` // A type with `*`, `->`, `==`, and default construction (default construction is assumed to set the singular "null" value) +* `Unique_pointer` // A type that matches `Pointer`, is movable, and is not copyable +* `Shared_pointer` // A type that matches `Pointer`, and is copyable + +# NL: Naming and layout suggestions + +Consistent naming and layout are helpful. +If for no other reason because it minimizes "my style is better than your style" arguments. +However, there are many, many, different styles around and people are passionate about them (pro and con). +Also, most real-world projects include code from many sources, so standardizing on a single style for all code is often impossible. +After many requests for guidance from users, we present a set of rules that you might use if you have no better ideas, but the real aim is consistency, rather than any particular rule set. +IDEs and tools can help (as well as hinder). + +Naming and layout rules: + +* [NL.1: Don't say in comments what can be clearly stated in code](#Rl-comments) +* [NL.2: State intent in comments](#Rl-comments-intent) +* [NL.3: Keep comments crisp](#Rl-comments-crisp) +* [NL.4: Maintain a consistent indentation style](#Rl-indent) +* [NL.5: Avoid encoding type information in names](#Rl-name-type) +* [NL.7: Make the length of a name roughly proportional to the length of its scope](#Rl-name-length) +* [NL.8: Use a consistent naming style](#Rl-name) +* [NL.9: Use `ALL_CAPS` for macro names only](#Rl-all-caps) +* [NL.10: Prefer `underscore_style` names](#Rl-camel) +* [NL.11: Make literals readable](#Rl-literals) +* [NL.15: Use spaces sparingly](#Rl-space) +* [NL.16: Use a conventional class member declaration order](#Rl-order) +* [NL.17: Use K&R-derived layout](#Rl-knr) +* [NL.18: Use C++-style declarator layout](#Rl-ptr) +* [NL.19: Avoid names that are easily misread](#Rl-misread) +* [NL.20: Don't place two statements on the same line](#Rl-stmt) +* [NL.21: Declare one name (only) per declaration](#Rl-dcl) +* [NL.25: Don't use `void` as an argument type](#Rl-void) +* [NL.26: Use conventional `const` notation](#Rl-const) +* [NL.27: Use a `.cpp` suffix for code files and `.h` for interface files](#Rl-file-suffix) + +Most of these rules are aesthetic and programmers hold strong opinions. +IDEs also tend to have defaults and a range of alternatives. +These rules are suggested defaults to follow unless you have reasons not to. + +We have had comments to the effect that naming and layout are so personal and/or arbitrary that we should not try to "legislate" them. +We are not "legislating" (see the previous paragraph). +However, we have had many requests for a set of naming and layout conventions to use when there are no external constraints. + +More specific and detailed rules are easier to enforce. + +These rules bear a strong resemblance to the recommendations in the [PPP Style Guide](http://www.stroustrup.com/Programming/PPP-style.pdf) +written in support of Stroustrup's [Programming: Principles and Practice using C++](http://www.stroustrup.com/programming.html). + +### NL.1: Don't say in comments what can be clearly stated in code + +##### Reason + +Compilers do not read comments. +Comments are less precise than code. +Comments are not updated as consistently as code. + +##### Example, bad + + auto x = m * v1 + vv; // multiply m with v1 and add the result to vv + +##### Enforcement + +Build an AI program that interprets colloquial English text and see if what is said could be better expressed in C++. + +### NL.2: State intent in comments + +##### Reason + +Code says what is done, not what is supposed to be done. Often intent can be stated more clearly and concisely than the implementation. + +##### Example + + void stable_sort(Sortable& c) + // sort c in the order determined by <, keep equal elements (as defined by ==) in + // their original relative order + { + // ... quite a few lines of non-trivial code ... } - static int i = 0; - static const int j = 0; +##### Note - f(i); // silent side effect - f(j); // undefined behavior +If the comment and the code disagree, both are likely to be wrong. + +### NL.3: Keep comments crisp + +##### Reason + +Verbosity slows down understanding and makes the code harder to read by spreading it around in the source file. + +##### Note + +Use intelligible English. +I might be fluent in Danish, but most programmers are not; the maintainers of my code might not be. +Avoid SMS lingo and watch your grammar, punctuation, and capitalization. +Aim for professionalism, not "cool." + +##### Enforcement + +not possible. + +### NL.4: Maintain a consistent indentation style + +##### Reason + +Readability. Avoidance of "silly mistakes." + +##### Example, bad + + int i; + for (i = 0; i < max; ++i); // bug waiting to happen + if (i == j) + return i; + +##### Note + +Always indenting the statement after `if (...)`, `for (...)`, and `while (...)` is usually a good idea: + + if (i < 0) error("negative argument"); + + if (i < 0) + error("negative argument"); + +##### Enforcement + +Use a tool. + +### NL.5: Avoid encoding type information in names -**Enforcement**: Issue a diagnostic for any use of a C-style `(T)expression` cast that would invoke a `static_cast` downcast, `const_cast`, or `reinterpret_cast`. To fix: Use a `dynamic_cast`, `const`-correct declaration, or `variant`, respectively. +##### Rationale +If names reflect types rather than functionality, it becomes hard to change the types used to provide that functionality. +Also, if the type of a variable is changed, code using it will have to be modified. +Minimize unintentional conversions. +##### Example, bad - -### Type.5: Don't use a variable before it has been initialized. + void print_int(int i); + void print_string(const char*); -[ES.20: Always initialize an object](#Res-always) is required. + print_int(1); // repetitive, manual type matching + print_string("xyzzy"); // repetitive, manual type matching +##### Example, good + void print(int i); + void print(string_view); // also works on any string-like sequence - -### Type.6: Always initialize a member variable. + print(1); // clear, automatic type matching + print("xyzzy"); // clear, automatic type matching -**Reason**: -Before a variable has been initialized, it does not contain a deterministic valid value of its type. It could contain any arbitrary bit pattern, which could be different on each call. +##### Note -**Example**: +Names with types encoded are either verbose or cryptic. - struct X { int i; }; + printS // print a std::string + prints // print a C-style string + printi // print an int - X x; - use(x); // BAD, x hs not been initialized +Requiring techniques like Hungarian notation to encode a type has been used in untyped languages, but is generally unnecessary and actively harmful in a strongly statically-typed language like C++, because the annotations get out of date (the warts are just like comments and rot just like them) and they interfere with good use of the language (use the same name and overload resolution instead). - X x2{}; // GOOD - use(x2); +##### Note -**Enforcement**: - - Issue a diagnostic for any constructor of a non-trivially-constructible type that does not initialize all member variables. To fix: Write a data member initializer, or mention it in the member initializer list. - - Issue a diagnostic when constructing an object of a trivially constructible type without `()` or `{}` to initialize its members. To fix: Add `()` or `{}`. +Some styles use very general (not type-specific) prefixes to denote the general use of a variable. + auto p = new User(); + auto p = make_unique(); + // note: "p" is not being used to say "raw pointer to type User," + // just generally to say "this is an indirection" - -### Type.7: Avoid accessing members of raw unions. Prefer `variant` instead. + auto cntHits = calc_total_of_hits(/*...*/); + // note: "cnt" is not being used to encode a type, + // just generally to say "this is a count of something" -**Reason**: -Reading from a union member assumes that member was the last one written, and writing to a union member assumes another member with a nontrivial destructor had its destructor called. This is fragile because it cannot generally be enforced to be safe in the language and so relies on programmer discipline to get it right. +This is not harmful and does not fall under this guideline because it does not encode type information. -**Example**: +##### Note - union U { int i; double d; }; - - U u; - u.i = 42; - use(u.d); // BAD, undefined - - variant u; - u = 42; // u now contains int - use(u.get()); // ok - use(u.get()); // throws ??? update this when standardization finalizes the variant design - -Note that just copying a union is not type-unsafe, so safe code can pass a union from one piece of unsafe code to another. +Some styles distinguish members from local variable, and/or from global variable. -**Enforcement**: - - Issue a diagnostic for accessing a member of a union. To fix: Use a `variant` instead. - - + struct S { + int m_; + S(int m) : m_{abs(m)} { } + }; - -### Type.8: Avoid reading from varargs or passing vararg arguments. Prefer variadic template parameters instead. +This is not harmful and does not fall under this guideline because it does not encode type information. -**Reason**: -Reading from a vararg assumes that the correct type was actually passed. Passing to varargs assumes the correct type will be read. This is fragile because it cannot generally be enforced to be safe in the language and so relies on programmer discipline to get it right. +##### Note -**Example**: +Like C++, some styles distinguish types from non-types. +For example, by capitalizing type names, but not the names of functions and variables. - int sum(...) { - // ... - while( /*...*/ ) - result += va_arg(list, int); // BAD, assumes it will be passed ints + typename + class HashTable { // maps string to T // ... - } - - sum( 3, 2 ); // ok - sum( 3.14159, 2.71828 ); // BAD, undefined - - template - auto sum(Args... args) { // GOOD, and much more flexible - return (... + args); // note: C++17 "fold expression" - } - - sum( 3, 2 ); // ok: 5 - sum( 3.14159, 2.71828 ); // ok: ~5.85987 + }; -Note: Declaring a `...` parameter is sometimes useful for techniques that don't involve actual argument passing, notably to declare “take-anything” functions so as to disable "everything else" in an overload set or express a catchall case in a template metaprogram. - -**Enforcement**: - - Issue a diagnostic for using `va_list`, `va_start`, or `va_arg`. To fix: Use a variadic template parameter list instead. - - Issue a diagnostic for passing an argument to a vararg parameter. To fix: Use a different function, or `[[suppress(types)]]`. + HashTable index; +This is not harmful and does not fall under this guideline because it does not encode type information. +### NL.7: Make the length of a name roughly proportional to the length of its scope - -## Bounds safety profile +**Rationale**: The larger the scope the greater the chance of confusion and of an unintended name clash. -This profile makes it easier to construct code that operates within the bounds of allocated blocks of memory. It does so by focusing on removing the primary sources of bounds violations: pointer arithmetic and array indexing. One of the core features of this profile is to restrict pointers to only refer to single objects, not arrays. +##### Example -For the purposes of this document, bounds-safety is defined to be the property that a program does not use a variable to access memory outside of the range that was allocated and assigned to that variable. (Note that the safety is intended to be complete when combined also with [Type safety](#SS-type) and [Lifetime safety](#SS-lifetime), which cover other unsafe operations that allow bounds violations, such as type-unsafe casts that 'widen' pointers.) + double sqrt(double x); // return the square root of x; x must be non-negative -The following are under consideration but not yet in the rules below, and may be better in other profiles: + int length(const char* p); // return the number of characters in a zero-terminated C-style string - - + int length_of_string(const char zero_terminated_array_of_char[]) // bad: verbose -An implementation of this profile shall recognize the following patterns in source code as non-conforming and issue a diagnostic. + int g; // bad: global variable with a cryptic name + int open; // bad: global variable with a short, popular name - -### Bounds.1: Don't use pointer arithmetic. Use `array_view` instead. +The use of `p` for pointer and `x` for a floating-point variable is conventional and non-confusing in a restricted scope. -**Reason**: -Pointers should only refer to single objects, and pointer arithmetic is fragile and easy to get wrong. `array_view` is a bounds-checked, safe type for accessing arrays of data. +##### Enforcement -**Example; bad**: +??? - void f(int* p, int count) - { - if (count < 2) return; +### NL.8: Use a consistent naming style - int* q = p + 1; // BAD +**Rationale**: Consistency in naming and naming style increases readability. - ptrdiff_t d; - int n; - d = (p - &n); // OK - d = (q - p); // OK +##### Note - int n = *p++; // BAD +There are many styles and when you use multiple libraries, you can't follow all their different conventions. +Choose a "house style", but leave "imported" libraries with their original style. - if (count < 6) return; +##### Example - p[4] = 1; // BAD +ISO Standard, use lower case only and digits, separate words with underscores: - p[count - 1] = 2; // BAD +* `int` +* `vector` +* `my_map` - use(&p[0], 3); // BAD - } +Avoid identifier names that contain double underscores `__` or that start with an underscore followed by a capital letter (e.g., `_Throws`). +Such identifiers are reserved for the C++ implementation. -**Example; good**: +##### Example - void f(array_view a) // BETTER: use array_view in the function declaration - { - if (a.length() < 2) return; +[Stroustrup](http://www.stroustrup.com/Programming/PPP-style.pdf): +ISO Standard, but with upper case used for your own types and concepts: - int n = *a++; // OK +* `int` +* `vector` +* `My_map` - array_view q = a + 1; // OK +##### Example - if (a.length() < 6) return; +CamelCase: capitalize each word in a multi-word identifier: - a[4] = 1; // OK +* `int` +* `vector` +* `MyMap` +* `myMap` - a[count – 1] = 2; // OK +Some conventions capitalize the first letter, some don't. - use(a.data(), 3); // OK - } +##### Note -**Enforcement**: -Issue a diagnostic for any arithmetic operation on an expression of pointer type that results in a value of pointer type. +Try to be consistent in your use of acronyms and lengths of identifiers: + int mtbf {12}; + int mean_time_between_failures {12}; // make up your mind - -### Bounds.2: Only index into arrays using constant expressions. +##### Enforcement -**Reason**: -Dynamic accesses into arrays are difficult for both tools and humans to validate as safe. `array_view` is a bounds-checked, safe type for accessing arrays of data. `at()` is another alternative that ensures single accesses are bounds-checked. If iterators are needed to access an array, use the iterators from an `array_view` constructed over the array. +Would be possible except for the use of libraries with varying conventions. -**Example; bad**: +### NL.9: Use `ALL_CAPS` for macro names only - void f(array a, int pos) - { - a[pos/2] = 1; // BAD - a[pos-1] = 2; // BAD - a[-1] = 3; // BAD - no replacement, just don't do this - a[10] = 4; // BAD - no replacement, just don't do this - } +##### Reason -**Example; good**: +To avoid confusing macros with names that obey scope and type rules. - // ALTERNATIVE A: Use an array_view +##### Example - // A1: Change parameter type to use array_view - void f(array_view a, int pos) + void f() { - a[pos/2] = 1; // OK - a[pos-1] = 2; // OK + const int SIZE{1000}; // Bad, use 'size' instead + int v[SIZE]; } - // A2: Add local array_view and use that - void f(array arr, int pos) - { - array_view a = arr, int pos) - a[pos/2] = 1; // OK - a[pos-1] = 2; // OK - } +##### Note - // ALTERNATIVE B: Use at() for access - void f()(array a, int pos) - { - at(a, pos/2) = 1; // OK - at(a, pos-1) = 2; // OK - } +In particular, this avoids confusing macros with non-macro symbolic constants (see also [Enum.5: Don't use `ALL_CAPS` for enumerators](#Renum-caps)) -**Example; bad**: + enum bad { BAD, WORSE, HORRIBLE }; // BAD - void f() - { - int arr[COUNT]; - for (int i = 0; i < COUNT; ++i) - arr[i] = i; // BAD, cannot use non-constant indexer - } +##### Enforcement -**Example; good**: +* Flag macros with lower-case letters +* Flag `ALL_CAPS` non-macro names - // ALTERNATIVE A: Use an array_view - void f() - { - int arr[COUNT]; - array_view av = arr; - for (int i = 0; i < COUNT; ++i) - av[i] = i; - } +### NL.10: Prefer `underscore_style` names - // ALTERNATIVE B: Use at() for access - void f() - { - int arr[COUNT]; - for (int i = 0; i < COUNT; ++i) - at(arr,i) = i; - } +##### Reason +The use of underscores to separate parts of a name is the original C and C++ style and used in the C++ Standard Library. -**Enforcement**: -Issue a diagnostic for any indexing expression on an expression or variable of array type (either static array or `std::array`) where the indexer is not a compile-time constant expression. +##### Note -Issue a diagnostic for any indexing expression on an expression or variable of array type (either static array or `std::array`) where the indexer is not a value between `0` or and the upper bound of the array. +This rule is a default to use only if you have a choice. +Often, you don't have a choice and must follow an established style for [consistency](#Rl-name). +The need for consistency beats personal taste. -**Rewrite support**: Tooling can offer rewrites of array accesses that involve dynamic index expressions to use `at()` instead: +This is a recommendation for [when you have no constraints or better ideas](#S-naming). +This rule was added after many requests for guidance. - static int a[10]; +##### Example - void f(int i, int j) - { - a[i + j] = 12; // BAD, could be rewritten as... - at(a, i + j) = 12; // OK - bounds-checked - } +[Stroustrup](http://www.stroustrup.com/Programming/PPP-style.pdf): +ISO Standard, but with upper case used for your own types and concepts: +* `int` +* `vector` +* `My_map` - -### Bounds.3: No array-to-pointer decay. +##### Enforcement -**Reason**: -Pointers should not be used as arrays. `array_view` is a bounds-checked, safe alternative to using pointers to access arrays. +Impossible. -**Example; bad**: +### NL.11: Make literals readable - void g(int* p, size_t length); +##### Reason - void f() - { - int a[5]; - g(a, 5); // BAD - g(&a[0], 1); // OK - } +Readability. -**Example; good**: +##### Example - void g(int* p, size_t length); - void g1(array_view av); // BETTER: get g() changed. +Use digit separators to avoid long strings of digits - void f() - { - int a[5]; - array_view av = a; + auto c = 299'792'458; // m/s2 + auto q2 = 0b0000'1111'0000'0000; + auto ss_number = 123'456'7890; - g(a.data(), a.length()); // OK, if you have no choice - g1(a); // OK - no decay here, instead use implicit array_view ctor - } +##### Example -**Enforcement**: -Issue a diagnostic for any expression that would rely on implicit conversion of an array type to a pointer type. +Use literal suffixes where clarification is needed + auto hello = "Hello!"s; // a std::string + auto world = "world"; // a C-style string + auto interval = 100ms; // using - -### Bounds.4: Don't use standard library functions and types that are not bounds-checked. +##### Note -**Reason**: -These functions all have bounds-safe overloads that take `array_view`. Standard types such as `vector` can be modified to perform bounds-checks under the bounds profile (in a compatible way, such as by adding contracts), or used with `at()`. +Literals should not be sprinkled all over the code as ["magic constants"](#Res-magic), +but it is still a good idea to make them readable where they are defined. +It is easy to make a typo in a long string of integers. -**Example; bad**: +##### Enforcement - void f() +Flag long digit sequences. The trouble is to define "long"; maybe 7. + +### NL.15: Use spaces sparingly + +##### Reason + +Too much space makes the text larger and distracts. + +##### Example, bad + + #include < map > + + int main(int argc, char * argv [ ]) { - array a, b; - memset(a.data(), 0, 10); // BAD, and contains a length error - memcmp(a.data(), b.data(), 10); // BAD, and contains a length error + // ... } -**Example; good**: +##### Example - void f() + #include + + int main(int argc, char* argv[]) { - array a, b; - memset(a, 0); // OK - memcmp({a,b}); // OK + // ... } -**Example**: If code is using an unmodified standard library, then there are still workarounds that enable use of `std::array` and `std::vector` in a bounds-safe manner. Code can call the `.at()` member function on each class, which will result in an `std::out_of_range` exception being thrown. Alternatively, code can call the `at()` free function, which will result in fail-fast (or a customized action) on a bounds violation. +##### Note - void f(std::vector& v, std::array a, int i) - { - v[0] = a[0]; // BAD - v.at(0) = a[0]; // OK (alternative 1) - at(v, 0) = a[0]; // OK (alternative 2) +Some IDEs have their own opinions and add distracting space. - v.at(0) = a[i]; // BAD - v.at(0) = a.at(i) // OK (alternative 1) - v.at(0) = at(a, i); // OK (alternative 2) - } +This is a recommendation for [when you have no constraints or better ideas](#S-naming). +This rule was added after many requests for guidance. -**Enforcement**: - - Issue a diagnostic for any call to a standard library function that is not bounds-checked. ??? insert link to a list of banned functions +##### Note -**TODO Notes**: - - Impact on the standard library will require close coordination with WG21, if only to ensure compatibility even if never standardized. - - We are considering specifying bounds-safe overloads for stdlib (especially C stdlib) functions like `memcmp` and shipping them in the GSL. - - For existing stdlib functions and types like `vector` that are not fully bounds-checked, the goal is for these features to be bounds-checked when called from code with the bounds profile on, and unchecked when called from legacy code, possibly using constracts (concurrently being proposed by several WG21 members). +We value well-placed whitespace as a significant help for readability. Just don't overdo it. +### NL.16: Use a conventional class member declaration order +##### Reason +A conventional order of members improves readability. - -## Lifetime safety profile +When declaring a class use the following order +* types: classes, enums, and aliases (`using`) +* constructors, assignments, destructor +* functions +* data +Use the `public` before `protected` before `private` order. +This is a recommendation for [when you have no constraints or better ideas](#S-naming). +This rule was added after many requests for guidance. +##### Example + class X { + public: + // interface + protected: + // unchecked function for use by derived class implementations + private: + // implementation details + }; - -# GSL: Guideline support library +##### Example -The GSL is a small library of facilities designed to support this set of guidelines. -Without these facilities, the guidelines would have to be far more restrictive on language details. +Sometimes, the default order of members conflicts with a desire to separate the public interface from implementation details. +In such cases, private types and functions can be placed with private data. -The Core Guidelines support library is defined in namespace `gsl` and the names may be aliases for standard library or other well-known library names. Using the (compile-time) indirection through the `gsl` namespace allows for experimentation and for local variants of the support facilities. + class X { + public: + // interface + protected: + // unchecked function for use by derived class implementations + private: + // implementation details (types, functions, and data) + }; -The support library facilities are designed to be extremely lightweight (zero-overhead) so that they impose no overhead compared to using conventional alternatives. -Where desirable, they can be "instrumented" with additional functionality (e.g., checks) for tasks such as debugging. +##### Example, bad -These Guidelines assume a `variant` type, but this is not currently in GSL because the design is being actively refined in the standards committee. +Avoid multiple blocks of declarations of one access (e.g., `public`) dispersed among blocks of declarations with different access (e.g. `private`). + class X { // bad + public: + void f(); + public: + int g(); + // ... + }; - -## GSL.view: Views +The use of macros to declare groups of members often leads to violation of any ordering rules. +However, using macros obscures what is being expressed anyway. -These types allow the user to distinguish between owning and non-owning pointers and between pointers to a single object and pointers to the first element of a sequence. +##### Enforcement -These "views" are never owners. +Flag departures from the suggested order. There will be a lot of old code that doesn't follow this rule. -References are never owners. +### NL.17: Use K&R-derived layout -The names are mostly ISO standard-library style (lower case and underscore): +##### Reason -* `T*` // The `T*` is not an owner, may be `nullptr` (Assumed to be pointing to a single element) -* `char*` // A C-style string (a zero-terminated array of characters); can be `nullptr` -* `const char*` // A C-style string; can be `nullptr` -* `T&` // The `T&` is not an owner, may not be `&(T&)*nullptr` (language rule) +This is the original C and C++ layout. It preserves vertical space well. It distinguishes different language constructs (such as functions and classes) well. -The "raw-pointer" notation (e.g. `int*`) is assumed to have its most common meaning; that is, a pointer points to an object, but does not own it. -Owners should be converted to resource handles (e.g., `unique_ptr` or `vector`) or marked `owner` +##### Note -* `owner` // a `T*`that owns the object pointed/referred to; can be `nullptr` -* `owner` // a `T&` that owns the object pointed/referred to +In the context of C++, this style is often called "Stroustrup". -`owner` is used to mark owning pointers in code that cannot be upgraded to use proper resource handles. -Reasons for that include +This is a recommendation for [when you have no constraints or better ideas](#S-naming). +This rule was added after many requests for guidance. -* cost of conversion -* the pointer is used with an ABI -* the pointer is part of the implementation of a resource handle. +##### Example -An `owner` differs from a resource handle for a `T` by still requiring an explicit `delete`. + struct Cable { + int x; + // ... + }; -An `owner` is assumed to refer to an object on the free store (heap). + double foo(int x) + { + if (0 < x) { + // ... + } -If something is not supposed to be `nullptr`, say so: + switch (x) { + case 0: + // ... + break; + case amazing: + // ... + break; + default: + // ... + break; + } -* `not_null` // `T` is usually a pointer type (e.g., `not_null` and `not_null>`) that may not be `nullptr`. -`T` can be any type for which `==nullptr` is meaningful. + if (0 < x) + ++x; -* `array_view` // [`p`:`p+n`), constructor from `{p,q}` and `{p,n}`; `T` is the pointer type -* `array_view_p` // `{p,predicate}` [`p`:`q`) where `q` is the first element for which `predicate(*p)` is true -* `string_view` // `array_view` -* `cstring_view` // `array_view` + if (x < 0) + something(); + else + something_else(); -A `*_view` refers to zero or more mutable `T`s unless `T` is a `const` type. + return some_value; + } -"Pointer arithmetic" is best done within `array_view`s. -A `char*` that points to something that is not a C-style string (e.g., a pointer into an input buffer) should be represented by an `array_view`. -There is no really good way to say "pointer to a single `char` (`string_view{p,1}` can do that, and `T*` where `T` is a `char` in a template that has not been specialized for C-style strings). +Note the space between `if` and `(` -* `zstring` // a `char*` supposed to be a C-style string; that is, a zero-terminated sequence of `char` or `null_ptr` -* `czstring` // a `const char*` supposed to be a C-style string; that is, a zero-terminated sequence of `const` `char` ort `null_ptr` +##### Note -Logically, those last two aliases are not needed, but we are not always logical, -and they make the distinction between a pointer to one `char` and a pointer to a C-style string explicit. -A sequence of characters that is not assumed to be zero-terminated sould be a `char*`, rather than a `zstring`. -French accent optional. +Use separate lines for each statement, the branches of an `if`, and the body of a `for`. -Use `not_null` for C-style strings that cannot be `nullptr`. ??? Do we need a name for `not_null`? or is its ugliness a feature? +##### Note +The `{` for a `class` and a `struct` is *not* on a separate line, but the `{` for a function is. - -## GSL.owner: Ownership pointers +##### Note -* `unique_ptr` // unique ownership: `std::unique_ptr` -* `shared_ptr` // shared ownership: `std::shared_ptr` (a counted pointer) -* `stack_array` // A stack-allocated array. The number of elements are determined at construction and fixed thereafter. The elements are mutable unless `T` is a `const` type. -* `dyn_array` // ??? needed ??? A heap-allocated array. The number of elements are determined at construction and fixed thereafter. -The elements are mutable unless `T` is a `const` type. Basically an `array_view` that allocates and owns its elements. +Capitalize the names of your user-defined types to distinguish them from standards-library types. +##### Note - -## GSL.assert: Assertions +Do not capitalize function names. -* `Expects` // precondition assertion. Currently placed in function bodies. Later, should be moved to declarations. - // `Expects(p)` terminates the program unless `p==true` - // ??? `Expect` in under control of some options (enforcement, error message, alternatives to terminate) -* `Ensures` // postcondition assertion. Currently placed in function bodies. Later, should be moved to declarations. +##### Enforcement +If you want enforcement, use an IDE to reformat. - -## GSL.util: Utilities +### NL.18: Use C++-style declarator layout -* `finally` // `finally(f)` makes a `Final_act{f}` with a destructor that invokes `f` -* `narrow_cast` // `narrow_cast(x)` is `static_cast(x)` -* `narrow` // `narrow(x)` is `static_cast(x)` if `static_cast(x)==x` or it throws `narrowing_error` -* `implicit` // "Marker" to put on single-argument constructors to explicitly make them non-explicit -(I don't know how to do that except with a macro: `#define implicit`). -* `move_owner` // `p=move_owner(q)` means `p=q` but ??? +##### Reason +The C-style layout emphasizes use in expressions and grammar, whereas the C++-style emphasizes types. +The use in expressions argument doesn't hold for references. - -## GSL.concept: Concepts +##### Example -These concepts (type predicates) are borrowed from Andrew Sutton's Origin library, the Range proposal, and the ISO WG21 Palo Alto TR. -They are likely to be very similar to what will become part of the ISO C++ standard. -The notation is that of the ISO WG21 Concepts TS (???ref???). + T& operator[](size_t); // OK + T &operator[](size_t); // just strange + T & operator[](size_t); // undecided -* `Range` -* `String` // ??? -* `Number` // ??? -* `Sortable` -* `Pointer` // A type with `*`, `->`, `==`, and default construction (default construction is assumed to set the singular "null" value) [see smartptrconcepts](#Rr-smartptrconcepts) -* `Unique_ptr` // A type that matches `Pointer`, has move (not copy), and matches the Lifetime profile criteria for a `unique` owner type [see smartptrconcepts](#Rr-smartptrconcepts) -* `Shared_ptr` // A type that matches `Pointer`, has copy, and matches the Lifetime profile criteria for a `shared` owner type [see smartptrconcepts](#Rr-smartptrconcepts) -* `EqualityComparable` // ???Must we suffer CaMelcAse??? -* `Convertible` -* `Common` -* `Boolean` -* `Integral` -* `SignedIntegral` -* `SemiRegular` -* `Regular` -* `TotallyOrdered` -* `Function` -* `RegularFunction` -* `Predicate` -* `Relation` -* ... +##### Note +This is a recommendation for [when you have no constraints or better ideas](#S-naming). +This rule was added after many requests for guidance. - -# NL: Naming and layout rules +##### Enforcement -Consistent naming and layout are helpful. If for no other reason because it minimizes "my style is better than your style" arguments. -However, there are many, many, different styles around and people are passionate about them (pro and con). -Also, most real-world projects includes code from many sources, so standardizing on a single style for all code is often impossible. -We present a set of rules that you might use if you have no better ideas, but the real aim is consistency, rather than any particular rule set. -IDEs and tools can help (as well as hinder). +Impossible in the face of history. -Naming and layout rules: -* [NL 1: Don't say in comments what can be clearly stated in code](#Rl-comments) -* [NL.2: State intent in comments](#Rl-comments-intent) -* [NL.3: Keep comments crisp](#Rl-comments-crisp) -* [NL.4: Maintain a consistent indentation style](#Rl-indent) -* [NL.5: Don't encode type information in names](#Rl-name-type) -* [NL.6: Make the length of a name roughly proportional to the length of its scope](#Rl-name-length) -* [NL.7: Use a consistent naming style](#Rl-name) -* [NL 9: Use ALL_CAPS for macro names only](Rl-space) -* [NL.10: Avoid CamelCase](#Rl-camel) -* [NL.15: Use spaces sparingly](#Rl-space) -* [NL.16: Use a conventional class member declaration order](#Rl-order) -* [NL.17: Use K&R-derived layout](#Rl-knr) -* [NL.18: Use C++-style declarator layout](#Rl-ptr) +### NL.19: Avoid names that are easily misread -Most of these rules are aesthetic and programmers hold strong opinions. -IDEs also tend to have defaults and a range of alternatives.These rules are suggested defaults to follow unless you have reasons not to. +##### Reason -More specific and detailed rules are easier to enforce. +Readability. +Not everyone has screens and printers that make it easy to distinguish all characters. +We easily confuse similarly spelled and slightly misspelled words. +##### Example - -### NL.1: Don't say in comments what can be clearly stated in code + int oO01lL = 6; // bad -**Reason**: Compilers do not read comments. -Comments are less precise than code. -Comments are not updates as consistently as code. + int splunk = 7; + int splonk = 8; // bad: splunk and splonk are easily confused -**Example, bad**: +##### Enforcement - auto x = m*v1 + vv; // multiply m with v1 and add the result to vv +??? -**Enforcement**: Build an AI program that interprets colloquial English text and see if what is said could be better expressed in C++. +### NL.20: Don't place two statements on the same line +##### Reason - -### NL.2: State intent in comments +Readability. +It is really easy to overlook a statement when there is more on a line. -**Reason**: Code says what is done, not what is supposed to be done. Often intent can be stated more clearly and concisely than the implementation. +##### Example -**Example**: + int x = 7; char* p = 29; // don't + int x = 7; f(x); ++x; // don't - void stable_sort(Sortable& c) - // sort c in the order determined by <, keep equal elements (as defined by ==) in their original relative order - { - // ... quite a few lines of non-trivial code ... - } +##### Enforcement -**Note**: If the comment and the code disagrees, both are likely to be wrong. +Easy. +### NL.21: Declare one name (only) per declaration - -### NL.3: Keep comments crisp +##### Reason -**Reason**: Verbosity slows down understanding and makes the code harder to read by spreading it around in the source file. +Readability. +Minimizing confusion with the declarator syntax. -**Enforcement**: not possible. +##### Note +For details, see [ES.10](#Res-name-one). - -### NL.4: Maintain a consistent indentation style -**Reason**: Readability. Avoidance of "silly mistakes." +### NL.25: Don't use `void` as an argument type -**Example, bad**: +##### Reason - int i; - for (i=0; i -### NL.5 Don't encode type information in names + void g(); // better -**Rationale**: If names reflects type rather than functionality, it becomes hard to change the types used to provide that functionality. -Names with types encoded are either verbose or cryptic. -Hungarian notation is evil (at least in a strongly statically-typed language). +##### Note -**Example**: +Even Dennis Ritchie deemed `void f(void)` an abomination. +You can make an argument for that abomination in C when function prototypes were rare so that banning: - ??? + int f(); + f(1, 2, "weird but valid C89"); // hope that f() is defined int f(a, b, c) char* c; { /* ... */ } -**Note**: Some styles distinguishes members from local variable, and/or from global variable. +would have caused major problems, but not in the 21st century and in C++. - struct S { - int m_; - S(int m) :m_{abs(m)) { } - }; +### NL.26: Use conventional `const` notation -This is not evil. +##### Reason -**Note**: Some styles distinguishes types from non-types. +Conventional notation is more familiar to more programmers. +Consistency in large code bases. - typename - class Hash_tbl { // maps string to T - // ... - }; - - Hash_tbl index; +##### Example -This is not evil. + const int x = 7; // OK + int const y = 9; // bad + const int *const p = nullptr; // OK, constant pointer to constant int + int const *const p = nullptr; // bad, constant pointer to constant int - -### NL.7: Make the length of a name roughly proportional to the length of its scope +##### Note -**Rationale**: ??? +We are well aware that you could claim the "bad" examples are more logical than the ones marked "OK", +but they also confuse more people, especially novices relying on teaching material using the far more common, conventional OK style. -**Example**: +As ever, remember that the aim of these naming and layout rules is consistency and that aesthetics vary immensely. - ??? +This is a recommendation for [when you have no constraints or better ideas](#S-naming). +This rule was added after many requests for guidance. -**Enforcement**: ??? +##### Enforcement +Flag `const` used as a suffix for a type. - -### NL.8: Use a consistent naming style +### NL.27: Use a `.cpp` suffix for code files and `.h` for interface files -**Rationale**: Consistence in naming and naming style increases readability. +##### Reason -**Note**: Where are many styles and when you use multiple libraries, you can't follow all their differences conventions. -Choose a "house style", but leave "imported" libraries with their original style. +It's a longstanding convention. +But consistency is more important, so if your project uses something else, follow that. -**Example**, ISO Standard, use lower case only and digits, separate words with underscores: +##### Note - int - vector - my_map +This convention reflects a common use pattern: +Headers are more often shared with C to compile as both C++ and C, which typically uses `.h`, +and it's easier to name all headers `.h` instead of having different extensions for just those headers that are intended to be shared with C. +On the other hand, implementation files are rarely shared with C and so should typically be distinguished from `.c` files, +so it's normally best to name all C++ implementation files something else (such as `.cpp`). -Avoid double underscores `__` +The specific names `.h` and `.cpp` are not required (just recommended as a default) and other names are in widespread use. +Examples are `.hh`, `.C`, and `.cxx`. Use such names equivalently. +In this document, we refer to `.h` and `.cpp` as a shorthand for header and implementation files, +even though the actual extension might be different. -**Example**: [Stroustrup](http://www.stroustrup.com/Programming/PPP-style.pdf): -ISO Standard, but with upper case used for your own types and concepts: +Your IDE (if you use one) might have strong opinions about suffixes. - int - vector - My_map +##### Example -**Example**: CamelCase: capitalize each word in a multi-word identifier + // foo.h: + extern int a; // a declaration + extern void foo(); - int - vector - MyMap - myMap + // foo.cpp: + int a; // a definition + void foo() { ++a; } -Some conventions capitalize the first letter, some don't. +`foo.h` provides the interface to `foo.cpp`. Global variables are best avoided. -**Note**: Try to be consistent in your use of acronyms, lengths of identifiers: +##### Example, bad - int mtbf {12}; - int mean_time_between_failor {12}; // make up your mind + // foo.h: + int a; // a definition + void foo() { ++a; } -**Enforcement**: Would be possible except for the use of libraries with varying conventions. - +`#include ` twice in a program and you get a linker error for two one-definition-rule violations. +##### Enforcement - -### NL 9: Use ALL_CAPS for macro names only +* Flag non-conventional file names. +* Check that `.h` and `.cpp` (and equivalents) follow the rules below. -**Reason**: To avoid confusing macros from names that obeys scope and type rules +# FAQ: Answers to frequently asked questions -**Example**: +This section covers answers to frequently asked questions about these guidelines. - ??? - -**Note**: This rule applies to non-macro symbolic constants +### FAQ.1: What do these guidelines aim to achieve? - enum bad { BAD, WORSE, HORRIBLE }; // BAD - -**Enforcement**: +See the top of this page. This is an open-source project to maintain modern authoritative guidelines for writing C++ code using the current C++ Standard. The guidelines are designed to be modern, machine-enforceable wherever possible, and open to contributions and forking so that organizations can easily incorporate them into their own corporate coding guidelines. -* Flag macros with lower-case letters -* Flag ALL_CAPS non-macro names +### FAQ.2: When and where was this work first announced? +It was announced by [Bjarne Stroustrup in his CppCon 2015 opening keynote, "Writing Good C++14"](https://isocpp.org/blog/2015/09/stroustrup-cppcon15-keynote). See also the [accompanying isocpp.org blog post](https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines), and for the rationale of the type and memory safety guidelines see [Herb Sutter's follow-up CppCon 2015 talk, "Writing Good C++14 ... By Default"](https://isocpp.org/blog/2015/09/sutter-cppcon15-day2plenary). +### FAQ.3: Who are the authors and maintainers of these guidelines? - -### NL.10: Avoid CamelCase +The initial primary authors and maintainers are Bjarne Stroustrup and Herb Sutter, and the guidelines so far were developed with contributions from experts at CERN, Microsoft, Morgan Stanley, and several other organizations. At the time of their release, the guidelines are in a "0.6" state, and contributions are welcome. As Stroustrup said in his announcement: "We need help!" -**Reason**: The use of underscores to separate parts of a name is the originale C and C++ style and used in the C++ standard library. -If you prefer CamelCase, you have to choose among different flavors of camelCase. +### FAQ.4: How can I contribute? -**Example**: +See [CONTRIBUTING.md](https://github.com/isocpp/CppCoreGuidelines/blob/master/CONTRIBUTING.md). We appreciate volunteer help! - ??? - -**Enforcement**: Impossible. +### FAQ.5: How can I become an editor/maintainer? +By contributing a lot first and having the consistent quality of your contributions recognized. See [CONTRIBUTING.md](https://github.com/isocpp/CppCoreGuidelines/blob/master/CONTRIBUTING.md). We appreciate volunteer help! - -### NL.15: Use spaces sparingly +### FAQ.6: Have these guidelines been approved by the ISO C++ standards committee? Do they represent the consensus of the committee? -**Reason**: Too much space makes the text larger and distracts. +No. These guidelines are outside the standard. They are intended to serve the standard, and be maintained as current guidelines about how to use the current Standard C++ effectively. We aim to keep them in sync with the standard as that is evolved by the committee. -**Example, bad**: +### FAQ.7: If these guidelines are not approved by the committee, why are they under `github.com/isocpp`? - #include < map > - - int main ( int argc , char * argv [ ] ) - { - // ... - } - -**Example**: +Because `isocpp` is the Standard C++ Foundation; the committee's repositories are under [github.com/*cplusplus*](https://github.com/cplusplus). Some neutral organization has to own the copyright and license to make it clear this is not being dominated by any one person or vendor. The natural entity is the Foundation, which exists to promote the use and up-to-date understanding of modern Standard C++ and the work of the committee. This follows the same pattern that isocpp.org did for the [C++ FAQ](https://isocpp.org/faq), which was initially the work of Bjarne Stroustrup, Marshall Cline, and Herb Sutter and contributed to the open project in the same way. - #include - - int main(int argc, char* argv[]) - { - // ... - } +### FAQ.8: Will there be a C++98 version of these Guidelines? a C++11 version? -**Note**: Some IDEs have their own opinions and adds distracting space. +No. These guidelines are about how to best use modern standard C++ and write code assuming you have a modern conforming compiler. -**Note**: We value well-placed whitespace as a significant help for readability. Just don't overdo it. +### FAQ.9: Do these guidelines propose new language features? +No. These guidelines are about how to best use modern Standard C++, and they limit themselves to recommending only those features. +### FAQ.10: What version of Markdown do these guidelines use? - -### NL.16: Use a conventional class member declaration order +These coding standards are written using [CommonMark](http://commonmark.org), and `` HTML anchors. -**Reason**: A conventional order of members improves readability. +We are considering the following extensions from [GitHub Flavored Markdown (GFM)](https://help.github.com/articles/github-flavored-markdown/): -When declaring a class use the following order +* fenced code blocks (consistently using indented vs. fenced is under discussion) +* tables (none yet but we'll likely need them, and this is a GFM extension) -* types: classes, enums, and aliases (`using`) -* constructors, assignments, destructor -* functions -* data +Avoid other HTML tags and other extensions. -Used the `public` before `protected` before `private` order. +Note: We are not yet consistent with this style. -Private types and functions can be placed with private data. +### FAQ.50: What is the GSL (guidelines support library)? -**Example**: +The GSL is the small set of types and aliases specified in these guidelines. As of this writing, their specification herein is too sparse; we plan to add a WG21-style interface specification to ensure that different implementations agree, and to propose as a contribution for possible standardization, subject as usual to whatever the committee decides to accept/improve/alter/reject. - ??? +### FAQ.51: Is [github.com/Microsoft/GSL](https://github.com/Microsoft/GSL) the GSL? -**Enforcement**: Flag departures from the suggested order. There will be a lot of old code that doesn't follow this rule. +No. That is just a first implementation contributed by Microsoft. Other implementations by other vendors are encouraged, as are forks of and contributions to that implementation. As of this writing one week into the public project, at least one GPLv3 open-source implementation already exists. We plan to produce a WG21-style interface specification to ensure that different implementations agree. +### FAQ.52: Why not supply an actual GSL implementation in/with these guidelines? - -### NL.17: Use K&R-derived layout +We are reluctant to bless one particular implementation because we do not want to make people think there is only one, and inadvertently stifle parallel implementations. And if these guidelines included an actual implementation, then whoever contributed it could be mistakenly seen as too influential. We prefer to follow the long-standing approach of the committee, namely to specify interfaces, not implementations. But at the same time we want at least one implementation available; we hope for many. -**Reason**: This is the original C and C++ layout. It preserves vertical space well. It distinguishes different language constructs (such as functions and classes well). +### FAQ.53: Why weren't the GSL types proposed through Boost? -**Note**: In the context of C++, this style is often called "Stroustrup". +Because we want to use them immediately, and because they are temporary in that we want to retire them as soon as types that fill the same needs exist in the standard library. -**Example**: +### FAQ.54: Has the GSL (guidelines support library) been approved by the ISO C++ standards committee? - struct Cable { - int x; - // ... - }; - - double foo(int x) - { - if (0FAQ.55: If you're using the standard types where available, why is the GSL `span` different from the `string_view` in the Library Fundamentals 1 Technical Specification and C++17 Working Paper? Why not just use the committee-approved `string_view`? -**Note**: Use separate lines for each statement, the branches of an `if`, and the body of a `for`. +The consensus on the taxonomy of views for the C++ Standard Library was that "view" means "read-only", and "span" means "read/write". If you only need a read-only view of characters that does not need guaranteed bounds-checking and you have C++17, use C++17 `std::string_view`. Otherwise, if you need a read-write view that does not need guaranteed bounds-checking and you have C++20, use C++20 `std::span`. Otherwise, use `gsl::span`. -**Note** the `{` for a `class` and a `struct` in *not* on a separate line, but the `{` for a function is. +### FAQ.56: Is `owner` the same as the proposed `observer_ptr`? -**Note**: Capitalize the names of your user-defined types to distinguish them from standards-library types. +No. `owner` owns, is an alias, and can be applied to any indirection type. The main intent of `observer_ptr` is to signify a *non*-owning pointer. -**Note**: Do not capitalize function names. - -**Enforcement**: If you want enforcement, use an IDE to reformat. - +### FAQ.57: Is `stack_array` the same as the standard `array`? - -### NL.18: Use C++-style declarator layout +No. `stack_array` is guaranteed to be allocated on the stack. Although a `std::array` contains its storage directly inside itself, the `array` object can be put anywhere, including the heap. -**Reason**: The C-style layout emphasizes use in expressions and grammar, whereas the C++-style emphasizes types. -The use in expressions argument doesn't hold for references. +### FAQ.58: Is `dyn_array` the same as `vector` or the proposed `dynarray`? -**Example**: +No. `dyn_array` is a container, like `vector`, but it is not resizable; its size is fixed at runtime when it is constructed. +It is a safe way to refer to a dynamically "heap"-allocated fixed-size array. Unlike `vector`, it is intended to replace array-`new[]`. Unlike the `dynarray` that has been proposed in the committee, this does not anticipate compiler/language magic to somehow allocate it on the stack when it is a member of an object that is allocated on the stack; it simply refers to a "dynamic" or heap-based array. - T& operator[](size_t); // OK - T &operator[](size_t); // just strange - T & operator[](size_t); // undecided +### FAQ.59: Is `Expects` the same as `assert`? -**Enforcement**: Impossible in the face of history. +No. It is a placeholder for language support for contract preconditions. +### FAQ.60: Is `Ensures` the same as `assert`? - -# Appendix A: Libraries +No. It is a placeholder for language support for contract postconditions. + +# Appendix A: Libraries This section lists recommended libraries, and explicitly recommends a few. ??? Suitable for the general guide? I think not ??? - - -# Appendix B: Modernizing code +# Appendix B: Modernizing code Ideally, we follow all rules in all code. Realistically, we have to deal with a lot of old code: * application code written before the guidelines were formulated or known * libraries written to older/different standards +* code written under "unusual" constraints * code that we just haven't gotten around to modernizing If we have a million lines of new code, the idea of "just changing it all at once" is typically unrealistic. @@ -11774,10 +22204,10 @@ Thus, we need a way of gradually modernizing a code base. Upgrading older code to modern style can be a daunting task. Often, the old code is both a mess (hard to understand) and working correctly (for the current range of uses). -Typically, the original programmer is not around and test cases incomplete. -The fact that the code is a mess dramatically increases to effort needed to make any change and the risk of introducing errors. -Often messy, old code runs unnecessarily slowly because it requires outdated compilers and cannot take advantage of modern hardware. -In many cases, programs support would be required for major upgrade efforts. +Typically, the original programmer is not around and the test cases incomplete. +The fact that the code is a mess dramatically increases the effort needed to make any change and the risk of introducing errors. +Often, messy old code runs unnecessarily slowly because it requires outdated compilers and cannot take advantage of modern hardware. +In many cases, automated "modernizer"-style tool support would be required for major upgrade efforts. The purpose of modernizing code is to simplify adding new functionality, to ease maintenance, and to increase performance (throughput or latency), and to better utilize modern hardware. Making code "look pretty" or "follow modern style" are not by themselves reasons for change. @@ -11791,11 +22221,12 @@ How best to do it depends on the code, the pressure for updates, the backgrounds Here are some (very general) ideas: * The ideal is "just upgrade everything." That gives the most benefits for the shortest total time. -In most circumstances, it is also impossible. -* We could convert a code base module for module, but any rules that affects interfaces (especially ABIs), such as [use `array_view`](#SS-views), cannot be done on a per-module basis. + In most circumstances, it is also impossible. +* We could convert a code base module for module, but any rules that affects interfaces (especially ABIs), such as [use `span`](#SS-views), cannot be done on a per-module basis. * We could convert code "bottom up" starting with the rules we estimate will give the greatest benefits and/or the least trouble in a given code base. * We could start by focusing on the interfaces, e.g., make sure that no resources are lost and no pointer is misused. -This would be a set of changes across the whole code base, but would most likely have huge benefits. + This would be a set of changes across the whole code base, but would most likely have huge benefits. + Afterwards, code hidden behind those interfaces can be gradually modernized without affecting other code. Whichever way you choose, please note that the most advantages come with the highest conformance to the guidelines. The guidelines are not a random set of unrelated rules where you can randomly pick and choose with an expectation of success. @@ -11803,154 +22234,175 @@ The guidelines are not a random set of unrelated rules where you can randomly pi We would dearly love to hear about experience and about tools used. Modernization can be much faster, simpler, and safer when supported with analysis tools and even code transformation tools. - - -# Appendix C: Discussion +# Appendix C: Discussion This section contains follow-up material on rules and sets of rules. In particular, here we present further rationale, longer examples, and discussions of alternatives. -### Discussion: Define and initialize member variables in the order of member declaration - -Member variables are always initialized in the order they are declared in the class definition, so write them in that order in the constructor initialization list. Writing them in a different order just makes the code confusing because it won't run in the order you see, and that can make it hard to see order-dependent bugs. +### Discussion: Define and initialize data members in the order of member declaration - class Employee { - string email, first, last; - public: - Employee(const char* firstName, const char* lastName); - // ... - }; +Data members are always initialized in the order they are declared in the class definition, so write them in that order in the constructor initialization list. Writing them in a different order just makes the code confusing because it won't run in the order you see, and that can make it hard to see order-dependent bugs. - Employee::Employee(const char* firstName, const char* lastName) - : first(firstName) - , last(lastName) - , email(first + "." + last + "@acme.com") // BAD: first and last not yet constructed - {} + class Employee { + string email, first, last; + public: + Employee(const char* firstName, const char* lastName); + // ... + }; + Employee::Employee(const char* firstName, const char* lastName) + : first(firstName), + last(lastName), + // BAD: first and last not yet constructed + email(first + "." + last + "@acme.com") + {} In this example, `email` will be constructed before `first` and `last` because it is declared first. That means its constructor will attempt to use `first` and `last` too soon -- not just before they are set to the desired values, but before they are constructed at all. -If the class definition and the constructor body are in separate files, the long-distance influence that the order of member variable declarations has over the constructor's correctness will be even harder to spot. +If the class definition and the constructor body are in separate files, the long-distance influence that the order of data member declarations has over the constructor's correctness will be even harder to spot. -**References** +**References**: -[Cline99] §22.03-11 ï‚Ÿ [Dewhurst03] §52-53 ï‚Ÿ [Koenig97] §4 ï‚Ÿ [Lakos96] §10.3.5 ï‚Ÿ [Meyers97] §13 ï‚Ÿ [Murray93] §2.1.3 ï‚Ÿ [Sutter00] §47 +[\[Cline99\]](#Cline99) §22.03-11, [\[Dewhurst03\]](#Dewhurst03) §52-53, [\[Koenig97\]](#Koenig97) §4, [\[Lakos96\]](#Lakos96) §10.3.5, [\[Meyers97\]](#Meyers97) §13, [\[Murray93\]](#Murray93) §2.1.3, [\[Sutter00\]](#Sutter00) §47 -### Use of `=`, `{}`, and `()` as initializers +### Discussion: Use of `=`, `{}`, and `()` as initializers ??? -### Discussion: Use a factory function if you need "virtual behavior" during initialization +### Discussion: Use a factory function if you need "virtual behavior" during initialization If your design wants virtual dispatch into a derived class from a base class constructor or destructor for functions like `f` and `g`, you need other techniques, such as a post-constructor -- a separate member function the caller must invoke to complete initialization, which can safely call `f` and `g` because in member functions virtual calls behave normally. Some techniques for this are shown in the References. Here's a non-exhaustive list of options: - * *Pass the buck:* Just document that user code must call the post-initialization function right after constructing an object. - * *Post-initialize lazily:* Do it during the first call of a member function. A Boolean flag in the base class tells whether or not post-construction has taken place yet. - * *Use virtual base class semantics:* Language rules dictate that the constructor most-derived class decides which base constructor will be invoked; you can use that to your advantage. (See [Taligent94].) - * *Use a factory function:* This way, you can easily force a mandatory invocation of a post-constructor function. +* *Pass the buck:* Just document that user code must call the post-initialization function right after constructing an object. +* *Post-initialize lazily:* Do it during the first call of a member function. A Boolean flag in the base class tells whether or not post-construction has taken place yet. +* *Use virtual base class semantics:* Language rules dictate that the constructor of the most-derived class decides which base constructor will be invoked; you can use that to your advantage. (See [\[Taligent94\]](#Taligent94).) +* *Use a factory function:* This way, you can easily force a mandatory invocation of a post-constructor function. Here is an example of the last option: - class B { - public: - B() { /* ... */ f(); /*...*/ } // BAD: see Item 49.1 + class B { + public: + B() + { + /* ... */ + f(); // BAD: C.82: Don't call virtual functions in constructors and destructors + /* ... */ + } + + virtual void f() = 0; + }; + + class B { + protected: + class Token {}; - virtual void f() = 0; + public: + // constructor needs to be public so that make_shared can access it. + // protected access level is gained by requiring a Token. + explicit B(Token) { /* ... */ } // create an imperfectly initialized object + virtual void f() = 0; + + template + static shared_ptr create() // interface for creating shared objects + { + auto p = make_shared(typename T::Token{}); + p->post_initialize(); + return p; + } - // ... - }; + protected: + virtual void post_initialize() // called right after construction + { /* ... */ f(); /* ... */ } // GOOD: virtual dispatch is safe + } + }; - class B { - protected: - B() { /* ... */ } - virtual void PostInitialize() // called right after construction - { /* ... */ f(); /*...*/ } // GOOD: virtual dispatch is safe - public: - virtual void f() = 0; - template - static shared_ptr Create() { // interface for creating objects - auto p = make_shared(); - p->PostInitialize(); - return p; - } - }; + class D : public B { // some derived class + protected: + class Token {}; - class D : public B { /* "¦ */ }; // some derived class + public: + // constructor needs to be public so that make_shared can access it. + // protected access level is gained by requiring a Token. + explicit D(Token) : B{ B::Token{} } {} + void f() override { /* ... */ }; + + protected: + template + friend shared_ptr B::create(); + }; - shared_ptr p = D::Create(); // creating a D object + shared_ptr p = D::create(); // creating a D object This design requires the following discipline: -* Derived classes such as `D` must not expose a public constructor. Otherwise, `D`'s users could create `D` objects that don't invoke `PostInitialize`. -* Allocation is limited to `operator new`. `B` can, however, override `new` (see Items 45 and 46). -* `D` must define a constructor with the same parameters that `B` selected. Defining several overloads of `Create` can assuage this problem, however; and the overloads can even be templated on the argument types. +* Derived classes such as `D` must not expose a publicly callable constructor. Otherwise, `D`'s users could create `D` objects that don't invoke `post_initialize`. +* Allocation is limited to `operator new`. `B` can, however, override `new` (see Items 45 and 46 in [SuttAlex05](#SuttAlex05)). +* `D` must define a constructor with the same parameters that `B` selected. Defining several overloads of `create` can assuage this problem, however; and the overloads can even be templated on the argument types. -If the requirements above are met, the design guarantees that `PostInitialize` has been called for any fully constructed `B`-derived object. `PostInitialize` doesn't need to be virtual; it can, however, invoke virtual functions freely. +If the requirements above are met, the design guarantees that `post_initialize` has been called for any fully constructed `B`-derived object. `post_initialize` doesn't need to be virtual; it can, however, invoke virtual functions freely. In summary, no post-construction technique is perfect. The worst techniques dodge the whole issue by simply asking the caller to invoke the post-constructor manually. Even the best require a different syntax for constructing objects (easy to check at compile time) and/or cooperation from derived class authors (impossible to check at compile time). -**References**: [Alexandrescu01] §3 ï‚Ÿ [Boost] ï‚Ÿ [Dewhurst03] §75 ï‚Ÿ [Meyers97] §46 ï‚Ÿ [Stroustrup00] §15.4.3 ï‚Ÿ [Taligent94] +**References**: [\[Alexandrescu01\]](#Alexandrescu01) §3, [\[Boost\]](#Boost), [\[Dewhurst03\]](#Dewhurst03) §75, [\[Meyers97\]](#Meyers97) §46, [\[Stroustrup00\]](#Stroustrup00) §15.4.3, [\[Taligent94\]](#Taligent94) - +### Discussion: Make base class destructors public and virtual, or protected and non-virtual - +Should destruction behave virtually? That is, should destruction through a pointer to a `base` class be allowed? If yes, then `base`'s destructor must be public in order to be callable, and virtual otherwise calling it results in undefined behavior. Otherwise, it should be protected so that only derived classes can invoke it in their own destructors, and non-virtual since it doesn't need to behave virtually. -###Discussion: Make base class destructors public and virtual, or protected and nonvirtual +##### Example -Should destruction behave virtually? That is, should destruction through a pointer to a `base` class should be allowed? If yes, then `base`'s destructor must be public in order to be callable, and virtual otherwise calling it results in undefined behavior. Otherwise, it should be protected so that only derived classes can invoke it in their own destructors, and nonvirtual since it doesn't need to behave virtually virtual. +The common case for a base class is that it's intended to have publicly derived classes, and so calling code is just about sure to use something like a `shared_ptr`: -**Example**: The common case for a base class is that it's intended to have publicly derived classes, and so calling code is just about sure to use something like a `shared_ptr`: - -``` -class base { -public: - ~base(); // BAD, not virtual - virtual ~base(); // GOOD - // ... -}; + class Base { + public: + ~Base(); // BAD, not virtual + virtual ~Base(); // GOOD + // ... + }; -class derived : public base { /*...*/ }; + class Derived : public Base { /* ... */ }; -{ - shared_ptr pb = make_shared(); - // ... -} // ~pb invokes correct destructor only when ~base is virtual -``` + { + unique_ptr pb = make_unique(); + // ... + } // ~pb invokes correct destructor only when ~Base is virtual -In rarer cases, such as policy classes, the class is used as a base class for convenience, not for polymorphic behavior. It is recommended to make those destructors protected and nonvirtual: +In rarer cases, such as policy classes, the class is used as a base class for convenience, not for polymorphic behavior. It is recommended to make those destructors protected and non-virtual: -``` -class my_policy { -public: - virtual ~my_policy(); // BAD, public and virtual -protected: - ~my_policy(); // GOOD - // ... -}; + class My_policy { + public: + virtual ~My_policy(); // BAD, public and virtual + protected: + ~My_policy(); // GOOD + // ... + }; + + template + class customizable : Policy { /* ... */ }; // note: private inheritance -template -class customizable : Policy { /*...*/ }; // note: private inheritance -``` +##### Note -**Note**: This simple guideline illustrates a subtle issue and reflects modern uses of inheritance and object-oriented design principles. +This simple guideline illustrates a subtle issue and reflects modern uses of inheritance and object-oriented design principles. -For a base class `Base`, calling code might try to destroy derived objects through pointers to `Base`, such as when using a `shared_ptr`. If `Base`'s destructor is public and nonvirtual (the default), it can be accidentally called on a pointer that actually points to a derived object, in which case the behavior of the attempted deletion is undefined. This state of affairs has led older coding standards to impose a blanket requirement that all base class destructors must be virtual. This is overkill (even if it is the common case); instead, the rule should be to make base class destructors virtual if and only if they are public. +For a base class `Base`, calling code might try to destroy derived objects through pointers to `Base`, such as when using a `unique_ptr`. If `Base`'s destructor is public and non-virtual (the default), it can be accidentally called on a pointer that actually points to a derived object, in which case the behavior of the attempted deletion is undefined. This state of affairs has led older coding standards to impose a blanket requirement that all base class destructors must be virtual. This is overkill (even if it is the common case); instead, the rule should be to make base class destructors virtual if and only if they are public. To write a base class is to define an abstraction (see Items 35 through 37). Recall that for each member function participating in that abstraction, you need to decide: * Whether it should behave virtually or not. -* Whether it should be publicly available to all callers using a pointer to Base or else be a hidden internal implementation detail. +* Whether it should be publicly available to all callers using a pointer to `Base` or else be a hidden internal implementation detail. -As described in Item 39, for a normal member function, the choice is between allowing it to be called via a pointer to `Base` nonvirtually (but possibly with virtual behavior if it invokes virtual functions, such as in the NVI or Template Method patterns), virtually, or not at all. The NVI pattern is a technique to avoid public virtual functions. +As described in Item 39, for a normal member function, the choice is between allowing it to be called via a pointer to `Base` non-virtually (but possibly with virtual behavior if it invokes virtual functions, such as in the NVI or Template Method patterns), virtually, or not at all. The NVI pattern is a technique to avoid public virtual functions. -Destruction can be viewed as just another operation, albeit with special semantics that make nonvirtual calls dangerous or wrong. For a base class destructor, therefore, the choice is between allowing it to be called via a pointer to `Base` virtually or not at all; "nonvirtually" is not an option. Hence, a base class destructor is virtual if it can be called (i.e., is public), and nonvirtual otherwise. +Destruction can be viewed as just another operation, albeit with special semantics that make non-virtual calls dangerous or wrong. For a base class destructor, therefore, the choice is between allowing it to be called via a pointer to `Base` virtually or not at all; "non-virtually" is not an option. Hence, a base class destructor is virtual if it can be called (i.e., is public), and non-virtual otherwise. Note that the NVI pattern cannot be applied to the destructor because constructors and destructors cannot make deep virtual calls. (See Items 39 and 55.) -Corollary: When writing a base class, always write a destructor explicitly, because the implicitly generated one is public and nonvirtual. You can always `=default` the implementation if the default body is fine and you're just writing the function to give it the proper visibility and virtuality. +Corollary: When writing a base class, always write a destructor explicitly, because the implicitly generated one is public and non-virtual. You can always `=default` the implementation if the default body is fine and you're just writing the function to give it the proper visibility and virtuality. -**Exception**: Some component architectures (e.g., COM and CORBA) don't use a standard deletion mechanism, and foster different protocols for object disposal. Follow the local patterns and idioms, and adapt this guideline as appropriate. +##### Exception + +Some component architectures (e.g., COM and CORBA) don't use a standard deletion mechanism, and foster different protocols for object disposal. Follow the local patterns and idioms, and adapt this guideline as appropriate. Consider also this rare case: @@ -11959,100 +22411,97 @@ Consider also this rare case: Then, even though the destructor has to be public, there can be great pressure to not make it virtual because as the first virtual function it would incur all the run-time type overhead when the added functionality should never be needed. -In this rare case, you could make the destructor public and nonvirtual but clearly document that further-derived objects must not be used polymorphically as `B`'s. This is what was done with `std::unary_function`. +In this rare case, you could make the destructor public and non-virtual but clearly document that further-derived objects must not be used polymorphically as `B`'s. This is what was done with `std::unary_function`. + +In general, however, avoid concrete base classes (see Item 35). For example, `unary_function` is a bundle-of-typedefs that was never intended to be instantiated standalone. It really makes no sense to give it a public destructor; a better design would be to follow this Item's advice and give it a protected non-virtual destructor. -In general, however, avoid concrete base classes (see Item 35). For example, `unary_function` is a bundle-of-typedefs that was never intended to be instantiated standalone. It really makes no sense to give it a public destructor; a better design would be to follow this Item's advice and give it a protected nonvirtual destructor. +**References**: [\[SuttAlex05\]](#SuttAlex05) Item 50, [\[Cargill92\]](#Cargill92) pp. 77-79, 207, [\[Cline99\]](#Cline99) §21.06, 21.12-13, [\[Henricson97\]](#Henricson97) pp. 110-114, [\[Koenig97\]](#Koenig97) Chapters 4, 11, [\[Meyers97\]](#Meyers97) §14, [\[Stroustrup00\]](#Stroustrup00) §12.4.2, [\[Sutter02\]](#Sutter02) §27, [\[Sutter04\]](#Sutter04) §18 +### Discussion: Usage of noexcept -**References**: [C++CS Item 50]; [Cargill92] pp. 77-79, 207 Ÿ [Cline99] §21.06, 21.12-13 Ÿ [Henricson97] pp. 110-114 Ÿ [Koenig97] Chapters 4, 11 Ÿ [Meyers97] §14 Ÿ [Stroustrup00] §12.4.2 Ÿ [Sutter02] §27 Ÿ [Sutter04] §18 +??? +### Discussion: Destructors, deallocation, and swap must never fail +Never allow an error to be reported from a destructor, a resource deallocation function (e.g., `operator delete`), or a `swap` function using `throw`. It is nearly impossible to write useful code if these operations can fail, and even if something does go wrong it nearly never makes any sense to retry. Specifically, types whose destructors might throw an exception are flatly forbidden from use with the C++ Standard Library. Most destructors are now implicitly `noexcept` by default. +##### Example + class Nefarious { + public: + Nefarious() { /* code that could throw */ } // ok + ~Nefarious() { /* code that could throw */ } // BAD, should not throw + // ... + }; - -### Dicussion: Destructors, deallocation, and swap must never fail +1. `Nefarious` objects are hard to use safely even as local variables: -Never allow an error to be reported from a destructor, a resource deallocation function (e.g., `operator delete`), or a `swap` function using `throw`. It is nearly impossible to write useful code if these operations can fail, and even if something does go wrong it nearly never makes any sense to retry. Specifically, types whose destructors may throw an exception are flatly forbidden from use with the C++ standard library. Most destructors are now implicitly `noexcept` by default. -**Example**: + void test(string& s) + { + Nefarious n; // trouble brewing + string copy = s; // copy the string + } // destroy copy and then n -``` -class nefarious { -public: - nefarious() { /* code that could throw */ } // ok - ~nefarious() { /* code that could throw */ } // BAD, should be noexcept - // ... -}; -``` + Here, copying `s` could throw, and if that throws and if `n`'s destructor then also throws, the program will exit via `std::terminate` because two exceptions can't be propagated simultaneously. -* 1. `nefarious` objects are hard to use safely even as local variables: +2. Classes with `Nefarious` members or bases are also hard to use safely, because their destructors must invoke `Nefarious`' destructor, and are similarly poisoned by its bad behavior: -``` -void test(string& s) { - nefarious n; // trouble brewing - string copy = s; // copy the string -} // destroy copy and then n -``` -Here, copying `s` could throw, and if that throws and if `n`'s destructor then also throws, the program will exit via `std::terminate` because two exceptions can't be propagated simultaneously. -* 2. Classes with `nefarious` members or bases are also hard to use safely, because their destructors must invoke `nefarious`' destructor, and are similarly poisoned by its poor behavior: + class Innocent_bystander { + Nefarious member; // oops, poisons the enclosing class's destructor + // ... + }; -``` -class innocent_bystander { - nefarious member; // oops, poisons the enclosing class's destructor - // ... -}; + void test(string& s) + { + Innocent_bystander i; // more trouble brewing + string copy2 = s; // copy the string + } // destroy copy and then i -void test(string& s) { - innocent_bystander i; // more trouble brewing - string copy = s; // copy the string -} // destroy copy and then i -``` + Here, if constructing `copy2` throws, we have the same problem because `i`'s destructor now also can throw, and if so we'll invoke `std::terminate`. -Here, if constructing `copy2` throws, we have the same problem because `i`'s destructor now also can throw, and if so we'll invoke `std::terminate`. +3. You can't reliably create global or static `Nefarious` objects either: -* 3. You can't reliably create global or static `nefarious` objects either: -``` -static nefarious n; // oops, any destructor exception can't be caught -``` + static Nefarious n; // oops, any destructor exception can't be caught -* 4. You can't reliably create arrays of `nefarious`: +4. You can't reliably create arrays of `Nefarious`: -``` -void test() { - std::array arr; // this line can std::terminate(!) -``` -The behavior of arrays is undefined in the presence of destructors that throw because there is no reasonable rollback behavior that could ever be devised. Just think: What code can the compiler generate for constructing an `arr` where, if the fourth object's constructor throws, the code has to give up and in its cleanup mode tries to call the destructors of the already-constructed objects... and one or more of those destructors throws? There is no satisfactory answer. + void test() + { + std::array arr; // this line can std::terminate() + } + + The behavior of arrays is undefined in the presence of destructors that throw because there is no reasonable rollback behavior that could ever be devised. Just think: What code can the compiler generate for constructing an `arr` where, if the fourth object's constructor throws, the code has to give up and in its cleanup mode tries to call the destructors of the already-constructed objects ... and one or more of those destructors throws? There is no satisfactory answer. -* 5. You can't use `Nefarious` objects in standard containers: +5. You can't use `Nefarious` objects in standard containers: -``` -std::vector vec(10); // this is line can std::terminate() -``` -The standard library forbids all destructors used with it from throwing. You can't store `nefarious` objects in standard containers or use them with any other part of the standard library. + std::vector vec(10); // this line can std::terminate() + The standard library forbids all destructors used with it from throwing. You can't store `Nefarious` objects in standard containers or use them with any other part of the standard library. -**Note**: These are key functions that must not fail because they are necessary for the two key operations in transactional programming: to back out work if problems are encountered during processing, and to commit work if no problems occur. If there's no way to safely back out using no-fail operations, then no-fail rollback is impossible to implement. If there's no way to safely commit state changes using a no-fail operation (notably, but not limited to, `swap`), then no-fail commit is impossible to implement. +##### Note + +These are key functions that must not fail because they are necessary for the two key operations in transactional programming: to back out work if problems are encountered during processing, and to commit work if no problems occur. If there's no way to safely back out using no-fail operations, then no-fail rollback is impossible to implement. If there's no way to safely commit state changes using a no-fail operation (notably, but not limited to, `swap`), then no-fail commit is impossible to implement. Consider the following advice and requirements found in the C++ Standard: -> If a destructor called during stack unwinding exits with an exception, terminate is called (15.5.1). So destructors should generally catch exceptions and not let them propagate out of the destructor. --[C++03] §15.2(3) +> If a destructor called during stack unwinding exits with an exception, terminate is called (15.5.1). So destructors should generally catch exceptions and not let them propagate out of the destructor. --[\[C++03\]](#Cplusplus03) §15.2(3) > -> No destructor operation defined in the C++ Standard Library [including the destructor of any type that is used to instantiate a standard library template] will throw an exception. --[C++03] §17.4.4.8(3) +> No destructor operation defined in the C++ Standard Library (including the destructor of any type that is used to instantiate a standard-library template) will throw an exception. --[\[C++03\]](#Cplusplus03) §17.4.4.8(3) Deallocation functions, including specifically overloaded `operator delete` and `operator delete[]`, fall into the same category, because they too are used during cleanup in general, and during exception handling in particular, to back out of partial work that needs to be undone. -Besides destructors and deallocation functions, common error-safety techniques rely also on `swap` operations never failing--in this case, not because they are used to implement a guaranteed rollback, but because they are used to implement a guaranteed commit. For example, here is an idiomatic implementation of `operator=` for a type `T` that performs copy construction followed by a call to a no-fail `swap`: +Besides destructors and deallocation functions, common error-safety techniques rely also on `swap` operations never failing -- in this case, not because they are used to implement a guaranteed rollback, but because they are used to implement a guaranteed commit. For example, here is an idiomatic implementation of `operator=` for a type `T` that performs copy construction followed by a call to a no-fail `swap`: -``` -T& T::operator=( const T& other ) { - auto temp = other; - swap(temp); -} -``` + T& T::operator=(const T& other) + { + auto temp = other; + swap(temp); + return *this; + } (See also Item 56. ???) @@ -12060,319 +22509,577 @@ Fortunately, when releasing a resource, the scope for failure is definitely smal When using exceptions as your error handling mechanism, always document this behavior by declaring these functions `noexcept`. (See Item 75.) +**References**: [\[SuttAlex05\]](#SuttAlex05) Item 51; [\[C++03\]](#Cplusplus03) §15.2(3), §17.4.4.8(3), [\[Meyers96\]](#Meyers96) §11, [\[Stroustrup00\]](#Stroustrup00) §14.4.7, §E.2-4, [\[Sutter00\]](#Sutter00) §8, §16, [\[Sutter02\]](#Sutter02) §18-19 -**References**: C++CS Item 51; [C++03] §15.2(3), §17.4.4.8(3) Ÿ [Meyers96] §11 Ÿ [Stroustrup00] §14.4.7, §E.2-4 Ÿ [Sutter00] §8, §16 Ÿ [Sutter02] §18-19 - - - +## Define Copy, move, and destroy consistently -## Define Copy, move, and destroy consistently +##### Reason -**Reason**: ??? + ??? +##### Note -**Note**: If you define a copy constructor, you must also define a copy assignment operator. +If you define a copy constructor, you must also define a copy assignment operator. -**Note**: If you define a move constructor, you must also define a move assignment operator. +##### Note +If you define a move constructor, you must also define a move assignment operator. -**Example**: +##### Example - class x { - // ... + class X { public: - x(const x&) { /* stuff */ } + X(const X&) { /* stuff */ } // BAD: failed to also define a copy assignment operator - x(x&&) { /* stuff */ } + X(x&&) noexcept { /* stuff */ } // BAD: failed to also define a move assignment operator + + // ... }; - x x1; - x x2 = x1; // ok + X x1; + X x2 = x1; // ok x2 = x1; // pitfall: either fails to compile, or does something suspicious - If you define a destructor, you should not use the compiler-generated copy or move operation; you probably need to define or suppress copy and/or move. + class X { + HANDLE hnd; + // ... + public: + ~X() { /* custom stuff, such as closing hnd */ } + // suspicious: no mention of copying or moving -- what happens to hnd? + }; - class X { - HANDLE hnd; - // ... - public: - ~X() { /* custom stuff, such as closing hnd */ } - - // suspicious: no mention of copying or moving -- what happens to hnd? - }; - - X x1; - X x2 = x1; // pitfall: either fails to compile, or does something suspicious - x2 = x1; // pitfall: either fails to compile, or does something suspicious + X x1; + X x2 = x1; // pitfall: either fails to compile, or does something suspicious + x2 = x1; // pitfall: either fails to compile, or does something suspicious If you define copying, and any base or member has a type that defines a move operation, you should also define a move operation. - class x { - string s; // defines more efficient move operations - // ... other data members ... - public: - x(const x&) { /* stuff */ } - x& operator=(const x&) { /* stuff */ } + class X { + string s; // defines more efficient move operations + // ... other data members ... + public: + X(const X&) { /* stuff */ } + X& operator=(const X&) { /* stuff */ } - // BAD: failed to also define a move construction and move assignment - // (why wasn't the custom "stuff" repeated here?) - }; + // BAD: failed to also define a move construction and move assignment + // (why wasn't the custom "stuff" repeated here?) + }; - x test() - { - x local; - // ... - return local; // pitfall: will be inefficient and/or do the wrong thing - } + X test() + { + X local; + // ... + return local; // pitfall: will be inefficient and/or do the wrong thing + } If you define any of the copy constructor, copy assignment operator, or destructor, you probably should define the others. -**Note**: If you need to define any of these five functions, it means you need it to do more than its default behavior--and the five are asymmetrically interrelated. Here's how: +##### Note + +If you need to define any of these five functions, it means you need it to do more than its default behavior -- and the five are asymmetrically interrelated. Here's how: * If you write/disable either of the copy constructor or the copy assignment operator, you probably need to do the same for the other: If one does "special" work, probably so should the other because the two functions should have similar effects. (See Item 53, which expands on this point in isolation.) * If you explicitly write the copying functions, you probably need to write the destructor: If the "special" work in the copy constructor is to allocate or duplicate some resource (e.g., memory, file, socket), you need to deallocate it in the destructor. -* If you explicitly write the destructor, you probably need to explicitly write or disable copying: If you have to write a nontrivial destructor, it's often because you need to manually release a resource that the object held. If so, it is likely that those resources require careful duplication, and then you need to pay attention to the way objects are copied and assigned, or disable copying completely. +* If you explicitly write the destructor, you probably need to explicitly write or disable copying: If you have to write a non-trivial destructor, it's often because you need to manually release a resource that the object held. If so, it is likely that those resources require careful duplication, and then you need to pay attention to the way objects are copied and assigned, or disable copying completely. In many cases, holding properly encapsulated resources using RAII "owning" objects can eliminate the need to write these operations yourself. (See Item 13.) -Prefer compiler-generated (including `=default`) special members; only these can be classified as "trivial," and at least one major standard library vendor heavily optimizes for classes having trivial special members. This is likely to become common practice. +Prefer compiler-generated (including `=default`) special members; only these can be classified as "trivial", and at least one major standard library vendor heavily optimizes for classes having trivial special members. This is likely to become common practice. -**Exceptions**: When any of the special functions are declared only to make them nonpublic or virtual, but without special semantics, it doesn't imply that the others are needed. +**Exceptions**: When any of the special functions are declared only to make them non-public or virtual, but without special semantics, it doesn't imply that the others are needed. In rare cases, classes that have members of strange types (such as reference members) are an exception because they have peculiar copy semantics. In a class holding a reference, you likely need to write the copy constructor and the assignment operator, but the default destructor already does the right thing. (Note that using a reference member is almost always wrong.) -**References**: C++CS Item 52; [Cline99] §30.01-14 Ÿ [Koenig97] §4 Ÿ [Stroustrup00] §5.5, §10.4 Ÿ [SuttHysl04b] +**References**: [\[SuttAlex05\]](#SuttAlex05) Item 52; [\[Cline99\]](#Cline99) §30.01-14, [\[Koenig97\]](#Koenig97) §4, [\[Stroustrup00\]](#Stroustrup00) §5.5, §10.4, [\[SuttHysl04b\]](#SuttHysl04b) +Resource management rule summary: +* [Provide strong resource safety; that is, never leak anything that you think of as a resource](#Cr-safety) +* [Never return or throw while holding a resource not owned by a handle](#Cr-never) +* [A "raw" pointer or reference is never a resource handle](#Cr-raw) +* [Never let a pointer outlive the object it points to](#Cr-outlive) +* [Use templates to express containers (and other resource handles)](#Cr-templates) +* [Return containers by value (relying on move or copy elision for efficiency)](#Cr-value-return) +* [If a class is a resource handle, it needs a constructor, a destructor, and copy and/or move operations](#Cr-handle) +* [If a class is a container, give it an initializer-list constructor](#Cr-list) -Resource management rule summary: +### Discussion: Provide strong resource safety; that is, never leak anything that you think of as a resource -* [Provide strong resource safety; that is, never leak anything that you think of as a resource](#Cr safety) -* [Never throw while holding a resource not owned by a handle](#Cr never) -* [A "raw" pointer or reference is never a resource handle](#Cr raw) -* [Never let a pointer outlive the object it points to](#Cr outlive) -* [Use templates to express containers (and other resource handles)](#Cr templates) -* [Return containers by value (relying on move for efficiency)](#Cr value return) -* [If a class is a resource handle, it needs a constructor, a destructor, and copy and/or move operations](#Cr handle) -* [If a class is a container, give it an initializer-list constructor](#Cr list) +##### Reason +Prevent leaks. Leaks can lead to performance degradation, mysterious error, system crashes, and security violations. +**Alternative formulation**: Have every resource represented as an object of some class managing its lifetime. -### Provide strong resource safety; that is, never leak anything that you think of as a resource +##### Example -**Reason**: Prevent leaks. Leaks can lead to performance degradation, mysterious error, system crashes, and security violations. + template + class Vector { + private: + T* elem; // sz elements on the free store, owned by the class object + int sz; + // ... + }; -**Alternative formulation**: Have every resource represented as an object of some class managing its lifetime. +This class is a resource handle. It manages the lifetime of the `T`s. To do so, `Vector` must define or delete [the copy, move, and destruction operations](#Rc-five). -**Example**: +##### Example - template - class Vector { - // ... - private: - T* elem; // sz elements on the free store, owned by the class object - int sz; - }; + ??? "odd" non-memory resource ??? -This class is a resource handle. It manages the lifetime of the `T`s. To do so, `Vector` must define or delete the set of special operations (constructors, a destructor, etc.). +##### Enforcement -**Example**: +The basic technique for preventing leaks is to have every resource owned by a resource handle with a suitable destructor. A checker can find "naked `new`s". Given a list of C-style allocation functions (e.g., `fopen()`), a checker can also find uses that are not managed by a resource handle. In general, "naked pointers" can be viewed with suspicion, flagged, and/or analyzed. A complete list of resources cannot be generated without human input (the definition of "a resource" is necessarily too general), but a tool can be "parameterized" with a resource list. - ??? "odd" non-memory resource ??? +### Discussion: Never return or throw while holding a resource not owned by a handle -**Enforcement**: The basic technique for preventing leaks is to have every resource owned by a resource handle with a suitable destructor. A checker can find "naked `new`s". Given a list of C-style allocation functions (e.g., `fopen()`), a checker can also find uses that are not managed by a resource handle. In general, "naked pointers" can be viewed with suspicion, flagged, and/or analyzed. A a complete list of resources cannot be generated without human input (the definition of "a resource" is necessarily too general), but a tool can be "parameterized" with a resource list. +##### Reason +That would be a leak. -### Never throw while holding a resource not owned by a handle +##### Example -**Reason**: That would be a leak. + void f(int i) + { + FILE* f = fopen("a file", "r"); + ifstream is { "another file" }; + // ... + if (i == 0) return; + // ... + fclose(f); + } -**Example**: - - void f(int i) - { - FILE* f = fopen("a file","r"); - ifstream is { "another file" }; - // ... - if (i==0) return; - // ... - fclose(f); - } +If `i == 0` the file handle for `a file` is leaked. On the other hand, the `ifstream` for `another file` will correctly close its file (upon destruction). If you must use an explicit pointer, rather than a resource handle with specific semantics, use a `unique_ptr` or a `shared_ptr` with a custom deleter: + + void f(int i) + { + unique_ptr f(fopen("a file", "r"), fclose); + // ... + if (i == 0) return; + // ... + } -If `i==0` the file handle for `a file` is leaked. On the other hand, the `ifstream` for `another file` will correctly close its file (upon destruction). If you must use an explicit pointer, rather than a resource handle with specific semantics, use a `unique_ptr` or a `shared_ptr`: +Better: -void f(int i) - { - unique_ptr f = fopen("a file","r"); - // ... - if (i==0) return; - // ... - } + void f(int i) + { + ifstream input {"a file"}; + // ... + if (i == 0) return; + // ... + } -The code is simpler as well as correct. +##### Enforcement -**Enforcement**: A checker must consider all "naked pointers" suspicious. +A checker must consider all "naked pointers" suspicious. A checker probably must rely on a human-provided list of resources. For starters, we know about the standard-library containers, `string`, and smart pointers. -The use of `array_view` and `string_view` should help a lot (they are not resource handles). +The use of `span` and `string_view` should help a lot (they are not resource handles). +### Discussion: A "raw" pointer or reference is never a resource handle -### A "raw" pointer or reference is never a resource handle +##### Reason -**Reason** To be able to distinguish owners from views. +To be able to distinguish owners from views. -**Note**: This is independent of how you "spell" pointer: `T*`, `T&`, `Ptr` and `Range` are not owners. +##### Note +This is independent of how you "spell" pointer: `T*`, `T&`, `Ptr` and `Range` are not owners. -### Never let a pointer outlive the object it points to +### Discussion: Never let a pointer outlive the object it points to -**Reason**: To avoid extremely hard-to-find errors. Dereferencing such a pointer is undefined behavior and could lead to violations of the type system. +##### Reason -**Example**: +To avoid extremely hard-to-find errors. Dereferencing such a pointer is undefined behavior and could lead to violations of the type system. - string* bad() // really bad - { - vector v = { "this", "will", "cause" "trouble" }; - return &v[0]; // leaking a pointer into a destroyed member of a destroyed object (v) - } +##### Example - void use() - { - string* p = bad(); - vector xx = {7,8,9}; - string x = *p; // undefined behavior: x may not be 1 - *p = "Evil!"; // undefined behavior: we don't know what (if anytihng) is allocated a location p - } + string* bad() // really bad + { + vector v = { "This", "will", "cause", "trouble", "!" }; + // leaking a pointer into a destroyed member of a destroyed object (v) + return &v[0]; + } -The `string`s of `v` are destroyed upon exit from `bad()` and so is `v` itself. This the returned pointer points to unallocated memory on the free store. This memory (pointed into by `p`) may have been reallocated by the time `*p` is executed. There may be no `string` to read and a write through `p` could easily corrupt objects of unrelated types. + void use() + { + string* p = bad(); + vector xx = {7, 8, 9}; + // undefined behavior: x might not be the string "This" + string x = *p; + // undefined behavior: we don't know what (if anything) is allocated a location p + *p = "Evil!"; + } -**Enforcement**: Most compilers already warn about simple cases and has the information to do more. Consider any pointer returned from a function suspect. Use containers, resource handles, and views (e.g., `array_view` known not to be resource handles) to lower the number of cases to be examined. For starters, consider every class with a destructor a resource handle. +The `string`s of `v` are destroyed upon exit from `bad()` and so is `v` itself. The returned pointer points to unallocated memory on the free store. This memory (pointed into by `p`) might have been reallocated by the time `*p` is executed. There might be no `string` to read and a write through `p` could easily corrupt objects of unrelated types. +##### Enforcement -### Use templates to express containers (and other resource handles) +Most compilers already warn about simple cases and have the information to do more. Consider any pointer returned from a function suspect. Use containers, resource handles, and views (e.g., `span` known not to be resource handles) to lower the number of cases to be examined. For starters, consider every class with a destructor as resource handle. -**Reason**: To provide statically type-safe manipulation of elements. +### Discussion: Use templates to express containers (and other resource handles) -**Example**: +##### Reason - template class Vvector { - // ... - T* elem; // point to sz elements of type T - int sz; - }; +To provide statically type-safe manipulation of elements. -### Return containers by value (relying on move for efficiency) +##### Example -**Reason**: To simplify code and eliminate a need for explicit memory management. To bring an object into a surrounding scope, thereby extending its lifetime. + template class Vector { + // ... + T* elem; // point to sz elements of type T + int sz; + }; -**Example**: +### Discussion: Return containers by value (relying on move or copy elision for efficiency) - vector +##### Reason -**Example**: +To simplify code and eliminate a need for explicit memory management. To bring an object into a surrounding scope, thereby extending its lifetime. - factory +**See also**: [F.20, the general item about "out" output values](#Rf-out) -**Enforcement**: Check for pointers and references returned from functions and see if they are assigned to resource handles (e.g., to a `unique_ptr`). +##### Example + vector get_large_vector() + { + return ...; + } -### If a class is a resource handle, it needs a constructor, a destructor, and copy and/or move operations + auto v = get_large_vector(); // return by value is ok, most modern compilers will do copy elision -**Reason**: To provide complete control of the lifetime of the resource. To provide a coherent set of operations on the resource. +##### Exception -**Example**: +See the Exceptions in [F.20](#Rf-out). - messing with pointers +##### Enforcement -**Note**: If all members are resource handles, rely on the default special operations where possible. +Check for pointers and references returned from functions and see if they are assigned to resource handles (e.g., to a `unique_ptr`). - template struct Named { - string name; - T value; - }; +### Discussion: If a class is a resource handle, it needs a constructor, a destructor, and copy and/or move operations -Now `Named` has a default constructor, a destructor, and efficient copy and move operations, provided `T` has. +##### Reason -**Enforcement**: In general, a tool cannot know if a class is a resource handle. However, if a class has some of [the default operations](???), it should have all, and if a class has a member that is a resource handle, it should be considered a resource handle. +To provide complete control of the lifetime of the resource. To provide a coherent set of operations on the resource. +##### Example -### If a class is a container, give it an initializer-list constructor + ??? Messing with pointers -**Reason**: It is common to need an initial set of elements. +##### Note -**Example**: +If all members are resource handles, rely on the compiler-generated operations where possible. - template class Vector { - public: - Vector); - // ... - }; + template struct Named { + string name; + T value; + }; + +Now `Named` has a default constructor, a destructor, and efficient copy and move operations, provided `T` has. + +##### Enforcement - Vector vs = { "Nygaard", "Ritchie" }; +In general, a tool cannot know if a class is a resource handle. However, if a class has some of [the default operations](#SS-ctor), it should have all, and if a class has a member that is a resource handle, it should be considered as resource handle. -**Enforcement**: When is a class a container? +### Discussion: If a class is a container, give it an initializer-list constructor +##### Reason + +It is common to need an initial set of elements. + +##### Example + + template class Vector { + public: + Vector(std::initializer_list); + // ... + }; - -# To-do: Unclassified proto-rules + Vector vs { "Nygaard", "Ritchie" }; + +##### Enforcement + +When is a class a container? ??? + +# Appendix D: Supporting tools + +This section contains a list of tools that directly support adoption of the C++ Core Guidelines. This list is not intended to be an exhaustive list of tools +that are helpful in writing good C++ code. If a tool is designed specifically to support and links to the C++ Core Guidelines it is a candidate for inclusion. + +### Tools: [Clang-tidy](http://clang.llvm.org/extra/clang-tidy/checks/list.html) + +Clang-tidy has a set of rules that specifically enforce the C++ Core Guidelines. These rules are named in the pattern `cppcoreguidelines-*`. + +### Tools: [CppCoreCheck](https://docs.microsoft.com/en-us/visualstudio/code-quality/using-the-cpp-core-guidelines-checkers) + +The Microsoft compiler's C++ code analysis contains a set of rules specifically aimed at enforcement of the C++ Core Guidelines. + +# Glossary + +A relatively informal definition of terms used in the guidelines +(based off the glossary in [Programming: Principles and Practice using C++](http://www.stroustrup.com/programming.html)) + +More information on many topics about C++ can be found on the [Standard C++ Foundation](https://isocpp.org)'s site. + +* *ABI*: Application Binary Interface, a specification for a specific hardware platform combined with the operating system. Contrast with API. +* *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. +* *API*: Application Programming Interface, a set of functions that form the communication between various software components. Contrast with ABI. +* *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 type that is intended to be derived from (e.g., has a non-`final` virtual function), and objects of the type are intended to be used only indirectly (e.g., by pointer). \[In strict terms, "base class" could be defined as "something we derived from" but we are specifying in terms of the class designer's intent.\] 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 can 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. +* *concept*: (1) a notion, and idea; (2) a set of requirements, usually for a template argument. +* *concrete type*: a type that is not a base class, and objects of the type are intended to be used directly (not only by pointer/indirection), its size is known, it can typically be allocated anywhere the programmer wants (e.g., stack or statically). +* *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). +* *copy*: an operation that makes two objects have values that compare equal. See also move. +* *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. + 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. + 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. + 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. + 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. + 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. +* *ISO*: International Organization for Standardization. The C++ language is an ISO standard, ISO/IEC 14882. More information at [iso.org](http://iso.org). +* *library*: a collection of types, functions, classes, etc. implementing a set of facilities (abstractions) meant to be potentially used as part of more than 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. +* *move-only type*: a concrete type that is movable but not copyable. +* *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. +* *regular*: a semiregular type that is equality-comparable (see `std::regular` concept). After a copy, the copied object compares equal to the original object. A regular type behaves similarly to built-in types like `int` and can be compared with `==`. +In particular, an object of a regular type can be copied and the result of a copy is a separate object that compares equal to the original. See also *semiregular type*. +* *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. +* *semiregular*: a concrete type that is copyable (including movable) and default-constructible (see `std::semiregular` concept). The result of a copy is an independent object with the same value as the original. A semiregular type behaves roughly like a built-in type like `int`, but possibly without a `==` operator. See also *regular type*. +* *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. +* *TS*: [Technical Specification](https://www.iso.org/deliverables-all.html?type=ts), A Technical Specification addresses work still under technical development, or where it is believed that there will be a future, but not immediate, possibility of agreement on an International Standard. A Technical Specification is published for immediate use, but it also provides a means to obtain feedback. The aim is that it will eventually be transformed and republished as an International Standard. +* *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. +* *value type*: a term some people use to mean a regular or semiregular 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 This is our to-do list. Eventually, the entries will become rules or parts of rules. -Aternatively, we will decide that no change is needed and delete the entry. +Alternatively, we will decide that no change is needed and delete the entry. * No long-distance friendship * Should physical design (what's in a file) and large-scale design (libraries, groups of libraries) be addressed? * Namespaces +* Avoid using directives in the global scope (except for std, and other "fundamental" namespaces (e.g. experimental)) * How granular should namespaces be? All classes/functions designed to work together and released together (as defined in Sutter/Alexandrescu) or something narrower or wider? -* Should there be inline namespaces (a-la `std::literals::*_literals`)? +* Should there be inline namespaces (à la `std::literals::*_literals`)? * Avoid implicit conversions -* Const member functions should be thread safe "¦ aka, but I don't really change the variable, just assign it a value the first time its called "¦ argh -* Always initialize variables, use initialization lists for member variables. -* Anyone writing a public interface which takes or returns void* should have their toes set on fire.   That one has been a personal favourite of mine for a number of years. :) -* Use `const`'ness wherever possible: member functions, variables and (yippee) const_iterators +* Const member functions should be thread safe ... aka, but I don't really change the variable, just assign it a value the first time it's called ... argh +* Always initialize variables, use initialization lists for data members. +* Anyone writing a public interface which takes or returns `void*` should have their toes set on fire. That one has been a personal favorite of mine for a number of years. :) +* Use `const`-ness wherever possible: member functions, variables and (yippee) `const_iterators` * Use `auto` * `(size)` vs. `{initializers}` vs. `{Extent{size}}` * Don't overabstract * Never pass a pointer down the call stack * falling through a function bottom -* Should there be guidelines to choose between polymorphisms? YES. classic (virtual functions, reference semantics) vs. Sean Parent style (value semantics, type-erased, kind of like std::function) vs. CRTP/static? YES Perhaps even vs. tag dispatch? -* Speaking of virtual functions, should non-virtual interface be promoted? NO. (public non-virtual foo() calling private/protected do_foo())? Not a new thing, seeing as locales/streams use it, but it seems to be under-emphasized. +* Should there be guidelines to choose between polymorphisms? YES. classic (virtual functions, reference semantics) vs. Sean Parent style (value semantics, type-erased, kind of like `std::function`) vs. CRTP/static? YES Perhaps even vs. tag dispatch? * should virtual calls be banned from ctors/dtors in your guidelines? YES. A lot of people ban them, even though I think it's a big strength of C++ that they are ??? -preserving (D disappointed me so much when it went the Java way). WHAT WOULD BE A GOOD EXAMPLE? * Speaking of lambdas, what would weigh in on the decision between lambdas and (local?) classes in algorithm calls and other callback scenarios? -* And speaking of std::bind, Stephen T. Lavavej criticizes it so much I'm starting to wonder if it is indeed going to fade away in future. Should lambdas be recommended instead? -* What to do with leaks out of temporaries? : `p = (s1+s2).c_str();` -* pointer/iterator invalidation leading to dangling pointers - - void bad() - { - int* p = new int[700]; - int* q = &p[7]; - delete p; - - vector v(700); - int* q2 = &v[7]; - v.resize(900); - - // ... use q and q2 ... - } - +* And speaking of `std::bind`, Stephen T. Lavavej criticizes it so much I'm starting to wonder if it is indeed going to fade away in future. Should lambdas be recommended instead? +* What to do with leaks out of temporaries? : `p = (s1 + s2).c_str();` +* pointer/iterator invalidation leading to dangling pointers: + + void bad() + { + int* p = new int[700]; + int* q = &p[7]; + delete p; + + vector v(700); + int* q2 = &v[7]; + v.resize(900); + + // ... use q and q2 ... + } + * LSP * private inheritance vs/and membership * avoid static class members variables (race conditions, almost-global variables) * Use RAII lock guards (`lock_guard`, `unique_lock`, `shared_lock`), never call `mutex.lock` and `mutex.unlock` directly (RAII) * Prefer non-recursive locks (often used to work around bad reasoning, overhead) -* Join your threads! (because of `std::terminate` in destructor if not joined or detached... is there a good reason to detach threads?) -- ??? could support library provide a RAII wrapper for `std::thread`? +* Join your threads! (because of `std::terminate` in destructor if not joined or detached ... is there a good reason to detach threads?) -- ??? could support library provide a RAII wrapper for `std::thread`? * If two or more mutexes must be acquired at the same time, use `std::lock` (or another deadlock avoidance algorithm?) * When using a `condition_variable`, always protect the condition by a mutex (atomic bool whose value is set outside of the mutex is wrong!), and use the same mutex for the condition variable itself. * Never use `atomic_compare_exchange_strong` with `std::atomic` (differences in padding matter, while `compare_exchange_weak` in a loop converges to stable padding) * individual `shared_future` objects are not thread-safe: two threads cannot wait on the same `shared_future` object (they can wait on copies of a `shared_future` that refer to the same shared state) -* individual `shared_ptr` objects are not thread-safe: a thread cannot call a non-const member function of `shared_ptr` while another thread accesses (but different threads can call non-const member functions on copies of a `shared_ptr` that refer to the same shared object) +* individual `shared_ptr` objects are not thread-safe: different threads can call non-`const` member functions on *different* `shared_ptr`s that refer to the same shared object, but one thread cannot call a non-`const` member function of a `shared_ptr` object while another thread accesses that same `shared_ptr` object (if you need that, consider `atomic_shared_ptr` instead) * rules for arithmetic + +# Bibliography + +* + \[Abrahams01]: D. Abrahams. [Exception-Safety in Generic Components](http://www.boost.org/community/exception_safety.html). +* + \[Alexandrescu01]: A. Alexandrescu. Modern C++ Design (Addison-Wesley, 2001). +* + \[C++03]: ISO/IEC 14882:2003(E), Programming Languages — C++ (updated ISO and ANSI C++ Standard including the contents of (C++98) plus errata corrections). +* + \[Cargill92]: T. Cargill. C++ Programming Style (Addison-Wesley, 1992). +* + \[Cline99]: M. Cline, G. Lomow, and M. Girou. C++ FAQs (2ndEdition) (Addison-Wesley, 1999). +* + \[Dewhurst03]: S. Dewhurst. C++ Gotchas (Addison-Wesley, 2003). +* + \[Henricson97]: M. Henricson and E. Nyquist. Industrial Strength C++ (Prentice Hall, 1997). +* + \[Koenig97]: A. Koenig and B. Moo. Ruminations on C++ (Addison-Wesley, 1997). +* + \[Lakos96]: J. Lakos. Large-Scale C++ Software Design (Addison-Wesley, 1996). +* + \[Meyers96]: S. Meyers. More Effective C++ (Addison-Wesley, 1996). +* + \[Meyers97]: S. Meyers. Effective C++ (2nd Edition) (Addison-Wesley, 1997). +* + \[Meyers01]: S. Meyers. Effective STL (Addison-Wesley, 2001). +* + \[Meyers05]: S. Meyers. Effective C++ (3rd Edition) (Addison-Wesley, 2005). +* + \[Meyers15]: S. Meyers. Effective Modern C++ (O'Reilly, 2015). +* + \[Murray93]: R. Murray. C++ Strategies and Tactics (Addison-Wesley, 1993). +* + \[Stroustrup94]: B. Stroustrup. The Design and Evolution of C++ (Addison-Wesley, 1994). +* + \[Stroustrup00]: B. Stroustrup. The C++ Programming Language (Special 3rdEdition) (Addison-Wesley, 2000). +* + \[Stroustrup05]: B. Stroustrup. [A rationale for semantically enhanced library languages](http://www.stroustrup.com/SELLrationale.pdf). +* + \[Stroustrup13]: B. Stroustrup. [The C++ Programming Language (4th Edition)](http://www.stroustrup.com/4th.html). Addison Wesley 2013. +* + \[Stroustrup14]: B. Stroustrup. [A Tour of C++](http://www.stroustrup.com/Tour.html). + Addison Wesley 2014. +* + \[Stroustrup15]: B. Stroustrup, Herb Sutter, and G. Dos Reis: [A brief introduction to C++'s model for type- and resource-safety](https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Introduction%20to%20type%20and%20resource%20safety.pdf). +* + \[SuttHysl04b]: H. Sutter and J. Hyslop. [Collecting Shared Objects](https://web.archive.org/web/20120926011837/http://www.drdobbs.com/collecting-shared-objects/184401839) (C/C++ Users Journal, 22(8), August 2004). +* + \[SuttAlex05]: H. Sutter and A. Alexandrescu. C++ Coding Standards. Addison-Wesley 2005. +* + \[Sutter00]: H. Sutter. Exceptional C++ (Addison-Wesley, 2000). +* + \[Sutter02]: H. Sutter. More Exceptional C++ (Addison-Wesley, 2002). +* + \[Sutter04]: H. Sutter. Exceptional C++ Style (Addison-Wesley, 2004). +* + \[Taligent94]: Taligent's Guide to Designing Programs (Addison-Wesley, 1994). diff --git a/README.md b/README.md index fc47a5b50..b26629661 100644 --- a/README.md +++ b/README.md @@ -1,36 +1,51 @@ -# C++ Core Guidelines +[![C++ Core Guidelines](cpp_core_guidelines_logo_text.png)](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) ->"Within C++ is a smaller, simpler, safer language struggling to get out." +>"Within C++ is a smaller, simpler, safer language struggling to get out." >-- Bjarne Stroustrup -The C++ Core Guidelines are a collaborative effort led by Bjarne Stroustrup, much like the C++ language itself. They are the result of many -person-years of discussion and design across a number of organizations. Their design encourages general applicability and broad adoption but -they can be freely copied and modified to meet your organization's needs. +The [C++ Core Guidelines](CppCoreGuidelines.md) are a collaborative effort led by Bjarne Stroustrup, much like the C++ language itself. They are the result of many +person-years of discussion and design across a number of organizations. Their design encourages general applicability and broad adoption but +they can be freely copied and modified to meet your organization's needs. -The aim of the guidelines is to help people to use modern C++ effectively. By "modern C++" we mean C++11 and C++14 (and soon C++17). In other +## Getting started + +The guidelines themselves are found at [CppCoreGuidelines](CppCoreGuidelines.md). The document is in [GH-flavored MarkDown](https://github.github.com/gfm/). It is intentionally kept simple, mostly in ASCII, to allow automatic post-processing such as language translation and reformatting. The editors maintain one +[version formatted for browsing](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines). Note that it is manually integrated and can be slightly older than the version in the master branch. + +The Guidelines are a constantly evolving document without a strict "release" cadence. Bjarne Stroustrup periodically reviews the document and increments the version number in the introduction. [Checkins that increment the version number](https://github.com/isocpp/CppCoreGuidelines/releases) are tagged in git. + +Many of the guidelines make use of the header-only Guidelines Support Library. One implementation is available at [GSL: Guidelines Support Library](https://github.com/Microsoft/GSL). + +## Background and scope + +The aim of the guidelines is to help people to use modern C++ effectively. By "modern C++" we mean C++11 and newer. In other words, what would you like your code to look like in 5 years' time, given that you can start now? In 10 years' time? -The guidelines are focused on relatively higher-level issues, such as interfaces, resource management, memory management, and concurrency. Such -rules affect application architecture and library design. Following the rules will lead to code that is statically type safe, has no resource -leaks, and catches many more programming logic errors than is common in code today. And it will run fast - you can afford to do things right. +The guidelines are focused on relatively higher-level issues, such as interfaces, resource management, memory management, and concurrency. Such +rules affect application architecture and library design. Following the rules will lead to code that is statically type-safe, has no resource +leaks, and catches many more programming logic errors than is common in code today. And it will run fast -- you can afford to do things right. -We are less concerned with low-level issues, such as naming conventions and indentation style. However, no topic that can help a programmer is +We are less concerned with low-level issues, such as naming conventions and indentation style. However, no topic that can help a programmer is out of bounds. -Our initial set of rules emphasize safety (of various forms) and simplicity. They may very well be too strict. We expect to have to introduce +Our initial set of rules emphasizes safety (of various forms) and simplicity. They may very well be too strict. We expect to have to introduce more exceptions to better accommodate real-world needs. We also need more rules. -You will find some of the rules contrary to your expectations or even contrary to your experience. If we haven't suggested you change your -coding style in any way, we have failed! Please try to verify or disprove rules! In particular, we'd really like to have some of our rules +You will find some of the rules contrary to your expectations or even contrary to your experience. If we haven't suggested that you change your +coding style in any way, we have failed! Please try to verify or disprove rules! In particular, we'd really like to have some of our rules backed up with measurements or better examples. -You will find some of the rules obvious or even trivial. Please remember that one purpose of a guideline is to help someone who is less +You will find some of the rules obvious or even trivial. Please remember that one purpose of a guideline is to help someone who is less experienced or coming from a different background or language to get up to speed. -The rules are designed to be supported by an analysis tool. Violations of rules will be flagged with references (or links) to the relevant rule. +The rules are designed to be supported by an analysis tool. Violations of rules will be flagged with references (or links) to the relevant rule. We do not expect you to memorize all the rules before trying to write code. The rules are meant for gradual introduction into a code base. We plan to build tools for that and hope others will too. -Comments and suggestions for improvements are most welcome. We plan to modify and extend this document as our understanding improves and the -language and the set of available libraries improve. +## Contributions and LICENSE + +Comments and suggestions for improvements are most welcome. We plan to modify and extend this document as our understanding improves and the +language and the set of available libraries improve. More details are found at [CONTRIBUTING](./CONTRIBUTING.md) and [LICENSE](./LICENSE). + +Thanks to [DigitalOcean](https://www.digitalocean.com/?refcode=32f291566cf7&utm_campaign=Referral_Invite&utm_medium=Referral_Program&utm_source=CopyPaste) for hosting the Standard C++ Foundation website. diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 000000000..81c8b9d31 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,5 @@ +# Security Policy + +## Reporting a Vulnerability + +Please report vulnerabilities, if any, to cppcg-editors@isocpp.org diff --git a/_config.yml b/_config.yml new file mode 100644 index 000000000..189a6896d --- /dev/null +++ b/_config.yml @@ -0,0 +1,2 @@ +include: [CppCoreGuidelines.md] +exclude: [docs, talks, Gemfile, params.json] diff --git a/_includes/head.html b/_includes/head.html new file mode 100644 index 000000000..dff33cc73 --- /dev/null +++ b/_includes/head.html @@ -0,0 +1,65 @@ + + + + + + + + + C++ Core Guidelines + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_includes/sidebar.html b/_includes/sidebar.html new file mode 100644 index 000000000..16f6e2a0f --- /dev/null +++ b/_includes/sidebar.html @@ -0,0 +1,70 @@ +
+
+
+ + +
+ + + +
+
diff --git a/_layouts/default.html b/_layouts/default.html new file mode 100644 index 000000000..34f1f723c --- /dev/null +++ b/_layouts/default.html @@ -0,0 +1,17 @@ + + + + {% include head.html %} + + + + {% include sidebar.html %} + + + +
+ {{ content }} +
+ + + diff --git a/cpp_core_guidelines_16b.png b/cpp_core_guidelines_16b.png new file mode 100644 index 000000000..ebc304e91 Binary files /dev/null and b/cpp_core_guidelines_16b.png differ diff --git a/cpp_core_guidelines_logo_text.png b/cpp_core_guidelines_logo_text.png new file mode 100644 index 000000000..d8c5cbbef Binary files /dev/null and b/cpp_core_guidelines_logo_text.png differ diff --git a/docs/Introduction to type and resource safety.pdf b/docs/Introduction to type and resource safety.pdf new file mode 100644 index 000000000..c32bf079c Binary files /dev/null and b/docs/Introduction to type and resource safety.pdf differ diff --git a/docs/Lifetime.pdf b/docs/Lifetime.pdf new file mode 100644 index 000000000..cdf8e786c Binary files /dev/null and b/docs/Lifetime.pdf differ diff --git a/docs/Lifetimes I and II - v0.9.1.pdf b/docs/Lifetimes I and II - v0.9.1.pdf deleted file mode 100644 index a272e53d8..000000000 Binary files a/docs/Lifetimes I and II - v0.9.1.pdf and /dev/null differ diff --git a/docs/P0122R4.pdf b/docs/P0122R4.pdf new file mode 100644 index 000000000..31c0b065e Binary files /dev/null and b/docs/P0122R4.pdf differ diff --git a/docs/ctor-dtor-raii-popl12.pdf b/docs/ctor-dtor-raii-popl12.pdf new file mode 100644 index 000000000..ecf8c3056 Binary files /dev/null and b/docs/ctor-dtor-raii-popl12.pdf differ diff --git a/docs/gsl-intro.md b/docs/gsl-intro.md new file mode 100644 index 000000000..f7bd835be --- /dev/null +++ b/docs/gsl-intro.md @@ -0,0 +1,288 @@ + +# Using the Guidelines Support Library (GSL): A Tutorial and FAQ + +by Herb Sutter + +updated 2018-01-08 + + +## Overview: "Is this document a tutorial or a FAQ?" + +It aims to be both: + +- a tutorial you can read in order, following a similar style as the introduction of [K&R](https://en.wikipedia.org/wiki/The_C_Programming_Language) by building up examples of increasing complexity; and + +- a FAQ you can use as a reference, with each section showing the answer to a specific question. + + +## Motivation: "Why would I use GSL, and where can I get it?" + +First look at the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines); this is a support library for that document. Select a set of guidelines you want to adopt, then bring in the GSL as directed by those guidelines. + +You can try out the examples in this document on all major compilers and platforms using [this GSL reference implementation](https://github.com/microsoft/gsl). + + +# gsl::span: "What is gsl::span, and what is it for?" + +`gsl::span` is a replacement for `(pointer, length)` pairs to refer to a sequence of contiguous objects. It can be thought of as a pointer to an array, but that knows its bounds. + +For example, a `span` refers to a sequence of seven contiguous integers. + +A `span` does not own the elements it points to. It is not a container like an `array` or a `vector`, it is a view into the contents of such a container. + + +## span parameters: "How should I choose between span and traditional (ptr, length) parameters?" + +In new code, prefer the bounds-checkable `span` instead of separate pointer and length parameters. In older code, adopt `span` where reasonable as you maintain the code. + +A function that takes a pointer to an array and a separate length, such as: + +~~~cpp +// Error-prone: Process n contiguous ints starting at *p +void dangerous_process_ints(const int* p, size_t n); +~~~ + +is error-prone and difficult to use correctly: + +~~~cpp +int a[100]; +dangerous_process_ints(a, 1000); // oops: buffer overflow + +vector v(200); +dangerous_process_ints(v.data(), 1000); // oops: buffer overflow + +auto remainder = find(v.begin(), v.end(), some_value); + // now call dangerous_process_ints() to fill the rest of the container from *remainder to the end +dangerous_process_ints(&*remainder, v.end() - remainder); // correct but convoluted +~~~ + +Instead, using `span` encapsulates the pointer and the length: + +~~~cpp +// BETTER: Read s.size() contiguous ints starting at s[0] +void process_ints(span s); +~~~ + +which makes `process_ints` easier to use correctly because it conveniently deduces from common types: + +~~~cpp +int a[100]; +process_ints(a); // deduces correct length: 100 (constructs the span from a container) + +vector v(200); +process_ints(v); // deduces correct length: 200 (constructs the span from a container) +~~~ + +and conveniently supports modern C++ argument initialization when the calling code does have distinct pointer and length arguments: + +~~~cpp +auto remainder = find(v.begin(), v.end(), some_value); + // now call process_ints() to fill the rest of the container from *remainder to the end +process_ints({remainder, v.end()}); // correct and clear (constructs the span from an iterator pair) +~~~ + +> Things to remember +> - Prefer `span` instead of (pointer, length) pairs. +> - Pass a `span` like a pointer (i.e., by value for "in" parameters). Treat it like a pointer range. + + +## span and const: "What's the difference between `span` and `const span`?" + +`span` means that the `T` objects are read-only. Prefer this by default, especially as a parameter, if you don't need to modify the `T`s. + +`const span` means that the `span` itself can't be made to point at a different target. + +`const span` means both. + +> Things to remember +> - Prefer a `span` by default to denote that the contents are read-only, unless you do need read-write access. + + +## Iteration: "How do I iterate over a span?" + +A `span` is an encapsulated range, and so can be visited using a range-based `for` loop. + +Consider the implementation of a function like the `process_ints` that we saw in an earlier example. Visiting every object using a (pointer, length) pair requires an explicit index: + +~~~cpp +void dangerous_process_ints(int* p, size_t n) { + for (auto i = 0; i < n; ++i) { + p[i] = next_character(); + } +} +~~~ + +A `span` supports range-`for` -- note this is zero-overhead and does not need to perform any range check, because the range-`for` loop is known by construction not to exceed the range's bounds: + +~~~cpp +void process_ints(span s) { + for (auto& c : s) { + c = next_character(); + } +} +~~~ + +A `span` also supports normal iteration using `.begin()` and `.end()`. + +Note that you cannot compare iterators from different spans, even if they refer to the same array. + +An iterator is valid as long as the `span` that it is iterating over exists. + + +## Element access: "How do I access a single element in a span?" + +Use `myspan[offset]` to subscript, or equivalently use `iter + offset` wheren `iter` is a `span::iterator`. Both are range-checked. + + + +## Sub-spans: "What if I need a subrange of a span?" + +To refer to a sub-span, use `first`, `last`, or `subspan`. + +~~~cpp +void process_ints(span s) { + if (s.length() > 10) { + read_header(s.first(10)); // first 10 entries + read_rest(s.subspan(10)); // remaining entries + // ... + } +} +~~~ + +In rarer cases, when you know the number of elements at compile time and want to enable `constexpr` use of `span`, you can pass the length of the sub-span as a template argument: + +~~~cpp +constexpr int process_ints(span s) { + if (s.length() > 10) { + read_header(s.first<10>()); // first 10 entries + read_rest(s.subspan<10>()); // remaining entries + // ... + } + return s.size(); +} +~~~ + + +## span and STL: "How do I pass a span to an STL-style [begin,end) function?" + +Use `span::iterator`s. A `span` is iterable like any STL range. + +To call an STL `[begin,end)`-style interface, use `begin` and `end` by default, or other valid iterators if you don't want to pass the whole range: + +~~~cpp +void f(span s) { + // ... + auto found = find_if(s.begin(), s.end(), some_value); + // ... +} +~~~ + +If you are using a range-based algorithm such as from [Range-V3](https://github.com/ericniebler/range-v3), you can use a `span` as a range directly: + +~~~cpp +void f(span s) { + // ... + auto found = find_if(s, some_value); + // ... +} +~~~ + + +## Comparison: "When I compare `span`s, do I compare the `T` values or the underlying pointers?" + +Comparing two `span`s compares the `T` values. To compare two spans for identity, to see if they're pointing to the same thing, use `.data()`. + +~~~cpp +int a[] = { 1, 2, 3}; +span sa{a}; + +vector v = { 1, 2, 3 }; +span sv{v}; + +assert(sa == sv); // sa and sv both point to contiguous ints with values 1, 2, 3 +assert(sa.data() != sv.data()); // but sa and sv point to different memory areas +~~~ + +> Things to remember +> - Comparing spans compares their contents, not whether they point to the same location. + + +## Empty vs null: "Do I have to explicitly check whether a span is null?" + +Usually not, because the thing you usually want to check for is that the `span` is not empty, which means its size is not zero. It's safe to test the size of a span even if it's null. + +Remember that the following all have identical meaning for a `span s`: + +- `!s.empty()` +- `s.size() != 0` +- `s.data() != nullptr && s.size() != 0` (the first condition is actually redundant) + +The following is also functionally equivalent as it just tests whether there are zero elements: + +- `s != nullptr` (compares `s` against a null-constructed empty `span`) + +For example: + +~~~cpp +void f(span s) { + if (s != nullptr && s.size() > 0) { // bad: redundant, overkill + // ... + } + + if (s.size() > 0) { // good: not redundant + // ... + } + + if (!s.empty()) { // good: same as "s.size() > 0" + // ... + } +} + +~~~ + +> Things to remember +> - Usually you shouldn't check for a null `span`. For a `span s`, if you're comparing `s != nullptr` or `s.data() != nullptr`, check to make sure you shouldn't just be asking `!s.empty()`. + + +## as_bytes: "Why would I convert a span to `span`?" + +Because it's a type-safe way to get a read-only view of the objects' bytes. + +Without `span`, to view the bytes of an object requires writing a brittle cast: + +~~~cpp +void serialize(char* p, int length); // bad: forgot const + +void f(widget* p, int length) { + // serialize one object's bytes (incl. padding) + serialize(p, 1); // bad: copies just the first byte, forgot sizeof(widget) +} +~~~ + +With `span` the code is safer and cleaner: + +~~~cpp +void serialize(span); // can't forget const, the first test call site won't compile + +void f(span s) { + // ... + // serialize one object's bytes (incl. padding) + serialize(as_bytes(s)); // ok +} +~~~ + +Also, `span` lets you distinguish between `.size()` and `.size_bytes()`; make use of that distinction instead of multiplying by `sizeof(T)`. + +> Things to remember +> - Prefer `span`'s `.size_bytes()` instead of `.size() * sizeof(T)`. + + +## And a few `span`-related hints + +These are not directly related to `span` but can often come up while using `span`. + + * Use `byte` everywhere you are handling memory (as opposed to characters or integers). That is, when accessing a chunk of raw memory, use `gsl::span`. + + * Use `narrow()` when you cannot afford to be surprised by a value change during conversion to a smaller range. This includes going between a signed `span` size or index and an unsigned today's-STL-container `.size()`, though the `span` constructors from containers nicely encapsulate many of these conversions. + + * Similarly, use `narrow_cast()` when you are *sure* you won’t be surprised by a value change during conversion to a smaller range diff --git a/index.html b/index.html new file mode 100644 index 000000000..8ce489ff1 --- /dev/null +++ b/index.html @@ -0,0 +1,22 @@ +--- +layout: default +--- + +

This site is copy of the C++ Core Guidelines rendered for easier browsing. As the text on this page is integrated manually + you should refer to the C++ Core Guidelines repo for the most up-to-date version. +

+ + +
+
+ +
+
+ +{% capture readme %}{% include_relative README.md %}{% endcapture %} +{{ readme | markdownify }} diff --git a/params.json b/params.json new file mode 100644 index 000000000..9bc9107b8 --- /dev/null +++ b/params.json @@ -0,0 +1 @@ +{"name":"Cppcoreguidelines","tagline":"The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++","body":"# C++ Core Guidelines\r\n\r\n>\"Within C++ is a smaller, simpler, safer language struggling to get out.\" \r\n>-- Bjarne Stroustrup\r\n\r\nThe C++ Core Guidelines are a collaborative effort led by Bjarne Stroustrup, much like the C++ language itself. They are the result of many \r\nperson-years of discussion and design across a number of organizations. Their design encourages general applicability and broad adoption but \r\nthey can be freely copied and modified to meet your organization's needs. \r\n\r\nThe aim of the guidelines is to help people to use modern C++ effectively. By \"modern C++\" we mean C++11 and C++14 (and soon C++17). In other \r\nwords, what would you like your code to look like in 5 years' time, given that you can start now? In 10 years' time?\r\n\r\nThe guidelines are focused on relatively higher-level issues, such as interfaces, resource management, memory management, and concurrency. Such \r\nrules affect application architecture and library design. Following the rules will lead to code that is statically type safe, has no resource \r\nleaks, and catches many more programming logic errors than is common in code today. And it will run fast - you can afford to do things right.\r\n\r\nWe are less concerned with low-level issues, such as naming conventions and indentation style. However, no topic that can help a programmer is \r\nout of bounds.\r\n\r\nOur initial set of rules emphasize safety (of various forms) and simplicity. They may very well be too strict. We expect to have to introduce \r\nmore exceptions to better accommodate real-world needs. We also need more rules.\r\n\r\nYou will find some of the rules contrary to your expectations or even contrary to your experience. If we haven't suggested you change your \r\ncoding style in any way, we have failed! Please try to verify or disprove rules! In particular, we'd really like to have some of our rules \r\nbacked up with measurements or better examples.\r\n\r\nYou will find some of the rules obvious or even trivial. Please remember that one purpose of a guideline is to help someone who is less \r\nexperienced or coming from a different background or language to get up to speed.\r\n\r\nThe rules are designed to be supported by an analysis tool. Violations of rules will be flagged with references (or links) to the relevant rule. \r\nWe do not expect you to memorize all the rules before trying to write code.\r\n\r\nThe rules are meant for gradual introduction into a code base. We plan to build tools for that and hope others will too.\r\n\r\nComments and suggestions for improvements are most welcome. We plan to modify and extend this document as our understanding improves and the \r\nlanguage and the set of available libraries improve.\r\n","google":"","note":"Don't delete this file! It's used internally to help with page regeneration."} \ No newline at end of file diff --git a/public/css/custom.css b/public/css/custom.css new file mode 100644 index 000000000..f9cc38662 --- /dev/null +++ b/public/css/custom.css @@ -0,0 +1,418 @@ +.outer { + width: 100%; +} + +.inner { + position: relative; + max-width: 1280px; + padding: 20px 10px; + margin: 0 auto; +} + + +#header_wrap { + background: #212121; + background: -moz-linear-gradient(top, #373737, #212121); + background: -webkit-linear-gradient(top, #373737, #212121); + background: -ms-linear-gradient(top, #373737, #212121); + background: -o-linear-gradient(top, #373737, #212121); + background: linear-gradient(top, #373737, #212121); +} + +#header_wrap .inner { + padding: 50px 10px 30px 10px; +} + +#downloads { + position: absolute; + width: 210px; + z-index: 10; + bottom: -40px; + right: 0; + height: 70px; + background: url('http://github.com/images/icon_download.png') no-repeat 0% 90%; +} + +/** same style for highlighted, non-highlight */ +.cpp.hljs { + overflow-x: unset; +} + +/** override poole.css */ +pre code { + /* same as hljs */ + padding: 0.5em; +} + +/** highlight js change colors (overrides style) */ +.hljs-comment { + color: #008000; +} +.hljs-meta { + color: #2b91af; +} + +.zip_download_link { + display: block; + float: right; + width: 90px; + height:70px; + text-indent: -5000px; + overflow: hidden; + background: url(http://github.com/images/sprite_download.png) no-repeat bottom left; +} + +.tar_download_link { + display: block; + float: right; + width: 90px; + height:70px; + text-indent: -5000px; + overflow: hidden; + background: url(http://github.com/images/sprite_download.png) no-repeat bottom right; + margin-left: 10px; +} + +.zip_download_link:hover { + background: url(http://github.com/images/sprite_download.png) no-repeat top left; +} + +.tar_download_link:hover { + background: url(http://github.com/images/sprite_download.png) no-repeat top right; +} + +/** + * Try to display h5 headers left of paragraphs + */ + +h5 { + display: inline; +} + +h5:before { + content: '\A'; white-space:pre-line; +} + +h5 + p { + display: inline; +} + +p:after { + content: '\A'; white-space:pre-line; +} + +@media print { + .sidebar,.banner, a:after { + display: none; + } + .container { + width: 90%; + margin: 2em; + padding: 0px; + } + .* { + color: #000; + background-color: #fff; + @include box-shadow(none); + @include text-shadow(none); + } + code,p { + page-break-inside:avoid; + page-break-before:avoid; + } + pre code { + /* try to fit 100 max chars into one A4 line */ + font-size: 2.8mm; + } + h1,h2,h3,h4,h5,strong { + page-break-after:avoid; + } + h1,h2 { + page-break-before:always; + } + a:link, a:visited { + color: #000; + } +} + + +.tgl { + display: none; +} +.tgl + .tgl-btn { + outline: 0; + display: block; + width: 8em; + height: 2em; + position: relative; + cursor: pointer; + -webkit-user-select: none; + -moz-user-select: none; + -ms-user-select: none; + user-select: none; +} +.tgl + .tgl-btn:after, .tgl + .tgl-btn:before { + position: relative; + display: block; + content: ""; + width: 50%; + height: 100%; +} +.tgl + .tgl-btn:after { + left: 0; +} +.tgl + .tgl-btn:before { + display: none; +} +.tgl:checked + .tgl-btn:after { + left: 50%; +} + +.tgl-cpp + .tgl-btn { + overflow: hidden; + -webkit-backface-visibility: hidden; + backface-visibility: hidden; + background: #888; +} +.tgl-cpp + .tgl-btn:after, .tgl-cpp + .tgl-btn:before { + display: inline-block; + width: 100%; + text-align: center; + position: absolute; + line-height: 2em; + font-weight: bold; + color: #fff; +} +.tgl-cpp + .tgl-btn:after { + left: 100%; + content: attr(data-tg-on); +} +.tgl-cpp + .tgl-btn:before { + left: 0; + content: attr(data-tg-off); +} +.tgl-cpp + .tgl-btn:active { + background: #888; +} +.tgl-cpp:checked + .tgl-btn { + background: #268bd2; +} +.tgl-cpp:checked + .tgl-btn:before { + left: -100%; +} +.tgl-cpp:checked + .tgl-btn:after { + left: 0; +} + +// +// rougify style github +// +.highlight table td { padding: 5px; } +.highlight table pre { margin: 0; } +.highlight .cm { + color: #999988; + font-style: italic; +} +.highlight .cp { + color: #999999; + font-weight: bold; +} +.highlight .c1 { + color: #999988; + font-style: italic; +} +.highlight .cs { + color: #999999; + font-weight: bold; + font-style: italic; +} +.highlight .c, .highlight .ch, .highlight .cd, .highlight .cpf { + color: #999988; + font-style: italic; +} +.highlight .err { + color: #a61717; + background-color: #e3d2d2; +} +.highlight .gd { + color: #000000; + background-color: #ffdddd; +} +.highlight .ge { + color: #000000; + font-style: italic; +} +.highlight .gr { + color: #aa0000; +} +.highlight .gh { + color: #999999; +} +.highlight .gi { + color: #000000; + background-color: #ddffdd; +} +.highlight .go { + color: #888888; +} +.highlight .gp { + color: #555555; +} +.highlight .gs { + font-weight: bold; +} +.highlight .gu { + color: #aaaaaa; +} +.highlight .gt { + color: #aa0000; +} +.highlight .kc { + color: #000000; + font-weight: bold; +} +.highlight .kd { + color: #000000; + font-weight: bold; +} +.highlight .kn { + color: #000000; + font-weight: bold; +} +.highlight .kp { + color: #000000; + font-weight: bold; +} +.highlight .kr { + color: #000000; + font-weight: bold; +} +.highlight .kt { + color: #445588; + font-weight: bold; +} +.highlight .k, .highlight .kv { + color: #000000; + font-weight: bold; +} +.highlight .mf { + color: #009999; +} +.highlight .mh { + color: #009999; +} +.highlight .il { + color: #009999; +} +.highlight .mi { + color: #009999; +} +.highlight .mo { + color: #009999; +} +.highlight .m, .highlight .mb, .highlight .mx { + color: #009999; +} +.highlight .sb { + color: #d14; +} +.highlight .sc { + color: #d14; +} +.highlight .sd { + color: #d14; +} +.highlight .s2 { + color: #d14; +} +.highlight .se { + color: #d14; +} +.highlight .sh { + color: #d14; +} +.highlight .si { + color: #d14; +} +.highlight .sx { + color: #d14; +} +.highlight .sr { + color: #009926; +} +.highlight .s1 { + color: #d14; +} +.highlight .ss { + color: #990073; +} +.highlight .s, .highlight .sa, .highlight .dl { + color: #d14; +} +.highlight .na { + color: #008080; +} +.highlight .bp { + color: #999999; +} +.highlight .nb { + color: #0086B3; +} +.highlight .nc { + color: #445588; + font-weight: bold; +} +.highlight .no { + color: #008080; +} +.highlight .nd { + color: #3c5d5d; + font-weight: bold; +} +.highlight .ni { + color: #800080; +} +.highlight .ne { + color: #990000; + font-weight: bold; +} +.highlight .nf, .highlight .fm { + color: #990000; + font-weight: bold; +} +.highlight .nl { + color: #990000; + font-weight: bold; +} +.highlight .nn { + color: #555555; +} +.highlight .nt { + color: #000080; +} +.highlight .vc { + color: #008080; +} +.highlight .vg { + color: #008080; +} +.highlight .vi { + color: #008080; +} +.highlight .nv, .highlight .vm { + color: #008080; +} +.highlight .ow { + color: #000000; + font-weight: bold; +} +.highlight .o { + color: #000000; + font-weight: bold; +} +.highlight .w { + color: #bbbbbb; +} +.highlight { + background-color: #f8f8f8; +} diff --git a/public/css/hyde.css b/public/css/hyde.css new file mode 100644 index 000000000..e0debb236 --- /dev/null +++ b/public/css/hyde.css @@ -0,0 +1,252 @@ +/* + * __ __ + * /\ \ /\ \ + * \ \ \___ __ __ \_\ \ __ + * \ \ _ `\/\ \/\ \ /'_` \ /'__`\ + * \ \ \ \ \ \ \_\ \/\ \_\ \/\ __/ + * \ \_\ \_\/`____ \ \___,_\ \____\ + * \/_/\/_/`/___/> \/__,_ /\/____/ + * /\___/ + * \/__/ + * + * Designed, built, and released under MIT license by @mdo. Learn more at + * https://github.com/poole/hyde. + */ + + +/* + * Contents + * + * Global resets + * Sidebar + * Container + * Reverse layout + * Themes + */ + + +/* + * Global resets + * + * Update the foundational and global aspects of the page. + */ + +html { + font-family: "PT Sans", Helvetica, Arial, sans-serif; +} +@media (min-width: 48em) { + html { + font-size: 16px; + } +} +@media (min-width: 58em) { + html { + font-size: 20px; + } +} + + +/* + * Sidebar + * + * Flexible banner for housing site name, intro, and "footer" content. Starts + * out above content in mobile and later moves to the side with wider viewports. + */ + +.sidebar { + text-align: center; + padding: none; + color: rgba(255,255,255,.5); + background-color: #202020; +} +@media (min-width: 48em) { + .sidebar { + overflow-y: scroll; + position: fixed; + top: 0; + left: 0; + bottom: 0; + width: 18rem; + text-align: left; + } +} + +/* Sidebar links */ +.sidebar a { + color: #fff; +} + +/* About section */ +.sidebar-about h1 { + color: #fff; + margin-top: 0; + font-family: "Abril Fatface", serif; + font-size: 3.25rem; +} + +/* Sidebar nav */ +.sidebar-nav { + margin-bottom: 1rem; +} +.sidebar-nav-item { + display: block; + line-height: 1.75; +} +a.sidebar-nav-item:hover, +a.sidebar-nav-item:focus { + text-decoration: underline; +} +.sidebar-nav-item.active { + font-weight: bold; +} + +/* Sticky sidebar + * + * Add the `sidebar-sticky` class to the sidebar's container to affix it the + * contents to the bottom of the sidebar in tablets and up. + */ + +@media (min-width: 48em) { + .sidebar-sticky { + position: absolute; + right: 1rem; + bottom: 1rem; + left: 1rem; + top: 0rem; + } +} + + +/* Container + * + * Align the contents of the site above the proper threshold with some margin-fu + * with a 25%-wide `.sidebar`. + */ + +.content { + padding-top: 4rem; + padding-bottom: 4rem; +} + +@media (min-width: 48em) { + .content { + max-width: 38rem; + margin-left: 20rem; + margin-right: 2rem; + } +} + +@media (min-width: 64em) { + .content { + margin-left: 22rem; + margin-right: 4rem; + } +} + + +/* + * Reverse layout + * + * Flip the orientation of the page by placing the `.sidebar` on the right. + */ + +@media (min-width: 48em) { + .layout-reverse .sidebar { + left: auto; + right: 0; + } + .layout-reverse .content { + margin-left: 2rem; + margin-right: 20rem; + } +} + +@media (min-width: 64em) { + .layout-reverse .content { + margin-left: 4rem; + margin-right: 22rem; + } +} + + + +/* + * Themes + * + * As of v1.1, Hyde includes optional themes to color the sidebar and links + * within blog posts. To use, add the class of your choosing to the `body`. + */ + +/* Base16 (http://chriskempson.github.io/base16/#default) */ + +/* Red */ +.theme-base-08 .sidebar { + background-color: #ac4142; +} +.theme-base-08 .content a, +.theme-base-08 .related-posts li a:hover { + color: #ac4142; +} + +/* Orange */ +.theme-base-09 .sidebar { + background-color: #d28445; +} +.theme-base-09 .content a, +.theme-base-09 .related-posts li a:hover { + color: #d28445; +} + +/* Yellow */ +.theme-base-0a .sidebar { + background-color: #f4bf75; +} +.theme-base-0a .content a, +.theme-base-0a .related-posts li a:hover { + color: #f4bf75; +} + +/* Green */ +.theme-base-0b .sidebar { + background-color: #90a959; +} +.theme-base-0b .content a, +.theme-base-0b .related-posts li a:hover { + color: #90a959; +} + +/* Cyan */ +.theme-base-0c .sidebar { + background-color: #75b5aa; +} +.theme-base-0c .content a, +.theme-base-0c .related-posts li a:hover { + color: #75b5aa; +} + +/* Blue */ +.theme-base-0d .sidebar { + background-color: #6a9fb5; +} +.theme-base-0d .content a, +.theme-base-0d .related-posts li a:hover { + color: #6a9fb5; +} + +/* Magenta */ +.theme-base-0e .sidebar { + background-color: #aa759f; +} +.theme-base-0e .content a, +.theme-base-0e .related-posts li a:hover { + color: #aa759f; +} + +/* Brown */ +.theme-base-0f .sidebar { + background-color: #8f5536; +} +.theme-base-0f .content a, +.theme-base-0f .related-posts li a:hover { + color: #8f5536; +} diff --git a/public/css/poole.css b/public/css/poole.css new file mode 100644 index 000000000..dfec045d8 --- /dev/null +++ b/public/css/poole.css @@ -0,0 +1,439 @@ +/* + * ___ + * /\_ \ + * _____ ___ ___\//\ \ __ + * /\ '__`\ / __`\ / __`\\ \ \ /'__`\ + * \ \ \_\ \/\ \_\ \/\ \_\ \\_\ \_/\ __/ + * \ \ ,__/\ \____/\ \____//\____\ \____\ + * \ \ \/ \/___/ \/___/ \/____/\/____/ + * \ \_\ + * \/_/ + * + * Designed, built, and released under MIT license by @mdo. Learn more at + * https://github.com/poole/poole. + */ + + +/* + * Contents + * + * Body resets + * Custom type + * Messages + * Container + * Masthead + * Posts and pages + * Pagination + * Reverse layout + * Themes + */ + + +/* + * Body resets + * + * Update the foundational and global aspects of the page. + */ + + +html, +body { + margin: 0; + padding: 0; +} + +html { + font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; + font-size: 16px; + line-height: 1.5; +} +@media (min-width: 38em) { + html { + font-size: 20px; + } +} + +body { + color: #515151; + background-color: #fff; + -webkit-text-size-adjust: 100%; + -ms-text-size-adjust: 100%; +} + +/* No `:visited` state is required by default (browsers will use `a`) */ +a { + color: #268bd2; + text-decoration: none; +} +a strong { + color: inherit; +} +/* `:focus` is linked to `:hover` for basic accessibility */ +a:hover, +a:focus { + text-decoration: underline; +} + +/* Headings */ +h1, h2, h3, h4, h5, h6 { + margin-bottom: .5rem; + font-weight: bold; + line-height: 1.25; + color: #313131; + text-rendering: optimizeLegibility; +} +h1 { + font-size: 2rem; +} +h2 { + margin-top: 1rem; + font-size: 1.5rem; +} +h3 { + margin-top: 1.5rem; + font-size: 1.25rem; +} +h4, h5, h6 { + margin-top: 1rem; + font-size: 1rem; +} + +/* Body text */ +p { + margin-top: 0; + margin-bottom: 1rem; +} + +strong { + color: #303030; +} + + +/* Lists */ +ul, ol, dl { + margin-top: 0; + margin-bottom: 1rem; +} + +dt { + font-weight: bold; +} +dd { + margin-bottom: .5rem; +} + +/* Misc */ +hr { + position: relative; + margin: 1.5rem 0; + border: 0; + border-top: 1px solid #eee; + border-bottom: 1px solid #fff; +} + +abbr { + font-size: 85%; + font-weight: bold; + color: #555; + text-transform: uppercase; +} +abbr[title] { + cursor: help; + border-bottom: 1px dotted #e5e5e5; +} + +/* Code */ +code, +pre { + font-family: "Roboto Mono", monospace; +} +code { + padding: .2em .2em; + font-size: 90%; + background-color: #f9f9f9; + border-radius: 3px; +} + +@media (max-width: 70em) { + code { + white-space: pre-wrap; + word-break: break-all; + word-wrap: break-word; + } +} +pre { + display: block; + margin-top: 0; + font-size: .8rem; + line-height: 1.4; + background-color: #f9f9f9; +} +@media (min-width: 70em) { + pre { + display: inline-block; + min-width: 50em; + white-space: pre; + } +} +@media (min-width: 70em) { + pre code { + display: inline-block; + min-width: 50em; + } +} +pre code { + padding: 0; + font-size: 100%; + color: black; + background-color: transparent; +} + +/* Pygments via Jekyll */ +.highlight { + margin-bottom: 1rem; + border-radius: 4px; +} +.highlight pre { + margin-bottom: 0; +} + +/* Gist via GitHub Pages */ +.gist .gist-file { + font-family: Menlo, Monaco, "Courier New", monospace !important; +} +.gist .markdown-body { + padding: 15px; +} +.gist pre { + padding: 0; + background-color: transparent; +} +.gist .gist-file .gist-data { + font-size: .8rem !important; + line-height: 1.4; +} +.gist code { + padding: 0; + color: inherit; + background-color: transparent; + border-radius: 0; +} + +/* Quotes */ +blockquote { + padding: .5rem 1rem; + margin: .8rem 0; + color: #7a7a7a; + border-left: .25rem solid #e5e5e5; +} +blockquote p:last-child { + margin-bottom: 0; +} +@media (min-width: 30em) { + blockquote { + padding-right: 5rem; + padding-left: 1.25rem; + } +} + +img { + display: block; + max-width: 100%; + margin: 0 0 1rem; + border-radius: 5px; +} + +/* Tables */ +table { + margin-bottom: 1rem; + width: 100%; + border: 1px solid #e5e5e5; + border-collapse: collapse; +} +td, +th { + padding: .25rem .5rem; + border: 1px solid #e5e5e5; +} +tbody tr:nth-child(odd) td, +tbody tr:nth-child(odd) th { + background-color: #f9f9f9; +} + + +/* + * Custom type + * + * Extend paragraphs with `.lead` for larger introductory text. + */ + +.lead { + font-size: 1.25rem; + font-weight: 300; +} + + +/* + * Messages + * + * Show alert messages to users. You may add it to single elements like a `

`, + * or to a parent if there are multiple elements to show. + */ + +.message { + margin-bottom: 1rem; + padding: 1rem; + color: #717171; + background-color: #f9f9f9; +} + + +/* + * Container + * + * Center the page content. + */ + +.container { + max-width: 38rem; + padding-left: 1rem; + padding-right: 1rem; + margin-left: auto; + margin-right: auto; +} + + +/* + * Masthead + * + * Super small header above the content for site name and short description. + */ + +.masthead { + padding-top: 1rem; + padding-bottom: 1rem; + margin-bottom: 3rem; +} +.masthead-title { + margin-top: 0; + margin-bottom: 0; + color: #505050; +} +.masthead-title a { + color: #505050; +} +.masthead-title small { + font-size: 75%; + font-weight: 400; + color: #c0c0c0; + letter-spacing: 0; +} + + +/* + * Posts and pages + * + * Each post is wrapped in `.post` and is used on default and post layouts. Each + * page is wrapped in `.page` and is only used on the page layout. + */ + +.page, +.post { + margin-bottom: 4em; +} + +/* Blog post or page title */ +.page-title, +.post-title, +.post-title a { + color: #303030; +} +.page-title, +.post-title { + margin-top: 0; +} + +/* Meta data line below post title */ +.post-date { + display: block; + margin-top: -.5rem; + margin-bottom: 1rem; + color: #9a9a9a; +} + +/* Related posts */ +.related { + padding-top: 2rem; + padding-bottom: 2rem; + border-top: 1px solid #eee; +} +.related-posts { + padding-left: 0; + list-style: none; +} +.related-posts h3 { + margin-top: 0; +} +.related-posts li small { + font-size: 75%; + color: #999; +} +.related-posts li a:hover { + color: #268bd2; + text-decoration: none; +} +.related-posts li a:hover small { + color: inherit; +} + + +/* + * Pagination + * + * Super lightweight (HTML-wise) blog pagination. `span`s are provide for when + * there are no more previous or next posts to show. + */ + +.pagination { + overflow: hidden; /* clearfix */ + margin-left: -1rem; + margin-right: -1rem; + font-family: "PT Sans", Helvetica, Arial, sans-serif; + color: #ccc; + text-align: center; +} + +/* Pagination items can be `span`s or `a`s */ +.pagination-item { + display: block; + padding: 1rem; + border: 1px solid #eee; +} +.pagination-item:first-child { + margin-bottom: -1px; +} + +/* Only provide a hover state for linked pagination items */ +a.pagination-item:hover { + background-color: #f5f5f5; +} + +@media (min-width: 30em) { + .pagination { + margin: 3rem 0; + } + .pagination-item { + float: left; + width: 50%; + } + .pagination-item:first-child { + margin-bottom: 0; + border-top-left-radius: 4px; + border-bottom-left-radius: 4px; + } + .pagination-item:last-child { + margin-left: -1px; + border-top-right-radius: 4px; + border-bottom-right-radius: 4px; + } +} diff --git a/public/images/bg_hr.png b/public/images/bg_hr.png new file mode 100644 index 000000000..514aee505 Binary files /dev/null and b/public/images/bg_hr.png differ diff --git a/public/images/blacktocat.png b/public/images/blacktocat.png new file mode 100644 index 000000000..e160053a5 Binary files /dev/null and b/public/images/blacktocat.png differ diff --git a/public/images/icon_download.png b/public/images/icon_download.png new file mode 100644 index 000000000..5a793f176 Binary files /dev/null and b/public/images/icon_download.png differ diff --git a/public/images/sprite_download.png b/public/images/sprite_download.png new file mode 100644 index 000000000..f9f8de24c Binary files /dev/null and b/public/images/sprite_download.png differ diff --git a/scripts/Makefile b/scripts/Makefile new file mode 100644 index 000000000..8ed3311f2 --- /dev/null +++ b/scripts/Makefile @@ -0,0 +1,128 @@ +# This Makefile is supposed to run on the Travis CI server and also locally +# it assumes the nodejs package managaer npm is installed + +# make magic not needed +MAKEFLAGS += --no-builtin-rules +.SUFFIXES: + +BUILD_DIR=build +SOURCEFILE = CppCoreGuidelines.md +SOURCEPATH = ../$(SOURCEFILE) + +.PHONY: default +default: all + +.PHONY: all +all: \ +check-markdown \ +check-references \ +check-notabs \ +hunspell-check \ +cpplint-all \ +check-badchars + +$(BUILD_DIR): + @mkdir -p $(BUILD_DIR) + +#### clean: remove all files generated by the productive rules +.PHONY: clean +clean: + rm -rf $(BUILD_DIR) + +#### distclean: remove all helper executables that may be downloaded by the Makefile +.PHONY: distclean +distclean: + rm -rf ./nodejs/node_modules + + +#### check markdown + +## run remark markdown checker based on configuration in .remarkrc +.PHONY: check-markdown +check-markdown: nodejs/node_modules/remark nodejs/remark/.remarkrc $(SOURCEPATH) $(BUILD_DIR) Makefile + echo '##################### Markdown check ##################' +## run remark, paste output to temporary file + cd nodejs; ./node_modules/.bin/remark ../$(SOURCEPATH) --no-color -q --config-path ./remark/.remarkrc 1> ../$(BUILD_DIR)/$(SOURCEFILE).fixed --frail + +## show a diff with changes remark suggests +.PHONY: show-diff +show-diff: nodejs/node_modules/remark nodejs/remark/.remarkrc $(SOURCEPATH) $(BUILD_DIR) Makefile + cd nodejs; ./node_modules/.bin/remark ../$(SOURCEPATH) --no-color -q --config-path ./remark/.remarkrc 1> ../$(BUILD_DIR)/$(SOURCEFILE).fixed +## compare temporary file to original, error and fail with message if differences exist + diff $(SOURCEPATH) $(BUILD_DIR)/$(SOURCEFILE).fixed -u3 || \ + (echo "Error: remark found bad markdown syntax, see output above" && false) + + +.PHONY: check-references +check-references: $(SOURCEPATH) $(BUILD_DIR) Makefile + @echo '##################### References check ##################' +## check references unique + @rm -f $(BUILD_DIR)/$(SOURCEFILE).uniq + @cat $(SOURCEPATH) | perl -ne 'print "$$1\n" if (/ $(BUILD_DIR)/$(SOURCEFILE).uniq +## check if output has data + @if [ -s "build/CppCoreGuidelines.md.uniq" ]; then echo 'Found duplicate anchors:'; cat $(BUILD_DIR)/$(SOURCEFILE).uniq; false; fi + +.PHONY: check-notabs +check-notabs: $(SOURCEPATH) $(BUILD_DIR) Makefile + @echo '##################### Tabs check ##################' +# find lines with tabs +# old file still might be around + @rm -f $(BUILD_DIR)/CppCoreGuidelines.md.tabs +# print file, add line numbers, remove tabs from nl tool, grep for remaining tabs, replace with stars + @cat ../$(SOURCEFILE) | nl -ba | perl -pe 's/(^[^\t]*)\t/$1--/g' | perl -ne 'print if /\t/' | perl -pe 's/\t/\*\*\*\*/g' > $(BUILD_DIR)/$(SOURCEFILE).tabs + @if [ -s $(BUILD_DIR)/CppCoreGuidelines.md.tabs ]; then echo 'Warning: Tabs found:'; cat $(BUILD_DIR)/CppCoreGuidelines.md.tabs; false; fi; + +.PHONY: check-badchars +check-badchars: $(SOURCEPATH) $(BUILD_DIR) Makefile + @echo '##################### Bad chars check ##################' +# find lines with tabs +# 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 (–’‘“”¸…¦) or Unicode EN SPACE found, use markdown-compatible symbols instead:'; cat $(BUILD_DIR)/CppCoreGuidelines.md.badchars; false; fi; + + +.PHONY: hunspell-check +hunspell-check: $(BUILD_DIR)/plain-nohtml.txt + @echo '##################### Spell check ##################' + sed -e 's!http\(s\)\{0,1\}://[^[:space:]]*!!g' build/plain-nohtml.txt | hunspell -d hunspell/en_US -p hunspell/isocpp.dic -u > $(BUILD_DIR)/hunspell-report.txt + @if [ -s $(BUILD_DIR)/hunspell-report.txt ]; then echo 'Warning: Spellcheck failed, fix words or add to dictionary:'; cat $(BUILD_DIR)/hunspell-report.txt; false; fi; + +# only list words that are not in dict +# to include all add them to bottom of hunspell/isocpp.dict, and run +# cat hunspell/isocpp.dic | sort | uniq > hunspell/isocpp.dic2; mv hunspell/isocpp.dic2 hunspell/isocpp.dic +.PHONY: hunspell-list +hunspell-list: $(BUILD_DIR)/plain.txt + sed -e 's!http\(s\)\{0,1\}://[^[:space:]]*!!g' build/plain-nohtml.txt | hunspell -p hunspell/isocpp.dic -l + +#### Cpplint + +.PHONY: cpplint-all +cpplint-all: $(BUILD_DIR)/codeblocks $(BUILD_DIR)/Makefile python/Makefile.in + @echo '##################### C++ Style check ##################' + cd $(BUILD_DIR)/codeblocks; $(MAKE) cpplint-all -k + +#### generic makefile for sourceblocks (need to be evaluated after c++ file generation) + +$(BUILD_DIR)/Makefile: python/Makefile.in + @cp python/Makefile.in $(BUILD_DIR)/codeblocks/Makefile + +#### split md file into plain text and code + +$(BUILD_DIR)/codeblocks: splitfile + +$(BUILD_DIR)/plain.txt: splitfile + +$(BUILD_DIR)/plain-nohtml.txt: $(BUILD_DIR)/plain.txt + sed 's; T; always use TH --> # instead +# - dropped "^AE" -> "E" (redundant) +# - "ing" is transformed to "N", not "NK" +# - "SCH(EO)" transforms to "SK" now +# - added R --> SILENT if (after a vowel) and no (vowel or +# "y" follows) like in "Marcy" or "abort" +# - H is SILENT in RH at beginning of words +# - H is SILENT if vowel leads and "Y" follows +# - some ".OUGH.." --> ...F exceptions added +# - "^V" transforms to "W" +# 2000-01-07 Kevin Atkinson +# Converted from header to data file. +# +# 2007-08-23 László Németh +# Add PHONE header and #PHONE keywords +# +# version 1.1 + +# Documentation: http://aspell.net/man-html/PHONEtic-Code.html + +PHONE 105 +PHONE AH(AEIOUY)-^ *H +PHONE AR(AEIOUY)-^ *R +PHONE A(HR)^ * +PHONE A^ * +PHONE AH(AEIOUY)- H +PHONE AR(AEIOUY)- R +PHONE A(HR) _ +PHONE BB- _ +PHONE B B +PHONE CQ- _ +PHONE CIA X +PHONE CH X +PHONE C(EIY)- S +PHONE CK K +PHONE COUGH^ KF +PHONE CC< C +PHONE C K +PHONE DG(EIY) K +PHONE DD- _ +PHONE D T +PHONE �< E +PHONE EH(AEIOUY)-^ *H +PHONE ER(AEIOUY)-^ *R +PHONE E(HR)^ * +PHONE ENOUGH^$ *NF +PHONE E^ * +PHONE EH(AEIOUY)- H +PHONE ER(AEIOUY)- R +PHONE E(HR) _ +PHONE FF- _ +PHONE F F +PHONE GN^ N +PHONE GN$ N +PHONE GNS$ NS +PHONE GNED$ N +PHONE GH(AEIOUY)- K +PHONE GH _ +PHONE GG9 K +PHONE G K +PHONE H H +PHONE IH(AEIOUY)-^ *H +PHONE IR(AEIOUY)-^ *R +PHONE I(HR)^ * +PHONE I^ * +PHONE ING6 N +PHONE IH(AEIOUY)- H +PHONE IR(AEIOUY)- R +PHONE I(HR) _ +PHONE J K +PHONE KN^ N +PHONE KK- _ +PHONE K K +PHONE LAUGH^ LF +PHONE LL- _ +PHONE L L +PHONE MB$ M +PHONE MM M +PHONE M M +PHONE NN- _ +PHONE N N +PHONE OH(AEIOUY)-^ *H +PHONE OR(AEIOUY)-^ *R +PHONE O(HR)^ * +PHONE O^ * +PHONE OH(AEIOUY)- H +PHONE OR(AEIOUY)- R +PHONE O(HR) _ +PHONE PH F +PHONE PN^ N +PHONE PP- _ +PHONE P P +PHONE Q K +PHONE RH^ R +PHONE ROUGH^ RF +PHONE RR- _ +PHONE R R +PHONE SCH(EOU)- SK +PHONE SC(IEY)- S +PHONE SH X +PHONE SI(AO)- X +PHONE SS- _ +PHONE S S +PHONE TI(AO)- X +PHONE TH @ +PHONE TCH-- _ +PHONE TOUGH^ TF +PHONE TT- _ +PHONE T T +PHONE UH(AEIOUY)-^ *H +PHONE UR(AEIOUY)-^ *R +PHONE U(HR)^ * +PHONE U^ * +PHONE UH(AEIOUY)- H +PHONE UR(AEIOUY)- R +PHONE U(HR) _ +PHONE V^ W +PHONE V F +PHONE WR^ R +PHONE WH^ W +PHONE W(AEIOU)- W +PHONE X^ S +PHONE X KS +PHONE Y(AEIOU)- Y +PHONE ZZ- _ +PHONE Z S + +#The rules in a different view: +# +# Exceptions: +# +# Beginning of word: "gn", "kn-", "pn-", "wr-" ----> drop first letter +# "Aebersold", "Gnagy", "Knuth", "Pniewski", "Wright" +# +# Beginning of word: "x" ----> change to "s" +# as in "Deng Xiaopeng" +# +# Beginning of word: "wh-" ----> change to "w" +# as in "Whalen" +# Beginning of word: leading vowels are transformed to "*" +# +# "[crt]ough" and "enough" are handled separately because of "F" sound +# +# +# A --> A at beginning +# _ otherwise +# +# B --> B unless at the end of word after "m", as in "dumb", "McComb" +# +# C --> X (sh) if "-cia-" or "-ch-" +# S if "-ci-", "-ce-", or "-cy-" +# SILENT if "-sci-", "-sce-", or "-scy-", or "-cq-" +# K otherwise, including in "-sch-" +# +# D --> K if in "-dge-", "-dgy-", or "-dgi-" +# T otherwise +# +# E --> A at beginnig +# _ SILENT otherwise +# +# F --> F +# +# G --> SILENT if in "-gh-" and not at end or before a vowel +# in "-gn" or "-gned" or "-gns" +# in "-dge-" etc., as in above rule +# K if before "i", or "e", or "y" if not double "gg" +# +# K otherwise (incl. "GG"!) +# +# H --> SILENT if after vowel and no vowel or "Y" follows +# or after "-ch-", "-sh-", "-ph-", "-th-", "-gh-" +# or after "rh-" at beginning +# H otherwise +# +# I --> A at beginning +# _ SILENT otherwise +# +# J --> K +# +# K --> SILENT if after "c" +# K otherwise +# +# L --> L +# +# M --> M +# +# N --> N +# +# O --> A at beginning +# _ SILENT otherwise +# +# P --> F if before "h" +# P otherwise +# +# Q --> K +# +# R --> SILENT if after vowel and no vowel or "Y" follows +# R otherwise +# +# S --> X (sh) if before "h" or in "-sio-" or "-sia-" +# SK if followed by "ch(eo)" (SCH(EO)) +# S otherwise +# +# T --> X (sh) if "-tia-" or "-tio-" +# 0 (th) if before "h" +# silent if in "-tch-" +# T otherwise +# +# U --> A at beginning +# _ SILENT otherwise +# +# V --> V if first letter of word +# F otherwise +# +# W --> SILENT if not followed by a vowel +# W if followed by a vowel +# +# X --> KS +# +# Y --> SILENT if not followed by a vowel +# Y if followed by a vowel +# +# Z --> S diff --git a/scripts/hunspell/en_US.dic b/scripts/hunspell/en_US.dic new file mode 100644 index 000000000..3eadc7395 --- /dev/null +++ b/scripts/hunspell/en_US.dic @@ -0,0 +1,62156 @@ +62154 +0/nm +0s/pt +0th/pt +1/n1 +1990s +1st/p +1th/tc +2/nm +2nd/p +2th/tc +3/nm +3rd/p +3th/tc +4/nm +4th/pt +5/nm +5th/pt +6/nm +6th/pt +7/nm +7th/pt +8/nm +8th/pt +9/nm +9th/pt +A +A's +AA +AAA +AB +ABC/M +ABM/S +ABS +AC +ACLU +ACM +ACT +ACTH +AD +ADC +ADP +AF +AFAIK +AFB +AFC +AFDC +AI +AIDS +AK +AL +ALGOL +ALU +AM +AMA +ANSI/M +AOL/M +AP +APB +APO +APR +AR +ARC +ARCO/M +ARPA/M +ARPANET/M +ASAP +ASCII +ASL +ASPCA +ATM/M +ATP +ATV/S +AV +AWACS +AWOL +AZ +AZT +Aachen/M +Aaren/M +Aarhus/M +Aarika/M +Aaron/M +Ab/M +Abagael/M +Abagail/M +Abba/M +Abbe/M +Abbey/M +Abbi/M +Abbie/M +Abbot/M +Abbott/M +Abby/M +Abbye/M +Abdel/M +Abdul/M +Abe/M +Abel/M +Abelard/M +Abelson/M +Aberdeen/M +Abernathy/M +Abeu/M +Abey/M +Abidjan/M +Abie/M +Abigael/M +Abigail/M +Abigale/M +Abilene/M +Abner/M +Abo/SM! +Aborigine/SM +Abra/M +Abraham/M +Abrahan/M +Abram/SM +Abramo/M +Abramson/M +Abran/M +Abuja +Abyssinia/M +Abyssinian +Ac/M +Acadia/M +Acapulco/M +Accra/M +Acevedo/M +Achaean/M +Achebe/M +Achernar/M +Acheson/M +Achilles +Ackerman/M +Aconcagua/M +Acosta/M +Acropolis/M +Acrux/M +Acta/M +Actaeon/M +Acton/M +Acts +Ad/MN +Ada/M +Adah/M +Adair/M +Adaline/M +Adam/SM +Adamo/M +Adamson/M +Adan/M +Adana/M +Adara/M +Adda/M +Addams +Addi/M +Addia/M +Addie/M +Addison/M +Addressograph/M +Addy/M +Ade/M +Adel/M +Adela/M +Adelaida/M +Adelaide/M +Adelbert/M +Adele/M +Adelheid/M +Adelice/M +Adelina/M +Adelind/M +Adeline/M +Adella/M +Adelle/M +Aden/M +Adena/M +Adenauer/M +Adey/M +Adham/M +Adhara/M +Adi/M +Adiana/M +Adidas/M +Adina/M +Adirondack/SM +Adkins/M +Adlai/M +Adler/M +Adm/M +Admiralty/S +Ado/M +Adolf/M +Adolfo/M +Adolph/M +Adolphe/M +Adolpho/M +Adolphus/M +Adonis/SM +Adora/M +Adore/M +Adoree/M +Adorne/M +Adrea/M +Adrenalin/MS +Adria/MX +Adrian/M +Adriana/M +Adriane/M +Adrianna/M +Adrianne/M +Adriano/M +Adriatic +Adrien/M +Adriena/M +Adrienne/M +Advent/SM +Adventist/M +Advil/M +Aegean +Aelfric/M +Aeneas +Aeneid/M +Aeolus/M +Aeriel/M +Aeriela/M +Aeriell/M +Aeschylus/M +Aesculapius/M +Aesop/M +Afghan/SM +Afghani/SM +Afghanistan/M +Afr +Africa/M +African/MS +Afrikaans/M +Afrikaner/SM +Afro/MS +Afrocentric +Afrocentrism/S +Afton/M +Ag/M +Agace/M +Agamemnon/M +Agassiz/M +Agata/M +Agatha/M +Agathe/M +Aggi/M +Aggie/M +Aggy/SM +Aglaia/M +Agna/M +Agnella/M +Agnes/M +Agnese/M +Agnesse/M +Agneta/M +Agnew/M +Agni/M +Agnola/M +Agosto/M +Agra/M +Agretha/M +Agricola/M +Agrippa/M +Agrippina/M +Aguascalientes/M +Aguie/M +Aguilar/M +Aguinaldo/M +Aguirre/M +Aguistin/M +Aguste/M +Agustin/M +Ahab/M +Aharon/M +Ahmad/M +Ahmadabad +Ahmed/M +Ahriman/M +Aida/M +Aidan/M +Aigneis/M +Aiken/M +Aila/M +Ailbert/M +Aile/M +Ailee/M +Aileen/M +Ailene/M +Ailey/M +Aili/SM +Ailina/M +Ailsun/M +Ailyn/M +Aime/M +Aimee/M +Aimil/M +Aindrea/M +Ainslee/M +Ainsley/M +Ainslie/M +Ainu/M +Airbus/M +Airedale/SM +Aires +Aisha/M +Ajax/M +Ajay/M +Akbar/M +Akihito/M +Akim/M +Akita/M +Akkad/M +Akron/M +Aksel/M +Al/MRY +Ala/MS +Alabama/M +Alabaman/S +Alabamian/MS +Aladdin/M +Alain/M +Alaine/M +Alair/M +Alameda/M +Alamo/SM +Alamogordo/M +Alan/M +Alana/M +Alanah/M +Aland/M +Alane/M +Alanna/M +Alano/M +Alanson/M +Alar/M +Alard/M +Alaric/M +Alasdair/M +Alaska/M +Alaskan/S +Alastair/M +Alasteir/M +Alaster/M +Alayne/M +Alba/M +Albania/M +Albanian/SM +Albany/M +Albee/M +Alberich/M +Alberik/M +Alberio/M +Albert/M +Alberta/M +Albertan/S +Albertina/M +Albertine/M +Alberto/M +Albie/M +Albigensian +Albina/M +Albion/M +Albireo/M +Albrecht/M +Albuquerque/M +Alcatraz/M +Alcestis/M +Alcibiades/M +Alcmena/M +Alcoa/M +Alcott/M +Alcuin/M +Alcyone/M +Aldan/M +Aldebaran/M +Alden/M +Alderamin/M +Aldin/M +Aldis/M +Aldo/M +Aldon/M +Aldous/M +Aldric/M +Aldrich/M +Aldridge/M +Aldrin/M +Aldus/M +Aldwin/M +Alec/M +Alecia/M +Aleck/M +Aleda/M +Aleece/M +Aleen/M +Aleichem/M +Alejandra/M +Alejandrina/M +Alejandro/M +Alejoa/M +Aleksandr/M +Alembert/M +Alena/M +Alene/M +Aleppo/M +Aler/M +Alessandra/M +Alessandro/M +Aleta/M +Alethea/M +Aleut/SM +Aleutian/S +Alex/M +Alexa/M +Alexander/SM +Alexandr/M +Alexandra/M +Alexandre/M +Alexandria/M +Alexandrian/S +Alexandrina/M +Alexandro/MS +Alexei/M +Alexi/SM +Alexia/M +Alexina/M +Alexine/M +Alexio/M +Alf/M +Alfa/M +Alfi/M +Alfie/M +Alfons/M +Alfonse/M +Alfonso/M +Alfonzo/M +Alford/M +Alfred/M +Alfreda/M +Alfredo/M +Alfy/M +Algenib/M +Alger/M +Algeria/M +Algerian/MS +Algernon/M +Algieba/M +Algiers/M +Algol/M +Algonquian/SM +Algonquin/SM +Alhambra/M +Alhena/M +Ali/MS +Alia/M +Alic/M +Alica/M +Alice/M +Alicea/M +Alicia/M +Alick/M +Alida/M +Alidia/M +Alie/M +Alighieri/M +Alika/M +Alikee/M +Alina/M +Aline/M +Alioth/M +Alisa/M +Alisander/M +Alisha/M +Alison/M +Alissa/M +Alistair/M +Alister/M +Alisun/M +Alix/M +Aliza/M +Alkaid/M +Alla/M +Allah/M +Allahabad/M +Allan/M +Allard/M +Allayne/M +Alleen/M +Allegheny/MS +Allegra/M +Allen/M +Allendale/M +Allende/M +Allene/M +Allentown/M +Alley/M +Alleyn/M +Allhallows +Alli/MS +Allianora/M +Allie/M +Allin/M +Allina/M +Allison/M +Allissa/M +Allister/M +Allistir/M +Allix/M +Allstate/M +Allsun/M +Allx/M +Ally/MS +Allyce/M +Allyn/M +Allys +Allyson/M +Alma/M +Almach/M +Almaden/M +Almaty/M +Almeda/M +Almeria/M +Almeta/M +Almighty/M +Almira/M +Almire/M +Alnilam/M +Alnitak/M +Aloin/M +Aloise/M +Aloisia/M +Alon/M +Alonso/M +Alonzo/M +Aloysia/M +Aloysius/M +Alpert/M +Alphard/M +Alphecca/M +Alpheratz/M +Alphonse/M +Alphonso/M +Alpine +Alps +Alric/M +Alsace/M +Alsatian/MS +Alsop/M +Alston/M +Alta/M +Altai/M +Altaic/M +Altair/M +Althea/M +Altiplano/M +Alton/M +Altos/M +Aludra/M +Aluin/M +Aluino/M +Alva/M +Alvan/M +Alvarado/M +Alvarez/M +Alvaro/M +Alvera/M +Alverta/M +Alvie/M +Alvin/M +Alvina/M +Alvinia/M +Alvira/M +Alvis/M +Alvy/M +Alwin/M +Alwyn/M +Alyce/M +Alyda/M +Alyosha/M +Alys/M +Alysa/M +Alyse/M +Alysia/M +Alyson/M +Alyss +Alyssa/M +Alzheimer/M +Am/MR +Amabel/M +Amabelle/M +Amadeus/M +Amado/M +Amalea/M +Amalee/M +Amaleta/M +Amalia/M +Amalie/M +Amalita/M +Amalle/M +Amanda/M +Amandi/M +Amandie/M +Amandy/M +Amara/M +Amargo/M +Amarillo/M +Amata/M +Amati/M +Amazon/SM +Amazonian +Amber/YM +Amberly/M +Amble/M +Ambros/M +Ambrose/M +Ambrosi/M +Ambrosio/M +Ambrosius/M +Ambur/M +Amby/M +Amdahl/M +Ame/SM +Amelia/M +Amelie/M +Amelina/M +Ameline/M +Amelita/M +Amenhotep/M +Amer/M +Amerada/M +Amerasian/S +America/SM +American/MS +Americana/M +Americanism/SM +Americanization/SM +Americanize/SDG +Amerigo/M +Amerind/MS +Amerindian/MS +Amery/M +Ameslan/M +Amharic/M +Amherst/M +Ami/M +Amie/M +Amiga/M +Amii/M +Amil/M +Amish +Amitie/M +Amity/M +Ammamaria/M +Amman/M +Ammerman/M +Amoco/M +Amontillado/M +Amory/M +Amos +Amparo/M +Ampere/M +Ampex/M +Amritsar/M +Amsterdam/M +Amtrak/M +Amundsen/M +Amur/M +Amway/M +Amy/M +Amye/M +Ana/M +Anabal/M +Anabaptist/SM +Anabel/M +Anabella/M +Anabelle/M +Anacin/M +Anacreon/M +Anaheim/M +Analects/M +Analiese/M +Analise/M +Anallese/M +Anallise/M +Ananias/M +Anastasia/M +Anastasie/M +Anastassia/M +Anatol/M +Anatola/M +Anatole/M +Anatolia/M +Anatolian +Anatollo/M +Anaxagoras/M +Ancell/M +Anchorage/M +Andalusia/M +Andalusian +Andaman +Andean/M +Andee/M +Andeee/M +Anderea/M +Anders/N +Andersen/M +Anderson/M +Andes +Andi/M +Andie/M +Andonis/M +Andorra/M +Andover/M +Andra/SM +Andre/SM +Andrea/MS +Andreana/M +Andree/M +Andrei/M +Andrej/M +Andrew/MS +Andrey/M +Andria/M +Andriana/M +Andriette/M +Andris +Andromache/M +Andromeda/M +Andropov/M +Andros/M +Andrus/M +Andy/M +Anestassia/M +Anet/M +Anett/M +Anetta/M +Anette/M +Angara/M +Ange/M +Angel/M +Angela/M +Angele/SM +Angeleno/SM +Angeli/M +Angelia/M +Angelica/M +Angelico/M +Angelika/M +Angelina/M +Angeline/M +Angelique/M +Angelita/M +Angelle/M +Angelo/M +Angelou/M +Angevin/M +Angie/M +Angil/M +Angkor/M +Angles +Anglia/M +Anglican/MS +Anglicanism/MS +Anglicism/SM +Anglicization/MS +Anglicize/SDG +Anglo/MS +Anglophile/SM +Anglophilia/M +Anglophobe/MS +Anglophobia/M +Angola/M +Angolan/S +Angora/MS +Anguilla/M +Angus/M +Angy/M +Anheuser/M +Ania/M +Aniakchak/M +Anibal/M +Anica/M +Anissa/M +Anita/M +Anitra/M +Anjanette/M +Anjela/M +Ankara/M +Ann/M +Anna/M +Annabal/M +Annabel/M +Annabela/M +Annabell/M +Annabella/M +Annabelle/M +Annadiana/M +Annadiane/M +Annalee/M +Annaliese/M +Annalise/M +Annamaria/M +Annamarie/M +Annapolis/M +Annapurna/M +Anne/M +Annecorinne/M +Anneliese/M +Annelise/M +Annemarie/M +Annetta/M +Annette/M +Anni/MS +Annice/M +Annie/M +Annissa/M +Annmaria/M +Annmarie/M +Annnora/M +Annora/M +Annunciation/S +Anny/M +Anouilh/M +Ansel/M +Ansell/M +Anselm/M +Anselma/M +Anselmo/M +Anshan/M +Ansley/M +Anson/M +Anstice/M +Antaeus/M +Antananarivo/M +Antarctic/M +Antarctica/M +Antares +Anthe/M +Anthea/M +Anthia/M +Anthiathia/M +Anthony/M +Antichrist/MS +Antietam/M +Antigone/M +Antigua/M +Antillean +Antilles +Antin/M +Antioch/M +Antipas/M +Antipodes +Antofagasta/M +Antoine/M +Antoinette/M +Anton/MS +Antone/M +Antonella/M +Antonetta/M +Antoni/M +Antonia/M +Antonie/M +Antonietta/M +Antonin/M +Antonina/M +Antonino/M +Antoninus/M +Antonio/M +Antonius/M +Antonovics/M +Antony/M +Antwan/M +Antwerp/M +Anubis/M +Any/M +Anya/M +Apache/MS +Apalachicola/M +Apennines +Aphrodite/M +Apia/M +Apocalypse/M +Apocrypha/M +Apollinaire/M +Apollo/SM +Apollonian +Appalachia/M +Appalachian/MS +Appaloosa/MS +Appia/M +Appian/M +Apple/M +Appleseed/M +Appleton/M +Appolonia/M +Appomattox/M +Apr/M +April/MS +Aprilette/M +Apuleius/M +Aquarius/MS +Aquila/M +Aquinas/M +Aquino/M +Aquitaine/M +Ar/MY +Ara/M +Arab/MS +Arabel/M +Arabela/M +Arabele/M +Arabella/M +Arabelle/M +Arabia/M +Arabian/MS +Arabic/M +Arabist/MS +Araby/M +Araceli/M +Arafat/M +Araguaya/M +Aral/M +Araldo/M +Aramaic/M +Aramco/M +Arapaho/MS +Arapahoe's +Arapahoes +Ararat/M +Araucanian/M +Arawak/M +Arawakan/M +Arcadia/M +Arcadian +Arch/MR +Archaimbaud/M +Archambault/M +Archean +Archer/M +Archibald/M +Archibaldo/M +Archibold/M +Archie/M +Archimedes/M +Archy/M +Arctic/M +Arcturus/M +Arda/MH +Ardabil +Ardath/M +Ardeen/M +Ardelia/M +Ardelis/M +Ardella/M +Ardelle/M +Arden/M +Ardene/M +Ardenia/M +Ardine/M +Ardis/M +Ardisj/M +Ardith/M +Ardra/M +Ardyce/M +Ardys +Ardyth/M +Arel/M +Arequipa/M +Ares +Aretha/M +Argentina/M +Argentine/SM +Argentinean/S +Argentinian/S +Argo/SM +Argonaut/MS +Argonne/M +Argus/M +Ari/M +Ariadne/M +Ariana/M +Arianism/M +Arianist/SM +Aridatha/M +Arie/SM +Ariel/M +Ariela/M +Ariella/M +Arielle/M +Aries/S +Arin/M +Ario/M +Ariosto/M +Aristarchus/M +Aristides +Aristophanes/M +Aristotelean +Aristotelian/M +Aristotle/M +Arius/M +Ariz/M +Arizona/M +Arizonan/S +Arizonian/S +Arjuna/M +Ark/M +Arkansan/MS +Arkansas/M +Arkhangelsk/M +Arkwright/M +Arlan/M +Arlana/M +Arlee/M +Arleen/M +Arlen/M +Arlena/M +Arlene/M +Arleta/M +Arlette/M +Arley/M +Arleyne/M +Arlie/M +Arliene/M +Arlin/M +Arlina/M +Arlinda/M +Arline/M +Arlington/M +Arluene/M +Arly/M +Arlyn/M +Arlyne/M +Armada/M +Armageddon/SM +Armagnac/M +Arman/M +Armand/M +Armando/M +Armata/M +Armco/M +Armenia/M +Armenian/MS +Armin/M +Arminius/M +Armonk/M +Armour/M +Armstrong/M +Arnaldo/M +Arne/M +Arneb/M +Arney/M +Arnhem/M +Arni/M +Arnie/M +Arno/M +Arnold/M +Arnoldo/M +Arnuad/M +Arnulfo/M +Arny/M +Aron/M +Arpanet/M +Arragon/M +Arrhenius/M +Arri/M +Arron/M +Art/M +Artair/M +Artaxerxes/M +Arte/M +Artemas +Artemis/M +Artemus/M +Arther/M +Arthur/M +Arthurian +Artie/M +Artur/M +Arturo/M +Artus/M +Arty/M +Aruba/M +Arv/M +Arvie/M +Arvin/M +Arvy/M +Aryan/MS +Aryn/M +As +Asa/M +Asama/M +Ascella/M +Ascension/M +Ase/M +Asgard/M +Ash/MRY +Ashanti/M +Ashbey/M +Ashby/M +Ashely/M +Asher/M +Asheville/M +Ashia/M +Ashien/M +Ashil/M +Ashkenazim +Ashkhabad/M +Ashla/M +Ashlan/M +Ashland/M +Ashlee/M +Ashleigh/M +Ashlen/M +Ashley/M +Ashli/M +Ashlie/M +Ashlin/M +Ashly/M +Ashmolean/M +Ashton/M +Ashurbanipal/M +Asia/M +Asian/MS +Asiatic/SM +Asilomar/M +Asimov +Asmara/M +Asoka/M +Aspell/M +Aspen/M +Aspidiske/M +Asquith/M +Assad/M +Assam/M +Assamese/M +Assembly/MS +Assisi/M +Assyria/M +Assyrian/SM +Assyriology/M +Astaire/SM +Astarte/M +Aston/M +Astor/M +Astoria/M +Astra/M +Astrakhan/M +Astrid/M +Astrix/M +AstroTurf/S +Astroturf/M +Asturias/M +Asunci�n/M +Aswan/M +At/M +Atacama/M +Atahualpa/M +Atalanta/M +Atari/M +Atat�rk/M +Athabasca/M +Athabascan's +Athabaska's +Athabaskan/MS +Athena/M +Athene/M +Athenian/SM +Athens/M +Atkins/M +Atkinson/M +Atlanta/M +Atlante/MS +Atlantic/M +Atlantis/M +Atlas/SM +Atman +Atreus/M +Atria/M +Atropos/M +Ats +Attic +Attica/M +Attila/M +Attlee/M +Attn +Attucks +Atwood/M +Au/M +Aube/M +Auberge/M +Auberon/M +Aubert/M +Auberta/M +Aubine/M +Aubree/M +Aubrette/M +Aubrey/M +Aubrie/M +Aubry/M +Auckland/M +Auden/M +Audi/M +Audie/M +Audra/M +Audre/M +Audrey/M +Audrie/M +Audry/M +Audrye/M +Audubon/M +Audy/M +Auerbach/M +Aug/M +Augean +Augie/M +August/SM +Augusta/M +Augustan/S +Auguste/M +Augustin/M +Augustina/M +Augustine/M +Augustinian/S +Augusto/M +Augustus/M +Augy/M +Aundrea/M +Aura/M +Aurea/M +Aurel/M +Aurelea/M +Aurelia/M +Aurelie/M +Aurelio/M +Aurelius/M +Aureomycin/M +Auria/M +Aurie/M +Auriga/M +Aurilia/M +Aurlie/M +Auroora/M +Aurora/M +Aurore/M +Aurthur/M +Auschwitz/M +Aussie/MS +Austen/M +Austin/SM +Austina/M +Austine/M +Australasia/M +Australasian/S +Australia/M +Australian/MS +Australis/M +Australoid +Australopithecus/M +Austria/M +Austrian/SM +Austronesian +Autumn/M +Ava/M +Avalon/M +Ave/MS +Aveline/M +Aventine/M +Aventino/M +Averell/M +Averil/M +Averill/M +Avernus/M +Averroes/M +Avery/M +Averyl/M +Avesta/M +Avicenna/M +Avictor/M +Avie/M +Avigdor/M +Avignon/M +Avila/M +Avior/M +Avis +Aviv/M +Aviva/M +Avivah/M +Avogadro/M +Avon/M +Avram/M +Avril/M +Avrit/M +Avrom/M +Ax/M +Axe/M +Axel/M +Ayala/M +Ayers +Aylmar/M +Aylmer/M +Aymara/M +Aymer/M +Ayn/M +Azania/M +Azazel/M +Azerbaijan/M +Azores +Azov/M +Aztec/MS +Aztecan +B's +B/GT +BA +BASIC +BB +BBB +BBC +BBQ +BBS +BC +BCD +BIOS +BITNET/M +BLT +BM +BMW/M +BO +BR +BS +BSA +BSD +BTU +BTW +BYOB +Ba/M +Baal/SM +Bab/SM +Babar's +Babara/M +Babb/M +Babbage/M +Babbette/M +Babbie/M +Babbitt/M +Babcock/M +Babel/MS +Babette/M +Babita/M +Babka/M +Babylon/MS +Babylonia/M +Babylonian/SM +Bacall/M +Bacardi/M +Bacchanalia/M +Bacchic +Bacchus/M +Bach/M +Backus/M +Bacon/M +Bactria/M +Baden/M +Badlands/M +Baedeker/SM +Baez/M +Baffin/M +Baghdad/M +Bagrodia/MS +Baguio/M +Baha'i +Baha'ullah +Bahama/MS +Bahamanian/S +Bahamian/MS +Bahia/M +Bahrain/M +Baikal/M +Bail/M +Bailey/SM +Bailie/M +Baillie/M +Baily/M +Baird/M +Baja/M +Bakelite/M +Baker/M +Bakersfield/M +Baku/M +Bakunin/M +Balanchine/M +Balboa/M +Bald/MR +Balder/M +Balduin/M +Baldwin/M +Bale/M +Balearic/M +Balfour/M +Bali/M +Balinese +Balkan/SM +Balkhash/M +Ball/M +Ballard/SM +Balthazar/M +Baltic/M +Baltimore/M +Baluchistan/M +Balzac/M +Bamako/M +Bamberger/M +Bambi/M +Bambie/M +Bamby/M +Ban/M +Banach/M +Bancroft/M +Bandung/M +Bangalore/M +Bangkok/M +Bangladesh/M +Bangladeshi/S +Bangor/M +Bangui/M +Banjarmasin/M +Banjul/M +Bank/MS +Banky/M +Banneker/M +Bannister/M +Banting/M +Bantu/SM +Baotou/M +Baptist/MS +Baptiste/M +Bar/MH +Barabbas/M +Barb/RM +Barbabas/M +Barbabra/M +Barbadian/S +Barbados/M +Barbara/M +Barbaraanne/M +Barbarella/M +Barbarossa/M +Barbary/M +Barbe/M +Barbee/M +Barber/M +Barbette/M +Barbey/M +Barbi/M +Barbie/M +Barbour/M +Barbra/M +Barbuda/M +Barby/M +Barcelona/M +Barclay/M +Bard/M +Barde/M +Bardeen/M +Barents/M +Bari/M +Barker/M +Barkley/M +Barlow/M +Barn/M +Barnabas +Barnabe/M +Barnaby/M +Barnard/M +Barnaul/M +Barnebas/M +Barnes +Barnett/M +Barney/M +Barnhard/M +Barnie/M +Barnum/M +Barny/M +Baroda/M +Baron/M +Barquisimeto/M +Barr/M +Barranquilla/M +Barrera/M +Barret/M +Barrett/M +Barri/SM +Barrie/M +Barron/M +Barry/M +Barrymore/MS +Barstow/M +Bart/M +Bartel/M +Barth/M +Barthel/M +Bartholdi/M +Bartholemy/M +Bartholomeo/M +Bartholomeus/M +Bartholomew/M +Bartie/M +Bartlet/M +Bartlett/M +Bartolemo/M +Bartolomeo/M +Barton/M +Bartram/M +Barty/M +Bart�k/M +Bary/M +Baryram/M +Baryshnikov/M +Bascom/M +Base/M +Basel/M +Basho/M +Basia/M +Basie/M +Basil/M +Basile/M +Basilio/M +Basilius/M +Basque/SM +Basra/M +Bass/M +Basseterre/M +Bassett/M +Bastian/M +Bastien/M +Bastille/M +Basutoland/M +Bat/M +Bataan/M +Batavia/M +Bates +Batholomew/M +Bathsheba/M +Batista/M +Batman/M +Batsheva/M +Battle/M +Batu/M +Baudelaire/M +Baudoin/M +Baudouin/M +Bauer/M +Bauhaus/M +Bausch/M +Bavaria/M +Bavarian/S +Bax/M +Baxie/M +Baxter/M +Baxy/M +Bay/MR +Bayamon +Bayard/M +Bayda/M +Bayer/M +Bayes +Bayesian +Baylor/M +Bayonne/M +Bayreuth/M +Be/MH +Bea/M +Beach/M +Beadle/M +Beale/M +Bealle/M +Bean/M +Bear/M +Beard/M +Beardmore/M +Beardsley/M +Bearnaise/M +Bearnard/M +Beasley/M +Beatlemania/M +Beatles/M +Beatrice/M +Beatrisa/M +Beatrix/M +Beatriz/M +Beau/M +Beauchamps +Beaufort/M +Beaujolais/M +Beaumarchais/M +Beaumont/M +Beauregard/M +Beauvoir/M +Beaverton/M +Bebe/M +Becca/M +Bechtel/M +Beck/RM +Becka/M +Becker/M +Becket/M +Beckett/M +Becki/M +Beckie/M +Becky/M +Becquerel/M +Bede/M +Bedford/M +Bedouin/SM +Bee/M +Beebe/M +Beecher/M +Beelzebub/M +Beerbohm/M +Beethoven/M +Beeton/M +Begin/M +Behan/M +Behring/M +Beiderbecke/M +Beijing +Beilul/M +Beirut/M +Beitris/M +Bekesy/M +Bekki/M +Bel/M +Bela/M +Belarus +Belau/M +Belem/M +Belfast/M +Belg/M +Belgian/MS +Belgium/M +Belgrade/M +Belia/M +Belicia/M +Belinda/M +Belita/M +Belize/M +Bell/M +Bella/M +Bellamy/M +Bellanca/M +Bellatrix/M +Belle/M +Belleville/M +Bellina/M +Bellini/M +Bellovin/M +Bellow/M +Bellwood/M +Belmont/M +Belmopan/M +Beloit/M +Belorussia's +Belorussian/S +Belshazzar/M +Belton/M +Beltran/M +Beltsville/M +Belushi/M +Belva/M +Belvia/M +Ben/M +Benacerraf/M +Benares's +Bender/M +Bendick/M +Bendicty/M +Bendite/M +Bendix/M +Benedetta/M +Benedetto/M +Benedick/M +Benedict/M +Benedicta/M +Benedictine/MS +Benedicto/M +Benedikt/M +Benedikta/M +Benelux/M +Benet/M +Benetta/M +Benetton/M +Bengal/SM +Bengali/M +Benghazi/M +Bengt/M +Beniamino/M +Benin/M +Beninese +Benita/M +Benito/M +Benjamen/M +Benjamin/M +Benji/M +Benjie/M +Benjy/M +Benn/M +Bennett/M +Benni/M +Bennie/M +Bennington/M +Benny/M +Benoit/M +Benoite/M +Benson/M +Bent/M +Bentham/M +Bentlee/M +Bentley/MS +Benton/M +Benyamin/M +Benz/M +Benzedrine/M +Beograd's +Beowulf/M +Ber/MG +Berber/MS +Berenice/M +Beret/M +Berg/NRM +Bergen/M +Berger/M +Bergerac/M +Berget/M +Berglund/M +Bergman/M +Bergson/M +Bergsten/M +Bergstrom/M +Bering/RM +Beringer/M +Berk/YM +Berke/M +Berkeley/M +Berkie/M +Berkley/M +Berkly/M +Berkowitz/M +Berkshire/SM +Berky/M +Berle/M +Berlin/SZRM +Berliner/M +Berlioz/M +Berlitz/M +Berman/M +Bermuda/MS +Bermudan/S +Bermudian/S +Bern/M +Berna/M +Bernadene/M +Bernadette/M +Bernadina/M +Bernadine/M +Bernard/M +Bernardina/M +Bernardine/M +Bernardino/M +Bernardo/M +Bernarr/M +Bernays/M +Bernbach/M +Berne's +Bernelle/M +Bernese +Bernete/M +Bernetta/M +Bernette/M +Bernhard/M +Bernhardt/M +Berni/M +Bernice/M +Bernie/M +Berniece/M +Bernini/M +Bernita/M +Bernoulli/M +Bernstein/M +Berny/M +Berra/M +Berri/M +Berrie/M +Berry/M +Bert/M +Berta/M +Berte/M +Bertha/M +Berthe/M +Berti/M +Bertie/M +Bertillon/M +Bertina/M +Bertine/M +Berton/M +Bertram/M +Bertrand/M +Bertrando/M +Berty/M +Beryl/M +Beryle/M +Berzelius/M +Bess +Bessel/M +Bessemer/M +Bessie/M +Bessy/M +Best/M +Betelgeuse/M +Beth/M +Bethanne/M +Bethany/M +Bethe/M +Bethena/M +Bethesda/M +Bethina/M +Bethlehem/M +Bethune +Betsey/M +Betsy/M +Betta/M +Bette/M +Betteann/M +Betteanne/M +Betti/M +Bettie/M +Bettina/M +Bettine/M +Betty/SM +Bettye/M +Beulah/M +Bev's +Bevan/M +Beverie/M +Beverlee/M +Beverley/M +Beverlie/M +Beverly/M +Bevin/M +Bevon/M +Bevvy/M +Bhopal/M +Bhutan/M +Bhutanese +Bhutto/M +Bi/M +Bialystok/M +Bianca/M +Bianco/M +Bianka/M +Bib/M +Bibbie/M +Bibby/M +Bibbye/M +Bibi/M +Bible/MS +Biddie/M +Biddle/M +Biddy/M +Bidget/M +Bienville/M +Bierce/M +Bigelow/M +Bigfoot +Biko/M +Bil/MY +Bilbao/M +Bilbo/M +Bili/M +Bill/JM +Billi/M +Billie/M +Billings/M +Billy/M +Billye/M +Bimini/M +Bing/M +Bingham/M +Binghamton/M +Bini/M +Bink/M +Binky/M +Binni/M +Binnie/M +Binny/M +Bioko/M +Birch/M +Bird/M +Birdie/M +Birdseye/M +Birgit/M +Birgitta/M +Birk/M +Birkenstock/M +Birmingham/M +Biro/M +Biron/M +Biscay/M +Biscayne/M +Bishkek +Bishop/M +Bismarck/M +Bismark/M +Bissau/M +Bizet/M +Bjorn/M +Bk/M +Black's +Blackburn/M +Blackfeet +Blackfoot/M +Blackman/M +Blackmer/M +Blackpool/M +Blackstone/M +Blackwell/MS +Blaine/M +Blair/M +Blaire/M +Blake/M +Blakelee/M +Blakeley/M +Blakey/M +Blanca/M +Blanch/M +Blancha/M +Blanchard/M +Blanche/M +Blane/M +Blankenship/M +Blanton/M +Blantyre/M +Blatz/M +Blavatsky/M +Blayne/M +Bleeker/M +Blenheim/M +Blevins/M +Bligh/M +Blinni/M +Blinnie/M +Blinny/M +Bliss/M +Blisse/M +Blithe/M +Bloch/M +Bloemfontein/M +Blomberg/M +Blomquist/M +Blondell/M +Blondelle/M +Blondie/M +Blondy/M +Bloom/MR +Bloomer/M +Bloomfield/M +Bloomington/M +Blucher/M +Bluebeard/M +Blum/M +Blumenthal/M +Blvd +Blythe/M +Bo/MRZ +Bob/M +Bobbe/M +Bobbee/M +Bobbette/M +Bobbi/M +Bobbie/M +Bobbitt/M +Bobbsey/M +Bobby/M +Bobbye/M +Bobette/M +Bobina/M +Bobine/M +Bobinette/M +Bobrow/M +Boca/M +Boccaccio/M +Bodenheim/M +Bodhidharma/M +Bodhisattva/M +Boeing/M +Boeotia/M +Boeotian +Boer/M +Bogart/M +Bogartian/M +Bogey/M +Bogot�/M +Boheme/M +Bohemia/SM +Bohemian/SM +Bohr/M +Boigie/M +Bois/M +Boise/M +Boleyn/M +Bolivar/M +Bolivia/M +Bolivian/S +Bologna/M +Bolshevik/MS +Bolshevism/MS +Bolshevist/MS +Bolshevistic/M +Bolshoi/M +Bolton/M +Boltzmann/M +Bombay/M +Bonaparte/M +Bonaventure/M +Bond/M +Bondie/M +Bondon/M +Bondy/M +Bone/M +Bonham/M +Boniface/M +Bonita/M +Bonn/RM +Bonnee/M +Bonner/M +Bonneville/M +Bonni/M +Bonnibelle/M +Bonnie/M +Bonny/M +Bontempo/M +Booker/M +Boole/M +Boolean +Boone/M +Boonie/M +Boony/M +Boot/M +Boote/M +Booth/M +Boothe/M +Bootle/M +Bord/MN +Bordeaux/M +Borden/M +Bordie/M +Bordon/M +Bordy/M +Borealis/M +Boreas/M +Borg/M +Borges +Borgia/M +Boris +Bork/M +Born/M +Borneo/M +Borodin/M +Borroughs/M +Boru/M +Bosch/M +Bose/M +Bosnia/M +Bosnian/S +Bosporus/M +Bostitch/M +Boston/MS +Bostonian/SM +Boswell/MS +Botswana/M +Botticelli/M +Boucher/M +Boulder/M +Bourbaki/M +Bourbon/SM +Bourke/M +Bourne/M +Bournemouth/M +Bouvier +Bovary/M +Bowditch/M +Bowell/M +Bowen/M +Bowers +Bowery/M +Bowes +Bowie/M +Bowman/M +Boy/MR +Boyce/M +Boycey/M +Boycie/M +Boyd/M +Boyer/M +Boyle/M +Bo�tes +Br/TMN +Brad/MYN +Bradan/M +Bradbury/M +Bradburys +Braddock/M +Brade/M +Braden/M +Bradford/M +Bradley/M +Bradly/M +Bradney/M +Bradshaw/M +Bradstreet/M +Brady/M +Bragg/M +Brahe/M +Brahma/MS +Brahman/SM +Brahmanism/MS +Brahmaputra/M +Brahmin's +Brahms +Braille/GDSM +Brain/M +Brainard/SM +Bram/M +Brampton/M +Bran/M +Brana/M +Branch/M +Branchville/M +Brand/MRN +Brandais/M +Brande/M +Brandea/M +Brandeis/M +Brandel/M +Branden/M +Brandenburg/M +Brander/M +Brandi/M +Brandice/M +Brandie/M +Brandise/M +Brando/M +Brandon/M +Brandt/M +Brandtr/M +Brandy/M +Brandyn/M +Braniff/M +Brannon/M +Brant/M +Brantley/M +Braque/M +Brasilia +Bratislava/M +Brattain/M +Braun/M +Bray/M +Brazil/M +Brazilian/MS +Brazos/M +Brazzaville/M +Breanne/M +Brear/M +Breathalyzer/SM +Brecht/M +Breckenridge/M +Bree/M +Breena/M +Bremen/M +Bren/M +Brena/M +Brenda/M +Brendan/M +Brenden/M +Brendin/M +Brendis/M +Brendon/M +Brenn/RNM +Brenna/M +Brennan/M +Brennen/M +Brenner/M +Brent/M +Brenton/M +Bresenham/M +Brest/M +Bret/M +Breton +Brett/M +Brew/RM +Brewer/M +Brewster/M +Brezhnev/M +Bria/M +Brian/M +Briana/M +Brianna/M +Brianne/M +Briano/M +Briant/M +Brice/M +Bridalveil/M +Bride/M +Bridewell/M +Bridgeport/M +Bridger/M +Bridges +Bridget/M +Bridgetown/M +Bridgett/M +Bridgette/M +Bridgewater/M +Bridgman/M +Bridie/M +Brie/RSM +Brien/M +Brier/M +Brietta/M +Brig/M +Brigadoon +Brigg/MS +Brigham/M +Bright/M +Brighton/M +Brigid/M +Brigida/M +Brigit/M +Brigitta/M +Brigitte/M +Brillo +Brillouin/M +Brina/M +Brindisi/M +Briney/M +Brinkley/M +Brinn/M +Brinna/M +Briny/M +Brion/M +Brisbane/M +Bristol/M +Brit/MS +Brita/M +Britain/M +Britannia/M +Britannic +Britannica/M +Briticism/MS +British/RYZ +Britisher/M +Britishly/M +Britney/M +Britni/M +Briton/MS +Britt/MN +Britta/M +Brittan/M +Brittaney/M +Brittani/M +Brittany/MS +Britte/M +Britten/M +Britteny/M +Brittne/M +Brittney/M +Brittni/M +Brnaba/M +Brnaby/M +Brno/M +Broadway/SM +Brobdingnag/M +Brobdingnagian +Brock/M +Brockie/M +Brocky/M +Brod/M +Broddie/M +Broddy/M +Broderic/M +Broderick/M +Brodie/M +Brody/M +Broglie/M +Brok/M +Bron/M +Bronnie/M +Bronny/M +Bronson/M +Bronte +Bronx/M +Brook/SM +Brookdale/M +Brooke/M +Brookfield/M +Brookhaven/M +Brooklyn/M +Brookmont/M +Bros +Brose/M +Brown/MG +Browne/M +Brownell/M +Brownian/M +Brownie/MS +Browning/M +Brownsville/M +Brubeck/M +Bruce/M +Brucie/M +Bruckner/M +Bruegel/M +Brueghel's +Bruis/M +Brumidi/M +Brummel/M +Brunei/M +Brunelleschi/M +Brunhilda/M +Brunhilde/M +Bruno/M +Brunswick/M +Brussels +Brutus/M +Bruxelles/M +Bryan/M +Bryana/M +Bryant/M +Bryanty/M +Bryce/M +Bryn/M +Bryna/M +Brynn/RM +Brynna/M +Brynne/M +Brynner/M +Bryon/M +Brzezinski/M +Btu +Buber/M +Buchanan/M +Bucharest/M +Buchenwald/M +Buchwald/M +Buck/M +Buckie/M +Buckingham/M +Buckley/M +Buckner/M +Bucky/M +Bud/M +Budapest/M +Budd/M +Buddha/MS +Buddhism/SM +Buddhist/SM +Buddie/M +Buddy/M +Budweiser/MS +Buehring/M +Buena/M +Buffalo/M +Buffy/M +Buford/M +Bugatti/M +Buick/M +Buiron/M +Bujumbura/M +Bukhara/M +Bukharin/M +Bulawayo/M +Bulba/M +Bulfinch/M +Bulganin/M +Bulgaria/M +Bulgarian/S +Bullock/M +Bullwinkle/M +Bultmann/M +Bumbry/M +Bumppo/M +Bunche/M +Bundestag/M +Bundy/M +Bunin/M +Bunker/M +Bunni/M +Bunnie/M +Bunny/M +Bunsen/SM +Bunyan/M +Burbank/M +Burch/M +Burg/RM +Burger/M +Burgess/M +Burgoyne/M +Burgundian/S +Burgundy/MS +Burk/SM +Burke/M +Burl/M +Burlie/M +Burlingame/M +Burlington/M +Burma/M +Burmese +Burnaby/M +Burnard/M +Burne/MS +Burnett/M +Burns +Burnside/MS +Burr/M +Burris/M +Burroughs/M +Bursa/M +Burt/M +Burtie/M +Burton/M +Burty/M +Burundi/M +Burundian/S +Busch/M +Bush/M +Bushido/M +Bushnell/M +Butch/M +Butler/M +Butterfield/M +Buxtehude/M +Bu�uel/M +Byelorussia's +Byers/M +Byram/M +Byran/M +Byrann/M +Byrd/M +Byrle/M +Byrne/M +Byrom/M +Byron/M +Byronic +Byronism/M +Byzantine/S +Byzantium/M +C +C's +CA +CACM +CAD +CAI +CALCOMP/M +CAM +CAP +CARE +CATV +CB +CBC +CBS +CCTV +CCU +CD +CDC/M +CDT +CENTREX/M +CEO +CERN/M +CF +CFC +CFO +CIA +CID +CMOS +CNN +CNS +CO +COBOL +COD +COL +COLA +CPA +CPI +CPO +CPR +CPU/SM +CRT/S +CST +CT +CV +CZ +Ca/M +Cabernet/M +Cabot/M +Cabrera/M +Cabrini/M +Cacilia/M +Cacilie/M +Cad/M +Caddric/M +Cadette/S +Cadillac/MS +Cadiz/M +Caedmon/M +Caesar/MS +Cage/M +Cagney/M +Cahokia/M +Cahra/M +Caiaphas/M +Cain/MS +Caine/M +Cairistiona/M +Cairo/M +Caitlin/M +Caitrin/M +Cajun/MS +Cal/MY +CalComp/M +Calais/M +Calcomp/M +Calcutta/M +Calder/M +Calderon/M +Caldwell/M +Cale/M +Caleb/M +Caledonia/M +Calgary/M +Calhoun/M +Cali/M +Caliban/M +Calida/M +Calif/M +California/M +Californian/MS +Caligula/M +Calla/MS +Callaghan/M +Callahan/M +Callao/M +Callean/M +Calley/M +Calli/M +Callida/M +Callie/M +Calliope/M +Callisto/M +Cally/M +Caloocan/M +Caltech/M +Calumet/M +Calv/M +Calvary/M +Calvert/M +Calvin/M +Calvinism/MS +Calvinist/MS +Calvinistic +Calypso/M +Cam/M +Camacho/M +Camala/M +Cambodia/M +Cambodian/S +Cambrian/S +Cambridge/M +Camden/M +Camel/M +Camella/M +Camellia/M +Camelopardalis/M +Camelot/M +Camembert/MS +Cameron/M +Cameroon/SM +Cameroonian/S +Camey/M +Cami/M +Camila/M +Camile/M +Camilla/M +Camille/M +Camino/M +Cammi/M +Cammie/M +Cammy/M +Camoens/M +Campbell/M +Campbellsport/M +Campinas/M +Campos +Camry/M +Camus/M +Can/M +Canaan/M +Canaanite/SM +Canad/M +Canada/M +Canadian/S +Canadianism/SM +Canaletto/M +Canaries +Canaveral/M +Canberra/M +Cancer/MS +Cancun/M +Candace/M +Candi/SM +Candice/M +Candida/M +Candide/M +Candie/M +Candlewick/M +Candra/M +Candy/M +Canis/M +Cannes +Cannon/M +Canoga/M +Canonical +Canonical's +Canopus/M +Cantabrigian +Canterbury/M +Canton/M +Cantonese/M +Cantor/M +Cantrell/M +Cantu/M +Canute/M +Capek/M +Capella/M +Capet/M +Capetown/M +Caph/M +Capistrano/M +Capitan/M +Capitol/MS +Capitoline/M +Capone/M +Capote/M +Cappy/M +Capra/M +Capri/M +Caprice/M +Capricorn/MS +Capt/M +Capulet/M +Caputo/M +Car/MNY +Cara/M +Caracalla/M +Caracas/M +Caralie/M +Caravaggio/M +Carboloy/M +Carbondale/M +Carbone/MS +Carboniferous +Carborundum/MS +Carce/M +Cardenas/M +Cardiff/M +Cardin/M +Cardiod/M +Care/M +Caren/M +Carena/M +Caresa/M +Caressa/M +Caresse/M +Carey/M +Cari/M +Caria/M +Carib/M +Caribbean/S +Carie/M +Caril/M +Carilyn/M +Carin/M +Carina/M +Carine/M +Cariotta/M +Carissa/M +Carita/M +Caritta/M +Carl/MNG +Carla/M +Carlee/M +Carleen/M +Carlen/M +Carlene/M +Carleton/M +Carletonian/M +Carley/M +Carlie/M +Carlin/M +Carlina/M +Carline/M +Carling/M +Carlita/M +Carlo/SM +Carlota/M +Carlotta/M +Carlsbad/M +Carlson/M +Carlton/M +Carly/M +Carlye/M +Carlyle/M +Carlyn/M +Carlynn/M +Carlynne/M +Carma/M +Carmel/M +Carmela/M +Carmelia/M +Carmelina/M +Carmelita/M +Carmella/M +Carmelle/M +Carmelo/M +Carmen/M +Carmencita/M +Carmichael/M +Carmina/M +Carmine/M +Carmita/M +Carmon/M +Carnap/M +Carnegie/M +Carney/M +Carnot/M +Carny/M +Caro/M +Carol/M +Carola/M +Carolan/M +Carolann/M +Carole/M +Carolee/M +Carolin/M +Carolina/MS +Caroline/M +Carolingian +Carolinian/S +Caroljean/M +Carolus/M +Carolyn/M +Carolyne/M +Carolynn/M +Caron/M +Carpathian/MS +Carpenter/M +Carr/M +Carree/M +Carri/M +Carrie/M +Carrier/M +Carrillo/M +Carrissa/M +Carrol/M +Carroll/M +Carry/MR +Carson/M +Cart/MR +Carter/M +Cartesian +Carthage/M +Carthaginian/S +Cartier/M +Cartwright/M +Carty/RM +Caruso/M +Carver/M +Cary/M +Caryl/M +Caryn/M +Casablanca/M +Casals/M +Casandra/M +Casanova/SM +Casar/M +Cascades/M +Case/M +Casey/M +Cash/M +Casi/M +Casie/M +Caspar/M +Casper/M +Caspian +Cass +Cassandra/SM +Cassandre/M +Cassandry/M +Cassatt/M +Cassaundra/M +Cassey/M +Cassi/M +Cassie/M +Cassiopeia/M +Cassite/M +Cassius/M +Cassondra/M +Cassy/M +Castaneda/M +Castile's +Castillo/M +Castor/M +Castries/M +Castro/M +Catalan/MS +Catalina/M +Catalonia/M +Catarina/M +Catawba/M +Cate/M +Caterina/M +Caterpillar +Catha/M +Catharina/M +Catharine/M +Cathay/M +Cathe/RM +Cathee/M +Cather/M +Catherin/M +Catherina/M +Catherine/M +Cathi/M +Cathie/M +Cathleen/M +Cathlene/M +Catholic/S +Catholicism/SM +Cathrin/M +Cathrine/M +Cathryn/M +Cathy/M +Cathyleen/M +Cati/M +Catie/M +Catiline/M +Catina/M +Catlaina/M +Catlee/M +Catlin/M +Cato/M +Catrina/M +Catriona/M +Catskill/SM +Catt/M +Catullus/M +Caty/M +Caucasian/S +Caucasoid/S +Caucasus/M +Cauchy/M +Cavendish/M +Cavour/M +Caxton/M +Caye/M +Cayenne/M +Cayla/M +Cayman/M +Cayuga/M +Caz/M +Cazzie/M +Cb/M +Cchaddie/M +Cd/M +Ce +Ceausescu/M +Cebu/M +Cebuano/M +Cece/M +Cecelia/M +Cecil/M +Cecile/M +Ceciley/M +Cecilia/M +Cecilio/M +Cecilius/M +Cecilla/M +Cecily/M +Ced/M +Cedric/M +Ceil/M +Celanese/M +Cele/M +Celebes's +Celene/M +Celesta/M +Celeste/M +Celestia/M +Celestina/M +Celestine/M +Celestyn/M +Celestyna/M +Celia/M +Celie/M +Celina/M +Celinda/M +Celine/M +Celinka/M +Celisse/M +Celka/M +Celle/M +Cellini/M +Cello/M +Celsius/S +Celt/MS +Celtic/SM +Cenozoic +Centaurus/M +Centigrade +Centralia/M +Centrex +Cepheid +Cepheus/M +Cerberus/M +Cerenkov/M +Ceres/M +Cerf/M +Cervantes/M +Cesar/M +Cesare/M +Cesarean +Cesaro/M +Cessna/M +Cesya/M +Cetus/M +Ceylon/M +Ceylonese +Cezanne/S +Cf/M +Ch'in +Ch/MGNRS +Chablis/SM +Chad/M +Chadd/M +Chaddie/M +Chaddy/M +Chadian/S +Chadwick/M +Chaffey/M +Chagall/M +Chaim/M +Chaldea/M +Chaldean/M +Chalmers +Chamberlain/M +Chambers/M +Champlain/M +Chan/M +Chance/M +Chancellorsville/M +Chancey/M +Chanda/M +Chandal/M +Chandigarh/M +Chandler/M +Chandra/M +Chandragupta/M +Chandrasekhar/M +Chandy/M +Chane/M +Chanel/M +Chaney/M +Chang/M +Changchun/M +Changsha/M +Channa/M +Channing/M +Chantal/M +Chantalle/M +Chantilly/M +Chanukah's +Chao/M +Chaplin/M +Chapman/M +Chappaquiddick/M +Chara +Chardonnay +Charil/M +Charin/M +Chariot/M +Charis +Charissa/M +Charisse/M +Charita/M +Charity/M +Charla/M +Charlean/M +Charleen/M +Charlemagne/M +Charlena/M +Charlene/M +Charles/M +Charleston/SM +Charley/M +Charlie/M +Charline/M +Charlot/M +Charlotta/M +Charlotte/M +Charlottesville/M +Charlottetown/M +Charlton/M +Charmain/M +Charmaine/M +Charmane/M +Charmian/M +Charmin/M +Charmine/M +Charmion/M +Charo/M +Charolais +Charon/M +Chartres/M +Charybdis/M +Charyl/M +Chas +Chase/M +Chasity/M +Chastity/M +Chateaubriand +Chattahoochee/M +Chattanooga/M +Chatterley/M +Chatterton/M +Chaucer/M +Chaunce/M +Chauncey/M +Chautauqua/M +Chavez/M +Chayefsky/M +Che/M +Chechen/M +Chechnya/M +Cheddar/MS +Cheerios/M +Cheeto/M +Cheever/M +Chekhov/M +Chelsae/M +Chelsea/M +Chelsey/M +Chelsie/M +Chelsy/M +Chelyabinsk/M +Chen/M +Cheng/M +Chengdu +Cheops/M +Cher/M +Chere/M +Cherey/M +Cheri/M +Cherianne/M +Cherice/M +Cherida/M +Cherie/M +Cherilyn/M +Cherilynn/M +Cherin/M +Cherise/M +Cherish/M +Cheriton/M +Cherlyn/M +Chernenko/M +Chernobyl/M +Cherokee/MS +Cherri/M +Cherrita/M +Cherry/M +Chery/M +Cherye/M +Cheryl/M +Chesapeake/M +Cheshire/M +Cheslie/M +Chester/M +Chesterfield/M +Chesterton/M +Cheston/M +Chet/M +Chev/M +Chevalier/M +Cheviot/M +Chevrolet/M +Chevy/M +Cheyenne/SM +Chi/M +Chiang/M +Chianti/S +Chiarra/M +Chiba/M +Chic/M +Chicago/M +Chicagoan/SM +Chicana/MS +Chicano/MS +Chick/M +Chickasaw/SM +Chickie/M +Chicky/M +Chico/M +Chihuahua/MS +Chile/MS +Chilean/S +Chilton/M +Chimborazo/M +Chimera/S +Chimiques +Chimu/M +Chin/M +China/M +Chinaman/M +Chinamen +Chinatown/SM +Chinese/M +Ching/M +Chinook/MS +Chip/M +Chipewyan/M +Chippendale/M +Chippewa/MS +Chiquia/M +Chiquita/M +Chirico/M +Chisholm/M +Chisinau/M +Chittagong/M +Chlo/M +Chloe/M +Chloette/M +Chloris +Choctaw/MS +Chomsky/M +Chongqing +Chopin/M +Chou/M +Chretien/M +Chris/M +Chrisse/M +Chrissie/M +Chrissy/M +Christ/SMN +Christa/M +Christabel/M +Christabella/M +Christal/M +Christalle/M +Christan/M +Christchurch/M +Christean/M +Christel/M +Christen/M +Christendom/MS +Christensen/M +Christenson/M +Christi/M +Christian/MS +Christiana/M +Christiane/M +Christianity/SM +Christianize/GSD +Christiano/M +Christians/N +Christiansen/M +Christie/SM +Christin/M +Christina/M +Christine/M +Christlike +Christmas/SM +Christmastide/SM +Christmastime/S +Christoffel/M +Christoffer/M +Christoforo/M +Christoper/M +Christoph/MR +Christophe/M +Christopher/M +Christophorus/M +Christos/M +Christy's +Christye/M +Christyna/M +Chrisy/M +Chrotoem/M +Chrysa/M +Chrysler/M +Chrysostom/M +Chrystal/M +Chryste/M +Chrystel/M +Chucho/M +Chuck/M +Chukchi/M +Chumash/M +Chung/M +Chungking's +Church/MS +Churchill/M +Churchillian +Chuvash/M +Ci +Cicely/M +Cicero/M +Ciceronian +Cicily/M +Cid/M +Ciel/M +Cilka/M +Cincinnati/M +Cinda/M +Cindee/M +Cindelyn/M +Cinderella/MS +Cindi/M +Cindie/M +Cindra/M +Cindy/M +Cinerama/M +Cinnamon/M +Circe/M +Cirillo/M +Cirilo/M +Ciro/M +Cissiee/M +Cissy/M +Citibank/M +Citroen/M +Cl/VM +Claiborn/M +Claiborne/M +Clair/M +Claire/M +Clairol/M +Clancy/M +Clapeyron/M +Clapton/M +Clara/M +Clarabelle/M +Clarance/M +Clare/M +Claremont/M +Clarence/M +Clarendon/M +Claresta/M +Clareta/M +Claretta/M +Clarette/M +Clarey/M +Clari/M +Claribel/M +Clarice/M +Clarie/M +Clarinda/M +Clarine/M +Clarissa/M +Clarisse/M +Clarita/M +Clark/M +Clarke/M +Clarridge/M +Clary/M +Claude/M +Claudell/M +Claudelle/M +Claudetta/M +Claudette/M +Claudia/M +Claudian/M +Claudianus/M +Claudie/M +Claudina/M +Claudine/M +Claudio/M +Claudius/M +Claus/NM +Clausen/M +Clausewitz/M +Clausius/M +Clay/M +Clayborn/M +Clayborne/M +Claybourne/M +Clayson/M +Clayton/M +Clea/M +Clearwater/M +Cleavland/M +Clem/XM +Clemence/M +Clemenceau/M +Clement/MS +Clemente/M +Clementia/M +Clementina/M +Clementine/M +Clementius/M +Clemmie/M +Clemmy/M +Clemons +Clemson/M +Cleo/M +Cleon/M +Cleopatra/M +Clerc/M +Clerissa/M +Cletis +Cletus/M +Cleve/M +Cleveland/M +Clevey/M +Clevie/M +Cliburn/M +Cliff/M +Clifford/M +Clifton/M +Clim/M +Cline/M +Clint/M +Clinton/M +Clio/M +Clive/M +Clo/M +Cloe/M +Cloris/M +Clotho/M +Clotilda/M +Clovis/M +Cluj/M +Cly/M +Clyde/M +Clydesdale/M +Clytemnestra/M +Clyve/M +Clywd/M +Cm/M +Co/M +Coates/M +Cob/M +Cobain/M +Cobb/M +Cobbie/M +Cobby/M +Cobol/M +Cochabamba/M +Cochin/M +Cochise/M +Cochran/M +Cockney +Cocteau/M +Cod/M +Codee/M +Codi/M +Codie/M +Cody/M +Coffey/M +Coffman/M +Cognac/M +Cohan/M +Cohen/M +Cohn/M +Coimbatore/M +Cointon/M +Coke/MS +Col/MY +Colan/M +Colas +Colbert/M +Colby/M +Cole/M +Coleen/M +Coleman/M +Colene/M +Coleridge/M +Colet/M +Coletta/M +Colette/M +Colfax/M +Colgate/M +Colin/M +Colleen/M +Collen/M +Collete/M +Collette/M +Collie/M +Collier/M +Collin/MS +Colline/M +Colly/RM +Colman/M +Colo/M +Cologne/M +Colombia/M +Colombian/S +Colombo/M +Colon/M +Coloradan/S +Colorado/M +Coloradoan/S +Colosseum/M +Colt/M +Coltrane/M +Columbia/M +Columbian +Columbine/M +Columbus/M +Colver/M +Com/M +Comanche/MS +Combs/M +Comdex/M +Comdr/M +Cominform/M +Commie +Commons/M +Commonwealth/M +Commonwealths +Communion/SM +Communism/S +Communist/S +Comoros +Compaq/M +Compton/M +CompuServe/M +Compuserve/M +Comte/M +Con/M +Conakry/M +Conan/M +Conant/M +Concepci�n/M +Concetta/M +Concettina/M +Conchita/M +Concord/MS +Concorde/M +Concordia/M +Condorcet/M +Conestoga +Confederacy/M +Confederate/S +Confucian/S +Confucianism/SM +Confucius/M +Cong/M +Congo/M +Congolese +Congregational +Congregationalist/S +Congress/MS +Congreve/M +Conley/M +Conn/RM +Connecticut/M +Connelly/M +Conner/M +Connery/M +Conney/M +Conni/M +Connie/M +Connor/SM +Conny/M +Conrad/M +Conrade/M +Conrado/M +Conrail/M +Conroy/M +Consalve/M +Conservative/S +Consolata/M +Constable/M +Constance/M +Constancia/M +Constancy/M +Constanta/M +Constantia/M +Constantin/M +Constantina/M +Constantine/M +Constantino/M +Constantinople/M +Constitution +Consuela/M +Consuelo/M +Continent/M +Continental/S +Contreras/M +Conway/M +Cook/M +Cooke/M +Cookie/M +Cooley/M +Coolidge/M +Coop/MR +Cooper/M +Coors/M +Copeland/M +Copenhagen/M +Copernican +Copernicus/M +Copland/M +Copley/M +Copperfield/M +Coppola/M +Coptic/M +Cora/M +Corabel/M +Corabella/M +Corabelle/M +Coral/M +Coralie/M +Coraline/M +Coralyn/M +Corbet/M +Corbett/M +Corbie/M +Corbin/M +Corby/M +Cord/M +Cordelia/M +Cordelie/M +Cordell/M +Cordey/M +Cordi/M +Cordie/M +Cordilleras +Cordoba +Cordula/M +Cordy/M +Coreen/M +Corella/M +Corenda/M +Corene/M +Coretta/M +Corette/M +Corey/M +Corfu/M +Cori/M +Corie/M +Corilla/M +Corina/M +Corine/M +Corinna/M +Corinne/M +Corinth/M +Corinthian/S +Corinthians/M +Coriolanus/M +Coriolis/M +Coriss/M +Corissa/M +Cork/M +Corliss/M +Corly/M +Cormack/M +Cornall/M +Corneille/M +Cornela/M +Cornelia/M +Cornelius/M +Cornell/M +Cornelle/M +Corney/M +Cornie/M +Cornish/S +Cornwall/M +Cornwallis/M +Corny/M +Coronado/M +Corot/M +Corp +Correggio/M +Correna/M +Correy/M +Corri/M +Corrianne/M +Corrie/M +Corrina/M +Corrine/M +Corrinne/M +Corry/M +Corsica/M +Corsican/S +Cort/M +Cortes/S +Cortez's +Cortie/M +Cortland/M +Cortney/M +Corty/M +Corvallis/M +Corvus/M +Cory/M +Cos +Cosby/M +Cosetta/M +Cosette/M +Cosimo/M +Cosme/M +Cosmo/M +Cossack/SM +Costa/M +Costanza/M +Costello/M +Costner/M +Cote/M +Cotonou/M +Cotopaxi/M +Cotton/M +Coulomb/M +Couperin/M +Courbet/M +Court/M +Courtenay/M +Courtnay/M +Courtney/M +Cousteau/M +Covent/M +Coventry/MS +Coward/M +Cowley/M +Cowper/M +Cox/M +Coy/M +Cozmo/M +Cozumel/M +Cpl +Cr/M +Crabbe/M +Craft/M +Craggie/M +Craggy/M +Craig/M +Cramer/M +Cranach/M +Crandall/M +Crane/M +Cranford/M +Cranmer/M +Cranston/M +Crater/M +Crawford/M +Cray/SM +Crayola/M +Creation/M +Creator/M +Cree/MDS +Creek/SM +Creigh/M +Creight/M +Creighton/M +Creole/MS +Creon/M +Crestview/M +Cretaceous/Y +Cretaceously/M +Cretan/S +Crete/M +Crichton/M +Crick/M +Crimea/M +Crimean +Crin/M +Cris/M +Crisco/M +Crissie/M +Crissy/M +Crista/M +Cristabel/M +Cristal/M +Cristen/M +Cristi/M +Cristian/M +Cristiano/M +Cristie/M +Cristin/M +Cristina/M +Cristine/M +Cristionna/M +Cristobal/M +Cristy/M +Croat/SM +Croatia/M +Croatian/S +Croce/M +Crockett/M +Crockpot/M +Croesus/SM +Croix/M +Cromwell/M +Cromwellian +Cronin/M +Cronkite/M +Cronus/M +Crookes/M +Crosby/M +Cross/M +Crowley/M +Crucifixion/MS +Cruikshank/M +Crusoe/M +Crux/M +Cruz/M +Cryptozoic/M +Crysta/M +Crystal/M +Crystie/M +Cs +Ct/M +Cthrine/M +Cu/M +Cuba/M +Cuban/S +Cuchulain/M +Cuisinart/M +Culbertson/M +Cull/MN +Cullan/M +Cullen/M +Culley/M +Cullie/M +Cullin/M +Cully/M +Culver/MS +Cumberland/M +Cummings +Cunard/M +Cunningham/M +Cupertino/M +Cupid/M +Curacao/M +Curcio/M +Curie/M +Curitiba/M +Curr/M +Curran/M +Currey/M +Currie/M +Currier/M +Curry/MR +Curt/M +Curtice/M +Curtis/M +Cushman/M +Custer/M +Cuvier/M +Cuzco/M +Cy/M +Cyanamid/M +Cyb/M +Cybele/M +Cybil/M +Cybill/M +Cyclades +Cyclopes +Cyclops/M +Cygnus/M +Cymbre/M +Cynde/M +Cyndi/M +Cyndia/M +Cyndie/M +Cyndy/M +Cynthea/M +Cynthia/M +Cynthie/M +Cynthy/M +Cyprian +Cypriot/SM +Cyprus/M +Cyrano/M +Cyril/M +Cyrill/M +Cyrille/M +Cyrillic +Cyrillus/M +Cyrus/M +Czech +Czechoslovak/S +Czechoslovakia/M +Czechoslovakian/S +Czechs +Czerniak/M +Czerny/M +D +D'Arcy +D's +DA +DAG +DARPA/M +DAT +DB +DBMS +DC +DD +DDS +DDT +DE +DEC/M +DECNET +DECnet/M +DECstation/M +DECsystem/M +DECtape/M +DH +DI +DJ +DMD +DMZ +DNA +DOA +DOB +DOD +DOE +DOS +DOT +DP +DPT +DPs +DST +DTP +DUI +DWI +Dacca's +Dacey/M +Dachau/M +Dacia/M +Dacie/M +Dacron/MS +Dacy/M +Dada/M +Dadaism/M +Dadaist/M +Dade/M +Daedalus/M +Dael/M +Daffi/M +Daffie/M +Daffy/M +Dag/M +Dagmar/M +Dagny/M +Daguerre/M +Dagwood/M +Dahl/M +Dahlia/M +Dahomey/M +Daile/M +Daimler/M +Daisey/M +Daisi/M +Daisie/M +Daisy/M +Dakar/M +Dakota/SM +Dakotan +Dal/M +Dale/M +Dalenna/M +Daley/M +Dalhousie/M +Dali/SM +Dalia/M +Dalian/M +Dalila/M +Dall/M +Dallas/M +Dalli/MS +Dallon/M +Dalmatia/M +Dalmatian/SM +Daloris/M +Dalston/M +Dalt/M +Dalton/M +Daly/M +Damara/M +Damaris/M +Damascus/M +Dame/SMN +Damian/M +Damiano/M +Damien/M +Damion/M +Damita/M +Damocles/M +Damon/M +Dan/SM +Dana/M +Dana� +Danbury/M +Dane/SM +Danelaw/M +Danell/M +Danella/M +Danette/M +Dangerfield/M +Dani/M +Dania/M +Danial/M +Danica/M +Danice/M +Danie/M +Daniel/SM +Daniela/M +Daniele/M +Daniella/M +Danielle/M +Danielson/M +Danika/M +Danila/M +Danish +Danit/M +Danita/M +Danna/M +Dannel/M +Danni/M +Dannie/M +Danny/M +Dannye/M +Dante/M +Danton/M +Danube/M +Danubian +Danville/M +Danya/M +Danyelle/M +Danyette/M +Danzig/M +Daphene/M +Daphna/M +Daphne/M +Dar/MNH +Dara/M +Darb/M +Darbee/M +Darbie/M +Darby/M +Darcee/M +Darcey/M +Darci/M +Darcie/M +Darcy/M +Darda/M +Dardanelles +Dare/M +Dareen/M +Darell/M +Darelle/M +Daren/M +Dari/M +Daria/M +Darice/M +Darill/M +Darin/M +Dario/M +Darius/M +Darjeeling/M +Darla/M +Darleen/M +Darlene/M +Darline/M +Darling/M +Darlington/M +Darlleen/M +Darn/M +Darnall/M +Darnell/M +Daron/M +Darrel/M +Darrell/M +Darrelle/M +Darren/M +Darrick/M +Darrin/M +Darrow/M +Darryl/M +Darsey/M +Darsie/M +Darth/M +Dartmouth/M +Darvon/M +Darwin/M +Darwinian/S +Darwinism/MS +Darwinist/MS +Darya/M +Daryl/M +Daryle/M +Daryn/M +Dasha/M +Dasi/M +Dasie/M +Dasya/M +Datamation/M +Datamedia/M +Datha/M +Datsun/M +Daugherty/M +Daumier/M +Daune/M +Dav/MN +Davao/M +Dave/M +Daveen/M +Daven/M +Davenport/M +Daveta/M +Davey/M +David/SM +Davida/M +Davidde/M +Davide/M +Davidson/M +Davie/M +Davin/M +Davina/M +Davine/M +Davinich/M +Davis/M +Davita/M +Davon/M +Davy/SM +Dawes/M +Dawn/M +Dawna/M +Dawson/M +Day/M +Dayle/M +Dayna/M +Dayton/M +Ddene/M +De/NM +DeKalb/M +DeKastere/M +DeMorgan/M +Dean/M +Deana/M +Deandre/M +Deane/M +Deann/M +Deanna/M +Deanne/M +Dearborn/M +Deb/MS +Debbi/M +Debbie/M +Debby/M +Debee/M +Debera/M +Debi/M +Debian +Debian's +Debor/M +Debora/M +Deborah/M +Debra/M +Debussy/M +Dec/M +Decalogue/M +Decatur/M +Decca/M +Deccan/M +December/SM +Deck/RM +Decker/M +Dede/M +Dedekind/M +Dedie/M +Dedra/M +Dee/M +Deeann/M +Deeanne/M +Deedee/M +Deena/M +Deerdre/M +Deere/M +Deeyn/M +Defoe/M +Degas/M +Dehlia/M +Deidre/M +Deimos/M +Deina/M +Deirdre/MS +Deity/M +Dejesus/M +Del/MY +Dela/M +Delacroix/M +Delacruz/M +Delainey/M +Delaney/M +Delano/M +Delaware/MS +Delawarean/SM +Delbert/M +Delcina/M +Delcine/M +Deleon/M +Delft/M +Delgado/M +Delhi/M +Delia/M +Delibes/M +Delila/M +Delilah/M +Delilahs +Delinda/M +Delius/M +Dell/M +Della/M +Dellwood/M +Delly/M +Delmar/M +Delmarva/M +Delmer/M +Delmonico +Delmor/M +Delmore/M +Delora/M +Delores/M +Deloria/M +Deloris/M +Delphi/M +Delphic +Delphine/M +Delphinia/M +Delphinus/M +Delta/M +Dem/MG +Demavend/M +Demerol/M +Demeter/M +Demetra/M +Demetre/M +Demetri/MS +Demetria/M +Demetrius/M +Deming/M +Democrat/MS +Democratic +Democritus/M +Demosthenes/M +Demott/M +Dempsey/M +Den/M +Dena/M +Dene/M +Deneb/M +Denebola/M +Deneen/M +Deng/M +Deni/SM +Denice/M +Denise/M +Denmark/M +Denna/M +Dennet/M +Denney/M +Denni/MS +Dennie/M +Dennison/M +Denny/M +Denver/M +Deny/M +Denys +Denyse/M +Deon/M +Deonne/M +Dependant/MS +Dept/M +Der/M +Derby/SM +Derbyshire/M +Derek/M +Derick/M +Derk/M +Dermot/M +Derrek/M +Derrick/M +Derrida/M +Derrik/M +Derril/M +Derron/M +Derry/M +Derward/M +Derwin/M +Des +Descartes/M +Desdemona/M +Desi/M +Desirae/M +Desiree/M +Desiri/M +Desmond/M +Desmund/M +Detroit/M +Deuteronomy/M +Deutsch/M +Dev/M +Deva/M +Devan/M +Devanagari/M +Devi/M +Devin/M +Devina/M +Devinne/M +Devland/M +Devlen/M +Devlin/M +Devon/M +Devondra/M +Devonian +Devonna/M +Devonne/M +Devonshire/M +Devora/M +Devy/M +Dew/M +Dewain/M +Dewar/M +Dewayne/M +Dewey/M +Dewie/M +Dewitt/M +Dex/M +Dexedrine/M +Dexter/M +Dhaka +Dhaulagiri/M +Di/M +DiCaprio/M +DiMaggio/M +Diaghilev/M +Diahann/M +Dian/M +Diana/M +Diandra/M +Diane/M +Dianemarie/M +Diann/M +Dianna/M +Dianne/M +Diannne/M +Diarmid/M +Diaspora/SM +Diaz's +Dick/XM +Dickens/M +Dickensian/S +Dickerson/M +Dickie/M +Dickinson/M +Dickson/M +Dicky/M +Dictaphone/SM +Diderot/M +Didi/M +Dido/M +Diefenbaker/M +Diego/M +Diem/M +Diena/M +Dierdre/M +Diesel's +Dieter/M +Dietrich/M +Dietz/M +Dijkstra/M +Dijon/M +Dilan/M +Dilbert/M +Dill/M +Dillard/M +Dillie/M +Dillinger/M +Dillon/M +Dilly/M +Dimitri/M +Dimitry/M +Dina/M +Dinah/M +Dinnie/M +Dinny/M +Dino/M +Diocletian/M +Diogenes/M +Dion/M +Dione/M +Dionis/M +Dionisio/M +Dionne/M +Dionysian +Dionysus/M +Diophantine/M +Dior/M +Dipper/M +Dir +Dirac/M +Dirichlet/M +Dirk/M +Dis +Disney/M +Disneyland/M +Disraeli/M +Dita/M +Ditzel/M +Dix/M +Dixie/M +Dixiecrat/MS +Dixieland/MS +Dixon/M +Djakarta's +Djibouti/M +Dmitri/M +Dnepr's +Dnepropetrovsk/M +Dnieper's +Dniester/M +Dniren/M +Dobbin/M +Doberman +Dobro/M +Doctor +Doctorow/M +Dode/M +Dodge/M +Dodgson/M +Dodi/M +Dodie/M +Dodington/M +Dodoma/M +Dodson/M +Dody/M +Doe/M +Doge/M +Dogtown/M +Doha/M +Dolby/SM +Dole/M +Dolf/M +Doll/M +Dolley/M +Dolli/M +Dollie/M +Dolly/M +Dolores/M +Dolorita/SM +Dolph/M +Dom/M +Domenic/M +Domenico/M +Domeniga/M +Domesday/M +Dominga/M +Domingo/M +Dominguez/M +Domini/M +Dominic/M +Dominica/M +Dominican/MS +Dominick/M +Dominik/M +Dominique/M +Domitian/M +Don/SM +Dona/M +Donahue/M +Donal/M +Donald/M +Donaldson/M +Donall/M +Donalt/M +Donatello/M +Donaugh/M +Donavon/M +Donella/M +Donelle/M +Donetsk/M +Donetta/M +Donia/M +Donica/M +Donielle/M +Donizetti/M +Donn/RM +Donna/M +Donnamarie/M +Donne/M +Donnell/M +Donnelly/M +Donner/M +Donni/M +Donnie/M +Donny/M +Donovan/M +Dooley/M +Doolittle/M +Doonesbury/M +Doppler/M +Dora/M +Dorado/M +Doralia/M +Doralin/M +Doralyn/M +Doralynn/M +Doralynne/M +Dorcas +Dorchester/M +Doreen/M +Dorelia/M +Dorella/M +Dorelle/M +Dorena/M +Dorene/M +Doretta/M +Dorette/M +Dorey/M +Dori/MS +Doria/M +Dorian/M +Doric +Dorice/M +Dorie/M +Dorine/M +Dorisa/M +Dorise/M +Dorita/M +Doro/M +Dorolice/M +Dorolisa/M +Dorotea/M +Doroteya/M +Dorothea/M +Dorothee/M +Dorothy/M +Dorree/M +Dorri/SM +Dorrie/M +Dorry/M +Dorsey/M +Dorthea/M +Dorthy/M +Dortmund/M +Dory/M +Dor�/M +Dosi/M +Dostoevsky/M +Dot/M +Doti/M +Dotson/M +Dotti/M +Dottie/M +Dotty/M +Douala/M +Douay/M +Doubleday/M +Doug/M +Dougherty/M +Dougie/M +Douglas/M +Douglass +Dougy/M +Douro/M +Dov/MR +Dover/M +Dow/M +Downey/M +Downs +Doy/M +Doyle/M +Dr/M +Draco/M +Draconian +Dracula/M +Drake/M +Dramamine/MS +Drambuie/M +Drano/M +Dravidian/M +Dre/M +Dreddy/M +Dredi/M +Dreiser/M +Dresden/M +Drew/M +Drexel/M +Dreyfus/M +Dreyfuss +Drona/M +Dru/M +Druci/M +Drucie/M +Drucill/M +Drucy/M +Drud/M +Drugi/M +Druid's +Drummond/M +Drury/M +Drusi/M +Drusie/M +Drusilla/M +Drusy/M +Dryden/M +Dshubba/M +Du/M +DuPont/MS +Duane/M +Dubai/M +Dubcek/M +Dubhe/M +Dublin/M +Dubrovnik/M +Dubuque/M +Duchamp/M +Dud/M +Dudley/M +Duff/M +Duffie/M +Duffy/M +Dugald/M +Duisburg/M +Duke/M +Dukey/M +Dukie/M +Duky/M +Dulce/M +Dulcea/M +Dulci/M +Dulcia/M +Dulciana/M +Dulcie/M +Dulcine/M +Dulcinea/M +Dulcy/M +Dulles/M +Dulsea/M +Duluth/M +Dumas +Dumbo/M +Dumont/M +Dumpster/S +Dumpty/M +Dun/M +Dunant/M +Dunbar/M +Dunc/M +Duncan/M +Dundee/M +Dunedin/M +Dunham/M +Dunkirk/M +Dunlap/M +Dunn/M +Dunne/M +Dunstan/M +Dupont/MS +Dur/M +Duracell/M +Duran/M +Durand/M +Durant/M +Durante/M +Durban/M +Durex/M +Durham/MS +Durkee/M +Durkheim/M +Durocher/M +Durward/M +Duse/M +Dusenberg/M +Dusenbury/M +Dushanbe/M +Dustin/M +Dusty/M +Dutch/M +Dutchman/M +Dutchmen +Dutchwoman +Dutchwomen +Duvalier/M +Dvina/M +Dvor�k/M +Dwain/M +Dwayne/M +Dwight/M +Dy/M +Dyan/M +Dyana/M +Dyane/M +Dyann/M +Dyanna/M +Dyanne/M +Dyer/M +Dyke/M +Dylan/M +Dyna/M +Dynah/M +Dzerzhinsky/M +D�rer/M +D�sseldorf +E +E's +EBCDIC +EC +ECG +EDP +EDT +EEC +EEG +EEO +EEOC +EFL +EFT +EGA/M +EKG +EM +EMT +ENE +EOE +EPA +ER +ERA +ESE +ESL +ESP +EST +ET +ETA +ETD +EU +Eachelle/M +Eada/M +Eadie/M +Eadith/M +Eadmund/M +Eakins/M +Eal/M +Ealasaid/M +Eamon/M +Earhart/M +Earl/M +Earle/M +Earlene/M +Earlie/M +Earline/M +Early/M +Earnest/M +Earnestine/M +Earp/M +Eartha/M +Earvin/M +East/ZSMR +Easter/M +Eastern/RZ +Easterner/M +Easthampton/M +Eastland/M +Eastman/M +Eastwick/M +Eastwood/M +Eaton/M +Eb/MN +Eba/M +Ebba/M +Eben/M +Ebeneezer/M +Ebeneser/M +Ebenezer/M +Eberhard/M +Eberto/M +Ebola +Ebonee/M +Ebonics +Ebony/M +Ebro/M +Eccles +Ecclesiastes/M +Eco/M +Ecole/M +Econometrica/M +Ecstasy/S +Ecuador/M +Ecuadoran/S +Ecuadorean/S +Ecuadorian/S +Ed/XMN +Eda/M +Edam/SM +Edan/M +Edd/M +Edda/M +Eddi/M +Eddie/M +Eddy/M +Ede/M +Edee/M +Edeline/M +Eden/M +Edgar/M +Edgard/M +Edgardo/M +Edgerton/M +Edgewater/M +Edgewood/M +Edi/MH +Edie/M +Edik/M +Edin/M +Edinburgh/M +Edison/M +Edita/M +Edith/M +Editha/M +Edithe/M +Ediva/M +Edlin/M +Edmon/M +Edmond/M +Edmonton/M +Edmund/M +Edna/M +Edouard/M +Edsel/M +Edsger/M +Eduard/M +Eduardo/M +Edubuntu +Edubuntu's +Eduino/M +Edvard/M +Edward/SM +Edwardian +Edwardo/M +Edwin/M +Edwina/M +Edy/M +Edyth/M +Edythe/M +Eeyore/M +Effie/M +Efrain/M +Efrem/M +Efren/M +Egan/M +Egbert/M +Egerton/M +Egon/M +Egor/M +Egypt/M +Egyptian/S +Egyptology/M +Ehrlich/M +Eichmann/M +Eiffel/M +Eileen/M +Eilis/M +Eimile/M +Einstein/SM +Einsteinian +Eire/M +Eirena/M +Eisenhower/M +Eisenstein/M +Eisner/M +Ekaterina/M +Ekberg/M +Ekstrom/M +Ektachrome/M +El/MY +Elaina/M +Elaine/M +Elana/M +Elane/M +Elanor/M +Elayne/M +Elba/MS +Elbe/M +Elbert/M +Elberta/M +Elbertina/M +Elbertine/M +Elbrus/M +Elden/M +Eldin/M +Eldon/M +Eldorado's +Eldredge/M +Eldridge/M +Eleanor/M +Eleanora/M +Eleanore/M +Eleazar/M +Electra/M +Eleen/M +Elena/M +Elene/M +Eleni/M +Elenore/M +Eleonora/M +Eleonore/M +Elfie/M +Elfreda/M +Elfrida/M +Elfrieda/M +Elga/M +Elgar/M +Eli/M +Elia/SM +Elianora/M +Elianore/M +Elicia/M +Elie/M +Elihu/M +Elijah/M +Elinor/M +Elinore/M +Eliot/M +Elisa/M +Elisabet/M +Elisabeth/M +Elisabetta/M +Elise/M +Eliseo/M +Elisha/M +Elissa/M +Elita/M +Eliza/M +Elizabet/M +Elizabeth/M +Elizabethan/S +Elka/M +Elke/M +Elkhart/M +Ella/M +Elladine/M +Ellary/M +Elle/M +Ellen/M +Ellene/M +Ellerey/M +Ellery/M +Ellesmere/M +Ellette/M +Elli/SM +Ellie/M +Ellington/M +Elliot/M +Elliott/M +Ellison/M +Ellissa/M +Ellswerth/M +Ellsworth/M +Ellwood/M +Elly/M +Ellyn/M +Ellynn/M +Elma/M +Elmer/M +Elmhurst/M +Elmira/M +Elmo/M +Elmore/M +Elmsford/M +Elna/MH +Elnar/M +Elnath/M +Elnora/M +Elnore/M +Elohim/M +Eloisa/M +Eloise/M +Elonore/M +Elora/M +Eloy/M +Elroy/M +Elsa/M +Elsbeth/M +Else/M +Elset/M +Elsey/M +Elsi/M +Elsie/M +Elsinore/M +Elspeth/M +Elston/M +Elsworth/M +Elsy/M +Eltanin/M +Elton/M +Elva/M +Elvera/M +Elvia/M +Elvin/M +Elvina/M +Elvira/M +Elvis/M +Elvyn/M +Elwin/M +Elwira/M +Elwood/M +Elwyn/M +Ely/M +Elyn/M +Elyse/M +Elysees +Elysha/M +Elysia/M +Elysian +Elysium/SM +Elyssa/M +Elys�e/M +Em/M +Ema/M +Emacs/M +Emalee/M +Emalia/M +Emanuel/M +Emanuele/M +Emelda/M +Emelen/M +Emelia/M +Emelina/M +Emeline/M +Emelita/M +Emelyne/M +Emera/M +Emerson/M +Emery/M +Emil/M +Emile/M +Emilee/M +Emili/M +Emilia/M +Emilie/M +Emiline/M +Emilio/M +Emily/M +Eminence/MS +Emlen/M +Emlyn/M +Emlynn/M +Emlynne/M +Emma/M +Emmalee/M +Emmaline/M +Emmalyn/M +Emmalynn/M +Emmalynne/M +Emmanuel/M +Emmeline/M +Emmerich/M +Emmery/M +Emmet/M +Emmett/M +Emmey/M +Emmi/M +Emmie/M +Emmit/M +Emmott/M +Emmy/SM +Emmye/M +Emogene/M +Emory/M +Emyle/M +Emylee/M +Endicott/M +Endymion/M +Eng/M +Engel/MS +Engelbert/M +England/M +Englebert/M +Englewood/M +English/GDRSM +Englishman/M +Englishmen +Englishwoman/M +Englishwomen +Engracia/M +Enid/M +Enif/M +Eniwetok/M +Enkidu/M +Ennis/M +Enoch/M +Enos +Enrica/M +Enrichetta/M +Enrico/M +Enrika/M +Enrique/M +Enriqueta/M +Ensolite/M +Enterprise/M +Eocene +Eolanda/M +Eolande/M +Ephesian/S +Ephesians/M +Ephesus/M +Ephraim/M +Ephrayim/M +Ephrem/M +Epictetus/M +Epicurean +Epicurus/M +Epimethius/M +Epiphany/SM +Episcopal/S +Episcopalian/S +Epistle/SM +Epsom/M +Epstein/M +Equuleus/M +Er/M +Eran/M +Erasmus/M +Erastus/M +Erato/M +Eratosthenes/M +Erda/M +Erebus/M +Erek/M +Erena/M +Erhard/M +Erhart/M +Eric/M +Erica/M +Erich/M +Ericha/M +Erick/M +Ericka/M +Erickson/M +Ericson's +Ericsson's +Eridanus/M +Erie/SM +Erik/M +Erika/M +Erikson/M +Erin/M +Erina/M +Erinn/M +Erinna/M +Eris +Eritrea/M +Erl/M +Erlang/M +Erlenmeyer/M +Erma/M +Ermanno/M +Ermengarde/M +Ermentrude/M +Ermin/M +Ermina/M +Erminia/M +Erminie/M +Erna/M +Ernaline/M +Ernest/M +Ernesta/M +Ernestine/M +Ernesto/M +Ernestus/M +Ernie/M +Ernst/M +Erny/M +Eros/SM +Errick/M +Errol/M +Erroll/M +Erse/M +Erskine/M +Ertha/M +Erv/M +ErvIn/M +Ervin/M +Erwin/M +Eryn/M +Es +Esau/M +Escher/M +Escherichia/M +Escondido/M +Esdras/M +Eskimo/SM +Esma/M +Esmaria/M +Esmark/M +Esme/M +Esmeralda/M +Esp/M +Espagnol/M +Esperanto/M +Esperanza/M +Espinoza/M +Esposito/M +Esq/M +Esquire/S +Esra/M +Essa/M +Essen/M +Essene/SM +Essequibo/M +Essex/M +Essie/M +Essy/M +Esta/M +Establishment/MS +Esteban/M +Estel/M +Estela/M +Estele/M +Estell/M +Estella/M +Estelle/M +Ester/M +Esterh�zy/M +Estes +Estevan/M +Esther/M +Estonia/M +Estonian/S +Estrada/M +Estrella/M +Estrellita/M +Etan/M +Ethan/M +Ethe/M +Ethel/M +Ethelbert/M +Ethelda/M +Ethelin/M +Ethelind/M +Etheline/M +Ethelred/M +Ethelyn/M +Ethernet/MS +Ethiopia/M +Ethiopian/S +Ethyl/M +Etienne/M +Etna/M +Etruria/M +Etruscan/MS +Etta/M +Etti/M +Ettie/M +Ettore/M +Etty/M +Eu/M +Eucharist/SM +Eucharistic +Euclid/M +Eudora/M +Euell/M +Eugen/M +Eugene/M +Eugenia/M +Eugenie/M +Eugenio/M +Eugenius/M +Eugine/M +Eula/M +Eulalie/M +Euler/M +Eulerian/M +Eumenides +Eunice/M +Euphemia/M +Euphrates/M +Eur/M +Eurasia/M +Eurasian/S +Euripides/M +Eurodollar/SM +Europa/M +Europe/M +European/MS +Europeanization/SM +Europeanized +Eurydice/M +Eustace/M +Eustachian/M +Eustacia/M +Euterpe/M +Ev/MN +Eva/M +Evaleen/M +Evan/MS +Evangelia/M +Evangelical/S +Evangelin/M +Evangelina/M +Evangeline/M +Evangelist/MS +Evania/M +Evanne/M +Evanston/M +Evansville/M +Eve/M +Eveleen/M +Evelin/M +Evelina/M +Eveline/M +Evelyn/M +Even/M +Evenki/M +EverReady/M +Everard/M +Eveready/M +Evered/M +Everest/M +Everett/M +Everette/M +Everglades +Everhart/M +Evey/M +Evie/M +Evin/M +Evita/M +Evonne/M +Evvie/M +Evvy/M +Evy/M +Evyn/M +Ewan/M +Eward/M +Ewart/M +Ewell/M +Ewen/M +Ewing/M +Excalibur/M +Excedrin/M +Excellency/MS +Exchequer/SM +Exeter/M +Exodus/M +Exxon/M +Eyck/M +Eyde/M +Eydie/M +Eyre/M +Eysenck/M +Ezechiel/M +Ezekiel/M +Ezequiel/M +Eziechiele/M +Ezmeralda/M +Ezra/M +Ezri/M +F +F's +FAA +FAQ/SM +FBI +FCC +FD +FDA +FDIC +FDR/M +FHA +FICA +FIFO +FL +FM +FNMA/M +FOFL +FORTH/M +FORTRAN +FPO +FSLIC +FTC +FTP +FUD +FWD +FY +FYI +Fabe/MR +Faber/M +Faberg�/M +Fabian/S +Fabiano/M +Fabien/M +Fabio/M +Fae/M +Faeroe/M +Fafnir/M +Fagin/M +Fahd/M +Fahrenheit/S +Faina/M +Fair/M +Fairbanks +Fairchild/M +Fairfax/M +Fairfield/M +Fairleigh/M +Fairlie/M +Fairmont/M +Fairport/M +Fairview/M +Faisal/M +Faisalabad +Faith/M +Falito/M +Falk/M +Falkland/MS +Falkner/M +Fallon/M +Fallopian/M +Falstaff/M +Falwell/M +Fan/M +Fanchette/M +Fanchon/M +Fancie/M +Fancy/M +Fanechka/M +Fania/M +Fanni/M +Fannie/M +Fanny/SM +Fanya/M +Far/MY +Fara/M +Faraday/M +Farah/M +Farand/M +Farber/M +Fargo/M +Farica/M +Farkas/M +Farlay/M +Farlee/M +Farleigh/M +Farley/M +Farlie/M +Farly/M +Farmer/M +Farmington/M +Farr/M +Farra/M +Farragut/M +Farrah/M +Farrakhan/M +Farrand/M +Farrel/M +Farrell/M +Farris/M +Fascism's +Fascist's +Fassbinder/M +Fates +Father/SM +Fatima/M +Faulkner/M +Faulknerian +Faun/M +Faunie/M +Fauntleroy/M +Faust/M +Faustian +Faustina/M +Faustine/M +Faustino/M +Faustus/M +Fawkes/M +Fawn/M +Fawne/M +Fawnia/M +Fax/M +Fay/M +Faydra/M +Faye/M +Fayette/M +Fayetteville/M +Fayina/M +Fayre/M +Fayth/M +Faythe/M +Fe/M +Featherman/M +Feb/M +February/MS +Fed/SM +FedEx/M +Federal/S +Federalist +Federica/M +Federico/M +Fedora/M +Fee/M +Felder/M +Feldman/M +Felecia/M +Felic/M +Felicdad/M +Felice/M +Felicia/M +Felicio/M +Felicity/M +Felicle/M +Felike/M +Feliks/M +Felipa/M +Felipe/M +Felisha/M +Felita/M +Felix/M +Feliza/M +Felizio/M +Fellini/M +Fenelia/M +Fenian/M +Fenwick/M +Feodor/M +Feodora/M +Ferber/M +Ferd/M +Ferdie/M +Ferdinand/M +Ferdinanda/M +Ferdinande/M +Ferdinando/M +Ferdy/M +Fergus/M +Ferguson/M +Ferlinghetti/M +Fermat/M +Fermi/M +Fern/M +Fernanda/M +Fernande/M +Fernandez/M +Fernandina/M +Fernando/M +Ferne/M +Ferrari/M +Ferraro/M +Ferreira/M +Ferrel/M +Ferrell/M +Ferrer/M +Ferris +Fess/M +Fey/M +Feynman/M +Fez/M +Fiann/M +Fianna/M +Fiat/M +Fiberglas/M +Fibonacci/M +Fichte/M +Fidel/M +Fidela/M +Fidelia/M +Fidelio/M +Fidelity/M +Fido/M +Fidole/M +Field/MGS +Fielding/M +Fifi/M +Fifine/M +Figaro/M +Figueroa/M +Fiji/M +Fijian/SM +Filbert/M +Filberte/M +Filberto/M +Filia/M +Filide/M +Filip/M +Filipino/SM +Filippa/M +Filippo/M +Fillmore/M +Filmer/M +Filmore/M +Filofax/S +Fin/M +Fina/M +Finch/M +Findlay/M +Findley/M +Finland/M +Finlay/M +Finley/M +Finn/MS +Finnbogadottir/M +Finnegan/M +Finnish +Fiona/M +Fionna/M +Fionnula/M +Fiorello/M +Fiorenze/M +Fiori/M +Firefox/M +Firestone/M +Fischbein/M +Fischer/M +Fisher/M +Fishkill/M +Fisk/M +Fiske/M +Fitch/M +Fitchburg/M +Fitz/M +Fitzgerald/M +Fitzpatrick/M +Fitzroy/M +Fizeau/M +Fla/M +Flanagan/M +Flanders/M +Flatt/M +Flaubert/M +Fledermaus/M +Fleischer/M +Fleischman/M +Fleisher/M +Flem/JGM +Fleming/M +Flemish/GDSM +Flemished/M +Flemishing/M +Flemming/M +Fletch/MR +Fletcher/M +Fleur/M +Fleurette/M +Flin/M +Flinn/M +Flint/M +Flintstones +Flo/M +Flor/M +Flora/M +Florance/M +Flore/SM +Florella/M +Florence/M +Florencia/M +Florentia/M +Florentine/S +Florenza/M +Florette/M +Flori/SM +Floria/M +Florian/M +Florida/M +Floridan/S +Floridian/S +Florie/M +Florina/M +Florinda/M +Florine/M +Florri/M +Florrie/M +Florry/M +Flory/M +Flossi/M +Flossie/M +Flossy/M +Flowers +Floyd/M +Flss/M +Flynn/M +Fm/M +Foch/M +Fokker/M +Foley/M +Folsom +Fomalhaut/M +Fonda/M +Fons +Fonsie/M +Fontaine/M +Fontainebleau/M +Fontana/M +Fonz/M +Fonzie/M +Foote/M +Forbes/M +Ford/M +Fordham/M +Foreman/M +Forest/MR +Forester/M +Formica/MS +Formosa/M +Formosan +Forrest/RM +Forrester/M +Forster/M +Fortaleza/M +Fortran/M +Foss/M +Foster/M +Foucault/M +Fourier/M +Fourth +Fourths +Fowler/M +Fox/MS +Foxhall/M +Fr/MD +Fragonard/M +Fran/MS +Francaise/M +France/MS +Francene/M +Francesca/M +Francesco/M +Franchot/M +Francie/M +Francine/M +Francis +Francisca/M +Franciscan/MS +Francisco/M +Franciska/M +Franciskus/M +Franck/M +Francklin/M +Francklyn/M +Franco/M +Francois/M +Francoise/M +Francyne/M +Frank/SM +Frankel/M +Frankenstein/MS +Frankford/M +Frankfort/M +Frankfurt/RM +Frankfurter/M +Frankie/M +Frankish/M +Franklin/M +Franklyn/M +Franky/M +Franni/M +Frannie/M +Franny/M +Fransisco/M +Frants/M +Franz/NM +Franzen/M +Frasco/M +Fraser/M +Frasier/M +Frasquito/M +Frau/MN +Fraulein/S +Frayda/M +Frayne/M +Fraze/MR +Frazer/M +Frazier/M +Fred/M +Freda/M +Freddi/M +Freddie/M +Freddy/M +Fredek/M +Fredelia/M +Frederic/M +Frederica/M +Frederich/M +Frederick/MS +Fredericka/M +Frederico/M +Fredericton/M +Frederigo/M +Frederik/M +Frederique/M +Fredholm/M +Fredi/M +Fredia/M +Fredra/M +Fredric/M +Fredrick/M +Fredrickson/M +Fredrika/M +Free/M +Freedman/M +Freeland/M +Freeman/M +Freemason/SM +Freemasonry/MS +Freemon/M +Freeport/M +Freetown/M +Freida/M +Fremont/M +French/MDSG +Frenchman/M +Frenchmen +Frenchwoman/M +Frenchwomen +Freon/SM +Fresnel/M +Fresno/M +Freud/M +Freudian/S +Frey/M +Freya/M +Fri/M +Frick/M +Friday/SM +Frieda/M +Friedan/M +Friederike/M +Friedman/M +Friedrich/M +Friedrick/M +Frigga/M +Frigidaire/M +Frisbee/MS +Frisco/M +Frisian/SM +Frito/M +Fritz/M +Frobisher/M +Froissart/M +Fromm/M +Frontenac/M +Frost/M +Frostbelt/M +Fruehauf/M +Frunze/M +Fry/M +Frye/M +Fuchs/M +Fuentes/M +Fugger/M +Fuji/M +Fujitsu/M +Fujiyama +Fukuoka/M +Fulani/M +Fulbright/M +Fuller/M +Fullerton/M +Fulton/M +Fulvia/M +Funafuti +Fundy/M +Fushun/M +Fuzhou/M +Fuzzbuster/M +G's +G/B +GA +GAO +GB +GDP +GE/M +GED +GHQ +GHz +GI +GIGO +GM +GMT +GNOME/M +GNP +GOP +GOTO/MS +GP +GPA +GPO +GPSS +GSA +GU +GUI +Ga/M +Gabbey/M +Gabbi/M +Gabbie/M +Gabby/M +Gabe/M +Gabey/M +Gabi/M +Gabie/M +Gable/M +Gabon/M +Gabonese +Gaborone/M +Gabriel/M +Gabriela/M +Gabriele/M +Gabriell/M +Gabriella/M +Gabrielle/M +Gabriellia/M +Gabriello/M +Gabrila/M +Gaby/M +Gacrux/M +Gadsden/M +Gae/M +Gaea/M +Gael/SM +Gaelan/M +Gaelic/M +Gagarin/M +Gage/M +Gail/M +Gaile/M +Gaines/M +Gainesville/M +Gainsborough/M +Gaithersburg/M +Gal/MN +Galahad/MS +Galapagos/M +Galatea/M +Galatia/M +Galatians/M +Galaxy/M +Galbraith/M +Galbreath/M +Gale/M +Galen/M +Galibi/M +Galilean/MS +Galilee/M +Galileo/M +Galina/M +Gall/M +Gallagher/M +Gallard/M +Gallegos/M +Gallic +Gallicism/SM +Galloway/M +Gallup/M +Galois/M +Galsworthy/M +Galvan/M +Galvani/M +Galven/M +Galveston/M +Galvin/M +Gama/M +Gamaliel/M +Gambia/M +Gambian/S +Gamble/M +Gamow/M +Gan/M +Gandhi/M +Gandhian +Ganges/M +Gangtok/M +Gannie/M +Gannon/M +Ganny/M +Gantry/M +Ganymede/M +Gar/MH +Garald/M +Garbo/M +Garcia/M +Gard/M +Gardener/M +Gardie/M +Gardiner/M +Gardner/M +Gardy/M +Gare/MH +Garek/M +Gareth/M +Garey/M +Garfield/M +Garfunkel/M +Gargantua/M +Garibaldi/M +Garik/M +Garland/M +Garner/M +Garnet/M +Garnett/M +Garnette/M +Garold/M +Garrard/M +Garrek/M +Garret/M +Garreth/M +Garrett/M +Garrick/M +Garrik/M +Garrison/M +Garrot/M +Garrott/M +Garry/M +Garth/M +Garv/M +Garvey/M +Garvin/M +Garvy/M +Garwin/M +Garwood/M +Gary/M +Garza/M +Gascony/M +Gaspar/M +Gaspard/M +Gasparo/M +Gasper/M +Gasser/M +Gasset/M +Gaston/M +Gates +Gatlinburg/M +Gatling/M +Gatorade/M +Gatsby/M +Gatun/M +Gauguin/M +Gaul/MS +Gaulish/M +Gaulle/M +Gaultiero/M +Gauntley/M +Gauss/M +Gaussian +Gautama/M +Gauthier/M +Gautier/M +Gav/MN +Gavan/M +Gaven/M +Gavin/M +Gavra/M +Gavrielle/M +Gawain/M +Gawen/M +Gay/M +Gaye/M +Gayel/M +Gayelord/M +Gayla/M +Gayle/RM +Gayleen/M +Gaylene/M +Gayler/M +Gaylor/M +Gaylord/M +Gaynor/M +Gaza/M +Gaziantep/M +Gd/M +Gdansk/M +Ge/M +Gearalt/M +Gearard/M +Geary/M +Gehenna/M +Gehrig/M +Geiger/M +Geigy/M +Gelya/M +Gemini/SM +Gemma/M +Gen/M +Gena/M +Genaro/M +Gene/M +Genesco/M +Genesis/M +Genet/M +Geneva/M +Genevieve/M +Genevra/M +Genghis/M +Genia/M +Genna/M +Genni/M +Gennie/M +Gennifer/M +Genny/M +Geno/M +Genoa/SM +Genovera/M +Gentile's +Gentry/M +Genvieve/M +Geo/M +Geoff/M +Geoffrey/M +Geoffry/M +Georas/M +Geordie/M +Georg/M +George/SM +Georgeanna/M +Georgeanne/M +Georgena/M +Georgeta/M +Georgetown/M +Georgetta/M +Georgette/M +Georgi/M +Georgia/M +Georgian/S +Georgiana/M +Georgianna/M +Georgianne/M +Georgie/M +Georgina/M +Georgine/M +Georgy/M +Ger/M +Gerald/M +Geralda/M +Geraldine/M +Gerard/M +Gerardo/M +Gerber/M +Gerda/M +Gerek/M +Gerhard/M +Gerhardine/M +Gerhardt/M +Geri/M +Gerianna/M +Gerianne/M +Gerick/M +Gerik/M +Geritol/M +Gerladina/M +Germain/M +Germaine/M +German/SM +Germana/M +Germania/M +Germanic/M +Germantown/M +Germany/M +Germayne/M +Gerome/M +Geronimo/M +Gerrard/M +Gerri/M +Gerrie/M +Gerrilee/M +Gerry/M +Gershwin/MS +Gert/M +Gerta/M +Gerti/M +Gertie/M +Gertrud/M +Gertruda/M +Gertrude/M +Gertrudis/M +Gerty/M +Gery/M +Gestapo/SM +Gethsemane/M +Getty/M +Gettysburg/M +Gew�rztraminer +Ghana/M +Ghanaian/MS +Ghanian's +Ghats/M +Ghent/M +Gherardo/M +Ghibelline/M +Giacinta/M +Giacobo/M +Giacometti/M +Giacomo/M +Giacopo/M +Gian/M +Giana/M +Gianina/M +Gianna/M +Gianni/M +Giannini/M +Giauque/M +Giavani/M +Gib/M +Gibb/MS +Gibbie/M +Gibbon/M +Gibby/M +Gibraltar/MS +Gibson/M +Giddings/M +Gide/M +Gideon/MS +Gielgud/M +Gienah/M +Giff/RM +Giffard/M +Giffer/M +Giffie/M +Gifford/M +Giffy/M +Gigi/M +Gil/MY +Gila/M +Gilbert/M +Gilberta/M +Gilberte/M +Gilbertina/M +Gilbertine/M +Gilberto/M +Gilbertson/M +Gilburt/M +Gilchrist/M +Gilda/M +Gilead/M +Gilemette/M +Giles +Gilgamesh/M +Gilkson/M +Gill/M +Gillan/M +Gilles +Gillespie/M +Gillette/M +Gilli/M +Gilliam/M +Gillian/M +Gillie/M +Gilligan/M +Gilly/M +Gilmore/M +Gimbel/M +Gina/M +Ginelle/M +Ginevra/M +Ginger/M +Gingrich/M +Ginni/M +Ginnie/M +Ginnifer/M +Ginny/M +Gino/M +Ginsberg/M +Ginsburg/M +Gioconda/M +Giordano/M +Giorgi/M +Giorgia/M +Giorgio/M +Giorgione/M +Giotto/M +Giovanna/M +Giovanni/M +Gipsy's +Giralda/M +Giraldo/M +Giraud/M +Giraudoux/M +Gisela/M +Giselbert/M +Gisele/M +Gisella/M +Giselle/M +Gish/M +Giuditta/M +Giulia/M +Giuliano/M +Giulietta/M +Giulio/M +Giuseppe/M +Giustina/M +Giustino/M +Giusto/M +Giza/M +Gizela/M +Gk/M +Glad/M +Gladi/M +Gladstone/MS +Gladys +Glaser/M +Glasgow/M +Glass/M +Glastonbury/M +Glaswegian/S +Gleason/M +Gleda/M +Glen/M +Glenda/M +Glendale/M +Glenden/M +Glendon/M +Glenine/M +Glenn/M +Glenna/M +Glennie/M +Glennis/M +Glori/M +Gloria/M +Gloriana/M +Gloriane/M +Glory/M +Gloucester/M +Glover/M +Glyn/M +Glynda/M +Glynis/M +Glynn/M +Glynnis/M +Gnni/M +Gnostic/M +Gnosticism/M +Goa/M +Gobi/M +God/M +Godard/M +Godart/M +Goddard/M +Goddart/M +Godfree/M +Godfrey/M +Godfry/M +Godiva/M +Godot/M +Godspeed/S +Godthaab/M +Godunov/M +Godwin/M +Godzilla/M +Goebbels/M +Goering/M +Goethals/M +Goethe/M +Goff/M +Gog/M +Gogh/M +Gogol/M +Goiania/M +Golan/M +Golconda/M +Golda/M +Goldarina/M +Goldberg/M +Golden/M +Goldi/M +Goldia/M +Goldie/M +Goldilocks/M +Goldina/M +Golding/M +Goldman/M +Goldsmith/M +Goldstein/M +Goldwater/M +Goldwyn/M +Goldy/M +Goleta/M +Golgotha/M +Goliath/M +Goliaths +Gomez/M +Gomorrah/M +Gompers/M +Gondwanaland/M +Gonzales/M +Gonzalez/M +Gonzalo/M +Goober/M +Good/M +Goodman/M +Goodrich/M +Goodwin/M +Goodyear/M +Google/M +Gopher +Goran/M +Goraud/M +Gorbachev +Gordan/M +Gorden/M +Gordian/M +Gordie/M +Gordimer/M +Gordon/M +Gordy/M +Gore/M +Goren/M +Gorey/M +Gorgas +Gorgon/M +Gorgonzola/M +Gorham/M +Gorky/M +Gospel/SM +Goth/M +Gotham/M +Gothart/M +Gothic/S +Gothicism/M +Goths +Gottfried/M +Goucher/M +Gouda/SM +Gould/M +Gounod/M +Governor +Goya/M +Gr/M +Gracchus/M +Grace/M +Graceland/M +Gracia/M +Gracie/M +Graciela/M +Gradeigh/M +Gradey/M +Grady/M +Graehme/M +Graeme/M +Graff/M +Graffias/M +Grafton/M +Graham/M +Grahame/M +Graig/M +Grail/SM +Gram/M +Grammy/S +Grampians +Gran/M +Granada/M +Grange/MR +Granger/M +Grannie/M +Granny/M +Grant/M +Grantham/M +Granthem/M +Grantley/M +Granville/M +Grass/M +Grata/M +Gratia/M +Gratiana/M +Graves/M +Gray/M +Grayce/M +Grayson/M +Grazia/M +Grecian/S +Greece/M +Greek/SM +Greeley/M +Green/M +Greenberg/M +Greenblatt/M +Greenbriar/M +Greene/M +Greenfeld/M +Greenfield/M +Greenland/M +Greenpeace/M +Greensboro/M +Greensleeves/M +Greensville/M +Greentree/M +Greenville/M +Greenwich/M +Greer/M +Greg/M +Gregg/M +Greggory/M +Gregoire/M +Gregoor/M +Gregor/M +Gregorian +Gregorio/M +Gregorius/M +Gregory/M +Grenada/M +Grenadian/S +Grenadines +Grendel/M +Grenier/M +Grenoble/M +Grenville/M +Gresham/M +Greta/M +Gretal/M +Gretchen/M +Grete/M +Gretel/M +Grethel/M +Gretna/M +Gretta/M +Gretzky/M +Grey/M +Grieg/M +Grier/M +Griff/M +Griffie/M +Griffin/M +Griffith/M +Griffy/M +Grimaldi/M +Grimes +Grimm/M +Grinch/M +Gris/M +Griselda/M +Grissel/M +Griswold/M +Griz/M +Gromyko/M +Groot/M +Gropius/M +Gross +Grosset/M +Grossman/M +Grosvenor/M +Grosz/M +Grotius/M +Groton/M +Grove/RM +Grover/M +Grumman/M +Grundy/M +Grus/M +Grusky/M +Gruyeres +Gruy�re +Gr�newald/M +Guadalajara/M +Guadalcanal/M +Guadalquivir/M +Guadalupe/M +Guadeloupe/M +Guallatiri/M +Gualterio/M +Guam/M +Guamanian/SM +Guangzhou +Guantanamo/M +Guarani/M +Guardia/M +Guarnieri/M +Guatemala/M +Guatemalan/S +Guayaquil/M +Gucci/M +Guelph/M +Guendolen/M +Guenevere/M +Guenna/M +Guenther/M +Guernsey/SM +Guerra/M +Guerrero/M +Guevara/M +Guggenheim/M +Guglielma/M +Guglielmo/M +Guhleman/M +Gui/M +Guiana/M +Guido/M +Guilbert/M +Guillaume/M +Guillema/M +Guillemette/M +Guillermo/M +Guinea/M +Guinean/S +Guinevere/M +Guinna/M +Guinness/M +Guiyang +Guizot/M +Gujarat/M +Gujarati/M +Gujranwala/M +Gullah/M +Gulliver/M +Gun/M +Gunar/M +Gunderson/M +Gunilla/M +Gunnar/M +Gunner/M +Guntar/M +Gunter/M +Gunther/M +Guofeng/M +Gupta/M +Gurkha/M +Gus/M +Gusella/M +Guss +Gussi/M +Gussie/M +Gussy/M +Gusta/M +Gustaf/M +Gustafson/M +Gustav/M +Gustave/M +Gustavo/M +Gustavus/M +Gusti/M +Gustie/M +Gusty/M +Gutenberg/M +Guthrey/M +Guthrie/M +Guthry/M +Gutierrez/M +Guy/M +Guyana/M +Guyanese +Guzman/M +Gwalior/M +Gwen/M +Gwendolen/M +Gwendolin/M +Gwendoline/M +Gwendolyn/M +Gweneth/M +Gwenette/M +Gwenneth/M +Gwenni/M +Gwennie/M +Gwenny/M +Gwenora/M +Gwenore/M +Gwyn/M +Gwyneth/M +Gwynne/M +Gypsy/SM +G�del/M +G�teborg/M +H +H's +HBO/M +HDTV +HF +HHS +HI +HIV +HM +HMO +HMS +HOV +HP +HQ +HR +HRH +HS +HST +HTML +HTTP +HUD +Ha/M +Haag/M +Haas/M +Habakkuk/M +Haber/M +Haberman/M +Habib/M +Hackett/M +Had/M +Hadamard/M +Hadar/M +Haddad/M +Hades +Hadlee/M +Hadleigh/M +Hadley/M +Hadria/M +Hadrian/M +Hafiz/M +Hagan/M +Hagar/M +Hagen/M +Hager/M +Haggai/M +Hagiographa/M +Hagstrom/M +Hague/M +Hahn/M +Haifa/M +Hailee/M +Hailey/M +Haily/M +Haiphong/M +Haiti/M +Haitian/S +Hakeem/M +Hakim/M +Hakka/M +Hakluyt/M +Hal/SMY +Haldane/M +Hale/M +Haleakala/M +Haleigh/M +Halette/M +Haley/M +Hali/M +Halie/M +Halifax/M +Halimeda/M +Hall/M +Halley/M +Halli/M +Hallie/M +Hallinan/M +Hallmark/M +Halloween/MS +Hallsy/M +Hally/M +Halpern/M +Halsey/M +Halsy/M +Ham/M +Hamal/M +Haman/M +Hamburg/MS +Hamel/M +Hamey/M +Hamhung/M +Hamid/M +Hamil/M +Hamilcar/M +Hamilton/M +Hamiltonian/MS +Hamish/M +Hamitic/M +Hamlen/M +Hamlet/M +Hamlin/M +Hammad/M +Hammarskjold/M +Hammerstein/M +Hammett/M +Hammond/M +Hammurabi/M +Hamnet/M +Hampshire/M +Hampton/M +Hamsun/M +Han/SM +Hana/M +Hanan/M +Hancock/M +Handel/M +Handy/M +Haney/M +Hangul/M +Hangzhou +Hank/M +Hankel/M +Hanna/M +Hannah/M +Hanni/MS +Hannibal/M +Hannie/M +Hanny/M +Hanoi/M +Hanover/M +Hanoverian +Hans/N +Hansel/M +Hansen/M +Hansiain/M +Hanson/M +Hanuka/S +Hanukkah/M +Hanukkahs +Hapgood/M +Happy/M +Hapsburg/M +Harald/M +Harare +Harbert/M +Harbin/M +Harcourt/M +Hardin/M +Harding/M +Hardy/M +Hargreaves/M +Harlan/M +Harland/M +Harlem/M +Harlen/M +Harlene/M +Harlequin +Harley/M +Harli/M +Harlie/M +Harlin/M +Harlow/M +Harman/M +Harmon/M +Harmonia/M +Harmonie/M +Harmony/M +Harold/M +Haroun/M +Harp/MR +Harper/M +Harpy/SM +Harrell/M +Harri/SM +Harrie/M +Harriet/M +Harriett/M +Harrietta/M +Harriette/M +Harrington/M +Harriot/M +Harriott/M +Harrisburg/M +Harrison/M +Harrisonburg/M +Harry/M +Hart/M +Harte/M +Hartford/M +Hartley/M +Hartline/M +Hartman/M +Hartwell/M +Harv/M +Harvard/M +Harvey/MS +Harwell/M +Harwilll/M +Hasbro/M +Hasheem/M +Hashim/M +Hasidim +Haskel/M +Haskell/M +Haskins/M +Haslett/M +Hastie/M +Hastings/M +Hasty/M +Hatchure/M +Hatfield/M +Hathaway/M +Hatteras/M +Hatti/M +Hattie/M +Hatty/M +Haugen/M +Hauptmann/M +Hausa/M +Hausdorff/M +Hauser/M +Havana/SM +Havarti +Havel/M +Haven/M +Haw +Hawaii/M +Hawaiian/S +Hawking +Hawkins/M +Hawley/M +Hawthorne/M +Hay/SM +Hayden/M +Haydn/M +Haydon/M +Hayes +Hayley/M +Haynes +Hayward/M +Haywood/M +Hayyim/M +Haze/M +Hazel/M +Hazlett/M +Hazlitt/M +He/M +Head/M +Heall/M +Hearst/M +Heartwood/M +Heath/MR +Heather/M +Heathkit/M +Heathman/M +Heaviside/M +Heb/M +Hebe/M +Hebert/M +Hebraic +Hebraism/MS +Hebrew/SM +Hebrides/M +Hecate/M +Hector/M +Hecuba/M +Heda/M +Hedda/M +Heddi/M +Heddie/M +Hedi/M +Hedvig/M +Hedvige/M +Hedwig/M +Hedwiga/M +Hedy/M +Heep/M +Hefner/M +Hegel/M +Hegelian +Hegira/M +Heida/M +Heidegger/M +Heidelberg/M +Heidi/M +Heidie/M +Heifetz/M +Heimlich/M +Heindrick/M +Heine/M +Heineken/M +Heinlein/M +Heinrich/M +Heinrick/M +Heinrik/M +Heinz/M +Heinze/M +Heisenberg/M +Heiser/M +Hejira's +Helaina/M +Helaine/M +Helen/M +Helena/M +Helene/M +Helenka/M +Helga/M +Helge/M +Helicon/M +Heliopolis/M +Helios/M +Hell's +Hellene/SM +Hellenic +Hellenism/MS +Hellenist/MS +Hellenistic +Hellenization/M +Hellenize +Heller/M +Hellespont/M +Helli/M +Hellman/M +Helmholtz/M +Helmut/M +Helsa/M +Helsinki/M +Helvetian/S +Helvetius/M +Helyn/M +Hemingway/M +Hench/M +Henderson/M +Hendrick/SM +Hendrickson/M +Hendrik/M +Hendrika/M +Hendrix/M +Henka/M +Henley/M +Hennessey/M +Henri/M +Henrie/M +Henrieta/M +Henrietta/M +Henriette/M +Henrik/M +Henry/M +Henryetta/M +Hensley/M +Henson/M +Hepburn/M +Hephaestus/M +Hephzibah/M +Hepplewhite +Hera/M +Heracles/M +Heraclitus/M +Herb/M +Herbart/M +Herbert/M +Herbie/M +Herby/M +Herc/M +Herculaneum/M +Hercule/MS +Herculean +Herculie/M +Herder/M +Hereford/SM +Heriberto/M +Herkimer/M +Herman/M +Hermann/M +Hermaphroditus/M +Hermes +Hermia/M +Hermie/M +Hermina/M +Hermine/M +Herminia/M +Hermione/M +Hermite/M +Hermon/M +Hermosa/M +Hermosillo/M +Hermy/M +Hernandez/M +Hernando/M +Herod/M +Herodotus/M +Herold/M +Herr/MG +Herrera/M +Herrick/M +Herring/M +Herrington/M +Hersch/M +Herschel/M +Hersey/M +Hersh/M +Hershel/M +Hershey/M +Herta/M +Hertha/M +Hertz/M +Hertzog/M +Hertzsprung/M +Herve/M +Hervey/M +Herzegovina/M +Herzl/M +Hesiod/M +Hesperus/M +Hess/M +Hesse/M +Hessian/MS +Hester/M +Hesther/M +Hestia/M +Heston/M +Hetti/M +Hettie/M +Hetty/M +Heublein/M +Heusen/M +Heuser/M +Hew/M +Hewe/M +Hewet/M +Hewett/M +Hewie/M +Hewitt/M +Hewlett/M +Heyerdahl/M +Heywood/M +Hezekiah/M +Hf/M +Hg/M +Hi/M +Hialeah/M +Hiawatha/M +Hibernia/M +Hibernian/S +Hickey/SM +Hickman/M +Hickok/M +Hicks/M +Hieronymus/M +Higashiosaka +Higgins/M +Highfield/M +Highlander/SM +Highlands +Highness/M +Hilario/M +Hilarius/M +Hilary/M +Hilbert/M +Hilda/M +Hildagard/M +Hildagarde/M +Hilde/M +Hildebrand/M +Hildegaard/M +Hildegarde/M +Hildy/M +Hill/M +Hillard/M +Hillary/M +Hillcrest/M +Hillel/M +Hillery/M +Hilliard/M +Hilliary/M +Hillie/M +Hillier/M +Hillsboro/M +Hillsdale/M +Hilly/RM +Hillyer/M +Hilton/M +Himalaya/MS +Himalayan/S +Himmler/M +Hinayana/M +Hinda/M +Hindemith/M +Hindenburg/M +Hindi/M +Hindu/MS +Hinduism/SM +Hindustan/M +Hindustani/MS +Hines/M +Hinkle/M +Hinsdale/M +Hinton/M +Hinze/M +Hipparchus/M +Hippocrates/M +Hippocratic +Hiram/M +Hirey/M +Hirohito/M +Hiroshi/M +Hiroshima/M +Hirsch/M +Hispanic/SM +Hispaniola/M +Hiss/M +Hitachi/M +Hitchcock/M +Hitler/SM +Hittite/SM +Hmong +Ho/M +Hobard/M +Hobart/M +Hobbes/M +Hobbs/M +Hobday/M +Hobey/M +Hobie/M +Hoboken/M +Hockney/M +Hodge/MS +Hodgkin/M +Hoebart/M +Hoff/M +Hoffa/M +Hoffman/M +Hofstadter/M +Hogan/M +Hogarth/M +Hohenlohe/M +Hohenstaufen/M +Hohenzollern/M +Hohhot/M +Hokkaido/M +Hokusai/M +Holbein/M +Holbrook/M +Holcomb/M +Holden/M +Holder/M +Holiday/M +Holiness/MS +Holland/RMSZ +Hollandaise/M +Hollander/M +Hollerith/M +Holley/M +Holli/SM +Hollie/M +Hollister/M +Holloway/M +Holly/M +Hollyanne/M +Hollywood/M +Holm/M +Holman/M +Holmes +Holocaust +Holocene +Holst/M +Holstein/MS +Holt/M +Holyoke/M +Holzman/M +Hom/MR +Homer/M +Homere/M +Homeric +Homerus/M +Hon/M +Honda/M +Hondo/M +Honduran/S +Honduras/M +Honecker/M +Honey/M +Honeywell/M +Honiara/M +Honolulu/M +Honor/M +Honoria/M +Honshu/M +Hood/M +Hooke/MR +Hooker/M +Hooper/M +Hoosier/SM +Hoover/MS +Hope/M +Hopewell/M +Hopi/SM +Hopkins/M +Hopkinsian/M +Hopper/M +Horace/M +Horacio/M +Horatia/M +Horatio/M +Horatius/M +Hormel/M +Hormuz/M +Horn/M +Hornblower/M +Horne/M +Horowitz/M +Horst/M +Hort/MN +Horten/M +Hortense/M +Hortensia/M +Horton/M +Horus/M +Hosea/M +Host/MS +Hottentot/SM +Houdaille/M +Houdini/M +House/M +Housman/M +Houston/M +Houyhnhnm/M +Howard/M +Howe/M +Howell/MS +Howey/M +Howie/M +Howrah/M +Hoyle/SM +Hoyt/M +Hrothgar/M +Hts/M +Huang/M +Hubbard/M +Hubble/M +Hube/RM +Huber/M +Hubert/M +Huberto/M +Hubey/M +Hubie/M +Huck/M +Huddersfield/M +Hudson/M +Huerta/M +Huey/M +Huff/M +Huffman/M +Huggins +Hugh/MS +Hughie/M +Hugibert/M +Hugo/M +Huguenot/SM +Hugues/M +Hui/M +Huitzilopitchli/M +Hulda/M +Hull/M +Humbert/M +Humberto/M +Humboldt/M +Hume/M +Humfrey/M +Humfrid/M +Humfried/M +Hummel/M +Humphrey/SM +Humpty/M +Humvee +Hun/MS +Hunfredo/M +Hung/M +Hungarian/MS +Hungary/M +Hunt/MR +Hunter/M +Huntington/M +Huntlee/M +Huntley/M +Huntsville/M +Hurlee/M +Hurleigh/M +Hurley/M +Huron/SM +Hurst/M +Hurwitz/M +Hus +Husain's +Husein/M +Hussein/M +Husserl/M +Huston/M +Hutchins/M +Hutchinson/M +Hutchison/M +Hutton/M +Hutu/M +Huxley/M +Huygens/M +Hy/M +Hyacinth/M +Hyacintha/M +Hyacinthe/M +Hyacinthia/M +Hyacinthie/M +Hyades +Hyannis/M +Hyatt/M +Hyde/M +Hyderabad/M +Hydra/M +Hyman/M +Hymen/M +Hymie/M +Hynda/M +Hyperion/M +Hyundai/M +Hz +H�loise/M +I +I'd +I'll +I'm +I've +IA +IBM/M +ICBM/S +ICC +ICU +ID +IDs +IE +IEEE +IL +IMF +IMHO +IMNSHO +IMO +IN +INRI +INS +INTERNET/M +IOU +IPA +IQ +IRA/S +IRS +ISBN +ISO +IT +ITCorp/M +ITT +ITcorp/M +IUD/S +IV +IVs +Ia/M +Iaccoca/M +Iago/M +Iain/M +Ian/M +Ianthe/M +Ibadan/M +Ibbie/M +Ibby/M +Iberia/M +Iberian/MS +Ibero/M +Ibo/M +Ibrahim/M +Ibsen/M +Icarus/M +Ice/M +Iceland/MRZ +Icelander/M +Icelandic +Ichabod/M +Ida/M +Idaho/MS +Idahoan/S +Idahoes +Idalia/M +Idalina/M +Idaline/M +Idell/M +Idelle/M +Idette/M +Ieyasu/M +Ifni/M +Iggie/M +Iggy/M +Ignace/M +Ignacio/M +Ignacius/M +Ignatius/M +Ignaz/M +Ignazio/M +Igor/M +Iguassu/M +Ijsselmeer/M +Ike/M +Ikey/M +Ikhnaton/M +Ila/M +Ilaire/M +Ilario/M +Ileana/M +Ileane/M +Ilene/M +Iliad/MS +Ilise/M +Ilka/M +Ill/M +Illa/M +Illinois/M +Illinoisan/MS +Illuminati +Ilona/M +Ilsa/M +Ilse/M +Ilysa/M +Ilyse/M +Ilyssa/M +Ilyushin/M +Imagen/M +Imbrium/M +Imelda/M +Immanuel/M +Imogen/M +Imogene/M +Imojean/M +Imus/M +In/PM +Ina/M +Inc/M +Inca/SM +Inchon/M +Ind/M +Independence/M +India/M +Indian/SM +Indiana/M +Indianan/S +Indianapolis/M +Indianian/S +Indira/M +Indochina/M +Indochinese +Indonesia/M +Indonesian/S +Indore/M +Indra/M +Indus/M +Indy/SM +Ines +Inesita/M +Inessa/M +Inez/M +Informatica/M +Inga/M +Ingaberg/M +Ingaborg/M +Ingamar/M +Ingar/M +Inge/RM +Ingeberg/M +Ingeborg/M +Ingelbert/M +Ingemar/M +Inger/M +Ingersoll/M +Inglebert/M +Inglewood/M +Inglis/M +Ingmar/M +Ingra/M +Ingram/M +Ingres/M +Ingrid/M +Ingrim/M +Ingunna/M +Inigo/M +Inna/M +Innis/M +Innocent/M +Innsbruck/M +Inonu/M +Inquisition/MS +Inst +Intel/M +Intelsat/M +Interdata/M +Internationale/M +Internet/M +Interpol/M +Inuit/MS +Inverness/M +Io/M +Iolande/M +Iolanthe/M +Iona/M +Ionesco/M +Ionian/M +Ionic/S +Iorgo/MS +Iormina/M +Iosep/M +Iowa/SM +Iowan/S +Iphigenia/M +Ipswich/M +Iqbal/M +Iquitos/M +Ir/M +Ira/M +Iran/M +Iranian/MS +Iraq/M +Iraqi/SM +Ireland/M +Irena/M +Irene/M +Irina/M +Iris +Irish/R +Irishman/M +Irishmen +Irishwoman/M +Irishwomen +Irita/M +Irkutsk/M +Irma/M +Iroquoian/MS +Iroquois/M +Irrawaddy/M +Irtish/M +Irv/MG +Irvin/M +Irvine/M +Irving/M +Irwin/M +Irwinn/M +Isa/M +Isaac/SM +Isaak/M +Isabel/M +Isabelita/M +Isabella/M +Isabelle/M +Isac/M +Isacco/M +Isador/M +Isadora/M +Isadore/M +Isahella/M +Isaiah/M +Isak/M +Iscariot/M +Iseabal/M +Isfahan/M +Isherwood/M +Ishim/M +Ishmael/M +Ishtar/M +Isiah/M +Isiahi/M +Isidor/M +Isidora/M +Isidore/M +Isidoro/M +Isidro/M +Isis/M +Islam/SM +Islamabad/M +Islamic/S +Islandia/M +Ismael/M +Isobel/M +Isolde/M +Ispahan's +Ispell/M +Israel/MS +Israeli/MS +Israelite/SM +Issac/M +Issi/M +Issiah/M +Issie/M +Issy/M +Istanbul/M +Istvan/M +Isuzu/M +It +Itaipu/M +Ital/M +Italian/MS +Italianate/GSD +Italy/M +Itasca/M +Itch/M +Itel/M +Ithaca/M +Ithacan +Ito/M +Iva/M +Ivan/M +Ivanhoe/M +Ivar/M +Ive/MRS +Iver/M +Ivett/M +Ivette/M +Ivie/M +Ivonne/M +Ivor/M +Ivory/M +Ivy/M +Izaak/M +Izabel/M +Izak/M +Izanagi/M +Izanami/M +Izhevsk/M +Izmir/M +Izvestia/M +Izzy/M +J's +J/X +JCS +JD +JFK/M +JP +JV +Jabez/M +Jablonsky/M +Jacenta/M +Jacinda/M +Jacinta/M +Jacintha/M +Jacinthe/M +Jack/M +Jackelyn/M +Jacki/M +Jackie/M +Jacklin/M +Jacklyn/M +Jackman/M +Jackquelin/M +Jackqueline/M +Jackson/SM +Jacksonian +Jacksonville/M +Jacky/M +Jaclin/M +Jaclyn/M +Jacob/SM +Jacobean +Jacobi/M +Jacobian/M +Jacobin/M +Jacobite/M +Jacobo/M +Jacobs/N +Jacobsen/M +Jacobson/M +Jacobus +Jacoby/M +Jacquard/SM +Jacquelin/M +Jacqueline/M +Jacquelyn/M +Jacquelynn/M +Jacquenetta/M +Jacquenette/M +Jacques/M +Jacquetta/M +Jacquette/M +Jacqui/M +Jacquie/M +Jacuzzi/S +Jacynth/M +Jada/M +Jade/M +Jae/M +Jaeger/M +Jagger/M +Jaime/M +Jaimie/M +Jain/M +Jaine/M +Jainism/M +Jaipur/M +Jakarta/M +Jake/MS +Jakie/M +Jakob/M +Jamaal/M +Jamaica/M +Jamaican/S +Jamal/M +Jamar/M +Jame/MS +Jamel/M +Jameson/M +Jamestown/M +Jamesy/M +Jamey/M +Jami/M +Jamie/M +Jamil/M +Jamill/M +Jamima/M +Jamison/M +Jammal/M +Jammie/M +Jan/M +Jana/M +Janacek/M +Janaya/M +Janaye/M +Jandy/M +Jane/M +Janean/M +Janeczka/M +Janeen/M +Janeiro/M +Janek/M +Janel/M +Janela/M +Janell/M +Janella/M +Janelle/M +Janene/M +Janenna/M +Janessa/M +Janesville/M +Janet/M +Janeta/M +Janetta/M +Janette/M +Janeva/M +Janey/M +Jania/M +Janice/M +Janie/M +Janifer/M +Janina/M +Janine/M +Janis/M +Janith/M +Janka/M +Janna/M +Jannel/M +Jannelle/M +Jannie/M +Janos/M +Janot/M +Jansen/M +Jansenist/M +January/MS +Janus/M +Jany/M +Japan/M +Japanese/SM +Japura/M +Jaquelin/M +Jaquelyn/M +Jaquenetta/M +Jaquenette/M +Jaquith/M +Jarad/M +Jard/M +Jareb/M +Jared/M +Jarib/M +Jarid/M +Jarlsberg +Jarrad/M +Jarred/M +Jarret/M +Jarrett/M +Jarrid/M +Jarrod/M +Jarvis/M +Jase/M +Jasen/M +Jasmin/M +Jasmina/M +Jasmine/M +Jason/M +Jasper/M +Jastrow/M +Jasun/M +Java/SM +JavaScript/M +Javanese +Javier/M +Jaxartes/M +Jay/M +Jayapura/M +Jaycee/SM +Jaye/M +Jayme/M +Jaymee/M +Jaymie/M +Jayne/M +Jaynell/M +Jayson/M +Jazmin/M +Jdavie/M +Jean/M +Jeana/M +Jeane/M +Jeanelle/M +Jeanette/M +Jeanie/M +Jeanine/M +Jeanna/M +Jeanne/M +Jeannette/M +Jeannie/M +Jeannine/M +Jecho/M +Jed/M +Jedd/M +Jeddy/M +Jedediah/M +Jedi/M +Jedidiah/M +Jeep/S +Jeeves/M +Jeff/M +Jefferey/M +Jefferson/M +Jeffersonian/S +Jeffery/M +Jeffie/M +Jeffrey/SM +Jeffry/M +Jeffy/M +Jehanna/M +Jehoshaphat/M +Jehovah/M +Jehu/M +Jekyll/M +Jelene/M +Jello/M +Jemie/M +Jemima/M +Jemimah/M +Jemmie/M +Jemmy/M +Jen/M +Jena/M +Jenda/M +Jenelle/M +Jeni/M +Jenica/M +Jeniece/M +Jenifer/M +Jeniffer/M +Jenilee/M +Jenine/M +Jenkins/M +Jenn/RMJ +Jenna/M +Jennee/M +Jenner/M +Jennette/M +Jenni/M +Jennica/M +Jennie/M +Jennifer/M +Jennilee/M +Jennine/M +Jennings/M +Jenny/M +Jeno/M +Jens/N +Jensen/M +Jephthah/M +Jerad/M +Jerald/M +Jeralee/M +Jeramey/M +Jeramie/M +Jere/M +Jereme/M +Jeremiah/M +Jeremiahs +Jeremias/M +Jeremie/M +Jeremy/M +Jeri/M +Jericho/M +Jermain/M +Jermaine/M +Jermayne/M +Jeroboam/M +Jerold/M +Jerome/M +Jeromy/M +Jerri/M +Jerrie/M +Jerrilee/M +Jerrilyn/M +Jerrine/M +Jerrod/M +Jerrold/M +Jerrome/M +Jerry/M +Jerrylee/M +Jersey/MS +Jerusalem/M +Jervis/M +Jes +Jess/M +Jessa/M +Jessalin/M +Jessalyn/M +Jessamine/M +Jessamyn/M +Jesse/M +Jessee/M +Jesselyn/M +Jessey/M +Jessi/M +Jessica/M +Jessie/M +Jessika/M +Jessy/M +Jesuit/SM +Jesus +Jeth/M +Jethro/M +Jew/MS +Jewel/M +Jewell/MD +Jewelle/M +Jewelled/M +Jewess/SM +Jewish/P +Jewishness/MS +Jewry/MS +Jezebel/MS +Jidda/M +Jilin +Jill/M +Jillana/M +Jillane/M +Jillayne/M +Jilleen/M +Jillene/M +Jilli/M +Jillian/M +Jillie/M +Jilly/M +Jim/M +Jimenez/M +Jimmie/M +Jimmy/M +Jinan +Jinnah/M +Jinny/M +Jivaro/M +Jo/MY +Joachim/M +Joan/M +Joana/M +Joane/M +Joanie/M +Joann/M +Joanna/M +Joanne/SM +Joaquin/M +Job/SM +Jobey/M +Jobi/M +Jobie/M +Jobina/M +Jobrel/M +Joby/M +Jobye/M +Jobyna/M +Jocasta/M +Jocelin/M +Joceline/M +Jocelyn/M +Jocelyne/M +Jock/M +Jocko/M +Jodee/M +Jodi/M +Jodie/M +Jody/M +Joe/M +Joeann/M +Joel/MY +Joela/M +Joelie/M +Joell/MN +Joella/M +Joelle/M +Joellen/M +Joelly/M +Joellyn/M +Joelynn/M +Joesph/M +Joete/M +Joey/M +Jogjakarta/M +Johan/M +Johann/M +Johanna/M +Johannah/M +Johannes +Johannesburg/M +Johansen/M +Johanson/M +John/SM +Johna/MH +Johnath/M +Johnathan/M +Johnathon/M +Johnette/M +Johnie/M +Johnna/M +Johnnie/M +Johnny/M +Johns/N +Johnsen/M +Johnson/M +Johnston/M +Johnstown/M +Johny/M +Joice/M +Jojo/M +Jolee/M +Joleen/M +Jolene/M +Joletta/M +Joli/M +Jolie/M +Joliet's +Joline/M +Jolla/M +Jolson/M +Joly/M +Jolyn/M +Jolynn/M +Jon/M +Jonah/M +Jonahs +Jonas +Jonathan/M +Jonathon/M +Jone/MS +Jonell/M +Jones/S +Joni/MS +Jonie/M +Jonson/M +Joplin/M +Jordain/M +Jordan/M +Jordana/M +Jordanian/S +Jordanna/M +Jordon/M +Jorey/M +Jorgan/M +Jorge/M +Jorgensen/M +Jorgenson/M +Jori/M +Jorie/M +Jorrie/M +Jorry/M +Jory/M +Joscelin/M +Jose/M +Josee/M +Josef/M +Josefa/M +Josefina/M +Joseito/M +Joseph/M +Josepha/M +Josephina/M +Josephine/M +Josephs +Josephson/M +Josephus/M +Josey/M +Josh/M +Joshia/M +Joshua/M +Joshuah/M +Josi/M +Josiah/M +Josias/M +Josie/M +Josselyn/M +Josue/M +Josy/M +Joule/M +Jourdain/M +Jourdan/M +Jovanovich/M +Jove/M +Jovian +Joy/M +Joya/M +Joyan/M +Joyann/M +Joyce/M +Joycean +Joycelin/M +Joye/M +Joyner/M +Jozef/M +Jpn +Jr/M +Jsandye/M +Juan/M +Juana/M +Juanita/M +Juarez +Jubal/M +Jud/M +Judah/M +Judaic +Judaical +Judaism/SM +Judas/S +Judd/M +Jude/M +Judea/M +Judi/MH +Judie/M +Judith/M +Juditha/M +Judon/M +Judson/M +Judy/M +Judye/M +Juggernaut/M +Juieta/M +Jul/M +Jule/MS +Julee/M +Juli/M +Julia/M +Julian/M +Juliana/M +Juliane/M +Juliann/M +Julianna/M +Julianne/M +Julie/M +Julienne/M +Juliet/M +Julieta/M +Julietta/M +Juliette/M +Julina/M +Juline/M +Julio/M +Julissa/M +Julita/M +Julius/M +July/SM +Julys +Jun/M +June/MS +Juneau/M +Junette/M +Jung/M +Jungfrau/M +Jungian +Junia/M +Junie/M +Junina/M +Junior/S +Junker/SM +Juno/M +Jupiter/M +Jurassic +Jurua/M +Justen/M +Justice/M +Justin/M +Justina/M +Justine/M +Justinian/M +Justinn/M +Justino/M +Justis/M +Justus/M +Jutish +Jutland/M +Juvenal/M +Jyoti/M +K's +K/G +KB +KC +KDE/M +KGB +KIA +KKK +KO +KP +KS +KY +Kaaba/M +Kabuki +Kabul/M +Kacey/M +Kacie/M +Kacy/M +Kaddish/M +Kaela/M +Kafka/M +Kafkaesque +Kagoshima/M +Kahaleel/M +Kahlil/M +Kahlua/M +Kahn/M +Kai/M +Kaia/M +Kaifeng/M +Kaila/M +Kaile/M +Kailey/M +Kain/M +Kaine/M +Kaiser/SM +Kaitlin/M +Kaitlyn/M +Kaitlynn/M +Kaja/M +Kajar/M +Kakalina/M +Kala/M +Kalahari/M +Kalamazoo/M +Kalashnikov/M +Kalb/M +Kale/M +Kaleb/M +Kaleena/M +Kalgoorlie/M +Kali/M +Kalie/M +Kalil/M +Kalila/M +Kalina/M +Kalinda/M +Kalindi/M +Kalle/M +Kalli/M +Kally/M +Kalmyk +Kalvin/M +Kama/M +Kamchatka/M +Kamehameha/M +Kameko/M +Kamikaze/MS +Kamila/M +Kamilah/M +Kamillah/M +Kampala/M +Kampuchea/M +Kan/MS +Kanchenjunga/M +Kandace/M +Kandahar/M +Kandinsky/M +Kandy/M +Kane/M +Kania/M +Kankakee/M +Kannada/M +Kano/M +Kanpur/M +Kansan/S +Kansas +Kant/M +Kantian +Kanya/M +Kaohsiung/M +Kaplan/M +Kaposi/M +Kara/M +Karachi/M +Karaganda/M +Karakorum/M +Karalee/M +Karalynn/M +Karamazov/M +Kare/M +Karee/M +Kareem/M +Karel/M +Karen/M +Karena/M +Karenina/M +Kari/M +Karia/M +Karie/M +Karil/M +Karilynn/M +Karim/M +Karin/M +Karina/M +Karine/M +Kariotta/M +Karisa/M +Karissa/M +Karita/M +Karl/MNX +Karla/M +Karlan/M +Karlee/M +Karleen/M +Karlen/M +Karlene/M +Karlie/M +Karlik/M +Karlis +Karloff/M +Karlotta/M +Karlotte/M +Karly/M +Karlyn/M +Karmen/M +Karna/M +Karney/M +Karo/YM +Karol/M +Karola/M +Karole/M +Karolina/M +Karoline/M +Karoly/M +Karon/M +Karp/M +Karrah/M +Karrie/M +Karroo/M +Karry/M +Kary/M +Karyl/M +Karylin/M +Karyn/M +Kasai/M +Kasey/M +Kashmir/SM +Kaspar/M +Kasparov/M +Kasper/M +Kass +Kassandra/M +Kassey/M +Kassi/M +Kassia/M +Kassie/M +Kat/M +Kata/M +Katalin/M +Kate/M +Katee/M +Katelyn/M +Katerina/M +Katerine/M +Katey/M +Kath/M +Katha/M +Katharina/M +Katharine/M +Katharyn/M +Kathe/M +Katherina/M +Katherine/M +Katheryn/M +Kathi/M +Kathiawar/M +Kathie/M +Kathleen/M +Kathlin/M +Kathmandu +Kathrine/M +Kathryn/M +Kathryne/M +Kathy/M +Kathye/M +Kati/M +Katie/M +Katina/M +Katine/M +Katinka/M +Katleen/M +Katlin/M +Katmai/M +Katmandu's +Katowice/M +Katrina/M +Katrine/M +Katrinka/M +Katti/M +Kattie/M +Katuscha/M +Katusha/M +Katy/M +Katya/M +Katz/M +Kauai/M +Kauffman/M +Kaufman/M +Kaunas/M +Kaunda/M +Kawabata/M +Kawasaki/M +Kay/M +Kaycee/M +Kaye/M +Kayla/M +Kayle/M +Kaylee/M +Kayley/M +Kaylil/M +Kaylyn/M +Kayne/M +Kazakh/M +Kazakhstan +Kazan/M +Kazantzakis/M +Kb +Kean/M +Keane/M +Kearney/M +Keary/M +Keaton/M +Keats/M +Keck/M +Keefe/MR +Keefer/M +Keegan/M +Keelby/M +Keeley/M +Keelia/M +Keely/M +Keen/M +Keenan/M +Keene/M +Keewatin/M +Keillor/M +Keir/M +Keisha/M +Keith/M +Kelbee/M +Kelby/M +Kelcey/M +Kelci/M +Kelcie/M +Kelcy/M +Kele/M +Kelila/M +Kellby/M +Kellen/M +Keller/M +Kelley/M +Kelli/M +Kellia/M +Kellie/M +Kellina/M +Kellogg/M +Kellsie/M +Kelly/M +Kellyann/M +Kelsey/M +Kelsi/M +Kelsy/M +Kelt's +Kelvin/M +Kelwin/M +Kemerovo/M +Kemp/M +Kempis/M +Ken/M +Kendal/M +Kendall/M +Kendell/M +Kendra/M +Kendre/M +Kendrick/MS +Kenilworth/M +Kenmore/M +Kenn/M +Kenna/M +Kennan/M +Kennecott/M +Kennedy/M +Kenneth/M +Kennett/M +Kennie/M +Kennith/M +Kenny/M +Kenon/M +Kenosha/M +Kensington/M +Kent/M +Kenton/M +Kentuckian/S +Kentucky/M +Kenya/M +Kenyan/S +Kenyatta/M +Kenyon/M +Keogh/M +Keokuk/M +Kepler/M +Ker/M +Kerby/M +Kerensky/M +Keri/M +Keriann/M +Kerianne/M +Kerk/M +Kermie/M +Kermit/M +Kermy/M +Kern/M +Kerouac/M +Kerr/M +Kerri/M +Kerrie/M +Kerrill/M +Kerrin/M +Kerry/M +Kerstin/M +Kerwin/M +Kerwinn/M +Kesley/M +Keslie/M +Kessia/M +Kessiah/M +Kessler/M +Kettering/M +Ketti/M +Kettie/M +Ketty/M +Kev/MN +Kevan/M +Keven/M +Kevin/M +Kevina/M +Kevlar +Kevon/M +Kevorkian/M +Kevyn/M +Kewaskum/M +Kewaunee/M +Kewpie/M +Key/M +Keynes/M +Keynesian/M +Khabarovsk/M +Khachaturian/M +Khalid/M +Khalil/M +Khan/M +Kharkov/M +Khartoum/M +Khayyam/M +Khmer/M +Khoisan/M +Khomeini/M +Khorana/M +Khrushchev/SM +Khufu/M +Khulna/M +Khwarizmi/M +Khyber/M +Ki/M +Kiah/M +Kial/M +Kickapoo/M +Kidd/M +Kieffer/M +Kiel/M +Kiele/M +Kienan/M +Kierkegaard/M +Kiersten/M +Kieth/M +Kiev/M +Kigali/M +Kikelia/M +Kikuyu/M +Kilauea/M +Kile/M +Kiley/M +Kilian/M +Kilimanjaro/M +Killebrew/M +Killian/M +Killie/M +Killy/M +Kim/M +Kimball/M +Kimbell/M +Kimberlee/M +Kimberley/M +Kimberli/M +Kimberly/M +Kimberlyn/M +Kimble/M +Kimbra/M +Kimmi/M +Kimmie/M +Kimmy/M +Kin/M +Kincaid/M +King/M +Kingsbury/M +Kingsley/M +Kingsly/M +Kingston/M +Kingstown/M +Kingwood/M +Kinna/M +Kinney/M +Kinnickinnic/M +Kinnie/M +Kinny/M +Kinsey/M +Kinshasa/M +Kinshasha/M +Kinsley/M +Kiowa/SM +Kip/M +Kipling/M +Kipp/MR +Kippar/M +Kipper/M +Kippie/M +Kippy/M +Kira/M +Kirbee/M +Kirbie/M +Kirby/M +Kirchhoff/M +Kirchner/M +Kirchoff/M +Kirghistan/M +Kirghiz/M +Kirghizia/M +Kiri/M +Kiribati +Kirinyaga/M +Kirk/M +Kirkland/M +Kirkpatrick/M +Kirkwood/M +Kirov/M +Kirsten/M +Kirsteni/M +Kirsti/M +Kirstin/M +Kirstyn/M +Kisangani/M +Kishinev/M +Kissee/M +Kissiah/M +Kissie/M +Kissinger/M +Kit/M +Kitakyushu/M +Kitchener/M +Kitti/M +Kittie/M +Kitty/M +Kiwanis/M +Kizzee/M +Kizzie/M +Klan/M +Klansman/M +Klara/M +Klarika/M +Klarrisa/M +Klaus/M +Klee/M +Kleenex/SM +Klein/M +Kleinrock/M +Klemens/M +Klement/M +Kleon/M +Kliment/M +Kline/M +Klingon/M +Klondike/SDMG +Klux/M +Knapp/M +Knauer/M +Knesset/M +Kngwarreye/M +Knickerbocker/MS +Knievel/M +Knight/M +Knobeloch/M +Knopf/M +Knossos/M +Knowles +Knox/M +Knoxville/M +Knudsen/M +Knudson/M +Knuth/M +Knutsen/M +Knutson/M +Kobayashi/M +Kobe/M +Koch/M +Kochab/M +Kodachrome/M +Kodak/SM +Kodaly/M +Kodiak/M +Koenig/M +Koenigsberg/M +Koenraad/M +Koestler/M +Kohinoor/M +Kohl/MR +Kohler/M +Kolyma/M +Kommunizma/M +Kong/M +Kongo/M +Konrad/M +Konstance/M +Konstantin/M +Konstantine/M +Konstanze/M +Koo/M +Koontz/M +Koppers/M +Kora/M +Koral/M +Koralle/M +Koran/SM +Koranic +Kordula/M +Kore/M +Korea/M +Korean/S +Korella/M +Koren/M +Koressa/M +Korey/M +Kori/M +Korie/M +Kornberg/M +Korney/M +Korrie/M +Korry/M +Kort/M +Kory/M +Korzybski/M +Kosciusko/M +Kossuth/M +Kosygin/M +Kovacs/M +Kowalewski/M +Kowalski/M +Kowloon/M +Kr/M +Kraemer/M +Kraft/M +Krakatau's +Krakatoa/M +Krakow/M +Kramer/M +Krasnodar/M +Krasnoyarsk/M +Krause/M +Krebs/M +Kremlin/M +Kremlinologist/MS +Kremlinology/MS +Kresge/M +Krieger/M +Kringle/M +Kris/M +Krisha/M +Krishna/M +Krishnah/M +Krispin/M +Krissie/M +Krissy/M +Krista/M +Kristal/M +Kristan/M +Kriste/M +Kristel/M +Kristen/M +Kristi/MN +Kristian/M +Kristie/M +Kristien/M +Kristin/M +Kristina/M +Kristine/M +Kristo/MS +Kristofer/M +Kristoffer/M +Kristofor/M +Kristoforo/M +Kristopher/M +Kristy/M +Kristyn/M +Kroc/M +Kroger/M +Kronecker/M +Kropotkin/M +Krueger/M +Kruger/M +Krugerrand/S +Krupp/M +Kruse/M +Krysta/M +Krystal/M +Krystalle/M +Krystle/M +Krystyna/M +Ku/M +Kublai/M +Kubrick/M +Kubuntu +Kubuntu's +Kuenning/M +Kuhn/M +Kuibyshev/M +Kumar/M +Kunming/M +Kuomintang/M +Kurd/SM +Kurdish/M +Kurdistan/SM +Kurosawa/M +Kurt/M +Kurtis/M +Kusch/M +Kuwait/M +Kuwaiti/SM +Kuznets/M +Kuznetsk/M +Kwakiutl/M +Kwangchow's +Kwangju/M +Kwanzaa/S +Ky/MH +Kyla/M +Kyle/M +Kylen/M +Kylie/M +Kylila/M +Kylynn/M +Kym/M +Kynthia/M +Kyoto/M +Kyrgyzstan +Kyrstin/M +Kyushu/M +L +L'Amour +L'Ouverture +L's +L'vov +LA +LAN +LBJ/M +LC +LCD +LCM +LDC +LED/SM +LIFO +LL +LLB +LLD +LNG +LOGO +LP +LPG +LPN/S +LSD +La/M +LaTeX/M +Lab/SM +Laban/M +Labrador/SM +Labradorean/S +Lac/M +Lacee/M +Lacey/M +Lachesis/M +Lacie/M +Lackawanna/M +Lacy/M +Ladoga/M +Ladonna/M +Lady/SM +Ladyship/MS +Laetitia/M +Lafayette/M +Lafitte/M +Lagos/M +Lagrange/M +Lagrangian/M +Laguerre/M +Laguna/M +Lahore/M +Laidlaw/M +Laina/M +Lainey/M +Laird/M +Laius/M +Lakehurst/M +Lakeisha/M +Lakewood/M +Lakisha/M +Lakshmi/M +Lalo/M +Lamaism/SM +Lamar/M +Lamarck/M +Lamaze +Lamb/M +Lambert/M +Lamborghini/M +Lammond/M +Lamond/M +Lamont/M +Lamport/M +Lana/M +Lanae/M +Lanai/M +Lancashire/M +Lancaster/M +Lance/M +Lancelot/M +Land/M +Landis/M +Landon/M +Landry/M +Landsat +Landsteiner/M +Landwehr/M +Lane/M +Lanette/M +Laney/M +Lang/M +Lange/M +Langeland/M +Langerhans/M +Langford/M +Langland/M +Langley/M +Langmuir/M +Langsdon/M +Langston/M +Lani/M +Lanie/M +Lanita/M +Lanna/M +Lanni/M +Lannie/M +Lanny/M +Lansing/M +Lanzhou +Lao/SM +Laocoon/M +Laotian/MS +Laplace/M +Lapland/ZMR +Lapp/SM +Lara/M +Laraine/M +Laramie/M +Lardner/M +Laredo/M +Lari/M +Larina/M +Larine/M +Larisa/M +Larissa/M +Lark/M +Larousse/M +Larry/M +Lars/NM +Larsen/M +Larson/M +Laryssa/M +Lascaux/M +Lassa/M +Lassen/M +Lassie/M +Laszlo/M +Lat/M +Latasha/M +Latashia/M +Lateran/M +Lathrop/M +Latia/M +Latin/RMS +Latina/SM +Latinate +Latino/S +Latisha/M +Latonya/M +Latoya/M +Latrena/M +Latrina/M +Latrobe/M +Lattimer/M +Latvia/M +Latvian/S +Laud/MR +Lauder/M +Lauderdale/M +Laue/M +Laughton/M +Launce/M +Laundromat/SM +Laura/M +Lauraine/M +Laural/M +Lauralee/M +Laurasia/M +Laure/M +Lauree/M +Laureen/M +Laurel/M +Laurella/M +Lauren/SM +Laurena/M +Laurence/M +Laurene/M +Laurent/M +Laurentian +Lauretta/M +Laurette/M +Lauri/M +Laurianne/M +Laurice/M +Laurie/M +Lauritz/M +Lauryn/M +Lausanne/M +Laval/M +Lavena/M +Lavern/M +Laverna/M +Laverne/M +Lavina/M +Lavinia/M +Lavinie/M +Lavoisier/M +Lavonne/M +Law/M +Lawanda/M +Lawford/M +Lawrence/M +Lawrenceville/M +Lawry/M +Lawson/M +Lawton/M +Lay/M +Layamon/M +Layla/M +Layne/M +Layney/M +Layton/M +Lazar/M +Lazare/M +Lazaro/M +Lazarus/M +Le/NM +Lea/M +Leach/M +Leadbelly/M +Leah/M +Leakey/M +Lean/M +Leander/M +Leandra/M +Leann/M +Leanna/M +Leanne/M +Leanor/M +Leanora/M +Lear/M +Leary/M +Leavenworth/M +Lebanese +Lebanon/M +Lebbie/M +Lebesgue/M +Leblanc/M +Leda/M +Lederberg/M +Lee/M +Leeann/M +Leeanne/M +Leeds/M +Leela/M +Leelah/M +Leeland/M +Leena/M +Leesa/M +Leese/M +Leeuwenhoek/M +Leeward/M +Left/S +Lefty/M +Legendre/M +Leger/SM +Leghorn/SM +Lego/M +Legra/M +Legree/M +Lehigh/M +Lehman/M +Leia/M +Leibniz/M +Leicester/SM +Leiden/M +Leif/M +Leigh/M +Leigha/M +Leighton/M +Leila/M +Leilah/M +Leipzig/M +Leisha/M +Lek/M +Lela/M +Lelah/M +Leland/M +Lelia/M +Lem/M +Lemaitre/M +Lemar/M +Lemke/M +Lemmie/M +Lemmy/M +Lemuel/M +Lemuria/M +Len/M +Lena/M +Lenard/M +Lenci/M +Lenee/M +Lenette/M +Lenin/M +Leningrad/M +Leninism/M +Leninist +Lenka/M +Lenna/M +Lennard/M +Lennie/M +Lennon/M +Lenny/M +Leno/M +Lenoir/M +Lenora/M +Lenore/M +Lent/SMN +Leo/MS +Leodora/M +Leoine/M +Leola/M +Leoline/M +Leon/M +Leona/M +Leonanie/M +Leonard/M +Leonardo/M +Leoncavallo/M +Leone/M +Leonel/M +Leonelle/M +Leonerd/M +Leonhard/M +Leonid/M +Leonidas/M +Leonie/M +Leonor/M +Leonora/M +Leonore/M +Leontine/M +Leontyne/M +Leopold/M +Leopoldo/M +Leopoldville/M +Leora/M +Lepidus/M +Lepke/M +Lepus/M +Lerner/M +Leroi/M +Leroy/M +Les/Y +Lesa/M +Leshia/M +Lesley/M +Lesli/M +Leslie/M +Lesly/M +Lesotho/M +Lesseps/M +Lessie/M +Lester/M +Lesya/M +Leta/M +Letha/M +Lethe/M +Lethia/M +Leticia/M +Letisha/M +Letitia/M +Letizia/M +Letta/M +Letterman/M +Letti/M +Lettie/M +Letty/M +Leupold/M +Lev/M +Levant/M +Levesque/M +Levey/M +Levi/MS +Leviathan +Levin/M +Levine/M +Leviticus/M +Levitt/M +Levon/M +Levy/M +Lew/M +Lewellyn/M +Lewes +Lewie/M +Lewinsky/M +Lewis/M +Lewiss +Lexi/MS +Lexie/M +Lexine/M +Lexington/M +Lexus/M +Lexy/M +Leyden/M +Leyla/M +Lezley/M +Lezlie/M +Lhasa/SM +Lhotse/M +Li/MY +Lia/M +Liam/M +Lian/M +Liana/M +Liane/M +Lianna/M +Lianne/M +Lib/M +Libbey/M +Libbi/M +Libbie/M +Libby/M +Liberace/M +Liberia/M +Liberian/S +Libra/SM +Libreville/M +Librium/M +Libya/M +Libyan/S +Licha/M +Lichtenstein/M +Lichter/M +Lida/M +Lidia/M +Lie/M +Lieberman/M +Liebfraumilch/M +Liechtenstein/RMZ +Lief/M +Liege/M +Liesa/M +Lieut/M +Lil/MY +Lila/SM +Lilah/M +Lilia/MS +Lilian/M +Liliana/M +Liliane/M +Lilith/M +Liliuokalani/M +Lilla/M +Lille/M +Lilli/MS +Lillian/M +Lillie/M +Lilliput/M +Lilliputian/SM +Lilllie/M +Lilly/M +Lilongwe/M +Lily/M +Lilyan/M +Lima/M +Limbaugh/M +Limbo +Limburger/SM +Limoges/M +Limpopo/M +Lin/M +Lina/M +Linc/M +Lincoln/SM +Lind/M +Linda/M +Lindberg/M +Lindbergh/M +Lindholm/M +Lindi/M +Lindie/M +Lindon/M +Lindquist/M +Lindsay/M +Lindsey/M +Lindstrom/M +Lindsy/M +Lindy/M +Linea/M +Linell/M +Linet/M +Linette/M +Link/M +Linn/M +Linnaeus/M +Linnea/M +Linnell/M +Linnet/M +Linnie/M +Linoel/M +Linotype/M +Linton/M +Linus/M +Linux/M +Linwood/M +Linzy/M +Lion/M +Lionel/M +Lionello/M +Lippi/M +Lippmann/M +Lipschitz/M +Lipscomb/M +Lipton/M +Lira/M +Lisa/M +Lisabeth/M +Lisbeth/M +Lisbon/M +Lise/M +Lisetta/M +Lisette/M +Lisha/M +Lishe/M +Lisle/M +Liss/M +Lissa/M +Lissajous/M +Lissi/M +Lissie/M +Lissy/M +Lister/M +Listerine/M +Liston/M +Liszt/M +Lita/M +Lithuania/M +Lithuanian/S +Little/M +Littleton/M +Litton/M +Liuka/M +Liv/M +Liva/M +Livermore/M +Liverpool/M +Liverpudlian/MS +Livia/M +Livingston/M +Livingstone/M +Livonia/M +Livvie/M +Livvy/M +Livvyy/M +Livy/M +Liz/M +Liza/M +Lizabeth/M +Lizbeth/M +Lizette/M +Lizzie/M +Lizzy/M +Ljubljana/M +Llewellyn/M +Lloyd/M +Llywellyn/M +Loafer/S +Lobachevsky/M +Lochinvar/M +Lock/M +Locke/M +Lockean/M +Lockhart/M +Lockheed/M +Lockian/M +Lockwood/M +Lodge/M +Lodovico/M +Lodowick/M +Lodz +Loeb/M +Loella/M +Loewe/M +Loewi/M +Logan/M +Lohengrin/M +Loire/M +Lois/M +Loise/M +Loki/M +Lola/M +Loleta/M +Lolita/M +Lolly/M +Lomb/M +Lombard/M +Lombardi/M +Lombardy/M +Lome +Lon/M +Lona/M +London/RMZ +Londonderry/M +Londoner/M +Lonee/M +Long/M +Longfellow/M +Longstreet/M +Longueuil/M +Loni/M +Lonna/M +Lonnard/M +Lonni/M +Lonnie/M +Lonny/M +Loomis/M +Lopez/M +Lora/M +Lorain/M +Loraine/M +Loralee/M +Loralie/M +Loralyn/M +Lorant/M +Lord/MS +Lordship/SM +Loree/M +Loreen/M +Lorelei/M +Lorelle/M +Loren/SM +Lorena/M +Lorene/M +Lorentz/M +Lorentzian/M +Lorenz/M +Lorenza/M +Lorenzo/M +Loretta/M +Lorette/M +Lori/M +Loria/M +Lorianna/M +Lorianne/M +Lorie/M +Lorilee/M +Lorilyn/M +Lorin/M +Lorinda/M +Lorine/M +Lorita/M +Lorna/M +Lorne/M +Lorraine/M +Lorrayne/M +Lorre/M +Lorri/M +Lorrie/M +Lorrin/M +Lorry/M +Lory/M +Los +Lot/M +Lothaire/M +Lothario/MS +Lott/M +Lotta/M +Lotte/M +Lotti/M +Lottie/M +Lotty/M +Lou/M +Louella/M +Louie/M +Louis/M +Louisa/M +Louise/M +Louisette/M +Louisiana/M +Louisianan/S +Louisianian/S +Louisville/M +Lourdes/M +Loutitia/M +Louvre/M +Love/M +Lovecraft/M +Lovejoy/M +Lovelace/M +Loveland/M +Lovell/M +Lowe/M +Lowell/M +Lowery/M +Lowlands/M +Lowrance/M +Loy/M +Loyang/M +Loyd/M +Loydie/M +Loyola/M +Lr +Lt/M +Ltd/M +Lu/M +Luanda/M +Luann/M +Lubbock/M +Lubumbashi/M +Luca/MS +Lucais/M +Luce/M +Lucerne/M +Lucho/M +Luci/MN +Lucia/MS +Lucian/M +Luciana/M +Luciano/M +Lucie/M +Lucien/M +Lucienne/M +Lucifer/M +Lucila/M +Lucile/M +Lucilia/M +Lucille/M +Lucina/M +Lucinda/M +Lucine/M +Lucio/M +Lucita/M +Lucite/MS +Lucius/M +Lucknow/M +Lucky/M +Lucretia/M +Lucretius/M +Lucy/M +Luddite/SM +Ludhiana/M +Ludlow/M +Ludmilla/M +Ludovico/M +Ludovika/M +Ludvig/M +Ludwig/M +Luella/M +Luelle/M +Lufthansa/M +Luftwaffe/M +Luger/M +Lugosi/M +Luigi/M +Luis/M +Luisa/M +Luise/M +Lukas/M +Luke/M +Lula/M +Lulita/M +Lulu/M +Lumi�re/M +Luna/M +Lund/M +Lundberg/M +Lundquist/M +Lupe/M +Lupus/M +Lura/M +Lurette/M +Luria/M +Lurleen/M +Lurlene/M +Lurline/M +Lusa/M +Lusaka/M +Lusitania/M +Lutero/M +Luther/M +Lutheran/SM +Lutheranism/MS +Lutz +Luxembourg/RMZ +Luxembourgian +Luxemburg's +Luz/M +Luzon/M +Ly/MY +LyX/M +Lyallpur/M +Lycra/S +Lycurgus/M +Lyda/M +Lydia/M +Lydian/S +Lydie/M +Lydon/M +Lyell/M +Lyle/M +Lyly/M +Lyman/M +Lyme/M +Lyn/M +Lynch/M +Lynchburg/M +Lynda/M +Lynde/M +Lyndel/M +Lyndell/M +Lyndon/M +Lyndsay/M +Lyndsey/M +Lyndsie/M +Lyndy/M +Lynea/M +Lynelle/M +Lynett/M +Lynette/M +Lynn/M +Lynna/M +Lynne/M +Lynnea/M +Lynnell/M +Lynnelle/M +Lynnet/M +Lynnett/M +Lynnette/M +Lynsey/M +Lyon/SM +Lyra/M +Lysenko/M +Lysistrata/M +Lysol/M +Lyssa/M +M's +M/GB +MA +MAG +MASH +MB +MBA +MC +MCI/M +MD +MDT +ME +MFA +MGM/M +MHz +MI +MIA +MIG/S +MIMD +MIPS +MIRV/DSG +MIT/M +MITRE/SM +MM +MMe +MN +MO +MP +MPH +MRI +MS +MSG +MST +MSW +MT +MTS +MTV +MULTICS/M +MVP +MW +Maalox/M +Mab/M +Mabel/M +Mabelle/M +Mable/M +Mac/SGMD +MacArthur/M +MacDonald/M +MacDraw/M +MacGregor/M +MacIntosh/M +MacKenzie/M +MacLeish/M +MacMillan/M +MacPaint/M +Macao/M +Macarthur/M +Macaulay/M +Macbeth/M +Maccabees/M +Maccabeus/M +Macdonald/M +Mace/MS +Macedon/M +Macedonia/M +Macedonian/S +Macgregor/M +Mach/M +Machiavelli/M +Machiavellian/S +Machs +Macias/M +Macintosh/M +Mack/M +Mackenzie/M +Mackinac/M +Mackinaw +Macmillan/M +Macon/SM +Macy/M +Mada/M +Madagascan/SM +Madagascar/M +Madalena/M +Madalyn/M +Madame/MS +Maddalena/M +Madden/M +Maddi/M +Maddie/M +Maddox/M +Maddy/M +Madeira/SM +Madel/M +Madelaine/M +Madeleine/M +Madelena/M +Madelene/M +Madelin/M +Madelina/M +Madeline/M +Madella/M +Madelle/M +Madelon/M +Madelyn/M +Madge/M +Madhya/M +Madison/M +Madlen/M +Madlin/M +Madonna/MS +Madras +Madrid/M +Madsen/M +Madurai/M +Mady/M +Mae/M +Maegan/M +Maelstrom/M +Maeterlinck/M +Mafia/MS +Mafioso/S +Mag/M +Magda/M +Magdaia/M +Magdalen/M +Magdalena/M +Magdalene/M +Magellan/M +Magellanic +Maggee/M +Maggi/M +Maggie/M +Maggy/M +Magi/M +Magill/M +Maginot/M +Magnitogorsk/M +Magnum +Magnuson/M +Magog/M +Magoo/M +Magritte/M +Magruder/M +Magsaysay/M +Maguire/SM +Magus/M +Magyar/MS +Mahabharata +Mahala/M +Mahalia/M +Maharashtra/M +Mahavira/M +Mahayana/M +Mahayanist +Mahdi/M +Mahfouz/M +Mahican/SM +Mahler/M +Mahmoud/M +Mahmud/M +Mahomet's +Mai/MR +Maia/M +Maible/M +Maier/M +Maiga/M +Maighdiln/M +Maigret/M +Mailer/M +Maillol/M +Maiman/M +Maimonides/M +Maine/MZR +Mainer/M +Mair/M +Maire/M +Maisey/M +Maisie/M +Maison/M +Maitilde/M +Maj +Maje/M +Majesty/MS +Major/M +Majorca/M +Majuro/M +Makarios/M +Maker/M +Mal/M +Mala/M +Malabar/M +Malabo/M +Malacca/M +Malachi/M +Malagasy/M +Malamud/M +Malanie/M +Malaprop/M +Malawi/M +Malawian/S +Malay/SM +Malaya/M +Malayalam/M +Malayan/MS +Malaysia/M +Malaysian/S +Malchy/M +Malcolm/M +Maldive/SM +Maldivian/S +Maldonado/M +Male/M +Malena/M +Mali/M +Malia/M +Malian/S +Malibu/M +Malina/M +Malinda/M +Malinde/M +Malinowski/M +Malissa/M +Malissia/M +Mallarm�/M +Mallissa/M +Mallorie/M +Mallory/M +Malone/M +Malorie/M +Malory/M +Malraux/M +Malta/M +Maltese +Malthus/M +Malthusian/S +Malva/M +Malvin/M +Malvina/M +Malynda/M +Mame/M +Mamet/M +Mamie/M +Mammon's +Mamore/M +Man/SM +Managua/M +Manama/M +Manasseh/M +Manaus's +Manchester/M +Manchu/MS +Manchuria/M +Manchurian/S +Mancini/M +Mancunian/MS +Manda/M +Mandalay/M +Mandarin +Mandel/M +Mandela +Mandelbrot/M +Mandi/M +Mandie/M +Mandingo/M +Mandy/M +Manet/M +Manfred/M +Manhattan/SM +Mani/M +Manichean/M +Manila/MS +Manitoba/M +Manitoulin/M +Manitowoc/M +Mankowski/M +Manley/M +Mann/GM +Mannheim/M +Mannie/M +Manning/M +Manny/M +Mano/M +Manolo/M +Manon/M +Mansfield/M +Manson/M +Mantegna/M +Mantle/M +Manuel/M +Manuela/M +Manville/M +Manx +Manya/M +Mao/M +Maoism/MS +Maoist/S +Maori/SM +Maplecrest/M +Mapplethorpe/M +Maputo/M +Mar/SMN +Mara/M +Marabel/M +Maracaibo/M +Marat/M +Marathi +Marathon/M +Marc/M +Marceau/M +Marcel/M +Marcela/M +Marcelia/M +Marcelino/M +Marcella/M +Marcelle/M +Marcellina/M +Marcelline/M +Marcello/M +Marcellus/M +Marcelo/M +March/MS +Marchall/M +Marchelle/M +Marci/M +Marcia/M +Marciano/M +Marcie/M +Marcile/M +Marcille/M +Marco/SM +Marconi/M +Marcotte/M +Marcus/M +Marcy/M +Mardi/SM +Marduk/M +Mareah/M +Maren/M +Marena/M +Maressa/M +Marga/M +Margalit/M +Margalo/M +Margaret/M +Margareta/M +Margarete/M +Margaretha/M +Margarethe/M +Margaretta/M +Margarette/M +Margarita/M +Margarito/M +Margaux/M +Marge/M +Margeaux/M +Margery/M +Marget/M +Margette/M +Margi/M +Margie/M +Margit/M +Margo/M +Margot/M +Margret/M +Margrethe/M +Marguerite/M +Margy/M +Mari/MS +Maria/M +Mariam/M +Marian/MS +Mariana/SM +Mariann/M +Marianna/M +Marianne/M +Mariano/M +Maribel/M +Maribelle/M +Maribeth/M +Marice/M +Maricela/M +Maridel/M +Marie/M +Marieann/M +Mariejeanne/M +Mariel/M +Mariele/M +Marielle/M +Mariellen/M +Marietta/M +Mariette/M +Marigold/M +Marijn/M +Marijo/M +Marika/M +Marilee/M +Marilin/M +Marillin/M +Marilyn/M +Marin/M +Marina/M +Marine/S +Marinna/M +Marino/M +Mario/M +Marion/M +Mariquilla/M +Marisa/M +Mariska/M +Marisol/M +Marissa/M +Marita/M +Maritain/M +Maritsa/M +Maritza/M +Mariupol/M +Marius/M +Mariya/M +Marj/M +Marja/M +Marje/M +Marji/M +Marjie/M +Marjorie/M +Marjory/M +Marjy/M +Mark/MS +Markab/M +Marketa/M +Markham/M +Markism/M +Markos +Markov +Markovian +Markovitz/M +Markus/M +Marla/M +Marlane/M +Marlboro/M +Marlborough/M +Marleah/M +Marlee/M +Marleen/M +Marlena/M +Marlene/M +Marley/M +Marlie/M +Marlin/M +Marline/M +Marlo/M +Marlon/M +Marlow/M +Marlowe/M +Marlyn/M +Marmaduke/M +Marmara/M +Marna/M +Marne/M +Marney/M +Marni/M +Marnia/M +Marnie/M +Marquesas/M +Marquette/M +Marquez/M +Marquis/M +Marquita/M +Marrakesh/M +Marrilee/M +Marriott/M +Marris/M +Marrissa/M +Marseillaise/SM +Marseille's +Marseilles +Marsh/M +Marsha/M +Marshal/M +Marshall/GDM +Marshalled/M +Marshalling/M +Marsiella/M +Mart/MN +Marta/M +Martainn/M +Martel/M +Martelle/M +Marten/M +Martguerita/M +Martha/M +Marthe/M +Marthena/M +Marti/M +Martial +Martian/S +Martica/M +Martie/M +Martin/M +Martina/M +Martinez/M +Martinique/M +Martino/M +Martinson/M +Martita/M +Marty/M +Martyn/M +Martynne/M +Marv/NM +Marva/M +Marve/M +Marvell/M +Marven/M +Marvin/M +Marwin/M +Marx/M +Marxian/S +Marxism/SM +Marxist/SM +Mary/M +Marya/M +Maryann/M +Maryanna/M +Maryanne/M +Marybelle/M +Marybeth/M +Maryellen/M +Maryjane/M +Maryjo/M +Maryl/M +Maryland/MZR +Marylee/M +Marylin/M +Marylinda/M +Marylou/M +Marylynne/M +Maryrose/M +Marys +Marysa/M +Masada/M +Masai/M +Masaryk/M +Mascagni/M +Masefield/M +Maseru/M +Masha/M +Mashhad/M +Mason/SM +Masonic +Masonite/M +Mass/S +Massachusetts/M +Massasoit/M +Massenet/M +Massey/M +Massimiliano/M +Massimo/M +Master/SM +Mata/M +Matelda/M +Mateo/M +Mathe/RM +Mathematica/M +Mathematik/M +Mather/M +Mathew/MS +Mathewson/M +Mathian/M +Mathias +Mathieu/M +Mathilda/M +Mathilde/M +Mathis +Matias/M +Matilda/M +Matilde/M +Matisse/SM +Matsumoto/M +Matt/M +Mattel/M +Matteo/M +Matterhorn/M +Matthaeus/M +Mattheus/M +Matthew/MS +Matthias +Matthieu/M +Matthiew/M +Matthus/M +Matti/M +Mattias/M +Mattie/M +Matty/M +Maud/M +Maude/M +Maudie/M +Maugham/M +Maui/M +Maupassant/M +Maura/M +Maure/M +Maureen/M +Maureene/M +Maurene/M +Mauriac/M +Maurice/M +Mauricio/M +Maurie/M +Maurine/M +Maurise/M +Maurita/M +Mauritania/M +Mauritanian/S +Mauritian/S +Mauritius/M +Maurits/M +Maurizia/M +Maurizio/M +Mauro/M +Maurois/M +Maury/M +Mauser/M +Mavis/M +Mavra/M +Mawr/M +Max/M +Maxi/M +Maxie/M +Maxim/M +Maximilian/M +Maximilianus/M +Maximilien/M +Maximo/M +Maxine/M +Maxtor/M +Maxwell/M +Maxwellian +Maxy/M +May/SMR +Maya/MS +Mayan/S +Maybelle/M +Maye/M +Mayer/M +Mayfair/M +Mayflower/M +Maynard/M +Mayne/M +Maynord/M +Mayo/M +Mayor/M +Maypole/SM +Mayra/M +Mazama/M +Mazarin/M +Mazatlan/M +Mazda/M +Mazzini/M +Mb +Mbabane/M +Mbini/M +McAdam/MS +McAllister/M +McBride/M +McCabe/M +McCain/M +McCall/M +McCarthy/M +McCarthyism/M +McCartney/M +McCarty/M +McCauley/M +McClain/M +McClellan/M +McClure/M +McCluskey/M +McConnell/M +McCormick/M +McCoy/SM +McCracken/M +McCray/M +McCullough/M +McDaniel/M +McDermott/M +McDonald/M +McDonnell/M +McDougall/M +McDowell/M +McElhaney/M +McEnroe/M +McFadden/M +McFarland/M +McGee/M +McGill/M +McGovern/M +McGowan/M +McGrath/M +McGraw/M +McGregor/M +McGuffey/M +McGuire/M +McIntosh/M +McIntyre/M +McKay/M +McKee/M +McKenzie/M +McKesson/M +McKinley/M +McKinney/M +McKnight/M +McLanahan/M +McLaughlin/M +McLean/M +McLeod/M +McLuhan/M +McMahon/M +McMartin/M +McMillan/M +McNamara/M +McNaughton/M +McNeil/M +McPherson/M +Md/M +Me/M +Mead/M +Meade/M +Meadows +Meagan/M +Meaghan/M +Meany/M +Meara/M +Mecca/MS +Mechelle/M +Medan/M +Medea/M +Medellin +Medfield/M +Medicaid/SM +Medicare/MS +Medici/MS +Medina/M +Mediterranean/MS +Medusa/M +Meg/MN +Megan/M +Megen/M +Meggi/M +Meggie/M +Meggy/M +Meghan/M +Meghann/M +Mehetabel/M +Mei/MR +Meier/M +Meighen/M +Meiji/M +Meir/M +Meister/M +Meistersinger/M +Mejia/M +Mekong/M +Mel/MY +Mela/M +Melamie/M +Melanesia/M +Melanesian/S +Melania/M +Melanie/M +Melantha/M +Melany/M +Melba/M +Melbourne/M +Melcher/M +Melchior/M +Melendez/M +Melesa/M +Melessa/M +Melicent/M +Melina/M +Melinda/M +Melinde/M +Melisa/M +Melisande/M +Melisandra/M +Melisenda/M +Melisent/M +Melissa/M +Melisse/M +Melita/M +Melitta/M +Mella/M +Melli/M +Mellicent/M +Mellie/M +Mellisa/M +Mellisent/M +Mellon/M +Melloney/M +Melly/M +Melodee/M +Melodie/M +Melody/M +Melonie/M +Melony/M +Melosa/M +Melpomene/M +Melton/M +Melva/M +Melville/M +Melvin/M +Melvyn/M +Memling/M +Memphis/M +Menander/M +Menard/M +Mencius/M +Mencken/M +Mendel/M +Mendeleev/M +Mendelian +Mendelssohn/M +Mendez/M +Mendie/M +Mendocino/M +Mendoza/M +Mendy/M +Menelaus/M +Menes/M +Menkalinan/M +Menkar/M +Menkent/M +Menlo/M +Mennonite/SM +Menominee +Menotti/M +Mensa/M +Mensch/M +Menuhin/M +Menzies/M +Mephistopheles/M +Merak/M +Mercado/M +Mercator/M +Mercedes +Mercer/M +Merci/M +Mercie/M +Merck/M +Mercurochrome/M +Mercury/MS +Mercy/M +Meredeth/M +Meredith/M +Meredithe/M +Merell/M +Meridel/M +Meridith/M +Meriel/M +Merilee/M +Merill/M +Merilyn/M +Meris +Merissa/M +Meriwether/M +Merl/M +Merla/M +Merle/M +Merlin/M +Merlina/M +Merline/M +Merna/M +Merola/M +Merralee/M +Merrel/M +Merriam/M +Merrick/M +Merridie/M +Merrie/M +Merrielle/M +Merrile/M +Merrilee/M +Merrili/M +Merrill/M +Merrily/M +Merrimac/M +Merrimack/M +Merritt/M +Merry/M +Mersey/M +Merton/M +Merv/M +Mervin/M +Merwin/M +Merwyn/M +Meryl/M +Mesa +Mesabi/M +Meshed's +Mesolithic/M +Mesopotamia/M +Mesopotamian/S +Mesozoic +Messerschmidt/M +Messiaen/M +Messiah/M +Messiahs +Messianic +Messrs/M +Meta/M +Methodism/SM +Methodist/MS +Methuen/M +Methuselah/M +Methuselahs +Metrecal/M +Metternich/M +Metzler/M +Meuse/M +Mex +Mexicali/M +Mexican/S +Mexico/M +Meyer/SM +Meyerbeer/M +Mg/M +Mgr +Mia/M +Miami/SM +Miaplacidus/M +Mic/M +Micaela/M +Micah/M +Mich/M +Michael/SM +Michaela/M +Michaelangelo/M +Michaelina/M +Michaeline/M +Michaella/M +Michaelmas/MS +Michaelson/M +Michail/M +Michal/M +Michale/M +Micheal/M +Micheil/M +Michel/M +Michelangelo/M +Michele/M +Michelin/M +Michelina/M +Micheline/M +Michell/M +Michelle/M +Michelson/M +Michigan/M +Michigander/S +Michiganite/S +Mick/M +Mickelson/M +Mickey/M +Micki/M +Mickie/M +Micky/M +Micmac/M +MicroVAX/M +MicroVAXes +Micronesia/M +Micronesian/S +Microport/M +Microsoft/M +Microsystems +Midas/M +Middlebury/M +Middlesex/M +Middleton/M +Middletown/M +Mideast/M +Mideastern +Midge/M +Midland/MS +Midway/M +Midwest/M +Midwestern/ZR +Midwesterner/M +Mignon/M +Mignonne/M +Miguel/M +Miguela/M +Miguelita/M +Mikael/M +Mikaela/M +Mike/M +Mikel/M +Mikey/M +Mikhail/M +Mikkel/M +Mikol/M +Mikoyan/M +Mil/MY +Milagros/M +Milan/M +Milanese +Mildred/M +Mildrid/M +Mile/SM +Milena/M +Milford/M +Milicent/M +Milissent/M +Milka/M +Milken/M +Mill/SMR +Millard/M +Millay/M +Miller/M +Millet/M +Milli/M +Millicent/M +Millie/M +Millikan/M +Millisent/M +Milly/M +Milne/M +Milo/M +Milquetoast/S +Milt/M +Miltiades/M +Miltie/M +Milton/M +Miltonic +Miltown/M +Milty/M +Milwaukee/M +Milzie/M +Mimi/M +Mimosa/M +Min/MR +Mina/M +Minda/M +Mindanao/M +Mindoro/M +Mindy/M +Miner/M +Minerva/M +Minetta/M +Minette/M +Ming/M +Mingus/M +Minn/M +Minna/M +Minnaminnie/M +Minne/M +Minneapolis/M +Minnesota/M +Minnesotan/S +Minni/M +Minnie/M +Minnnie/M +Minny/M +Minoan/S +Minolta/M +Minor/M +Minos +Minot/M +Minotaur/M +Minsk/M +Minsky/M +Minta/M +Mintaka/M +Minuit/M +Minuteman/M +Miocene +Miquela/M +Mir/M +Mira/M +Mirabeau/M +Mirabel/M +Mirabella/M +Mirabelle/M +Mirach/M +Miran/M +Miranda/M +Mireielle/M +Mireille/M +Mirella/M +Mirelle/M +Mirfak/M +Miriam/M +Mirilla/M +Mirna/M +Miro +Mirzam/M +Mischa/M +Misha/M +Miskito +Miss/SM +Missie/M +Mississauga/M +Mississippi/M +Mississippian/S +Missoula/M +Missouri/M +Missourian/S +Missy/M +Mistassini/M +Mister/SM +Misti/M +Mistress/MS +Misty/M +Mitch/M +Mitchael/M +Mitchel/M +Mitchell/M +Mitford/M +Mithra/M +Mithridates/M +Mitsubishi/M +Mitterrand/M +Mitty/M +Mitzi/M +Mizar/M +Mk +Mlle/M +Mme/SM +Mn/M +Mnemosyne/M +Mo/MN +Mobil/M +Mobile/M +Mobutu/M +Modesta/M +Modestia/M +Modestine/M +Modesto/M +Modesty/M +Modigliani/M +Modula/M +Moe/M +Moen/M +Mogadiscio's +Mogadishu +Mogul/MS +Mohamed/M +Mohammad/M +Mohammed's +Mohammedan/SM +Mohammedanism/MS +Mohandas/M +Mohandis/M +Mohawk/MS +Mohegan/S +Mohican's +Moho/M +Mohorovicic/M +Mohr/M +Moina/M +Moines/M +Moira/M +Moise/MS +Moiseyev/M +Moishe/M +Mojave/M +Moldavia/M +Moldavian/S +Moldova +Moliere +Molina/M +Moline/M +Moll/M +Mollee/M +Molli/M +Mollie/M +Molly/M +Molnar/M +Moloch/M +Molokai/M +Molotov/M +Moluccas +Mombasa/M +Mommy/M +Mon/SM +Mona/M +Monaco/M +Monah/M +Monash/M +Mondale/M +Monday/MS +Mondrian/M +Monegasque/SM +Monera/M +Monet/M +Monfort/M +Mongol/SM +Mongolia/M +Mongolian/S +Mongolic/M +Mongoloid/S +Monica/M +Monika/M +Monique/M +Monk/M +Monmouth/M +Monongahela/M +Monro/M +Monroe/M +Monrovia/M +Monsanto/M +Monsignor/MS +Monsignori +Mont/M +Montague/M +Montaigne/M +Montana/M +Montanan/MS +Montcalm/M +Montclair/M +Monte/M +Montenegrin +Montenegro/M +Monterey/M +Monterrey/M +Montesquieu/M +Montessori/M +Monteverdi/M +Montevideo/M +Montezuma +Montgomery/M +Monti/M +Monticello/M +Montmartre/M +Montoya/M +Montpelier/M +Montrachet/M +Montreal/M +Montserrat/M +Monty/M +Moody/M +Moog +Moon/M +Mooney/M +Moor/MS +Moore/M +Moorish +Mora/M +Morales/M +Moran/M +Moravia/M +Moravian +Mord/M +Mordecai/M +Mordred/M +Mordy/M +More/M +Moreen/M +Morehouse/M +Moreland/M +Morena/M +Moreno/M +Morey/M +Morgan/MS +Morgana/M +Morganica/M +Morganne/M +Morgen/M +Morgun/M +Moria/M +Moriarty/M +Morie/M +Morin/M +Morison/M +Morissa/M +Morita/M +Moritz/M +Morlee/M +Morley/M +Morly/M +Mormon/SM +Mormonism/MS +Morna/M +Moro/M +Moroccan/S +Morocco/M +Moroni/M +Morpheus/M +Morrie/M +Morris/M +Morrison/M +Morristown/M +Morrow/M +Morry/M +Morse/M +Mort/MN +Morten/M +Mortie/M +Mortimer/M +Morton/M +Morty/M +Mosaic +Moscone/M +Moscow/M +Mose/MSR +Moseley/M +Moselle/M +Moser/M +Moshe/M +Moslem's +Mosley/M +Moss/M +Mossberg/M +Mosul/M +Motorola/M +Motown/M +Mott/M +Mount/M +Mountbatten/M +Mountie/SM +Moussorgsky/M +Mouthe/M +Mouton/M +Mowgli/M +Moyer/M +Moyna/M +Moyra/M +Mozambican/S +Mozambique/M +Mozart/M +Mozelle/M +Mozes/M +Mozilla/M +Mr/M +Mrs +Ms/S +Msgr/M +Mt/M +Muawiya/M +Mubarak/M +Mueller/M +Muenster +Muffin/M +Mufi/M +Mufinella/M +Mugabe/M +Muhammad/M +Muhammadan/SM +Muhammadanism/S +Muir/M +Muire/M +Mukden/M +Mulder/M +Mullen/M +Muller/M +Mulligan/M +Mullikan/M +Mullins +Multan/M +Multibus/M +Multics/M +Mumford/M +Munch/M +Muncie/M +Mundt/M +Munich/M +Munmro/M +Munoz/M +Munro/M +Munroe/M +Munsey/M +Munson/M +Munster/MS +Muong/M +Muppet/M +Murasaki/M +Murat/M +Murchison/M +Murcia/M +Murdoch/M +Murdock/M +Mureil/M +Murial/M +Muriel/M +Murielle/M +Murillo/M +Murmansk/M +Murphy/M +Murray/M +Murrow/M +Murrumbidgee/M +Murry/M +Murvyn/M +Muscat/M +Muscovite/M +Muscovy/M +Muse/M +Musial/M +Muskegon/M +Muslim/MS +Mussolini/MS +Mussorgsky/M +Mutsuhito/M +Muzak/SM +Muzo/M +My/M +Myanmar +Myca/M +Mycah/M +Mycenae/M +Mycenaean +Mychal/M +Myer/MS +Mylar/S +Myles/M +Mylo/M +Mynheer/M +Myra/M +Myrah/M +Myranda/M +Myrdal/M +Myriam/M +Myrilla/M +Myrle/M +Myrlene/M +Myrna/M +Myron/M +Myrta/M +Myrtia/M +Myrtice/M +Myrtie/M +Myrtle/M +Myrvyn/M +Myrwyn/M +Mysore/M +Myst/M +M�nchhausen/M +N +N'Djamena +N's +NAACP +NASA/MS +NASDAQ +NATO/SM +NB +NBA +NBC +NBS +NC +NCAA +NCC +NCO +NCR +ND +NE +NF +NFC +NFL +NFS +NH +NHL +NIH +NIMBY +NJ +NLRB +NM +NOAA +NORAD/M +NOW +NP +NRA +NS +NSF +NT +NV +NW +NWT +NY +NYC +NYSE +NZ +Na/M +NaCl/M +Nabisco/M +Nabokov/M +Nada/M +Nadean/M +Nadeen/M +Nader/M +Nadia/M +Nadine/M +Nadiya/M +Nady/M +Nadya/M +Nagasaki/M +Nagoya/M +Nagpur/M +Nagy/M +Nahuatl/SM +Nahum/M +Naipaul/M +Nair/M +Nairobi/M +Naismith/M +Nakamura/M +Nakayama/M +Nakoma/M +Nalani/M +Nam/M +Namath/M +Namibia/M +Namibian/S +Nan/M +Nana/M +Nanak/M +Nananne/M +Nance/M +Nancee/M +Nancey/M +Nanchang/M +Nanci/M +Nancie/M +Nancy/M +Nanete/M +Nanette/M +Nani/M +Nanice/M +Nanine/M +Nanjing +Nanking's +Nannette/M +Nanni/M +Nannie/M +Nanny/M +Nanon/M +Nanook/M +Nansen/M +Nantes/M +Nantucket/M +Naoma/M +Naomi/M +Nap/M +Naphtali/M +Napier/M +Naples/M +Napoleon/MS +Napoleonic +Nappie/M +Nappy/M +Nara/M +Narbonne/M +Narcissus/M +Nari/M +Nariko/M +Narmada/M +Narragansett/M +Nash/M +Nashua/M +Nashville/M +Nassau/M +Nasser/M +Nat/M +Nata/M +Natal/M +Natala/M +Natale/M +Natalee/M +Natalia/M +Natalie/M +Natalina/M +Nataline/M +Natalya/M +Nataniel/M +Natasha/M +Natassia/M +Natchez +Nate/XMN +Nathalia/M +Nathalie/M +Nathan/MS +Nathanael/M +Nathanial/M +Nathaniel/M +Nathanil/M +Natividad/M +Nativity/M +Natka/M +Natty/M +Naugahyde/S +Naur/M +Nauru/M +Navaho's +Navajo/S +Navajoes +Navarro/M +Navona/M +Navratilova/M +Navy/S +Nazarene/MS +Nazareth/M +Nazi/SM +Nazism/S +Nb/M +Nd/M +Ndjamena/M +Ne +NeWS/M +Neal/M +Neala/M +Neale/M +Neall/M +Nealon/M +Nealson/M +Nealy/M +Neanderthal/S +Neapolitan/SM +Neb/M +Nebr/M +Nebraska/M +Nebraskan/MS +Nebuchadnezzar/MS +Ned/M +Neda/M +Nedda/M +Neddie/M +Neddy/M +Nedi/M +Needham/M +Neel/M +Neely/M +Nefen/M +Nefertiti/M +Negev/M +Negress/MS +Negritude/S +Negro/M +Negroes +Negroid/S +Nehemiah/M +Nehru/M +Neil/SM +Neila/M +Neile/M +Neill/M +Neilla/M +Neille/M +Nelda/M +Nelia/M +Nelie/M +Nell/M +Nelle/M +Nelli/M +Nellie/M +Nelly/M +Nels/N +Nelsen/M +Nelson/M +Nembutal/M +Nemesis/M +Neogene +Neolithic/M +Nepal/M +Nepalese +Nepali/MS +Neptune/M +Nereid/M +Nerf/M +Nerissa/M +Nerita/M +Nero/M +Neron/M +Nert/M +Nerta/M +Nerte/M +Nerti/M +Nertie/M +Nerty/M +Neruda/M +Nessa/M +Nessi/M +Nessie/M +Nessy/M +Nesta/M +Nester/M +Nestle/M +Nestor/M +Nestorius/M +Netherlander/SM +Netherlands/M +Netscape/M +Netta/M +Netti/M +Nettie/M +Nettle/M +Netty/M +Netzahualcoyotl/M +Neumann/M +Nev/M +Neva/M +Nevada/M +Nevadan/S +Nevadian/S +Nevil/M +Nevile/M +Neville/M +Nevin/SM +Nevis/M +Nevsa/M +Nevsky/M +Newark/M +Newbury/M +Newburyport/M +Newcastle/M +Newell/M +Newfoundland/SRMZ +Newfoundlander/M +Newman/M +Newport/M +Newsweek/MY +Newsweekly/M +Newton/M +Newtonian +Nexis/M +Neysa/M +Ngaliema/M +Nguyen/M +Ni/M +Niagara/M +Nial/M +Niall/M +Niamey/M +Nibelung/M +Nicaean +Nicaragua/M +Nicaraguan/S +Niccolo/M +Nice/M +Nicene +Nichol/MS +Nicholas +Nichole/M +Nicholle/M +Nicholson/M +Nick/M +Nickey/M +Nicki/M +Nickie/M +Nicklaus/M +Nicko/M +Nickola/MS +Nickolai/M +Nickolaus/M +Nicky/M +Nico/M +Nicobar/M +Nicodemus/M +Nicol/M +Nicola/MS +Nicolai/MS +Nicole/M +Nicolea/M +Nicolette/M +Nicoli/MS +Nicolina/M +Nicoline/M +Nicolle/M +Nicosia/M +Niebuhr/M +Niel/MS +Niels/N +Nielsen/M +Nielson/M +Nietzsche/M +Nieves/M +Nigel/M +Niger/M +Nigeria/M +Nigerian/S +Nigerien +Nightingale/M +Nijinsky/M +Nikaniki/M +Nike/M +Niki/M +Nikita/M +Nikki/M +Nikkie/M +Nikko/M +Niko/MS +Nikola/MS +Nikolai/M +Nikolaos/M +Nikolaus/M +Nikolayev's +Nikoletta/M +Nikolia/M +Nikolos/M +Nikon/M +Nil/MS +Nile/SM +Nils/N +Nilsen/M +Nilson/M +Nilsson/M +Nimitz/M +Nimrod/MS +Nina/M +Ninetta/M +Ninette/M +Nineveh/M +Ninnetta/M +Ninnette/M +Ninon/M +Nintendo/M +Niobe/M +Nippon/M +Nipponese +Nirenberg/M +Nirvana/S +Nisei/MS +Nissa/M +Nissan/M +Nisse/M +Nissie/M +Nissy/M +Nita/M +Niven/M +Nixie/M +Nixon/M +Nkrumah/M +No/M +NoDoz/M +Noach/M +Noah/M +Noak/M +Noam/M +Noami/M +Nobe/M +Nobel/M +Nobelist/SM +Nobie/M +Noble/M +Noby/M +Noe/M +Noel/MS +Noelani/M +Noell/M +Noella/M +Noelle/M +Noellyn/M +Noelyn/M +Noemi/M +Nola/M +Nolan/M +Nolana/M +Noland/M +Nolie/M +Noll/M +Nollie/M +Nolly/M +Nome/M +Nomi/M +Nona/M +Nonah/M +Noni/M +Nonie/M +Nonna/M +Nonnah/M +Nora/M +Norah/M +Norbert/M +Norberto/M +Norbie/M +Norby/M +Nordhoff/M +Nordic/S +Nordstrom/M +Norean/M +Noreen/M +Norene/M +Norfolk/M +Norina/M +Norine/M +Norma/M +Norman/SM +Normand/M +Normandy/M +Normie/M +Normy/M +Norplant +Norri/SM +Norrie/M +Norristown/M +Norry/M +Norse +Norseman/M +Norsemen +North/M +Northampton/M +Northeast/SM +Northerner/M +Northfield/M +Northrop/M +Northrup/M +Norths +Northumberland/M +Northwest/MS +Norton/M +Norw/M +Norwalk/M +Norway/M +Norwegian/S +Norwich/M +Nosferatu/M +Nostradamus/M +Nostrand/M +Notre/M +Nottingham/M +Nouakchott/M +Noumea/M +Nov/M +Nova/M +Novak/M +Novelia/M +Novell/SM +November/SM +Novgorod/M +Novocain/S +Novocaine/M +Novokuznetsk/M +Novosibirsk/M +Nowell/M +Noyce/M +Noyes/M +Np +Nubia/M +Nubian/M +Nugent/M +Nukualofa +Numbers/M +Nunavut/M +Nunez/M +Nunki/M +Nuremberg/M +Nureyev/M +Nutrasweet/M +Nyasa/M +Nydia/M +Nye/M +Nyerere/M +Nyquist/M +Nyssa/M +O +O'Brien/M +O'Casey +O'Clock +O'Connell/M +O'Connor/M +O'Dell/M +O'Donnell/M +O'Dwyer/M +O'Er +O'Hara +O'Hare/M +O'Higgins +O'Keeffe +O'Leary/M +O'Neil +O'Neill +O'Shea/M +O'Sullivan/M +OAS +OB +OCR +OD +ODs +OE +OED +OEM/M +OEMS +OH +OHSA/M +OJ +OK/MDG +OKs +ON +OOo/M +OPEC +OR +OS/M +OSHA +OT +OTB +OTC +OTOH +Oahu/M +Oakland/M +Oakley/M +Oakmont/M +Oates/M +Oaxaca/M +Ob/MD +Obadiah/M +Obadias/M +Obed/M +Obediah/M +Oberlin/M +Oberon/M +Obidiah/M +Obie/M +Oby/M +Occam/M +Occident/SM +Occidental/S +Oceania/M +Oceanside/M +Oceanus/M +Ochoa/M +Oconomowoc/M +Oct/M +Octavia/M +Octavian/M +Octavio/M +Octavius/M +October/MS +Ode/MR +Odele/M +Odelia/M +Odelinda/M +Odell/M +Odella/M +Odelle/M +Oder/M +Oderberg/MS +Odessa/M +Odets/M +Odetta/M +Odette/M +Odey/M +Odie/M +Odilia/M +Odille/M +Odin/M +Odis/M +Odo/M +Odom/M +Ody/M +Odysseus/M +Odyssey/M +Oedipal/Y +Oedipus/M +Oersted/M +Ofelia/M +Ofella/M +Offenbach/M +Ofilia/M +Ogbomosho/M +Ogdan/M +Ogden/M +Ogdon/M +Ogilvy/M +Oglethorpe/M +Ohio/M +Ohioan/S +Oise/M +Ojibwa/SM +Okamoto/M +Okayama/M +Okeechobee/M +Okefenokee +Okhotsk/M +Okinawa/M +Okinawan/S +Okla/M +Oklahoma/M +Oklahoman/SM +Oktoberfest +Ola/M +Olaf/M +Olag/M +Olav/M +Oldenburg/M +Oldfield/M +Oldsmobile/M +Olduvai/M +Ole/MV +Oleg/M +Olen/M +Olenek/M +Olenka/M +Olenolin/M +Olga/M +Olia/M +Oligocene +Olimpia/M +Olin/M +Olive/MZR +Oliver/M +Olivero/M +Olivette/M +Olivetti/M +Olivia/M +Olivie/RM +Olivier/M +Oliviero/M +Oliy/M +Ollie/M +Olly/M +Olmec +Olmsted/M +Olsen/M +Olson/M +Olva/M +Olvan/M +Olwen/M +Olympe/M +Olympia/SM +Olympiad/MS +Olympian/S +Olympic/S +Olympie/M +Olympus/M +Omaha/SM +Oman/M +Omar/M +Omdurman/M +Omero/M +Omnipotent +Omsk/M +Onassis/M +Ondrea/M +Oneal/M +Onega/M +Onegin/M +Oneida/SM +Onfre/M +Onfroi/M +Onida/M +Ono/M +Onofredo/M +Onondaga/MS +Onsager/M +Ont/M +Ontarian/S +Ontario/M +Oona/M +Oort/M +Opal/M +Opalina/M +Opaline/M +Opel/M +OpenOffice.org/M +Ophelia/M +Ophelie/M +Ophiuchus/M +Oppenheimer/M +Oprah/M +Ora/M +Oralee/M +Oralia/M +Oralie/M +Oralla/M +Oralle/M +Oran/M +Orange/M +Oranjestad/M +Orazio/M +Orbadiah/M +Ordovician +Ore/NM +Oreg/M +Oregon/M +Oregonian/S +Orel/M +Orelee/M +Orelia/M +Orelie/M +Orella/M +Orelle/M +Oren/M +Oreo +Orestes +Oriana/M +Orient/SM +Oriental/S +Orin/M +Orinoco/M +Orion/M +Oriya/M +Orizaba/M +Orkney/M +Orlan/M +Orland/M +Orlando/M +Orleans +Orlick/M +Orlon/SM +Orly/M +Orono/M +Orpheus/M +Orphic +Orr/MN +Orran/M +Orren/M +Orrin/M +Orsa/M +Orsola/M +Orson/M +Ortega/M +Ortensia/M +Orthodox/S +Ortiz/M +Orton/M +Orv/M +Orval/M +Orville/M +Orwell/M +Orwellian +Os/M +Osage/SM +Osaka/M +Osbert/M +Osborn/M +Osborne/M +Osbourn/M +Osbourne/M +Oscar/SM +Osceola/M +Osgood/M +Oshawa/M +Oshkosh/M +Osiris/M +Oslo/M +Osman/M +Osmond/M +Osmund/M +Ossie/M +Ostrander/M +Ostrogoth/M +Ostwald/M +Osvaldo/M +Oswald/M +Oswell/M +Otes +Otha/M +Othelia/M +Othella/M +Othello/M +Othilia/M +Othilie/M +Otho/M +Otis/M +Ottawa/MS +Ottilie/M +Otto/M +Ottoman +Ouagadougou/M +Ouija/MS +Ovid/M +Owen/MS +Oxford/MS +Oxnard +Oxonian +Oxus/M +Oz/M +Ozark/SM +Ozymandias/M +Ozzie/M +Ozzy/M +P +P's +PA +PAC +PARC/M +PASCAL +PBS +PBX +PC/M +PCB +PCP +PCs +PD +PDP +PDQ +PDT +PE +PET +PFC +PG +PIN +PJ's +PLO +PM +PMS +PO +POW +PP +PPS +PR +PRC +PRO +PS +PST +PT +PTA +PTO +PVC +PW +PX +Pa/M +Pablo/M +Pablum/M +Pabst/M +Pace/M +Pacheco/M +Pacific/M +Packard/SM +Packston/M +Packwood/M +Paco/M +Pacorro/M +Padang/M +Paddie/M +Paddy/M +Padget/M +Padgett/M +Padilla/M +Padraic/M +Padraig/M +Padrewski/M +Padriac/M +Paganini/M +Page/M +Paglia/M +Pahlavi/M +Paige/M +Pail/M +Paine/M +Pakistan/M +Pakistani/S +Palatine +Palembang/M +Paleocene +Paleogene +Paleolithic +Paleozoic +Palermo/M +Palestine/M +Palestinian/S +Palestrina/M +Paley/M +Palisades/M +Pall/M +Palladio/M +Palm/MR +Palmer/M +Palmerston/M +Palmolive/M +Palmyra/M +Palo/M +Paloma/M +Palomar/M +Pam/M +Pamela/M +Pamelina/M +Pamella/M +Pamirs +Pammi/M +Pammie/M +Pammy/M +Pampers +Pan/M +Panama/MS +Panamanian/S +Panchito/M +Pancho/M +Pandora/M +Pangaea/M +Pankhurst/M +Panmunjom/M +Pansie/M +Pansy/M +Pantagruel/M +Pantaloon/M +Panza/M +Paola/M +Paoli/M +Paolina/M +Paolo/M +Papagena/M +Papageno/M +Pappas/M +Paquito/M +Paracelsus/M +Paraclete/M +Paradise/M +Paraguay/M +Paraguayan/S +Paramaribo/M +Paramus/M +Paran� +Parcheesi/M +Pareto/M +Paris/M +Parisian/SM +Park/RMS +Parke/M +Parker/M +Parkersburg/M +Parkhouse/M +Parkinson/M +Parkman +Parliament/MS +Parmesan/S +Parnassus/SM +Parnell/M +Parr/M +Parrish/M +Parrnell/M +Parry/M +Parsee's +Parsifal/M +Parsons/M +Parthenon/M +Parthia/M +Pasadena/M +Pascal/M +Pascale/M +Paso/M +Pasquale/M +Passaic/M +Passion/SM +Passover/MS +Pasternak/M +Pasteur/M +Pat/MN +Patagonia/M +Patagonian/S +Pate/M +Patel/M +Paten/M +Paterson/M +Patience/M +Patin/M +Patna/M +Paton/M +Patric/M +Patrica/M +Patrice/M +Patricia/M +Patricio/M +Patrick/M +Patrizia/M +Patrizio/M +Patrizius/M +Patsy/SM +Patten/M +Patterson/M +Patti/M +Pattie/M +Pattin/M +Patton/M +Patty/M +Paul/MG +Paula/M +Paule/M +Pauletta/M +Paulette/M +Pauli/M +Paulie/M +Paulina/M +Pauline +Pauling/M +Paulita/M +Paulo/M +Paulsen/M +Paulson/M +Paulus/M +Pauly/M +Pavarotti +Pavel/M +Pavia/M +Pavla/M +Pavlov/M +Pavlova/MS +Pavlovian +Pawnee/SM +Pawtucket/M +Paxon/M +Paxton/M +Payne/SM +Payson/M +Payton/M +Paz/M +Pb/M +Pd/M +Peabody/M +Peace/M +Peachtree/M +Peadar/M +Peale/M +Pearce/M +Pearl/M +Pearla/M +Pearle/M +Pearlie/M +Pearline/M +Pearson/M +Peary/M +Pebrook/M +Pechora/M +Peck/M +Peckinpah/M +Pecos/M +Peder/M +Pedro/M +Peel/M +Peg/M +Pegasus/MS +Pegeen/M +Peggi/M +Peggie/M +Peggy/M +Pei/M +Peiping/M +Peirce/M +Pekinese's +Peking/SM +Pekingese/SM +Pele/M +Pelee/M +Pelham/M +Peloponnese/M +Pembroke/M +Pen/M +Pena/M +Penderecki/M +Pendleton/M +Penelopa/M +Penelope/M +Penn/M +Penna +Penney/M +Penni/M +Pennie/M +Pennington/M +Pennsylvania/M +Pennsylvanian/S +Penny/M +Penrod/M +Pensacola/M +Pentagon/M +Pentateuch/M +Pentecost/SM +Pentecostal/S +Pentecostalism/S +Pentium/M +Peoria/M +Pepe/M +Pepi/M +Pepillo/M +Pepin/M +Pepita/M +Pepito/M +Pepsi/M +PepsiCo/M +Pepsico/M +Pepys/M +Pequot/M +Perceval/M +Percival/M +Percy/M +Perelman/M +Perez/M +Pergamon/M +Peri/M +Peria/M +Perice/M +Periclean +Pericles/M +Perilla/M +Perkin/SM +Perl/M +Perla/M +Perle/M +Perm/M +Permalloy/M +Permian +Pernell/M +Pernod/M +Peron/M +Perot/M +Perren/M +Perri/M +Perrine/M +Perry/MR +Perseid/M +Persephone/M +Perseus/M +Pershing/M +Persia/M +Persian/S +Persis/M +Perth/M +Peru/M +Peruvian/S +Peshawar/M +Pet/MRZ +Peta/M +Pete/M +Peter/M +Peters/N +Petersburg/M +Petersen/M +Peterson/M +Peterus/M +Petey/M +Petkiewicz/M +Petr/M +Petra/M +Petrarch/M +Petrina/M +Petronella/M +Petronia/M +Petronilla/M +Petronille/M +Pettibone/M +Petty/M +Petunia/M +Peugeot/M +Pewaukee/M +Peyter/M +Peyton/M +Pfc +Pfizer/M +Ph/M +PhD +Phaedra/M +Phaethon/M +Phaidra/M +Phanerozoic +Pharaoh/M +Pharaohs +Pharisaic +Pharisaical +Pharisee/SM +Phebe/M +Phedra/M +Phekda/M +Phelia/M +Phelps/M +Phidias/M +Phil/MY +Philadelphia/M +Philbert/M +Philco/M +Philip/M +Philipa/M +Philippa/M +Philippe/M +Philippians/M +Philippine/SM +Philis/M +Philistine/SM +Phillida/M +Phillie/M +Phillip/MS +Phillipa/M +Phillipe/M +Phillipp/M +Phillis/M +Philly/SM +Philomena/M +Phineas/M +Phip/M +Phipps/M +Phobos/M +Phoebe/M +Phoenicia/M +Phoenician/SM +Phoenix/M +Photostat/MS +Photostatted +Photostatting +Phylis/M +Phyllida/M +Phyllis/M +Phyllys/M +Phylys/M +Pia/M +Piaf/M +Piaget/M +Pianola/M +Picasso/M +Piccadilly/M +Pickering/M +Pickett/M +Pickford/M +Pickman/M +Pickwick/M +Pict/M +Piedmont/M +Pier/M +Pierce/M +Pierette/M +Pierre/M +Pierrette/M +Pierrot/M +Pierson/M +Pieter/M +Pietra/M +Pietrek/M +Pietro/M +Piggy/M +Pigmy's +Pike/M +Pilate/M +Pilcomayo/M +Pilgrim +Pillsbury/M +Pinatubo/M +Pincas/M +Pinchas/M +Pincus/M +Pindar/M +Pinehurst/M +Pinkerton/M +Pinocchio/M +Pinochet/M +Pinsky/M +Pinter/M +Pinyin +Piotr/M +Pip/MR +Piper/M +Pipestone/M +Pippa/M +Pippo/M +Pippy/M +Piraeus/M +Pirandello/M +Pisa/M +Pisces/M +Pisistratus/M +Pissaro/M +Pitcairn/M +Pitney/M +Pitt/SM +Pittman/M +Pittsburgh/ZM +Pittsfield/M +Pittston/M +Pius/M +Pizarro/M +Pkwy +Plainfield/M +Plainview/M +Planck/M +Plano +Plantagenet/M +Plasticine/M +Plath/M +Plato/M +Platonic +Platonism/M +Platonist +Platte/M +Platteville/M +Plautus/M +Playboy/M +Playtex/M +Pleiads +Pleistocene +Plexiglas/MS +Pliny/M +Pliocene/S +Plutarch/M +Pluto/M +Plymouth/M +Pm/M +Po/M +Pocahontas/M +Pocono/MS +Podgorica/M +Podunk/M +Poe/M +Pogo/M +Poincar�/M +Poindexter/M +Poisson/M +Pokemon/M +Pol/MY +Poland/M +Polanski/M +Polaris/M +Polaroid/SM +Pole/MS +Polish +Politburo/M +Polk/M +Pollard/M +Pollock/SM +Pollux/M +Polly/M +Pollyanna/M +Polo/M +Polyhymnia/M +Polynesia/M +Polynesian/S +Polyphemus/M +Pomerania/M +Pomeranian +Pomona/M +Pompadour/M +Pompeian/S +Pompeii/M +Pompey/M +Ponce/M +Ponchartrain/M +Pontchartrain/M +Pontiac/M +Pontianak/M +Pooh/M +Poole/M +Poona/M +Pope/SM +Popek/MS +Popeye/M +Popocatepetl/M +Popper/M +Poppins/M +Poppy/M +Popsicle/MS +Porfirio/M +Porrima/M +Porsche/M +Port/MR +Porte/M +Porter/M +Portia/M +Portie/M +Portland/M +Portsmouth/M +Portugal/M +Portuguese/M +Porty/M +Poseidon/M +Posner/M +Post/M +Potemkin/M +Potomac/M +Potsdam/M +Pottawatomie/M +Potter/M +Potts/M +Poughkeepsie/M +Poul/M +Pound/M +Poussin/MS +Powell/M +Powers +Powhatan/M +Poznan/M +Pr/MN +Pradesh/M +Prado/M +Praetorian +Prague/M +Praia +Prakrit/M +Pratchett/M +Pratt/M +Prattville/M +Pravda/M +Praxiteles/M +Preakness/M +Precambrian +Preminger/M +Pren/M +Prent/M +Prentice/MGD +Prenticed/M +Prenticing/M +Prentiss/M +Pres +Presbyterian/S +Presbyterianism/S +Prescott/M +Presley/M +Preston/M +Pretoria/M +Priam/M +Pribilof/M +Price/M +Priestley/M +Prime's +Prince/M +Princeton/M +Principe/M +Principia/M +Prinz/M +Pris +Prisca/M +Priscella/M +Priscilla/M +Prissie/M +Procrustean +Procrustes/M +Procyon/M +Prof +Prohibition/MS +Prokofieff/M +Prokofiev/M +Promethean +Prometheus/M +Proserpine/M +Protagoras/M +Proterozoic/M +Protestant/SM +Protestantism/MS +Proteus/M +Proudhon/M +Proust/M +Provencals +Provence/M +Proven�al +Proverbs/M +Providence/SM +Provo/M +Proxmire/M +Prozac +Pru/M +Prudence/M +Prudential/M +Prudi/M +Prudy/M +Prue/M +Pruitt/M +Prussia/M +Prussian/S +Prut/M +Pryce/M +Psalms/M +Psalter/SM +Psyche/M +Pt/M +Ptah/M +Ptolemaic +Ptolemaists +Ptolemy/MS +Pu +Puccini/M +Puck/M +Puckett/M +Puebla/M +Pueblo/MS +Puerto/M +Puff/M +Puget/M +Pugh/M +Pulaski/SM +Pulitzer/SM +Pullman/MS +Punch/M +Punic +Punjab/M +Punjabi/M +Purcell/M +Purdue/M +Purim/SM +Purina/M +Puritan/SM +Puritanism/MS +Purus +Pusan/M +Pusey/M +Pushkin/M +Pushtu/M +Putin/M +Putnam/M +Putnem/M +Pvt/M +Pygmalion/M +Pygmy/SM +Pyhrric/M +Pyle/M +Pym/M +Pynchon/M +Pyongyang/M +Pyotr/M +Pyrenees +Pyrex/SM +Pyrrhic +Pythagoras/M +Pythagorean/S +Pythias +Python/M +P�tain/M +P�rto/M +Q +Q's +QA +QB +QC +QED +QM +Qaddafi/M +Qantas/M +Qatar/M +Qingdao +Qiqihar/M +Qom/M +Quaalude/M +Quaker/SM +Quakeress/M +Quakerism/S +Quantico/M +Quasimodo/M +Quaternary +Quayle/M +Que/M +Quebec/M +Quechua/M +Queen/SM +Queenie/M +Queensland/M +Quent/M +Quentin/M +Querida/M +Quetzalcoatl/M +Quezon/M +Quill/M +Quillan/M +Quincey/M +Quincy/M +Quinlan/M +Quinn/M +Quint/M +Quinta/M +Quintana/M +Quintilian/M +Quintilla/M +Quintin/M +Quintina/M +Quinton/M +Quintus/M +Quirinal/M +Quisling/M +Quito/M +Quixote/M +Quixotism/M +Quonset +R's +R/G +RAF +RAM/S +RBI/S +RC +RCA +RCS +RD +RDA +REIT +REM/S +RF +RFC +RFD +RI +RIP +RISC +RMS +RN +RNA +ROFL +ROM +ROTC +RP +RPM +RR +RSFSR +RSI +RSV +RSVP +RSX +RTFM +RV +RVs +Ra/M +Rab/M +Rabat/M +Rabbi/M +Rabelais/M +Rabelaisian +Rabi/M +Rabin/M +Rachael/M +Rachel/M +Rachele/M +Rachelle/M +Rachmaninoff/M +Racine/M +Rad/M +Radcliffe/M +Raddie/M +Raddy/M +Rae/M +Raeann/M +Raf/M +Rafa/M +Rafael/M +Rafaela/M +Rafaelia/M +Rafaelita/M +Rafaellle/M +Rafaello/M +Rafe/M +Raff/M +Raffaello/M +Raffarty/M +Rafferty/M +Rafi/M +Ragnar/M +Ragnar�k +Rahal/M +Rahel/M +Raimondo/M +Raimund/M +Raimundo/M +Raina/M +Raine/MR +Rainer/M +Rainier/M +Rajive/M +Rakel/M +Raleigh/M +Ralf/M +Ralina/M +Ralph/M +Ralston/M +Ram/M +Rama/M +Ramada/M +Ramadan/SM +Ramakrishna/M +Raman/M +Ramayana/M +Rambo/M +Ramirez/M +Ramiro/M +Ramo/MS +Ramon/M +Ramona/M +Ramonda/M +Ramsay/M +Ramses/M +Ramsey/M +Rana/M +Rance/M +Rancell/M +Rand/M +Randa/M +Randal/M +Randall/M +Randee/M +Randell/M +Randene/M +Randi/M +Randie/M +Randolf/M +Randolph/M +Randy/M +Ranee/M +Rangoon/M +Rani/MR +Rania/M +Ranice/M +Ranier/M +Ranique/M +Rankin/M +Rankine/M +Ranna/M +Ransell/M +Ransom/M +Raoul/M +Raphael/M +Raphaela/M +Rapunzel/M +Raquel/M +Raquela/M +Rasalgethi/M +Rasalhague/M +Rasia/M +Rasla/M +Rasmussen/M +Rasputin/M +Rastaban/M +Rastafarian/M +Rastus/M +Ratfor/M +Rather/M +Ratliff/M +Raul/M +Ravel/M +Raven/M +Ravi/M +Ravid/M +Raviv/M +Rawalpindi/M +Rawley/M +Rawlings/M +Rawlins/M +Rawlinson/M +Rawson/M +Ray/M +Rayburn/M +Raychel/M +Raye/M +Rayleigh/M +Raymond/M +Raymondville/M +Raymund/M +Raymundo/M +Rayna/M +Raynard/M +Raynell/M +Rayner/M +Raynor/M +Rayshell/M +Raytheon/M +Rb +Rd/M +Re/M +Rea/M +Read/GM +Reade/M +Reading/M +Reagan/M +Reagen/M +Realtor/S +Reamonn/M +Reasoner/M +Reba/M +Rebbecca/M +Rebe/M +Rebeca/M +Rebecca's +Rebecka/M +Rebeka/M +Rebekah/M +Rebekkah/M +Recife/M +Reconstruction/M +Redd/M +Redeemer/M +Redford/M +Redgrave/M +Redhook/M +Redmond/M +Redondo/M +Redstone/M +Ree/MDS +Reeba/M +Reebok/M +Reece/M +Reed/M +Reedville/M +Reena/M +Reese/M +Reeta/M +Reeva/M +Reeves +Refugio/M +Reg/MN +Regan/M +Regen/M +Reggi/MS +Reggie/M +Reggy/M +Regina/M +Reginae +Reginald/M +Reginauld/M +Regine/M +Regis/M +Regor/M +Regulus/M +Rehnquist +Reich/M +Reichenberg/M +Reichstag's +Reichstags +Reid/MR +Reidar/M +Reider/M +Reiko/M +Reilly/M +Reina/M +Reinald/M +Reinaldo/MS +Reine/M +Reinhard/M +Reinhardt/M +Reinhold/M +Reinold/M +Reinwald/M +Rem/M +Remarque/M +Rembrandt/M +Remington/M +Remus/M +Remy/M +Rena/M +Renado/M +Renae/M +Renaissance/SM +Renaldo/M +Renard/M +Renascence/SM +Renata/M +Renate/M +Renato/M +Renaud/M +Renault/MS +Rene/M +Renee/M +Renell/M +Renelle/M +Renie/M +Rennie/M +Reno/M +Renoir/M +Rensselaer/M +Renville/M +Rep/M +Representative/S +Republican/S +Republicanism/S +Requiem/MS +Resistance/SM +Restoration/M +Reta/M +Retha/M +Reub/NM +Reube/M +Reuben/M +Reunion/M +Reuters +Reuther/M +Reuven/M +Rev/M +Reva/M +Revelation/MS +Revere/M +Reverend +Revkah/M +Revlon/M +Rex/M +Rey/M +Reyes +Reykjavik/M +Reyna/M +Reynaldo/M +Reynard/M +Reynold/SM +Rf +Rh/M +Rhea/M +Rheba/M +Rhee/M +Rheims/M +Rheinholdt/M +Rhenish +Rheta/M +Rhett/M +Rhetta/M +Rhiamon/M +Rhianna/M +Rhiannon/M +Rhianon/M +Rhine/M +Rhineland/RM +Rhinelander/M +Rhoda/M +Rhodes +Rhodesia/M +Rhodesian/S +Rhodia/M +Rhodie/M +Rhody/M +Rhona/M +Rhonda/M +Rhone +Rhys/M +Riane/M +Riannon/M +Rianon/M +Ribbentrop/M +Ric/M +Rica/M +Rican/SM +Ricard/M +Ricardo/M +Ricca/M +Riccardo/M +Rice/M +Rich/M +Richard/MS +Richardo/M +Richardson/M +Richart/M +Richelieu/M +Richey/M +Richfield/M +Richie/M +Richland/M +Richmond/M +Richmound/M +Richter/M +Richthofen/M +Richy/M +Rici/M +Rick/M +Rickard/M +Rickenbacker/M +Rickenbaugh/M +Rickert/M +Rickey/M +Ricki/M +Rickie/M +Rickover/M +Ricky/M +Rico/M +Ricoriki/M +Riddle/M +Ride/M +Ridgefield/M +Ridgway/M +Riemann/M +Riesling/SM +Riga/M +Rigel/M +Riggs/M +Right/S +Rigoberto/M +Rigoletto/M +Rik/M +Riki/M +Rikki/M +Riley/M +Rilke/M +Rimbaud/M +Rina/M +Rinaldo/M +Rinehart/M +Ring/M +Ringling/M +Ringo/M +Rio/MS +Riobard/M +Riordan/M +Rip/M +Ripley/M +Risa/M +Rita/M +Ritalin +Ritchie/M +Ritter/M +Ritz/M +Riva/MS +Rivalee/M +Rivera/M +Rivers +Riverside/M +Riverview/M +Rivi/M +Riviera/MS +Rivkah/M +Rivy/M +Riyadh/M +Rn/M +Roach/M +Roana/M +Roanna/M +Roanne/M +Roanoke/M +Roarke/M +Rob/MZ +Robb/M +Robbert/M +Robbi/M +Robbie/M +Robbin/MS +Robby/M +Robbyn/M +Robena/M +Robenia/M +Robers/M +Roberson/M +Robert/MS +Roberta/M +Roberto/M +Robertson/SM +Robeson/M +Robespierre/M +Robin/M +Robina/M +Robinet/M +Robinett/M +Robinetta/M +Robinette/M +Robinia/M +Robinson/M +Robinsonville/M +Robles/M +Robson/M +Robt/M +Roby/M +Robyn/M +Rocco/M +Roch/M +Rocha/M +Rochambeau/M +Roche/M +Rochell/M +Rochella/M +Rochelle/M +Rochester/M +Rochette/M +Rock/M +Rockaway/MS +Rockefeller/M +Rockey/M +Rockford/M +Rockie/M +Rockland/M +Rockne/M +Rockville/M +Rockwell/M +Rocky/SM +Rod/M +Roda/M +Rodd/M +Roddenberry/M +Roddie/M +Roddy/M +Roderic/M +Roderich/M +Roderick/M +Roderigo/M +Rodge/ZMR +Rodger/M +Rodi/M +Rodie/M +Rodin/M +Rodina/M +Rodney/M +Rodolfo/M +Rodolph/M +Rodolphe/M +Rodrick/M +Rodrigo/M +Rodriguez/M +Rodrique/M +Rodriquez/M +Roentgen's +Rog/MRZ +Rogelio/M +Roger/M +Rogerio/M +Roget/M +Roi/SM +Rojas/M +Roland/M +Rolando/M +Roldan/M +Roley/M +Rolf/M +Rolfe/M +Rolland/M +Rollerblade/S +Rollie/M +Rollin/SM +Rollo/M +Rolodex +Rolph/M +Rolvaag/M +Rom/SM +Roma/M +Romain/M +Roman/SM +Romanesque/S +Romania/M +Romanian/SM +Romano/MS +Romanov/M +Romans/M +Romansh/M +Romanticism/S +Romany/SM +Rome/SM +Romeo/MS +Romero/M +Rommel/M +Romney/M +Romola/M +Romona/M +Romonda/M +Romulus/M +Romy/M +Ron/M +Rona/M +Ronald/M +Ronalda/M +Ronda/M +Ronica/M +Ronna/M +Ronni/M +Ronnica/M +Ronnie/M +Ronny/M +Ronstadt/M +Rontgen +Roobbie/M +Rooney/M +Roosevelt/M +Rooseveltian +Root/M +Roquefort/MS +Roquemore/M +Rora/M +Rori/M +Rorie/M +Rorke/M +Rorschach +Rory/M +Ros/N +Rosa/M +Rosabel/M +Rosabella/M +Rosabelle/M +Rosaleen/M +Rosales/M +Rosalia/M +Rosalie/M +Rosalind/M +Rosalinda/M +Rosalinde/M +Rosaline/M +Rosalyn/M +Rosalynd/M +Rosamond/M +Rosamund/M +Rosana/M +Rosanna/M +Rosanne/M +Rosario/M +Rosco/M +Roscoe/M +Rose/M +Roseann/M +Roseanna/M +Roseanne/M +Roseau +Rosecrans/M +Roseland/M +Roselia/M +Roselin/M +Roseline/M +Rosella/M +Roselle/M +Rosemaria/M +Rosemarie/M +Rosemary/M +Rosemonde/M +Rosen/M +Rosenberg/M +Rosenblum/M +Rosendo/M +Rosene/M +Rosenthal/M +Rosenzweig/M +Rosetta/M +Rosette/M +Roshelle/M +Rosicrucian/M +Rosie/M +Rosina/M +Rosita/M +Roslyn/M +Rosmunda/M +Ross +Rossetti/M +Rossi/M +Rossie/M +Rossini/M +Rossy/M +Rostand/M +Rostov/M +Roswell/M +Rosy/M +Rotarian/SM +Roth/M +Rothschild/M +Rotterdam/M +Rouault/M +Rourke/M +Rousseau/M +Rouvin/M +Rover/M +Row/MN +Rowan/M +Rowe/M +Rowen/M +Rowena/M +Rowland/M +Rowley/M +Rowney/M +Roxana/M +Roxane/M +Roxanna/M +Roxanne/M +Roxi/M +Roxie/M +Roxine/M +Roxy/M +Roy/M +Royal/M +Royall/M +Royce/M +Roz/M +Rozalie/M +Rozalin/M +Rozamond/M +Rozanna/M +Rozanne/M +Roze/M +Rozele/M +Rozella/M +Rozelle/M +Rozina/M +Rriocard/M +Rte +Ru/MH +Rubaiyat/M +Rube/M +Ruben/MS +Rubetta/M +Rubi/M +Rubia/M +Rubicon/SM +Rubie/M +Rubik/M +Rubin/M +Rubina/M +Rubinstein/M +Ruby/M +Ruchbah/M +Rudd/M +Ruddie/M +Ruddy/M +Rudie/M +Rudiger/M +Rudolf/M +Rudolfo/M +Rudolph/M +Rudy/M +Rudyard/M +Rufe/M +Rufus/M +Rugby's +Ruggiero/M +Ruhr/M +Ruiz/M +Rumania's +Rumanian's +Rumford/M +Rummel/M +Rumpelstiltskin/M +Runge/M +Runnymede/M +Runyon/M +Rupert/M +Ruperta/M +Ruperto/M +Ruppert/M +Ruprecht/M +Rurik/M +Rush/M +Rushdie/M +Rushmore/M +Ruskin/M +Russ/S +Russel/M +Russell/M +Russia/M +Russian/SM +Russo/M +Rustbelt/M +Rustie/M +Rustin/M +Rusty/M +Rutger/SM +Ruth/M +Ruthann/M +Ruthanne/M +Ruthe/M +Rutherford/M +Ruthi/M +Ruthie/M +Ruthy/M +Rutland/M +Rutledge/M +Rutter/M +Ruttger/M +Ruy/M +Rwanda/SM +Rwandan/S +Rwy/M +Rx/M +Ry/M +Ryan/M +Ryann/M +Rycca/M +Rydberg/M +Ryder/M +Ryley/M +Ryon/M +Ryukyu/M +Ryun/M +S +S's +SA +SAC +SALT +SAM +SASE +SAT +SBA +SC +SCCS +SCSI +SD +SDI +SE +SEATO +SEC +SF +SIDS +SIGGRAPH/M +SIMD +SIMULA/M +SJ +SK +SLR +SMSA/MS +SMTP +SO +SOP +SOS +SPARC/M +SPARCstation/M +SPCA +SPF +SPSS +SRO +SS +SSA +SSE +SSS +SST +SSW +ST +STD +STOL +SUV +SW +SWAK +SWAT +Saab/M +Saar/M +Saba/M +Sabbath/M +Sabbaths +Sabik/M +Sabin/M +Sabina/M +Sabine/M +Sabra/M +Sabrina/M +Sacajawea/M +Sacco/M +Sacha/M +Sachs/M +Sacramento/M +Sada/M +Sadat/M +Saddam/M +Sadducee/M +Sade/M +Sadella/M +Sadie/M +Sadr/M +Sadye/M +Sagan/M +Saginaw/M +Sagittarius/MS +Sahara/M +Saharan/M +Sahel +Saidee/M +Saigon/M +Saiph/M +Sakai/M +Sakhalin/M +Sakharov/M +Saki/M +Sal/MY +Saladin/M +Salado/M +Salaidh/M +Salas/M +Salazar/M +Saleem/M +Salem/M +Salerno/M +Salim/M +Salina/MS +Salinger/M +Salisbury/M +Salish/M +Salk/M +Salle/M +Sallee/M +Salli/M +Sallie/M +Sallust/M +Sally/M +Sallyann/M +Sallyanne/M +Salmon/M +Saloma/M +Salome/M +Salomi/M +Salomo/M +Salomon/M +Salomone/M +Salonika/M +Salton/M +Salvador/M +Salvadoran/S +Salvadorian/S +Salvatore/M +Salvidor/M +Salween/M +Salyut/M +Salz/M +Sam/M +Samantha/M +Samara/M +Samaria/M +Samaritan/MS +Samarkand/M +Sammie/M +Sammy/M +Samoa +Samoan/S +Samoset/M +Samoyed/M +Sampson/M +Samson/M +Samsonite/M +Samuel/SM +Samuele/M +Samuelson/M +San'a +San/M +Sana/M +Sanborn/M +Sanchez/M +Sancho/M +Sand/MRZ +Sandburg/M +Sande/M +Sander/M +Sanderling/M +Sanderson/M +Sandi/M +Sandia/M +Sandie/M +Sandinista +Sandor/M +Sandoval/M +Sandra/M +Sandro/M +Sandusky/M +Sandy/M +Sandye/M +Sanford/M +Sanforized +Sang/RM +Sanger/M +Sanhedrin/M +Sankara/M +Sanskrit/M +Sanskritic +Sanskritize/M +Sanson/M +Sansone/M +Santa/M +Santana/M +Santayana/M +Santeria +Santiago/M +Santo/MS +Sapphira/M +Sapphire/M +Sappho/M +Sapporo/M +Sara/M +Saraann/M +Saracen/MS +Saragossa/M +Sarah/M +Sarajane/M +Sarajevo/M +Saran/M +Sarasota/M +Saratoga/M +Saratov/M +Sarawak/M +Sardinia/M +Saree/M +Sarena/M +Sarene/M +Sarette/M +Sargasso/M +Sarge/M +Sargent/M +Sargon/M +Sari/M +Sarina/M +Sarine/M +Sarita/M +Sarnoff/M +Saroyan/M +Sarto/M +Sartre/M +Sascha/M +Sasha/M +Sashenka/M +Sask/M +Saskatchewan/M +Saskatoon/M +Sassoon/M +Sat/M +Satan/M +Satanism/M +Satanist/M +Saturday/MS +Saturn/M +Saturnalia/M +Satyanarayanan/M +Saud/M +Saudi/S +Saudra/M +Saukville/M +Saul/M +Sault/M +Sauncho/M +Saunder/SM +Saunderson/M +Saundra/M +Saussure/M +Sauternes/M +Sauveur/M +Savage/M +Savannah/M +Savina/M +Savior/M +Saviour/M +Savonarola/M +Savoy/M +Savoyard/M +Saw/M +Sawyer/M +Sawyere/M +Sax/M +Saxe/M +Saxon/SM +Saxony/M +Saxton/M +Say/ZMR +Sayer/M +Sayre/MS +Sb/M +Sc/M +Scala/M +Scan +Scandinavia/M +Scandinavian/S +Scaramouch/M +Scarborough/M +Scarface/M +Scarlatti/M +Scarlet/M +Scarlett/M +Schaefer/M +Schaeffer/M +Schafer/M +Schaffner/M +Schantz/M +Schapiro/M +Scheat/M +Schedar/M +Scheherazade/M +Scheherezade/M +Schelling/M +Schenectady/M +Schick/M +Schiller/M +Schlesinger/M +Schliemann/M +Schlitz/M +Schloss/M +Schmidt/M +Schmitt/M +Schnabel/M +Schneider/M +Schoenberg/M +Schofield/M +Schopenhauer/M +Schottky/M +Schrieffer/M +Schroeder/M +Schroedinger/M +Schr�dinger/M +Schubert/M +Schultz/M +Schulz/M +Schumacher/M +Schuman/M +Schumann/M +Schuster/M +Schuyler/M +Schuylkill/M +Schwab/M +Schwartz/M +Schwartzkopf/M +Schwarzenegger/M +Schweitzer/M +Schweppes/M +Schwinger/M +Schwinn/M +Scientology/M +Scipio/M +Scopes/M +Scorpio/SM +Scorpius/M +Scorsese/M +Scot/MS +Scotch/S +Scotchgard/M +Scotchman/M +Scotchmen +Scotchwoman +Scotchwomen +Scotia/M +Scotian/M +Scotland/M +Scotsman/M +Scotsmen +Scotswoman +Scotswomen +Scott/M +Scotti/M +Scottie/SM +Scottish +Scottsdale/M +Scotty's +Scout's +Scrabble/SM +Scranton/M +Scriabin/M +Scribner/MS +Scripps/M +Scripture/MS +Scrooge/MS +Scruggs/M +Scud/M +Sculley/M +Scylla/M +Scythia/M +Se/H +Seaborg/M +Seabrook/M +Seagate/M +Seagram/M +Seamus/M +Sean/M +Seana/M +Seaquarium/M +Sears/M +Seattle/M +Sebastian/M +Sebastiano/M +Sebastien/M +Seconal +Seder/SM +Sedgwick/M +See/M +Seebeck/M +Seeley/M +Segovia/M +Segre/M +Segundo/M +Seidel/M +Seiko/M +Seine/M +Seinfeld/M +Seka/M +Sela/M +Selassie/M +Selby/M +Selectric/M +Selena/M +Selene/M +Selestina/M +Seleucid/M +Seleucus/M +Selfridge/M +Selia/M +Selie/M +Selig/M +Selim/M +Selina/M +Selinda/M +Seline/M +Seljuk/M +Selkirk/M +Sella/M +Selle/ZM +Sellers/M +Selma/M +Selznick/M +Semarang/M +Seminole/SM +Semiramis/M +Semite/SM +Semitic/MS +Semtex +Sen +Sena/M +Senate/MS +Sendai/M +Seneca/MS +Senegal/M +Senegalese +Senior/S +Sennacherib/M +Sennett/M +Sensurround/M +Seoul/M +Sephardi/M +Sephira/M +Sepoy/M +Sept/M +September/MS +Septuagint/MS +Sequoia/M +Sequoya/M +Serafin/M +Serb/MS +Serbia/M +Serbian/S +Serbo/M +Serena/M +Serene/M +Serengeti/M +Serge/M +Sergeant/M +Sergei/M +Sergent/M +Sergio/M +Serpens/M +Serra/M +Serrano/M +Set/M +Seth/M +Seton/M +Seumas/M +Seurat/M +Seuss/M +Sevastopol/M +Severn/M +Severus/M +Seville/M +Seward/M +Sextans/M +Sexton/M +Seychelles +Seyfert +Seymour/M +Se�ora/M +Sgt +Shackleton/M +Shadow/M +Shae/M +Shafer/M +Shaffer/M +Shaina/M +Shaine/M +Shaker/S +Shakespeare/M +Shakespearean/S +Shakespearian +Shalna/M +Shalne/M +Shalom/M +Shamus/M +Shana/M +Shanan/M +Shanda/M +Shandee/M +Shandeigh/M +Shandie/M +Shandra/M +Shandy/M +Shane/M +Shanghai/GM +Shanghaiing/M +Shani/M +Shanie/M +Shanna/M +Shannah/M +Shannan/M +Shannen/M +Shannon/M +Shanon/M +Shanta/M +Shantee/M +Shantung/M +Shapiro/M +Shara/M +Sharai/M +Shari'a +Shari/M +Sharia/M +Sharity/M +Sharl/M +Sharla/M +Sharleen/M +Sharlene/M +Sharline/M +Sharon/M +Sharona/M +Sharp/M +Sharpe/M +Sharron/M +Sharyl/M +Shasta/M +Shaughn/M +Shaula/M +Shaun/M +Shauna/M +Shavian +Shavuot/M +Shaw/M +Shawano/M +Shawn/M +Shawna/M +Shawnee/SM +Shay/M +Shayla/M +Shaylah/M +Shaylyn/M +Shaylynn/M +Shayna/M +Shayne/M +Shcharansky/M +Shea/M +Sheba/M +Shebeli/M +Sheboygan/M +Shedir/M +Sheela/M +Sheelagh/M +Sheelah/M +Sheena/M +Sheeree/M +Sheetrock +Sheff/M +Sheffie/M +Sheffield/RMZ +Sheffielder/M +Sheffy/M +Sheila/M +Sheilah/M +Shel/MY +Shela/M +Shelagh/M +Shelba/M +Shelbi/M +Shelby/M +Shelden/M +Sheldon/M +Shelia/M +Shell/M +Shelley/M +Shelli/M +Shellie/M +Shelly/M +Shelton/M +Shem/M +Shena/M +Shenandoah/M +Shenyang/M +Sheol/M +Shep/M +Shepard/M +Shepherd/M +Sheppard/M +Shepperd/M +Sher/M +Sheratan/M +Sheraton/M +Sheree/M +Sheri/M +Sheridan/M +Sherie/M +Sherill/M +Sherilyn/M +Sherline/M +Sherlock/M +Sherlocke/M +Sherm/M +Sherman/M +Shermie/M +Shermy/M +Sherpa/SM +Sherri/M +Sherrie/M +Sherry/M +Sherwin/M +Sherwood/M +Sherwynd/M +Sherye/M +Sheryl/M +Shetland/S +Shevardnadze/M +Shi'ite +Shields/M +Shiite/SM +Shijiazhuang +Shikoku/M +Shillong/M +Shiloh/M +Shina/M +Shinto/MS +Shintoism/S +Shintoist/MS +Shir/M +Shiraz/M +Shirl/M +Shirlee/M +Shirleen/M +Shirlene/M +Shirley/M +Shirline/M +Shiva/M +Shmuel/M +Shockley/M +Shoji/M +Sholom/M +Shorewood/M +Short/M +Shorthorn/M +Shoshana/M +Shoshanna/M +Shoshone/SM +Shostakovitch/M +Shreveport/M +Shropshire/M +Shu/M +Shulman/M +Shurlock/M +Shurlocke/M +Shurwood/M +Shuttleworth +Shuttleworth's +Shylock/M +Shylockian/M +Si/M +Siam/M +Siamese/M +Sian's +Siana/M +Sianna/M +Sib/M +Sibbie/M +Sibby/M +Sibeal/M +Sibel/M +Sibelius/M +Sibella/M +Sibelle/M +Siberia/M +Siberian/S +Sibilla/M +Sibley/M +Sibyl/M +Sibylla/M +Sibylle/M +Sicilian/S +Siciliana/M +Sicily/M +Sid/M +Sidnee/M +Sidney/M +Sidoney/M +Sidonia/M +Sidonnie/M +Siegel/M +Siegfried/M +Sieglinda/M +Siegmund/M +Siemens/M +Siena/M +Sierpinski/M +Siffre/M +Sig/M +Sigfrid/M +Sigfried/M +Sigismond/M +Sigismondo/M +Sigismund/M +Sigismundo/M +Sigmund/M +Signor/M +Signora/M +Sigrid/M +Sigurd/M +Sigvard/M +Sihanouk/M +Sikh/MS +Sikhism/MS +Sikhs +Sikkim/M +Sikkimese +Sikorsky/M +Silas/M +Sile/M +Sileas/M +Silesia/M +Silurian/S +Silva/M +Silvain/M +Silvan/M +Silvana/M +Silvano/M +Silvanus/M +Silverman/M +Silverstein/M +Silvester/M +Silvia/M +Silvie/M +Silvio/M +Sim/MS +Simenon/M +Simeon/M +Simla/M +Simmonds/M +Simmons/M +Simmonsville/M +Simms/M +Simon/M +Simona/M +Simone/M +Simonette/M +Simonne/M +Simpson/M +Simula/M +Sinai/M +Sinatra/M +Sinclair/M +Sinclare/M +Sindbad/M +Sindee/M +Sindhi/M +Singapore/M +Singaporean/S +Singborg/M +Singer/M +Singleton/M +Sinhalese/M +Sinkiang/M +Siobhan/M +Sioux/M +Siouxie/M +Sir/MS +Sirius/M +Sisely/M +Sisile/M +Sissie/M +Sissy/M +Sistine +Sisyphean +Sisyphus/M +Siusan/M +Siva/M +Siward/M +Sjaelland/M +Skell/M +Skelly/M +Skinner/M +Skip/M +Skipp/RM +Skipper/M +Skippie/M +Skippy/M +Skipton/M +Skopje/M +Sky/M +Skye/M +Skylab/M +Skylar/M +Skyler/M +Slade/M +Slater/M +Slav/MS +Slavic/M +Slavonic/M +Slesinger/M +Sloan/M +Sloane/M +Slocum/M +Slovak/S +Slovakia/M +Slovakian/S +Slovene/S +Slovenia/M +Slovenian/S +Sly/M +Sm/M +Small/M +Smallwood/M +Smetana/M +Smirnoff/M +Smith/M +Smithfield/M +Smithson/M +Smithsonian/M +Smithtown/M +Smitty/M +Smokey/M +Smolensk/M +Smollett/M +Smucker/M +Smuts/M +Smyrna/M +Sn/M +Snake +Snead/M +Sneed/M +Snell/M +Snider/M +Snodgrass/M +Snoopy/M +Snow/M +Snowbelt/SM +Snyder/M +Soc +Socorro/M +Socrates/M +Socratic/S +Soddy/M +Sodom/M +Sofia/M +Sofie/M +Soho/M +Sol/MY +Solis/M +Sollie/M +Solly/M +Solomon/SM +Solon/M +Soloviev/M +Solzhenitsyn/M +Somali/MS +Somalia/M +Somalian/S +Somerset/M +Somerville/M +Somme/M +Somoza/M +Son/M +Sondheim/M +Sondra/M +Sonenberg/M +Songhai/M +Songhua/M +Sonia/M +Sonja/M +Sonni/M +Sonnie/M +Sonnnie/M +Sonny/M +Sonoma/M +Sonora/M +Sontag/M +Sony/M +Sonya/M +Sophey/M +Sophi/M +Sophia/SM +Sophie/M +Sophoclean +Sophocles/M +Sophronia/M +Sopwith/M +Sorbonne/M +Sorcha/M +Sorensen/M +Sorenson/M +Sorrentine/M +Sosa/M +Sosanna/M +Soto/M +Souphanouvong/M +Sousa/M +South/M +Southampton/M +Southeast/MS +Southerner/MS +Southey/M +Southfield/M +Souths +Southwest/MS +Soviet/S +Soweto/M +Soyinka/M +Soyuz/M +Sp/M +Spaatz/M +Spacewar/M +Spackle +Spafford/M +Spahn/M +Spain/M +Spalding/M +Spam/M +Span +Spanglish/S +Spaniard/SM +Spanish/M +Sparkman/M +Sparks +Sparta/M +Spartacus/M +Spartan/S +Speaker's +Spears +Spence/RM +Spencer/M +Spencerian +Spengler/M +Spenglerian +Spense/MR +Spenser/M +Spenserian +Sperry/M +Sphinx/M +Spica/M +Spiegel/M +Spielberg/M +Spike/M +Spillane/M +Spinoza/M +Spiro/M +Spitz/M +Spock/M +Spokane/M +Sposato/M +Springfield/M +Springsteen/M +Sprint/M +Sproul/M +Spuds/M +Sputnik +Squanto +Squaresville/M +Squibb/GM +Squibbing/M +Sr +Srinagar/M +St/M +Sta/M +Stace/M +Stacee/M +Stacey/M +Staci/M +Stacia/M +Stacie/M +Stacy/M +Stael/M +Stafani/M +Staffard/M +Stafford/M +Staffordshire/M +Staford/M +Stahl/M +Staley/M +Stalin/SM +Stalingrad/M +Stalinist +Stallone/M +Stamford/M +Stan/YMS +Standford/M +Standish/M +Stanfield/M +Stanford/M +Stanislas/M +Stanislaus/M +Stanislavsky/M +Stanislaw/M +Stanleigh/M +Stanley/M +Stanly/M +Stanton/M +Stanwood/M +Stapleton/M +Star/M +Stargate/M +Stark/M +Starkey/M +Starla/M +Starlene/M +Starlin/M +Starr/M +Statehouse's +Staten/M +Statler/M +Stauffer/M +Stavro/MS +Ste/M +Stearn/SM +Stearne/M +Steele/M +Steen/M +Stefa/M +Stefan/M +Stefania/M +Stefanie/M +Stefano/M +Steffane/M +Steffen/M +Steffi/M +Steffie/M +Stein/RM +Steinbeck/SM +Steinberg/M +Steinem/M +Steiner/M +Steinmetz/M +Steinway/M +Stella/M +Stendhal/M +Stendler/M +Stengel/M +Stepha/M +Stephan/M +Stephana/M +Stephani/M +Stephanie/M +Stephannie/M +Stephanus/M +Stephen/MS +Stephenie/M +Stephenson/M +Stephi/M +Stephie/M +Stephine/M +Sterling/M +Stern/M +Sternberg/M +Sterne/M +Sterno +Stesha/M +Stetson/SM +Steuben/M +Stevana/M +Steve/M +Steven/MS +Stevena/M +Stevenson/M +Stevie/M +Stevy/M +Steward/M +Stewart/M +Stieglitz/M +Stillman/M +Stillmann/M +Stillwell/M +Stilton/MS +Stimson/M +Stine/M +Stinky/M +Stirling/M +Stockhausen/M +Stockholm/M +Stockton/M +Stoddard/M +Stoic/MS +Stoicism/SM +Stokes/M +Stone/M +Stonehenge/M +Stoppard/M +Storm/M +Stormi/M +Stormie/M +Stormy/M +Stouffer/M +Stout/M +Stowe/M +Strabo/M +Stradivari/SM +Stradivarius/M +Strasbourg/M +Stratford/M +Strauss +Stravinsky/M +Streisand/M +Strickland/M +Strindberg/M +Strom/M +Stromberg/M +Stromboli/M +Strong/M +Strongheart/M +Stu/M +Stuart/MS +Stubblefield/MS +Studebaker/M +Sturm/M +Stuttgart/M +Stuyvesant/M +Stygian +Styrofoam/S +Styx/M +Suarez/M +Subaru/M +Sucre/M +Sudan/M +Sudanese/M +Sudanic/M +Sudetenland/M +Sue/M +Suellen/M +Suetonius/M +Suez/M +Suffolk/M +Sufi/M +Sufism/M +Suharto/M +Sui/M +Sukarno/M +Sukey/M +Suki/M +Sukkot/S +Sukkoth's +Sula/M +Sulawesi/M +Suleiman/M +Sulla/M +Sullivan/M +Sully/M +Sulzberger/M +Sumatra/M +Sumatran/S +Sumeria/M +Sumerian/M +Summer/SM +Summerdale/M +Sumner/M +Sumter/M +Sun +Sunbelt/M +Sundanese/M +Sundas +Sunday/MS +Sung/M +Sunni/MS +Sunnite/SM +Sunny/M +Sunnyvale/M +Sunshine/M +Superior/M +Superman/M +Supt/M +Surabaya/M +Surat/M +Surinam's +Suriname +Surinamese +Surya/M +Sus +Susan/M +Susana/M +Susanetta/M +Susann/M +Susanna/M +Susannah/M +Susanne/M +Susette/M +Susi/M +Susie/M +Susquehanna/M +Sussex/M +Susy/M +Sutherlan/M +Sutherland/M +Sutton/M +Suva/M +Suwanee/M +Suzann/M +Suzanna/M +Suzanne/M +Suzette/M +Suzhou/M +Suzi/M +Suzie/M +Suzuki/M +Suzy/M +Svalbard/M +Sven/M +Svend/M +Svengali +Sverdlovsk/M +Svetlana/M +Swabian/SM +Swahili/MS +Swanee/M +Swansea/M +Swanson/M +Swarthmore/M +Swartz/M +Swazi/SM +Swaziland/M +Swed/MN +Swede/SM +Sweden/M +Swedenborg/M +Swedish +Sweeney/SM +Sweet/M +Swen/M +Swenson/M +Swift/M +Swinburne/M +Swink/M +Swiss/S +Switz/MR +Switzer/M +Switzerland/M +Sybil/M +Sybila/M +Sybilla/M +Sybille/M +Sybyl/M +Syd/M +Sydel/M +Sydelle/M +Sydney/M +Sykes/M +Sylas/M +Sylow/M +Sylvan/M +Sylvania/M +Sylvester/M +Sylvia/M +Sylvie/M +Syman/M +Symington/M +Symon/M +Synge/M +Syracuse/M +Syria/M +Syriac/M +Syrian/SM +Szilard/M +Szymborska/M +T'ang +T's +T/G +TA +TB +TBA +TCP +TD +TDD +TEFL +TELNET/M +TENEX/M +TESL +TESOL +TEirtza/M +THC +TKO +TLC +TM +TN +TNT +TOEFL +TRW +TTL +TV/M +TVA +TVs +TWA/M +TWX +TX +Ta/M +Tab/MR +Tabasco/MS +Tabatha/M +Tabb/M +Tabbatha/M +Tabbi/M +Tabbie/M +Tabbitha/M +Tabby/M +Taber/M +Tabernacle/S +Tabina/M +Tabitha/M +Tabor/M +Tabriz/SM +Tacitus/M +Tacoma/M +Tad/M +Tadd/M +Taddeo/M +Taddeusz/M +Tadeas/M +Tadeo/M +Tades +Tadio/M +Tadzhikistan's +Tadzhikstan/M +Taegu/M +Taejon/M +Taffy/M +Taft/M +Tagalog/SM +Tagore/M +Tagus/M +Tahiti/M +Tahitian/S +Tahoe/M +Taichung/M +Tailor/M +Tainan/M +Taine/M +Taipei/M +Tait/M +Taite/M +Taiwan/M +Taiwanese +Taiyuan/M +Tajikistan +Taklamakan/M +Talbert/M +Talbot/M +Talia/M +Taliesin/M +Talladega/M +Tallahassee/M +Tallahatchie/M +Tallahoosa/M +Tallchief/M +Talley/M +Talleyrand/M +Tallia/M +Tallie/M +Tallinn/M +Tallou/M +Tallulah/M +Tally/M +Talmud/MS +Talmudic +Talmudist/MS +Talya/M +Talyah/M +Tam/M +Tamar/M +Tamara/M +Tamarah/M +Tamarra/M +Tamas +Tameka/M +Tamera/M +Tamerlane/M +Tami/M +Tamika/M +Tamiko/M +Tamil/MS +Tamma/M +Tammany/M +Tammara/M +Tammi/M +Tammie/M +Tammy/M +Tampa/M +Tampax/M +Tamqrah/M +Tamra/M +Tan/M +Tana/M +Tanaka/M +Tananarive/M +Tancred/M +Tandi/M +Tandie/M +Tandy/M +Taney/M +Tanganyika/M +Tangier/M +Tangshan/M +Tanhya/M +Tani/M +Tania/M +Tanisha/M +Tanitansy/M +Tann/RM +Tannenbaum/M +Tanner/M +Tanney/M +Tannh�user/M +Tannie/M +Tanny/M +Tansy/M +Tantalus/M +Tanya/M +Tanzania/M +Tanzanian/S +Tao/M +Taoism/MS +Taoist/MS +Tapdance/M +Tara/M +Tarah/M +Tarawa/M +Tarazed/M +Tarbell/M +Tarim/M +Tarkington/M +Tarra/M +Tarrah/M +Tarrance/M +Tarrytown/M +Tartar's +Tartary/M +Tartuffe/M +Taryn/M +Tarzan/M +Tasha/M +Tashkent/M +Tasia/M +Tasmania/M +Tasmanian/S +Tass/M +Tatar/SM +Tate/M +Tatiana/M +Tatiania/M +Tatum/M +Taurus/SM +Tawney/M +Tawnya/M +Tawsha/M +Taylor/SM +Tb +Tbilisi/M +Tc/M +Tchaikovsky/M +Te +TeX/M +Teador/M +Teasdale/M +Technicolor/MS +Technion/M +Tecumseh/M +Ted/M +Tedd/M +Tedda/M +Teddi/M +Teddie/M +Teddy/M +Tedi/M +Tedie/M +Tedman/M +Tedmund/M +Tedra/M +Teena/M +Teflon/MS +Tegucigalpa/M +Teheran's +Tehran +Tektronix/M +TelePrompTer/S +TelePrompter/M +Teledyne/M +Telefunken/M +Telemachus/M +Telemann/M +Teletype/SM +Telex/M +Tell/MR +Teller/M +Telnet/M +Telugu/M +Temp/M +Tempe/M +Temple/M +Templeman/M +Templeton/M +Tenex/M +Tenn/M +Tenneco/M +Tennessean/S +Tennessee/M +Tenney/M +Tennyson/M +Tenochtitlan/M +Teodoor/M +Teodor/M +Teodora/M +Teodorico/M +Teodoro/M +Tera/M +Terence/M +Terencio/M +Teresa/M +Terese/M +Tereshkova/M +Teresina/M +Teresita/M +Teressa/M +Teri/M +Teriann/M +Terkel/M +Terpsichore/M +Terra/M +Terran/M +Terrance/M +Terre/M +Terrel/M +Terrell/M +Terrence/M +Terri/M +Terrie/M +Terrijo/M +Terrill/M +Territorial/SM +Territory's +Terry/M +Terrye/M +Tersina/M +Tertiary +Terza/M +Tesla/M +Tess/M +Tessa/M +Tessi/M +Tessie/M +Tessy/M +Tethys/M +Tetons +Teuton/SM +Teutonic +Tex/M +Texaco/M +Texan/S +Texas/MS +Textron/M +Th/M +Thacher/M +Thackeray/M +Thad/M +Thaddeus/M +Thaddus/M +Thadeus/M +Thai/S +Thailand/M +Thain/M +Thaine/M +Thales/M +Thalia/M +Thames +Thane/M +Thanh/M +Thanksgiving/S +Thant/M +Thar/M +Thatch/MR +Thatcher/M +Thaxter/M +Thayer/M +Thayne/M +Thea/M +Theadora/M +Thebault/M +Thebes +Theda/M +Thedric/M +Thedrick/M +Theiler/M +Thekla/M +Thelma/M +Themistocles/M +Theo/M +Theobald/M +Theocritus/M +Theodor/M +Theodora/M +Theodore/M +Theodoric/M +Theodosia/M +Theodosian +Theodosius/M +Theosophy +Theravada/M +Theresa/M +Therese/M +Theresina/M +Theresita/M +Theressa/M +Therine/M +Thermos/SM +Theron/M +Theseus/M +Thespian/S +Thespis/M +Thessalonian +Thessalon�ki/M +Thessaly/M +Thia/M +Thibaud/M +Thibaut/M +Thiensville/M +Thieu/M +Thimbu/M +Thimphu +Thom/M +Thoma/SM +Thomasa/M +Thomasin/M +Thomasina/M +Thomasine/M +Thomism/M +Thomistic +Thompson/M +Thomson/M +Thor/M +Thorazine +Thoreau/M +Thorin/M +Thorn/M +Thornburg/M +Thorndike/M +Thornie/M +Thornton/M +Thorny/M +Thorpe/M +Thorstein/M +Thorsten/M +Thorvald/M +Thoth/M +Thrace/M +Thracian/M +Throneberry/M +Thruway/MS +Thu +Thucydides/M +Thule/M +Thunderbird/M +Thur/MS +Thurber/M +Thurman/M +Thursday/SM +Thurstan/M +Thurston/M +Ti/M +Tia/M +Tianjin +Tiber/M +Tiberius/M +Tibet/M +Tibetan/S +Tibold/M +Tiburon/M +Ticonderoga/M +Tiebold/M +Tiebout/M +Tieck/M +Tiena/M +Tienanmen/M +Tientsin's +Tierney/M +Tiertza/M +Tiff/M +Tiffani/M +Tiffanie/M +Tiffany/M +Tiffi/M +Tiffie/M +Tiffy/M +Tigris/M +Tijuana/M +Tilda/M +Tildi/M +Tildie/M +Tildy/M +Tiler/M +Tillich/M +Tillie/M +Tillman/M +Tilly/M +Tim/MS +Timbuktu/M +Timex/M +Timi/M +Timmi/M +Timmie/M +Timmy/M +Timofei/M +Timon/M +Timoteo/M +Timothea/M +Timothee/M +Timotheus/M +Timothy/M +Timur/M +Tina/M +Tine/M +Ting/M +Tinkertoy +Tinseltown/M +Tintoretto/M +Tioga/M +Tiphani/M +Tiphanie/M +Tiphany/M +Tippecanoe/M +Tipperary/M +Tirana's +Tirane +Tiresias/M +Tirol/M +Tirolean/S +Tirrell/M +Tish/M +Tisha/M +Titan/SM +Titania/M +Titanic/M +Titian/M +Titicaca/M +Tito/SM +Titus/M +Tl/M +Tlaloc/M +Tlingit/M +Tm/M +Tobago/M +Tobe/M +Tobey/M +Tobi/M +Tobiah/M +Tobias/M +Tobie/M +Tobin/M +Tobit/M +Toby/M +Tobye/M +Tocantins/M +Tocqueville +Tod/M +Todd/M +Toddie/M +Toddy/M +Togo/M +Togolese/M +Toiboid/M +Toinette/M +Tojo/M +Tokay/M +Tokugawa/M +Tokyo/M +Tokyoite/MS +Toland/M +Toledo/SM +Tolkien +Tolley/M +Tolstoy/M +Tolyatti/M +Tom/M +Toma/SM +Tomasina/M +Tomasine/M +Tomaso/M +Tombaugh/M +Tombigbee/M +Tome/M +Tomi/M +Tomkin/M +Tomlin/M +Tommi/M +Tommie/M +Tommy/M +Tompkins/M +Tomsk/M +Tonga/M +Tongan/SM +Toni/M +Tonia/M +Tonie/M +Tonio/M +Tonnie/M +Tonto/M +Tony/M +Tonya/M +Tonye/M +Toomey/M +Tootsie/M +Topeka/M +Topsy/M +Torah/M +Torahs +Tore/M +Torey/M +Tori/M +Torie/M +Torin/M +Toronto/M +Torquemada/M +Torr/XM +Torrance/M +Torre/MS +Torrence/M +Torrens/M +Torrey/M +Torricelli/M +Torrie/M +Torrin/M +Torry/M +Tortola/M +Tortuga/M +Tory/SM +Tosca/M +Toscanini/M +Toshiba/M +Toto/M +Toulouse/M +Tova/M +Tove/M +Town/M +Townes +Towney/M +Townie/M +Townley/M +Townsend/M +Towny/M +Towsley/M +Toynbee/M +Toyoda/M +Toyota/M +Trace/M +Tracee/M +Tracey/M +Traci/M +Tracie/M +Tractarians +Tracy/M +Trafalgar/M +Trajan/M +Tran/M +Transcaucasia/M +Transite/M +Transputer/M +Transvaal/M +Transylvania/M +Trappist/MS +Trastevere/M +Traver/MS +Travis/M +Travus/M +Treadwell/M +Treasury/SM +Treblinka/M +Trefor/M +Trekkie/M +Tremain/M +Tremaine/M +Tremayne/M +Trenna/M +Trent/M +Trenton/M +Tresa/M +Trescha/M +Tressa/M +Trev/RM +Trevar/M +Trevelyan/M +Trever/M +Trevino/M +Trevor/M +Trey/M +Triangulum/M +Trianon/M +Triassic +Tricia/M +Trieste/M +Trimble/M +Trimurti/M +Trina/M +Trinidad/M +Trinity/MS +Trip/M +Tripoli/M +Tripp/M +Trippe/M +Tris +Trish/M +Trisha/M +Trista/M +Tristam/M +Tristan/M +Triton/M +Trix/M +Trixi/M +Trixie/M +Trixy/M +Trobriand/M +Trojan/MS +Trollope/M +Trondheim/M +Tropez/M +Trotsky/M +Troutman/M +Troy/M +Troyes +Trstram/M +Truckee/M +Truda/M +Trude/M +Trudeau/M +Trudey/M +Trudi/M +Trudie/M +Trudy/M +Trueman/M +Trujillo/M +Trula/M +Trumaine/M +Truman/M +Trumann/M +Trumbull/M +Trump/M +Truth +Tsimshian/M +Tsiolkovsky/M +Tsitsihar/M +Tsunematsu/M +Tswana/M +Tuamotu/M +Tuareg/M +Tubman/M +Tuck/RM +Tucker/M +Tuckie/M +Tucky/M +Tucson/M +Tucuman/M +Tudor/MS +Tue/S +Tuesday/SM +Tulane/M +Tull/M +Tulley/M +Tully/M +Tulsa/M +Tums/M +Tungus/M +Tunguska/M +Tunis/M +Tunisia/M +Tunisian/S +Tupi/M +Tupperware +Tupungato/M +Turgenev/M +Turin/M +Turing/M +Turk/SM +Turkestan/M +Turkey/M +Turkic/SM +Turkish +Turkmenistan/M +Turner/M +Turpin/M +Tuscaloosa/M +Tuscan +Tuscany/M +Tuscarora/M +Tuscon/M +Tuskegee/M +Tussuad/M +Tut/M +Tutankhamen/M +Tutsi +Tuttle/M +Tuvalu +Twain/M +Tweed/M +Tweedledee/M +Tweedledum/M +Twila/M +Twinkie +Twp +Twyla/M +Ty/M +Tybalt/M +Tybi/M +Tybie/M +Tye/M +Tylenol/M +Tyler/M +Tymon/M +Tymothy/M +Tynan/M +Tyndale/M +Tyndall/M +Tyne/M +Typhon/M +Tyree/M +Tyrol's +Tyrolean/S +Tyrone/M +Tyrus/M +Tyson/M +Tzeltal/M +U +UAR +UART +UAW +UCLA/M +UFO/S +UHF +UK +UL +ULTRIX/M +UN +UNESCO +UNICEF +UNIX/M +UPC +UPI +UPS +URL +US +USA +USAF +USART +USC/M +USCG +USDA +USG/M +USIA +USMC +USN +USO +USP +USPS +USS +USSR +UT +UV +Ubangi/M +Ubuntu +Ubuntu's +UbuntuOne +UbuntuOne's +Ucayali/M +Uccello/M +Udale/M +Udall/M +Udell/M +Ufa/M +Uganda/M +Ugandan/S +Ugo/M +Uighur +Ujungpandang/M +Ukraine/M +Ukrainian/S +Ula/M +Ulberto/M +Ulick/M +Ulises/M +Ulla/M +Ullman/M +Ulric/M +Ulrica/M +Ulrich/M +Ulrick/M +Ulrika/M +Ulrikaumeko/M +Ulrike/M +Ulster/M +Ultrasuede +Ultrix/M +Ulyanovsk/M +Ulysses/M +Umberto/M +Umbriel/M +Umeko/M +Una/M +Underwood/M +Ungava/M +UniPlus/M +UniSoft/M +Unibus/M +Unicode/M +Union/MS +Unionist/SM +Uniroyal/M +Unisys/M +Unitarian/MS +Unitarianism/SM +Univac/M +Unix/M +Unukalhai/M +Upanishads +Updike/M +Upton/M +Ur/M +Ural/MS +Urania/M +Uranus/M +Urbain/M +Urban/M +Urbana/M +Urbano/M +Urbanus/M +Urdu/M +Urey/M +Uri/SM +Uriah/M +Uriel/M +Urquhart/M +Ursa/M +Ursala/M +Ursola/M +Urson/M +Ursula/M +Ursulina/M +Ursuline/M +Uruguay/M +Uruguayan/S +Urumqi +Usenet/M +Usenix/M +Ustinov/M +Uta/M +Utah/M +Utahan/SM +Ute/M +Utica/M +Utopia/MS +Utopian/S +Utrecht/M +Utrillo/M +Uzbek/M +Uzbekistan +Uzi/M +V +V's +VA +VAR +VAT +VAX/M +VAXes +VCR +VD +VDT +VDU +VF +VFW +VG +VGA +VHF +VHS +VI +VIP/S +VISTA +VJ +VLF +VLSI +VMS/M +VOA +VP +VT +VTOL +Va/M +Vachel/M +Vaclav/M +Vader/M +Vaduz/M +Vail/M +Val/MY +Valaree/M +Valaria/M +Valarie/M +Valdemar/M +Valdez/M +Vale/M +Valeda/M +Valencia/MS +Valene/M +Valenka/M +Valentia/M +Valentijn/M +Valentin/M +Valentina/M +Valentine/M +Valentino/M +Valenzuela/M +Valera/M +Valeria/M +Valerian/M +Valerie/M +Valerye/M +Valhalla/M +Valida/M +Valina/M +Valium/S +Valkyrie/SM +Valle/M +Vallejo +Valletta/M +Valli/M +Vallie/M +Vally/M +Valma/M +Valois/M +Valparaiso/M +Valry/M +Val�ry/M +Van/M +Vance/M +Vancouver/M +Vanda/M +Vandal/MS +Vandenberg/M +Vanderbilt/M +Vanderburgh/M +Vanderpoel/M +Vandyke/SM +Vanessa/M +Vang/M +Vania/M +Vanna/M +Vanni/M +Vannie/M +Vanny/M +Vanuatu +Vanya/M +Vanzetti/M +Varanasi/M +Varese/M +Vargas/M +Varian/M +Varityping/M +Vaseline/DSMG +Vasili/MS +Vasily/M +Vasquez/M +Vassar/M +Vassili/M +Vassily/M +Vatican/M +Vaudois +Vaughan/M +Vaughn/M +Vax/M +Vazquez/M +Veblen/M +Veda/MS +Vedanta/M +Vega/SM +Vegemite/M +Vela/M +Velcro/SM +Velez/M +Vella/M +Velma/M +Velveeta/M +Velvet/M +Vel�squez/M +Vel�zquez +Venetian/SM +Venezuela/M +Venezuelan/S +Venice/M +Venita/M +Venn/M +Ventura/M +Venus/S +Venusian/S +Vera/M +Veracruz/M +Veradis +Verde/M +Verderer/M +Verdi/M +Vere/M +Verena/M +Verene/M +Verge/M +Vergil's +Veriee/M +Verile/M +Verina/M +Verine/M +Verla/M +Verlag/M +Verlaine/M +Vermeer/M +Vermont/ZRM +Vermonter/M +Vern/NM +Verna/M +Verne/M +Vernen/M +Verney/M +Vernice/M +Vernon/M +Vernor/M +Verona/M +Veronese/M +Veronica/M +Veronika/M +Veronike/M +Veronique/M +Versailles/M +Versatec/M +Vesalius/M +Vespasian/M +Vespucci/M +Vesta/M +Vesuvius/M +Vevay/M +Vi/M +Viagra/M +Vic/M +Vicente/M +Vichy/M +Vick/ZM +Vickers/M +Vicki/M +Vickie/M +Vicksburg/M +Vicky/M +Victoir/M +Victor/M +Victoria/M +Victorian/S +Victorianism/S +Victrola/SM +Vida/M +Vidal/M +Vidovic/M +Vidovik/M +Vienna/M +Viennese/M +Vientiane/M +Viet/M +Vietcong/M +Vietminh/M +Vietnam/M +Vietnamese/M +Vijayawada/M +Viki/M +Viking/MS +Vikki/M +Vikky/M +Vikram/M +Vila +Vilhelmina/M +Villa/M +Villarreal/M +Villon/M +Vilma/M +Vilnius/M +Vilyui/M +Vin/M +Vina/M +Vince/M +Vincent/MS +Vincenty/M +Vincenz/M +Vinci/M +Vindemiatrix/M +Vinita/M +Vinni/M +Vinnie/M +Vinny/M +Vinson/M +Viola/M +Violante/M +Viole/M +Violet/M +Violetta/M +Violette/M +Virge/M +Virgie/M +Virgil/M +Virgilio/M +Virgina/M +Virginia/M +Virginian/S +Virginie/M +Virgo/MS +Visa/M +Visakhapatnam's +Visayans +Vishnu/M +Visigoth/M +Visigoths +Vistula/M +Vita/M +Vite/M +Vitia/M +Vitim/M +Vito/M +Vitoria/M +Vittoria/M +Vittorio/M +Vitus/M +Viv/M +Viva/M +Vivaldi +Vivekananda/M +Vivi/MN +Vivia/M +Vivian/M +Viviana/M +Vivianna/M +Vivianne/M +Vivie/M +Vivien/M +Viviene/M +Vivienne/M +Viviyan/M +Vivyan/M +Vivyanne/M +Vlad/M +Vladamir/M +Vladimir/M +Vladivostok/M +Vogel/M +Vol/M +Volga/M +Volgograd/M +Volkswagen/SM +Volstead/M +Volta/M +Voltaire/M +Volterra/M +Volvo/M +Von/M +Vonda/M +Vonnegut/M +Vonni/M +Vonnie/M +Vonny/M +Voronezh/M +Vorster/M +Vt/M +Vulcan/M +Vulg/M +Vulgate/SM +Vyky/M +W's +W/T +WA +WAC +WASP +WATS +WC +WFF +WHO +WI +WNW +WP +WSW +WV +WW +WWI +WWII +WWW +WY +WYSIWYG +Waals +Wabash/M +Wac/S +Wacke/M +Waco/M +Wade/M +Wadsworth/M +Wafs +Wagner/M +Wagnerian +Wahl/M +Waikiki/M +Wain/M +Wainwright/M +Wait/MR +Waite/M +Waiter/M +Wake/M +Wakefield/M +Waksman/M +Walbridge/M +Walcott/M +Wald/MN +Waldemar/M +Walden/M +Waldensian +Waldheim/M +Waldo/M +Waldon/M +Waldorf/M +Wales +Walesa/M +Walford/M +Walgreen/M +Walker/M +Walkman/S +Wall/SMR +Wallace/M +Wallache/M +Wallas/M +Wallenstein/M +Waller/M +Wallie/M +Wallis +Walliw/M +Walloon/SM +Wally/M +Walpole/M +Walpurgisnacht +Walsh/M +Walt/ZMR +Walter/M +Walther/M +Walton/M +Walworth/M +Waly/M +Wanamaker/M +Wanda/M +Wandie/M +Wandis/M +Waneta/M +Wang/M +Wanids/M +Wankel/M +Wansee/M +Wansley/M +Ward/MN +Warde/M +Warden/M +Ware/MG +Warfield/M +Warhol/M +Waring/M +Warner/M +Warnock/M +Warren/M +Warsaw/M +Warwick/M +Wasatch/M +Wash/M +Washburn/M +Washington/M +Washingtonian/S +Washoe/M +Wasp's +Wasserman/M +Wassermann/M +Wat/ZM +Watanabe/M +Waterbury/M +Watergate/M +Waterhouse/M +Waterloo/SM +Waters/M +Watertown/M +Watkins +Watson/M +Watt/MS +Watteau/M +Wattenberg/M +Watterson/M +Watusi/M +Waugh/M +Waukesha/M +Waunona/M +Waupaca/M +Waupun/M +Wausau/M +Wauwatosa/M +Wave/S +Waveland/M +Waverley/M +Waverly/M +Way/M +Waylan/M +Wayland/M +Waylen/M +Waylin/M +Waylon/M +Wayne/M +Waynesboro/M +Weatherford/M +Weaver/M +Web/MR +Webb/RM +Webber/M +Weber/M +Webern/M +Webster/MS +Websterville/M +Wed/M +Weddell/M +Wedgwood/M +Wednesday/SM +Weeks/M +Wehr/M +Wei/M +Weibull/M +Weidar/M +Weider/M +Weidman/M +Weierstrass/M +Weill/M +Weinberg/M +Weiner/M +Weinstein/M +Weisenheimer/M +Weiss/M +Weissman/M +Weissmuller/M +Weizmann/M +Welbie/M +Welby/M +Welcher/M +Welches +Weldon/M +Weldwood/M +Welland/M +Weller/M +Welles/M +Wellesley/M +Wellington/MS +Wellman/M +Wells/M +Wellsville/M +Welmers/M +Welsh +Welshman/M +Welshmen +Welshwoman/M +Welshwomen +Wenda/M +Wendall/M +Wendel/M +Wendeline/M +Wendell/M +Wendi/M +Wendie/M +Wendy/M +Wendye/M +Wenona/M +Wenonah/M +Wentworth/M +Werner/M +Wernher/M +Werther/M +Wes +Wesley/M +Wesleyan +Wessex/M +Wesson/M +West/MS +Westbrook/M +Westbrooke/M +Westchester/M +Western/ZRS +Westfield/M +Westhampton/M +Westinghouse/M +Westleigh/M +Westley/M +Westminster/M +Westmore/M +Weston/M +Westphalia/M +Westport/M +Westwood/M +Weyden/M +Weyerhauser/M +Weylin/M +Wezen/M +Whalen/M +Wharton/M +Wheaties/M +Wheatland/M +Wheaton/M +Wheatstone/M +Wheeler/M +Wheeling/M +Wheelock/M +Whelan/M +Wheller/M +Whig/SM +Whippany/M +Whipple/M +Whistler/M +Whit/M +Whitaker/M +Whitby/M +Whitcomb/M +White/MS +Whitefield/M +Whitehall/M +Whitehead/M +Whitehorse/M +Whiteleaf/M +Whiteley/M +Whitewater/M +Whitfield/M +Whitley/M +Whitlock/M +Whitman/M +Whitney/M +Whitsunday/MS +Whittaker/M +Whittier +Wiatt/M +Wichita/M +Wieland/M +Wiemar/M +Wier/M +Wiesel/M +Wiggins +Wigner/M +Wilberforce/M +Wilbert/M +Wilbur/M +Wilburn/M +Wilburt/M +Wilcox/M +Wilda/M +Wilde/MR +Wilden/M +Wilder/M +Wildon/M +Wileen/M +Wilek/M +Wiley/M +Wilford/M +Wilfred/M +Wilfredo/M +Wilfrid/M +Wilhelm/M +Wilhelmina/M +Wilhelmine/M +Wilie/M +Wilkerson/M +Wilkes/M +Wilkins/M +Wilkinson/M +Will/M +Willa/M +Willabella/M +Willamette/M +Willamina/M +Willard/M +Willcox/M +Willdon/M +Willem/M +Willemstad/M +Willetta/M +Willette/M +Willey/M +Willi/MS +William/SM +Williamsburg/M +Williamson/M +Willie/M +Willied/M +Willisson/M +Willoughby/M +Willow/M +Willy/SDM +Willyt/M +Wilma/M +Wilmar/M +Wilmer/M +Wilmette/M +Wilmington/M +Wilona/M +Wilone/M +Wilow/M +Wilshire/M +Wilson/M +Wilsonian +Wilt/M +Wilton/M +Wimbledon/M +Win/M +Winchell/M +Winchester/MS +Windham/M +Windhoek/M +Windows +Windsor/MS +Windward/M +Windy/M +Winehead/M +Winesap/M +Winfield/M +Winfred/M +Winfrey/M +Wini/M +Winifield/M +Winifred/M +Winkle/M +Winn/M +Winna/M +Winnah/M +Winne/M +Winnebago/M +Winnetka/M +Winni/M +Winnie/M +Winnifred/M +Winnipeg/M +Winny/M +Winograd/M +Winona/M +Winonah/M +Winooski/M +Winsborough/M +Winsett/M +Winslow/M +Winston/M +Winters +Winthrop/M +Wis/M +Wisc +Wisconsin/M +Wisconsinite/SM +Wise/M +Wisenheimer/M +Wit/M +Witherspoon/M +Witt/M +Wittgenstein/M +Wittie/M +Witty/M +Witwatersrand/M +Wm/M +Wodehouse/M +Wolcott/M +Wolf/M +Wolfe/M +Wolff/M +Wolfgang/M +Wolfie/M +Wolfy/M +Wollongong/M +Wollstonecraft/M +Wolsey/M +Wolverhampton/M +Wolverton/M +Wong/M +Wood/SM +Woodard/M +Woodberry/M +Woodbury/M +Woodhull/M +Woodie/M +Woodlawn/M +Woodman/M +Woodrow/M +Woodstock/M +Woodward/MS +Woody/M +Woolf/M +Woolongong/M +Woolworth/M +Woonsocket/M +Wooster/M +Wooten/M +Worcester/SM +Worcestershire/M +Worden/M +Wordsworth/M +Workman/M +Worms/M +Worth/M +Worthington/M +Worthy/M +Wotan/M +Wozniak/M +Wrangell/M +Wren/MS +Wrennie/M +Wright/M +Wrigley/M +Wroclaw +Wronskian/M +Wu/M +Wuhan/M +Wurlitzer/M +Wyatan/M +Wyatt/M +Wycherley/M +Wycliffe/M +Wye/MH +Wyeth/M +Wylie/M +Wylma/M +Wyman/M +Wyn/M +Wyndham/M +Wynn/M +Wynne/M +Wynnie/M +Wynny/M +Wyo/M +Wyoming/M +Wyomingite/SM +X +X's +XEmacs/M +XL +XML +XOR +XS +XXL +Xanadu +Xanthippe/M +Xanthus/M +Xavier/M +Xaviera/M +Xe/M +Xebec/M +Xena/M +Xenakis/M +Xenia/M +Xenix/M +Xenophon/M +Xenos +Xerox/MGSD +Xerxes/M +Xever/M +Xhosa/M +Xi'an +Xian/S +Xiaoping/M +Ximenes/M +Ximenez/M +Ximian/SM +Xingu/M +Xmas/SM +Xochipilli/M +Xuzhou/M +Xylia/M +Xylina/M +Xymenes/M +Y +Y's +YMCA +YMHA +YMMV +YT +YWCA +YWHA +Yacc/M +Yagi/M +Yahweh/M +Yakima/M +Yakut/M +Yakutsk/M +Yale/M +Yalies/M +Yalonda/M +Yalow/M +Yalta/M +Yalu/M +Yamaha/M +Yamoussoukro +Yanaton/M +Yance/M +Yancey/M +Yancy/M +Yang/M +Yangon +Yangtze/M +Yank/MS +Yankee/SM +Yaounde/M +Yaqui/M +Yard/M +Yardley/M +Yaroslavl/M +Yasmeen/M +Yasmin/M +Yates +Yb/M +Yeager/M +Yeats/M +Yehudi/M +Yehudit/M +Yekaterinburg/M +Yelena/M +Yellowknife/M +Yellowstone/M +Yeltsin +Yemen/M +Yemeni/S +Yemenite/SM +Yenisei/M +Yentl/M +Yerevan/M +Yerkes/M +Yesenia/M +Yetta/M +Yettie/M +Yetty/M +Yevette/M +Yevtushenko/M +Yggdrasil/M +Yiddish/M +Ymir/M +Ynes/M +Ynez/M +Yoda/M +Yoder/M +Yoknapatawpha/M +Yoko/M +Yokohama/M +Yolanda/M +Yolande/M +Yolane/M +Yolanthe/M +Yong/M +Yonkers/M +Yorgo/MS +Yorick/M +York/ZRMS +Yorke/M +Yorker/M +Yorkshire/MS +Yorktown/M +Yoruba/M +Yosemite/M +Yoshi/M +Yoshiko/M +Yost/M +Young/M +Youngstown/M +Yovonnda/M +Ypres/M +Ypsilanti/M +Ysabel/M +Yuba/M +Yucatan +Yugo/M +Yugoslav/M +Yugoslavia/M +Yugoslavian/S +Yuh/M +Yuki/M +Yukon/M +Yul/M +Yule/MS +Yuletide/S +Yulma/M +Yuma/M +Yunnan/M +Yuri/M +Yurik/M +Yves/M +Yvette/M +Yvon/M +Yvonne/M +Yvor/M +Z/X +Zabrina/M +Zaccaria/M +Zach/M +Zacharia/SM +Zachariah/M +Zacharie/M +Zachary/M +Zacherie/M +Zachery/M +Zack/M +Zackariah/M +Zagreb/M +Zahara/M +Zaire/M +Zairian/S +Zak/M +Zambezi/M +Zambia/M +Zambian/S +Zamboni +Zamenhof/M +Zamora/M +Zan/M +Zandra/M +Zane/M +Zaneta/M +Zanuck/M +Zanzibar/M +Zapata/M +Zaporozhye/M +Zappa/M +Zara/M +Zarah/M +Zared/M +Zaria/M +Zarla/M +Zea/M +Zealand/M +Zeb/M +Zebadiah/M +Zebedee/M +Zebulen/M +Zebulon/M +Zechariah/M +Zed/M +Zedekiah/M +Zedong/M +Zeffirelli/M +Zeiss/M +Zeke/M +Zelda/M +Zelig/M +Zellerbach/M +Zelma/M +Zen/M +Zena/M +Zenger/M +Zenia/M +Zennist/M +Zeno/M +Zephaniah/M +Zephyrus/M +Zeppelin's +Zerk/M +Zeus/M +Zhdanov/M +Zhengzhou +Zhivago/M +Zhukov/M +Zia/M +Zibo/M +Ziegfeld/MS +Ziegler/M +Ziggy/M +Zilvia/M +Zimbabwe/M +Zimbabwean/S +Zimmerman/M +Zion/SM +Zionism/MS +Zionist/MS +Zita/M +Zitella/M +Zn/M +Zoe/M +Zola/M +Zollie/M +Zolly/M +Zomba/M +Zonda/M +Zondra/M +Zonnya/M +Zora/M +Zorah/M +Zorana/M +Zorina/M +Zorine/M +Zorn/M +Zoroaster/M +Zoroastrian/S +Zoroastrianism/MS +Zorro/M +Zosma/M +Zr/M +Zs +Zsazsa/M +Zsigmondy/M +Zubenelgenubi/M +Zubeneschamali/M +Zukor/M +Zulema/M +Zulu/MS +Zululand/M +Zuni/S +Zuzana/M +Zwingli/M +Zworykin/M +Z�rich/M +a +aardvark/SM +ab/DY +aback +abacus/SM +abaft +abalone/SM +abandon/LGDRS +abandoner/M +abandonment/SM +abase/LGDSR +abasement/S +abaser/M +abash/SDLG +abashed/UY +abashment/MS +abate/DSRLG +abated/U +abatement/MS +abater/M +abattoir/SM +abbess/SM +abbey/MS +abbot/MS +abbr +abbrev +abbreviate/XDSNG +abbreviated/UA +abbreviates/A +abbreviating/A +abbreviation/M +abb�/S +abdicate/NGDSX +abdication/M +abdomen/SM +abdominal/YS +abduct/DGS +abduction/SM +abductor/SM +abeam +aberrant/YS +aberration/SM +aberrational +abet/S +abetted +abetting +abettor/SM +abeyance/MS +abeyant +abhor/S +abhorred +abhorrence/MS +abhorrent/Y +abhorrer/M +abhorring +abidance/MS +abide/JGSR +abider/M +abiding/Y +ability/IMES +abject/SGPDY +abjection/MS +abjectness/SM +abjuration/SM +abjuratory +abjure/ZGSRD +abjurer/M +ablate/VGNSDX +ablation/M +ablative/SY +ablaze +able/U +abler/E +ables/E +ablest +abloom +ablution/MS +abnegate/NGSDX +abnegation/M +abnormal/SY +abnormality/SM +aboard +abode/GMDS +abolish/LZRSDG +abolisher/M +abolishment/MS +abolition/SM +abolitionism/SM +abolitionist/SM +abominable +abominably +abominate/XSDGN +abomination/M +aboriginal/YS +aborigine/SM +aborning +abort/SRDVG +abortion/MS +abortionist/MS +abortive/PY +abortiveness/M +abound/GDS +about/S +above/S +aboveboard +aboveground +abracadabra/S +abrade/SRDG +abrader/M +abrasion/MS +abrasive/SYMP +abrasiveness/S +abreaction/MS +abreast +abridge/DSRG +abridged/U +abridger/M +abridgment/SM +abroad +abrogate/XDSNG +abrogation/M +abrogator/SM +abrupt/TRYP +abruptness/SM +abs/M +abscess/GDSM +abscissa/SM +abscission/SM +abscond/SDRZG +absconder/M +abseil/SGDR +absence/SM +absent/SGDRY +absentee/MS +absenteeism/SM +absentia/M +absentminded/PY +absentmindedness/S +absinthe/SM +absolute/NPRSYTX +absoluteness/SM +absolution/M +absolutism/MS +absolutist/SM +absolve/GDSR +absolver/M +absorb/ASGD +absorbed/U +absorbency/MS +absorbent/MS +absorber/SM +absorbing/Y +absorption/MS +absorptive +absorptivity/M +abstain/GSDRZ +abstainer/M +abstemious/YP +abstemiousness/MS +abstention/SM +abstinence/MS +abstinent/Y +abstract/PTVGRDYS +abstracted/YP +abstractedness/SM +abstracter/M +abstraction/SM +abstractionism/M +abstractionist/SM +abstractness/SM +abstractor/MS +abstruse/PRYT +abstruseness/SM +absurd/PRYST +absurdity/SM +absurdness/SM +abundance/SM +abundant/Y +abuse/GVZDSRB +abused/E +abuser/M +abuses/E +abusing/E +abusive/YP +abusiveness/SM +abut/LS +abutment/SM +abutted +abutter/MS +abutting +abuzz +abysmal/Y +abyss/SM +abyssal +ac/DRG +acacia/SM +academe/MS +academia/SM +academic/S +academical/Y +academician/SM +academicianship +academy/SM +acanthus/MS +accede/SDG +accelerate/NGSDXV +accelerated/U +accelerating/Y +acceleration/M +accelerator/SM +accelerometer/SM +accent/SGMD +accented/U +accentual/Y +accentuate/XNGSD +accentuation/M +accept/RDBSZVG +acceptability's/U +acceptability/SM +acceptable/P +acceptableness/SM +acceptably/U +acceptance/SM +acceptant +acceptation/SM +accepted/Y +accepter/M +accepting/PY +acceptor/MS +access/SDMG +accessed/A +accessibility/IMS +accessible/IU +accessibly/I +accession/SMDG +accessors +accessory/SM +accidence/M +accident/MS +accidental/SPY +accidentalness/M +acclaim/SDRG +acclaimer/M +acclamation/MS +acclimate/XSDGN +acclimation/M +acclimatisation +acclimatise/DG +acclimatization/AMS +acclimatize/RSDGZ +acclimatized/U +acclimatizes/A +acclivity/SM +accolade/GDSM +accommodate/XVNGSD +accommodated/U +accommodating/Y +accommodation/M +accommodative/P +accommodativeness/M +accompanied/U +accompanier/M +accompaniment/MS +accompanist/SM +accompany/DRSG +accomplice/MS +accomplish/SRDLZG +accomplished/U +accomplisher/M +accomplishment/SM +accord/SZGMRD +accordance/SM +accordant/Y +accorder/M +according/Y +accordion/MS +accordionist/SM +accost/SGD +account/BMDSGJ +accountability's/U +accountability/MS +accountable/U +accountableness/M +accountably/U +accountancy/SM +accountant/MS +accounted/U +accounting/M +accouter/GSD +accouterment's +accouterments +accoutrement/M +accredit/SGD +accreditation/SM +accredited/U +accretion/SM +accrual/MS +accrue/SDG +acct +acculturate/XSDVNG +acculturation/M +accumulate/VNGSDX +accumulation/M +accumulative/YP +accumulativeness/M +accumulator/MS +accuracy/IMS +accurate/IY +accurateness/SM +accursed/YP +accursedness/SM +accusal/M +accusation/SM +accusative/S +accusatory +accuse/SRDZG +accused/M +accuser/M +accusing/Y +accustom/SGD +accustomed/P +accustomedness/M +ace/SM +aced/M +acerbate/DSG +acerbic +acerbically +acerbity/MS +acetaminophen/S +acetate/MS +acetic +acetone/SM +acetonic +acetylene/MS +ache/DSG +ached/A +achene/SM +aches/A +achievable/U +achieve/LZGRSDB +achieved/UA +achievement/SM +achiever/M +aching/Y +achoo +achromatic +achy/TR +acid/SMYP +acidic +acidification/M +acidify/NSDG +acidity/SM +acidness/M +acidoses +acidosis/M +acidulous +acing/M +acknowledge/GZDRS +acknowledgeable +acknowledged/U +acknowledgedly +acknowledgement/SAM +acknowledger/M +acknowledgment/SAM +acme/SM +acne/MDS +acolyte/MS +aconite/MS +acorn/SM +acoustic/S +acoustical/Y +acoustician/M +acoustics/M +acquaint/GASD +acquaintance/MS +acquaintanceship/S +acquainted/U +acquiesce/GSD +acquiescence/SM +acquiescent/Y +acquirable +acquire/ASDG +acquirement/SM +acquisition's/A +acquisition/SM +acquisitive/PY +acquisitiveness/MS +acquit/S +acquittal/MS +acquittance/M +acquitted +acquitter/M +acquitting +acre/MS +acreage/MS +acrid/TPRY +acridity/MS +acridness/SM +acrimonious/YP +acrimoniousness/MS +acrimony/MS +acrobat/SM +acrobatic/S +acrobatically +acrobatics/M +acronym/SM +acrophobia/SM +acropolis/SM +across +acrostic/SM +acrylate/M +acrylic/S +act's +act/SADVG +acting/S +actinic +actinide/SM +actinium/MS +actinometer/MS +action's/IA +action/DMSGB +actions/AI +activate/AXCDSNGI +activated/U +activation/AMCI +activator/SM +active/APY +actively/I +activeness/MS +actives +activism/MS +activist/MS +activities/A +activity/MSI +actor/MAS +actress/SM +actual/SY +actuality/SM +actualization/MAS +actualize/GSD +actualizes/A +actuarial/Y +actuary/MS +actuate/GNXSD +actuation/M +actuator/SM +acuity/MS +acumen/SM +acupressure/S +acupuncture/SM +acupuncturist/S +acute/YTSRP +acuteness/MS +acyclic +acyclically +acyclovir/S +ad's +ad/AS +adage/MS +adagio/S +adamant/SY +adapt/SRDBZVG +adaptability/MS +adaptable/U +adaptation/MS +adapted/P +adaptedness/M +adapter/M +adapting/A +adaption +adaptive/U +adaptively +adaptiveness/M +adaptivity +add/ZGBSDR +addend/SM +addenda +addendum/M +adder/M +addict/SGVD +addiction/MS +addictive/P +addition/MS +additional/Y +additive/YMS +additivity +addle/GDS +address/MDRSZGB +addressability +addressable/U +addressed/A +addressee/SM +addresser/M +addresses/A +adduce/GRSD +adducer/M +adduct/DGVS +adduction/M +adductor/M +adenine/SM +adenoid/S +adenoidal +adept/RYPTS +adeptness/MS +adequacy/IMS +adequate/IPY +adequateness's/I +adequateness/SM +adhere/ZGRSD +adherence/SM +adherent/YMS +adherer/M +adhesion/MS +adhesive/PYMS +adhesiveness/MS +adiabatic +adiabatically +adieu/S +adipose/S +adi�s +adj +adjacency/MS +adjacent/Y +adjectival/Y +adjective/MYS +adjoin/SDG +adjoint/M +adjourn/DGLS +adjournment/SM +adjudge/DSG +adjudicate/VNGXSD +adjudication/M +adjudicator/SM +adjudicatory +adjunct/VSYM +adjuration/SM +adjure/GSD +adjust/DRALGSB +adjustable/U +adjustably +adjusted/U +adjuster's/A +adjuster/SM +adjustive +adjustment/MAS +adjustor's +adjutant/SM +adman/M +admen +administer/GDJS +administrable +administrate/XSDVNG +administration/M +administrative/Y +administrator/MS +administratrix/M +admirable/P +admirableness/M +admirably +admiral/SM +admiralty/MS +admiration/MS +admire/RSDZBG +admirer/M +admiring/Y +admissibility/ISM +admissible/I +admissibly +admission/AMS +admit/AS +admittance/MS +admitted/A +admittedly +admitting/A +admix/SDG +admixture/SM +admonish/GLSRD +admonisher/M +admonishing/Y +admonishment/SM +admonition/MS +admonitory +ado/MS +adobe/MS +adolescence/MS +adolescent/SYM +adopt/RDSBZVG +adopted/AU +adopter/M +adoption/MS +adoptive/Y +adopts/A +adorable/P +adorableness/SM +adorably +adoration/SM +adore/DSRGZB +adorer/M +adoring/Y +adorn/SGLD +adorned/U +adornment/SM +adrenal/YS +adrenalin +adrenaline/MS +adrift +adroit/RTYP +adroitness/MS +ads +adsorb/GSD +adsorbate/M +adsorbent/S +adsorption/MS +adsorptive/Y +adulate/GNDSX +adulation/M +adulator/SM +adulatory +adult/MYPS +adulterant/SM +adulterate/NGSDX +adulterated/U +adulteration/M +adulterer/SM +adulteress/MS +adulterous/Y +adultery/SM +adulthood/MS +adultness/M +adumbrate/XSDVGN +adumbration/M +adumbrative/Y +adv +advance/DSRLZG +advancement/MS +advancer/M +advantage/GMEDS +advantageous/EY +advantageousness/M +advent/SVM +adventist/S +adventitious/PY +adventitiousness/M +adventive/Y +adventure/SRDGMZ +adventurer/M +adventuresome +adventuress/SM +adventurous/YP +adventurousness/SM +adverb/SM +adverbial/MYS +adversarial +adversary/SM +adverse/DSRPYTG +adverseness/MS +adversity/SM +advert/GSD +advertise/JGZSRDL +advertised/U +advertisement/SM +advertiser/M +advertising/M +advertorial/S +advice/SM +advisability/SIM +advisable/I +advisableness/M +advisably +advise/ZRSDGLB +advised/YU +advisedly/I +advisee/MS +advisement/MS +adviser/M +advisor's +advisor/S +advisory/S +advocacy/SM +advocate/NGVDS +advocation/M +advt +adz/MDSG +adze's +aegis/SM +aeolian +aeon's +aerate/XNGSD +aeration/M +aerator/MS +aerial/SMY +aerialist/MS +aerie/SRMT +aeroacoustic +aerobatic/S +aerobic/S +aerobically +aerodrome/SM +aerodynamic/S +aerodynamically +aerodynamics/M +aeronautic/S +aeronautical/Y +aeronautics/M +aerosol/MS +aerosolize/D +aerospace/SM +aesthete/S +aesthetic/U +aesthetically +aestheticism/MS +aesthetics/M +aether/M +aetiology/M +afar/S +affability/MS +affable/TR +affably +affair/SM +affect/EGSD +affectation/MS +affected/UEYP +affectedness/EM +affecter/M +affecting/Y +affection/EMS +affectionate/UY +affectioned +affectioning +affective/MY +afferent/YS +affiance/GDS +affidavit/SM +affiliate/EXSDNG +affiliated/U +affiliation/EM +affine +affinity/SM +affirm/ASDG +affirmation/SAM +affirmative/SY +affix/SDG +afflatus/MS +afflict/GVDS +affliction/SM +afflictive/Y +affluence/SM +affluent/YS +afford/DSBG +afforest/A +afforestation/SM +afforested +afforesting +afforests +affray/MDSG +affricate/VNMS +affrication/M +affricative/M +affright +affront/GSDM +afghan/MS +aficionado/MS +afield +afire +aflame +afloat +aflutter +afoot +afore +aforementioned +aforesaid +aforethought/S +afoul +afraid/U +afresh +afro +aft/ZR +afterbirth/M +afterbirths +afterburner/MS +aftercare/SM +aftereffect/MS +afterglow/MS +afterimage/MS +afterlife/M +afterlives +aftermath/M +aftermaths +aftermost +afternoon/SM +afters/M +aftershave/S +aftershock/SM +aftertaste/SM +afterthought/MS +afterward/S +afterworld/MS +again +against +agapae +agape/S +agar/MS +agate/SM +agave/SM +age/GJDRSMZ +aged/PY +agedness/M +ageism/S +ageist/S +ageless/YP +agelessness/MS +agency/SM +agenda/MS +agent/AMS +agented +agenting +agentive +ageratum/M +agglomerate/XNGVDS +agglomeration/M +agglutinate/VNGXSD +agglutination/M +agglutinin/MS +aggrandize/LDSG +aggrandizement/SM +aggravate/SDNGX +aggravating/Y +aggravation/M +aggregate/EGNVD +aggregated/U +aggregately +aggregateness/M +aggregates +aggregation/SM +aggregative/Y +aggression/SM +aggressive/U +aggressively +aggressiveness/S +aggressor/MS +aggrieve/GDS +aggrieved/Y +aghast +agile/YTR +agility/MS +agitate/XVNGSD +agitated/Y +agitation/M +agitator/SM +agitprop/MS +agleam +aglitter +aglow +agnostic/SM +agnosticism/MS +ago +agog +agonize/ZGRSD +agonized/Y +agonizedly/S +agonizing/Y +agony/SM +agoraphobia/MS +agoraphobic/S +agrarian/S +agrarianism/MS +agree/LEBDS +agreeable/EP +agreeableness/SME +agreeably/E +agreeing/E +agreement/ESM +agreer/S +agribusiness/SM +agricultural/Y +agriculturalist/S +agriculture/MS +agriculturist/SM +agrochemicals +agronomic/S +agronomist/SM +agronomy/MS +aground +ague/MS +ah +aha/S +ahead +ahem/S +ahoy/S +aid/ZGDRS +aide/MS +aided/U +aider/M +aigrette/SM +ail/LSDG +aileron/MS +ailment/SM +aim/ZSGDR +aimer/M +aimless/YP +aimlessness/MS +ain't +air/MDRTZGJS +airbag/MS +airbase/S +airborne +airbrush/SDMG +airbus/SM +aircraft/MS +aircrew/M +airdrop/MS +airdropped +airdropping +airfare/S +airfield/MS +airflow/SM +airfoil/MS +airframe/MS +airfreight/SGD +airhead/MS +airily +airiness/MS +airing/M +airless/P +airlessness/S +airlift/MDSG +airline/SRMZ +airliner/M +airlock/MS +airmail/DSG +airman/M +airmass +airmen +airpark +airplane/SM +airplay/S +airport/MS +airship/MS +airsick/P +airsickness/SM +airspace/SM +airspeed/SM +airstrip/MS +airtight/P +airtightness/M +airtime +airwaves +airway/SM +airworthiness/SM +airworthy/PTR +airy/PRT +aisle/DSGM +aitch/MS +ajar +aka +akimbo +akin +ala/MS +alabaster/MS +alack/S +alacrity/SM +alanine/M +alarm/SDG +alarming/Y +alarmist/MS +alas/S +alb/MS +alba/M +albacore/SM +albatross/SM +albedo/M +albeit +albinism/SM +albino/MS +album/MNXS +albumen/M +albumin/MS +albuminous +alchemical +alchemist/SM +alchemy/MS +alcohol/MS +alcoholic/MS +alcoholically +alcoholism/SM +alcove/MSD +aldehyde/M +alder/SM +alderman/M +aldermen +alderwoman +alderwomen +ale/MVS +aleatory +alee +alehouse/MS +alembic/SM +aleph/M +alert/STZGPRDY +alerted/Y +alertness/MS +alewife/M +alewives +alfalfa/MS +alfresco +alga/M +algae +algaecide +algal +algebra/MS +algebraic +algebraical/Y +algebraist/M +alginate/SM +algorithm/MS +algorithmic +algorithmically +alias/GSD +alibi/MDSG +alien/RDGMBS +alienable/IU +alienate/SDNGX +alienation/M +alienist/MS +alight/DSG +align/LASDG +aligned/U +aligner/SM +alignment/SAM +alike/U +alikeness/M +aliment/SDMG +alimentary +alimony/MS +alinement's +aliquot/S +alive/P +aliveness/MS +aliyah/M +aliyahs +alkali/M +alkalies +alkaline +alkalinity/MS +alkalize/SDG +alkaloid/MS +alkyd/S +alkyl/M +all-time +all/S +allay/GDS +allegation/SM +allege/SDG +alleged/Y +allegiance/SM +allegiant +allegoric +allegorical/YP +allegoricalness/M +allegorist/MS +allegory/SM +allegretto/MS +allegri +allegro/MS +allele/SM +alleluia/S +allemande/M +allergen/MS +allergenic +allergic +allergically +allergist/MS +allergy/MS +alleviate/SDVGNX +alleviation/M +alleviator/MS +alley/MS +alleyway/MS +alliance/MS +allier +allies/M +alligator/DMGS +alliterate/XVNGSD +alliteration/M +alliterative/Y +allocable/U +allocatable +allocate/ACSDNGX +allocated/U +allocation/AMC +allocative +allocator/AMS +allophone/MS +allophonic +allot/SDL +allotment/MS +allotments/A +allotrope/M +allotropic +allots/A +allotted/A +allotter/M +allotting/A +allover/S +allow/SBGD +allowable/P +allowableness/M +allowably +allowance/GSDM +allowed/Y +allowing/E +allows/E +alloy/SGMD +alloyed/U +allspice/MS +allude/GSD +allure/GLSD +allurement/SM +alluring/Y +allusion/MS +allusive/PY +allusiveness/MS +alluvial/S +alluvions +alluvium/MS +ally/ASDG +alma +almagest +almanac/MS +almightiness/M +almighty/P +almond/SM +almoner/MS +almost +alms/A +almshouse/SM +almsman/M +alnico +aloe/MS +aloft +aloha/SM +alone/P +aloneness/M +along +alongshore +alongside +aloof/YP +aloofness/MS +aloud +alp/MS +alpaca/SM +alpha/MS +alphabet/SGDM +alphabetic/S +alphabetical/Y +alphabetization/SM +alphabetize/SRDGZ +alphabetizer/M +alphanumeric/S +alphanumerical/Y +alpine/S +already +alright +also +alt/RZS +altar/MS +altarpiece/SM +alter/RDZBG +alterable/UI +alteration/MS +altercate/NX +altercation/M +altered/U +alternate/SDVGNYX +alternation/M +alternative/YMSP +alternativeness/M +alternator/MS +although +altimeter/SM +altitude/SM +alto/SM +altogether/S +altruism/SM +altruist/SM +altruistic +altruistically +alum/SM +alumina/SM +aluminum/MS +alumna/M +alumnae +alumni +alumnus/MS +alundum +alveolar/Y +alveoli +alveolus/M +alway/S +am/AS +amain +amalgam/MS +amalgamate/VNGXSD +amalgamation/M +amanuenses +amanuensis/M +amaranth/M +amaranths +amaretto/S +amaryllis/MS +amass/GRSD +amasser/M +amateur/SM +amateurish/YP +amateurishness/MS +amateurism/MS +amatory +amaze/LDSRGZ +amazed/Y +amazement/MS +amazing/Y +amazon/MS +amazonian +ambassador/MS +ambassadorial +ambassadorship/MS +ambassadress/SM +amber/MS +ambergris/SM +ambiance/MS +ambidexterity/MS +ambidextrous/Y +ambience's +ambient/S +ambiguity/MS +ambiguous/YP +ambiguously/U +ambiguousness/M +ambit/M +ambition/GMDS +ambitious/PY +ambitiousness/MS +ambivalence/SM +ambivalent/Y +amble/GZDSR +ambler/M +ambrose +ambrosia/SM +ambrosial/Y +ambulance/MS +ambulant/S +ambulate/DSNGX +ambulation/M +ambulatory/S +ambuscade/MGSRD +ambuscader/M +ambush/MZRSDG +ambusher/M +ameba's +ameliorate/XVGNSD +amelioration/M +amen/DRGTSB +amenability/SM +amenably +amend/SBRDGL +amended/U +amender/M +amendment/SM +amends/M +amenity/MS +amenorrhea/M +amerce/SDLG +amercement/MS +americanized +americium/MS +amethyst/MS +amethystine +amiability/MS +amiable/RPT +amiableness/M +amiably +amicability/SM +amicable/P +amicableness/M +amicably +amid/S +amide/SM +amidships +amidst +amigo/MS +amines +amino/M +aminobenzoic +amir's +amiss +amity/SM +ammeter/MS +ammo/MS +ammonia/MS +ammoniac +ammonium/M +ammunition/MS +amnesia/SM +amnesiac/MS +amnesic/S +amnesty/GMSD +amniocenteses +amniocentesis/M +amnion/SM +amniotic +amoeba/SM +amoebic +amoeboid +amok/MS +among +amongst +amontillado/MS +amoral/Y +amorality/MS +amorous/PY +amorousness/SM +amorphous/PY +amorphousness/MS +amortization/SUM +amortize/SDG +amortized/U +amount/SMRDZG +amour/MS +amp/SGMDY +amperage/SM +ampere/MS +ampersand/MS +amphetamine/MS +amphibian/SM +amphibious/PY +amphibiousness/M +amphibology/M +amphitheater/SM +amphora/M +amphorae +ample/PTR +ampleness/M +amplification/M +amplifier/M +amplify/DRSXGNZ +amplitude/MS +ampoule's +ampule/SM +amputate/DSNGX +amputation/M +amputee/SM +ams +amt +amuck's +amulet/SM +amuse/LDSRGVZ +amused/Y +amusement/SM +amuser/M +amusing/YP +amusingness/M +amyl/M +amylase/MS +an/CS +anabolic +anabolism/MS +anachronism/SM +anachronistic +anachronistically +anaconda/MS +anaerobe/SM +anaerobic +anaerobically +anaglyph/M +anagram/MS +anagrammatic +anagrammatically +anagrammed +anagramming +anal/Y +analgesia/MS +analgesic/S +analog/SM +analogical/Y +analogize/SDG +analogous/YP +analogousness/MS +analogue/SM +analogy/MS +analysand/MS +analyses +analysis/AM +analyst/SM +analytic/S +analytical/Y +analyticity/S +analytics/M +analyzable/U +analyze/DRSZGA +analyzed/U +analyzer/M +anamorphic +anapaest's +anapest/SM +anapestic/S +anaphora/M +anaphoric +anaphorically +anaplasmosis/M +anarchic +anarchical/Y +anarchism/MS +anarchist/MS +anarchistic +anarchy/MS +anastigmatic +anastomoses +anastomosis/M +anastomotic +anathema/MS +anathematize/GSD +anatomic +anatomical/YS +anatomist/MS +anatomize/GSD +anatomy/MS +ancestor/SMDG +ancestral/Y +ancestress/SM +ancestry/SM +anchor/SGDM +anchorage/SM +anchored/U +anchorite/MS +anchoritism/M +anchorman/M +anchormen +anchorpeople +anchorperson/S +anchorwoman +anchorwomen +anchovy/MS +ancient/SRYTP +ancientness/MS +ancillary/S +and/DZGS +andante/S +andiron/MS +androgen/SM +androgenic +androgynous +androgyny/SM +android/MS +anecdotal/Y +anecdote/SM +anechoic +anemia/SM +anemic/S +anemically +anemometer/MS +anemometry/M +anemone/SM +anent +aneroid +anesthesia/MS +anesthesiologist/MS +anesthesiology/SM +anesthetic/SM +anesthetically +anesthetist/MS +anesthetization/SM +anesthetize/ZSRDG +anesthetizer/M +aneurysm/MS +anew +angel/MDSG +angelfish/SM +angelic +angelica/MS +angelical/Y +anger/GDMS +angina/MS +angiography +angioplasty/S +angiosperm/MS +angle/GMZDSRJ +angler/M +angleworm/MS +anglicize/SDG +angling/M +angora/MS +angrily +angriness/M +angry/RTP +angst/MS +angstrom/MS +anguish/DSMG +angular/Y +angularity/MS +anhydride/M +anhydrite/M +anhydrous/Y +aniline/SM +animadversion/SM +animadvert/DSG +animal/MYPS +animalcule/MS +animate/YNGXDSP +animated/A +animatedly +animately/I +animateness/MI +animates/A +animating/A +animation/AMS +animator/SM +animism/SM +animist/S +animistic +animized +animosity/MS +animus/SM +anion/MS +anionic/S +anise/MS +aniseed/MS +aniseikonic +anisette/SM +anisotropic +anisotropy/MS +ankh/M +ankhs +ankle/GMDS +anklebone/SM +anklet/MS +annal/MNS +annalist/MS +anneal/DRSZG +annealer/M +annelid/MS +annex/GSD +annexation/SM +annexe/M +annihilate/XSDVGN +annihilation/M +annihilator/MS +anniversary/MS +annotate/VNGXSD +annotated/U +annotation/M +annotator/MS +announce/ZGLRSD +announced/U +announcement/SM +announcer/M +annoy/ZGSRD +annoyance/MS +annoyer/M +annoying/Y +annual/YS +annualized +annuitant/MS +annuity/MS +annul/SL +annular/YS +annuli +annulled +annulling +annulment/MS +annulus/M +annum +annunciate/XNGSD +annunciation/M +annunciator/SM +anode/SM +anodic +anodize/GDS +anodyne/SM +anoint/DRLGS +anointer/M +anointment/SM +anomalous/YP +anomalousness/M +anomaly/MS +anomic +anomie/M +anon/S +anonymity/MS +anonymous/YP +anonymousness/M +anopheles/M +anorak/SM +anorectic/S +anorexia/SM +anorexic/S +another/M +ans/M +answer/MZGBSDR +answerable/U +answered/U +answerer/M +ant/GSMD +antacid/MS +antagonism/MS +antagonist/MS +antagonistic +antagonistically +antagonize/GZRSD +antagonized/U +antagonizing/U +antarctic +ante/MS +anteater/MS +antebellum +antecedence/MS +antecedent/SMY +antechamber/SM +antedate/GDS +antediluvian/S +anteing +antelope/MS +antenatal +antenna/MS +antennae +anterior/SY +anteroom/SM +anthem/MGDS +anther/MS +anthill/S +anthologist/MS +anthologize/GDS +anthology/SM +anthraces +anthracite/MS +anthrax/M +anthropic +anthropocentric +anthropogenic +anthropoid/S +anthropological/Y +anthropologist/MS +anthropology/SM +anthropometric/S +anthropometry/M +anthropomorphic +anthropomorphically +anthropomorphism/SM +anthropomorphizing +anthropomorphous +anti/S +antiabortion +antiabortionist/S +antiaircraft +antibacterial/S +antibiotic/SM +antibody/MS +antic/MS +anticancer +anticipate/XVGNSD +anticipated/U +anticipation/M +anticipative/Y +anticipatory +anticked +anticking +anticlerical/S +anticlimactic +anticlimactically +anticlimax/SM +anticline/SM +anticlockwise +anticoagulant/S +anticoagulation/M +anticommunism/SM +anticommunist/SM +anticompetitive +anticyclone/MS +anticyclonic +antidemocratic +antidepressant/SM +antidisestablishmentarianism/M +antidote/DSMG +antifascist/SM +antiformant +antifreeze/SM +antifundamentalist/M +antigen/MS +antigenic +antigenicity/SM +antigone +antihero/M +antiheroes +antihistamine/MS +antihistorical +antiknock/MS +antilabor +antilogarithm/SM +antilogs +antimacassar/SM +antimalarial/S +antimatter/SM +antimicrobial/S +antimissile/S +antimony/SM +anting/M +antinomian +antinomy/M +antinuclear +antioxidant/MS +antiparticle/SM +antipasti +antipasto/MS +antipathetic +antipathy/SM +antipersonnel +antiperspirant/MS +antiphon/SM +antiphonal/SY +antipodal/S +antipode/MS +antipodean/S +antipollution/S +antipoverty +antiquarian/MS +antiquarianism/MS +antiquary/SM +antiquate/NGSD +antiquation/M +antique/MGDS +antiquity/SM +antiredeposition +antiresonance/M +antiresonator +antisemitic +antisemitism/M +antisepses +antisepsis/M +antiseptic/S +antiseptically +antiserum/SM +antislavery/S +antisocial/Y +antispasmodic/S +antisubmarine +antisymmetric +antisymmetry +antitank +antitheses +antithesis/M +antithetic +antithetical/Y +antithyroid +antitoxin/MS +antitrust/MR +antivenin/MS +antiviral/S +antivivisectionist/S +antiwar +antler/SDM +antonym/SM +antonymous +antral +antsy/RT +anus/SM +anvil/MDSG +anxiety/MS +anxious/PY +anxiousness/SM +any +anybody/S +anyhow +anymore +anyone/MS +anyplace +anything/S +anytime +anyway/S +anywhere/S +anywise +aorta/MS +aortic +apace +apache/MS +apart/LP +apartheid/SM +apartment/MS +apartness/M +apathetic +apathetically +apathy/SM +apatite/MS +ape/MDRSG +aped/A +apelike +aper/A +aperiodic +aperiodically +aperiodicity/M +aperitif/S +aperture/MDS +apex/MS +aphasia/SM +aphasic/S +aphelia +aphelion/SM +aphid/MS +aphonic +aphorism/MS +aphoristic +aphoristically +aphrodisiac/SM +apiarist/SM +apiary/SM +apical/YS +apices's +apiece +apish/YP +apishness/M +aplenty +aplomb/SM +apocalypse/MS +apocalyptic +apocrypha/M +apocryphal/YP +apocryphalness/M +apogee/MS +apolar +apolitical/Y +apologetic/S +apologetically/U +apologetics/M +apologia/SM +apologist/MS +apologize/GZSRD +apologizer/M +apologizes/A +apologizing/U +apology/MS +apoplectic +apoplexy/SM +apostasy/SM +apostate/SM +apostatize/DSG +apostle/SM +apostleship/SM +apostolic +apostrophe/SM +apostrophized +apothecary/MS +apothegm/MS +apotheoses +apotheosis/M +apotheosized +apotheosizes +apotheosizing +appall/SDG +appalling/Y +appaloosa/S +appanage/M +apparatus/SM +apparel/SGMD +apparency +apparent/U +apparently/I +apparentness/M +apparition/SM +appeal/SGMDRZ +appealer/M +appealing/UY +appear/AEGDS +appearance/AMES +appearer/S +appease/DSRGZL +appeased/U +appeasement/MS +appeaser/M +appellant/MS +appellate/VNX +appellation/M +appellative/MY +append/SGZDR +appendage/MS +appendectomy/SM +appendices +appendicitis/SM +appendix/SM +appertain/DSG +appetite/MVS +appetizer/SM +appetizing/YU +applaud/ZGSDR +applauder/M +applause/MS +apple/MS +applecart/M +applejack/MS +applesauce/SM +applet/S +appliance/SM +applicabilities +applicability/IM +applicable/I +applicably +applicant/MS +applicate/V +application/MA +applicative/Y +applicator/MS +applier/SM +appliqu�/MSG +appliqu�d +apply/AGSDXN +appoint/ELSADG +appointee/SM +appointer/MS +appointive +appointment/ASEM +apportion/GADLS +apportionment/SAM +appose/SDG +apposite/XYNVP +appositeness/MS +apposition/M +appositive/SY +appraisal/SAM +appraise/ZGDRS +appraised/A +appraisees +appraiser/M +appraises/A +appraising/Y +appreciable/I +appreciably/I +appreciate/XDSNGV +appreciated/U +appreciation/M +appreciative/PIY +appreciativeness/MI +appreciator/MS +appreciatory +apprehend/DRSG +apprehender/M +apprehensible +apprehension/SM +apprehensive/YP +apprehensiveness/SM +apprentice/DSGM +apprenticeship/SM +apprise/DSG +apprizer/SM +apprizingly +apprizings +approach/BRSDZG +approachability/UM +approachable/UI +approacher/M +approbate/NX +approbation/EMS +appropriable +appropriate/XDSGNVYTP +appropriated/U +appropriately/I +appropriateness/SMI +appropriation/M +appropriator/SM +approval/ESM +approve/DSREG +approved/U +approver's/E +approver/SM +approving/YE +approx +approximate/XGNVYDS +approximation/M +approximative/Y +appurtenance/MS +appurtenant/S +apricot/MS +apron/SDMG +apropos +apse/MS +apsis/M +apt/UPYI +apter +aptest +aptitude/SM +aptness's/U +aptness/SMI +aqua/SM +aquaculture/MS +aqualung/SM +aquamarine/SM +aquanaut/SM +aquaplane/GSDM +aquarium/MS +aquatic/S +aquatically +aquavit/SM +aqueduct/MS +aqueous/Y +aquiculture's +aquifer/SM +aquiline +arabesque/SM +arability/MS +arable/S +arachnid/MS +arachnoid/M +arachnophobia +arbiter/MS +arbitrage/GMZRSD +arbitrager/M +arbitrageur/S +arbitrament/MS +arbitrarily +arbitrariness/MS +arbitrary/P +arbitrate/SDXVNG +arbitration/M +arbitrator/SM +arbor/DMS +arboreal/Y +arbores +arboretum/MS +arborvitae/MS +arbutus/SM +arc/DSGM +arcade/SDMG +arcana/M +arcane/P +arch/PGVZTMYDSR +archaeological/Y +archaeologist/SM +archaic/P +archaically +archaism/SM +archaist/MS +archaize/GDRSZ +archaizer/M +archangel/SM +archbishop/SM +archbishopric/SM +archdeacon/MS +archdiocesan +archdiocese/SM +archduchess/MS +archduke/MS +archenemy/SM +archeologist's +archeology/MS +archer/M +archery/MS +archetypal +archetype/SM +archfiend/SM +archfool +archiepiscopal +arching/M +archipelago/SM +architect/MS +architectonic/S +architectonics/M +architectural/Y +architecture/SM +architrave/MS +archival +archive/DRSGMZ +archived/U +archivist/MS +archness/MS +archway/SM +arclike +arcsine +arctangent +arctic/S +ardency/M +ardent/Y +ardor/SM +arduous/YP +arduousness/SM +are/BS +area/SM +areal +areawide +aren't +arena/SM +arenaceous +argent/MS +arginine/MS +argon/MS +argonaut/S +argosy/SM +argot/SM +arguable/IU +arguably/IU +argue/DSRGZ +arguer/M +argument/SM +argumentation/SM +argumentative/YP +argumentativeness/MS +argyle/S +aria/SM +arid/TYRP +aridity/SM +aridness/M +aright +arise/GJSR +arisen +aristocracy/SM +aristocrat/MS +aristocratic +aristocratically +arithmetic/MS +arithmetical/Y +arithmetician/SM +arithmetize/SD +ark/MS +arm's +arm/ASEDG +armada/SM +armadillo/MS +armament's/E +armament/EAS +armature/MGSD +armband/SM +armchair/MS +armed/U +armer/MES +armful/SM +armhole/MS +arming/M +armistice/MS +armless +armlet/SM +armload/M +armor/ZRDMGS +armored/U +armorer/M +armorial/S +armory/DSM +armpit/MS +armrest/MS +army/SM +aroma/SM +aromatherapist/S +aromatherapy/S +aromatic/SP +aromatically +aromaticity/M +aromaticness/M +arose +around +arousal/MS +arouse/GSD +aroused/U +arpeggio/SM +arr/TV +arrack/M +arraign/SDGL +arraignment/MS +arrange/ZDSRLG +arrangeable/A +arranged/EA +arrangement/AMSE +arranger/M +arranges/EA +arranging/EA +arrant/Y +arras/SM +array/ESGMD +arrayer +arrear/SM +arrest/ADSG +arrestee/MS +arrester/MS +arresting/Y +arrestor/MS +arrhythmia/SM +arrhythmic +arrhythmical +arrival/MS +arrive/SRDG +arriver/M +arrogance/MS +arrogant/Y +arrogate/XNGDS +arrogation/M +arrow/SDMG +arrowhead/SM +arrowroot/MS +arroyo/MS +arsenal/MS +arsenate/M +arsenic/MS +arsenide/M +arsine/MS +arson/SM +arsonist/MS +art/SM +artefact's +arterial/SY +arteriolar +arteriole/SM +arterioscleroses +arteriosclerosis/M +artery/SM +artesian +artful/YP +artfulness/SM +arthritic/S +arthritides +arthritis/M +arthrogram/MS +arthropod/SM +arthroscope/S +arthroscopic +artichoke/SM +article/GMDS +articulable/I +articular +articulate/VGNYXPSD +articulated/EU +articulately/I +articulateness/IMS +articulates/I +articulation/M +articulator/SM +articulatory +artifact/MS +artifice/ZRSM +artificer/M +artificial/PY +artificiality/MS +artificialness/M +artillerist +artillery/SM +artilleryman/M +artillerymen +artiness/MS +artisan/SM +artist/MS +artiste/SM +artistic/I +artistically/I +artistry/SM +artless/YP +artlessness/MS +artsy/RT +artwork/MS +arty/TPR +arum/MS +as +asap +asbestos/MS +ascend/ADGS +ascendancy/MS +ascendant/SY +ascender/SM +ascension/SM +ascent/SM +ascertain/DSBLG +ascertainment/MS +ascetic/SM +ascetically +asceticism/MS +ascot/MS +ascribe/GSDB +ascription/MS +ascriptive +aseptic/S +aseptically +asexual/Y +asexuality/MS +ash/MNDRSG +ashame/D +ashamed/UY +ashcan/SM +ashlar/GSDM +ashman/M +ashore +ashram/SM +ashtray/MS +ashy/RT +aside/S +asinine/Y +asininity/MS +ask/DRZGS +askance +asked/U +asker/M +askew/P +aslant +asleep +asocial/S +asp/MNRXS +asparagus/MS +aspartame/S +aspect/SM +aspen/M +asper/M +asperity/SM +aspersion/SM +asphalt/MDRSG +asphodel/MS +asphyxia/MS +asphyxiate/GNXSD +asphyxiation/M +aspic/MS +aspidistra/MS +aspirant/MS +aspirate/NGDSX +aspiration/M +aspirational +aspirator/SM +aspire/GSRD +aspirer/M +aspirin/SM +asplenium +ass/MNS +assail/BGDS +assailable/U +assailant/SM +assassin/MS +assassinate/DSGNX +assassination/M +assault/SGVMDR +assaulter/M +assaultive/YP +assay/SZGRD +assayer/M +assemblage/MS +assemble/ADSREG +assembled/U +assembler/EMS +assemblies/A +assembly/EAM +assemblyman/M +assemblymen +assemblywoman +assemblywomen +assent/SGMRD +assert/ADGS +asserter/MS +assertion/AMS +assertional +assertive/PY +assertiveness/SM +assess/BLSDG +assessed/A +assesses/A +assessment/SAM +assessor/MS +asset/SM +asseverate/XSDNG +asseveration/M +asshole/MS! +assiduity/SM +assiduous/PY +assiduousness/SM +assign/ALBSGD +assignation/MS +assigned/U +assignee/MS +assigner/MS +assignment/MAS +assignor/MS +assigns/CU +assimilate/VNGXSD +assimilation/M +assimilationist/M +assist/RDGS +assistance/SM +assistant/SM +assistantship/SM +assisted/U +assister/M +assize/MGSD +assn +assoc +associable +associate/SDEXNG +associated/U +associateship +association/ME +associational +associative/Y +associativity/S +associator/MS +assonance/SM +assonant/S +assort/LRDSG +assorter/M +assortment/SM +asst +assuage/SDG +assuaged/U +assumability +assume/SRDBJG +assumer/M +assuming/UA +assumption/SM +assumptive +assurance/AMS +assure/AGSD +assured/PYS +assuredness/M +assurer/SM +assuring/YA +astatine/MS +aster/ESM +asteria +asterisk/SGMD +asterisked/U +astern +asteroid/SM +asteroidal +asthma/MS +asthmatic/S +astigmatic/S +astigmatism/SM +astir +astonish/GSDL +astonishing/Y +astonishment/SM +astound/SDG +astounding/Y +astraddle +astrakhan/SM +astral/SY +astray +astride +astringency/SM +astringent/YS +astrolabe/MS +astrologer/MS +astrological/Y +astrologist/M +astrology/SM +astronaut/SM +astronautic/S +astronautical +astronautics/M +astronomer/MS +astronomic +astronomical/Y +astronomy/SM +astrophysical +astrophysicist/SM +astrophysics/M +astute/RTYP +astuteness/MS +asunder +asylum/MS +asymmetric +asymmetrical/Y +asymmetry/MS +asymptomatic +asymptomatically +asymptote/MS +asymptotic/Y +asymptotically +asynchronism/M +asynchronous/Y +asynchrony +at +atavism/MS +atavist/MS +atavistic +ataxia/MS +ataxic/S +ate/S +atelier/SM +atemporal +atheism/SM +atheist/SM +atheistic +atheroscleroses +atherosclerosis/M +athirst +athlete/MS +athletic/S +athletically +athleticism/M +athletics/M +athwart +atilt +atlantes +atlas/SM +atmosphere/DSM +atmospheric/S +atmospherically +atoll/MS +atom/SM +atomic/S +atomically +atomicity/M +atomics/M +atomistic +atomization/SM +atomize/GZDRS +atomizer/M +atonal/Y +atonality/MS +atone/LDSG +atonement/SM +atop +atria +atrial +atrium/M +atrocious/YP +atrociousness/SM +atrocity/SM +atrophic +atrophy/DSGM +atropine/SM +attach/BLGZMDRS +attached/UA +attacher/M +attachment/ASM +attach�/S +attack/GBZSDR +attacker/M +attain/AGSD +attainabilities +attainability/UM +attainable/U +attainableness/M +attainably/U +attainder/MS +attained/U +attainer/MS +attainment/MS +attar/MS +attempt/ADSG +attempter/MS +attend/SGZDR +attendance/MS +attendant/SM +attended/U +attendee/SM +attender/M +attention/IMS +attentional +attentionality +attentive/YIP +attentiveness/IMS +attenuate/SDXGN +attenuated/U +attenuation/M +attenuator/MS +attest/GSDR +attestation/SM +attested/U +attester/M +attic/MS +attire/SDG +attitude/MS +attitudinal/Y +attitudinize/SDG +attn +attorney/SM +attract/BSDGV +attractant/SM +attraction/MS +attractive/UYP +attractiveness/UM +attractivenesses +attractor/MS +attributable/U +attribute/BVNGRSDX +attributed/U +attributer/M +attribution/M +attributional +attributive/SY +attrition/MS +attune/SDG +atty +atwitter +atypical/Y +aubergine/MS +auburn/SM +auction/MDSG +auctioneer/SDMG +audacious/PY +audaciousness/SM +audacity/MS +audibility/MSI +audible/I +audibles +audibly/I +audience/MS +audio/SM +audiogram/SM +audiological +audiologist/MS +audiology/SM +audiometer/MS +audiometric +audiometry/M +audiophile/SM +audiotape/S +audiovisual/S +audit/SMDVG +audited/U +audition/MDSG +auditor/MS +auditorium/MS +auditory/S +auger/SM +aught/S +augment/DRZGS +augmentation/SM +augmentative/S +augmenter/M +augur/GDMS +augury/SM +august/STPYR +augustness/SM +auk/MS +aunt/MYS +auntie/MS +aunty's +aura/SM +aural/Y +aureole/GMSD +aureomycin +auric +auricle/SM +auricular +aurora/SM +auroral +auscultate/XDSNG +auscultation/M +auspice/SM +auspicious/IPY +auspiciousness/IM +auspiciousnesses +austere/TYRP +austereness/M +austerity/SM +austral +australes +australites +authentic/UI +authentically +authenticate/GNDSX +authenticated/U +authentication/M +authenticator/MS +authenticity/MS +author/DMGS +authoress/S +authorial +authoritarian/S +authoritarianism/MS +authoritative/PY +authoritativeness/SM +authority/SM +authorization/MAS +authorize/AGDS +authorized/U +authorizer/SM +authorizes/U +authorship/MS +autism/MS +autistic/S +auto/SDMG +autobahn/MS +autobiographer/MS +autobiographic +autobiographical/Y +autobiography/MS +autoclave/SDGM +autocollimator/M +autocorrelate/GNSDX +autocorrelation/M +autocracy/SM +autocrat/SM +autocratic +autocratically +autodial/R +autodidact/MS +autofluorescence +autograph/MDG +autographs +autoignition/M +autoimmune +autoimmunity/S +autoloader +automaker/S +automata's +automate/NGDSX +automatic/S +automatically +automation/M +automatism/SM +automatize/DSG +automaton/SM +automobile/GDSM +automorphism/SM +automotive +autonavigator/SM +autonomic/S +autonomous/Y +autonomy/MS +autopilot/SM +autopsy/MDSG +autoregressive +autorepeat/GS +autostart +autosuggestibility/M +autotransformer/M +autoworker/S +autumn/MS +autumnal/Y +aux +auxiliary/S +auxin/MS +av/ZR +avail/BSZGRD +availability/USM +available/U +availableness/M +availably +availing/U +avalanche/MGSD +avant +avarice/SM +avaricious/PY +avariciousness/M +avast/S +avatar/MS +avaunt/S +avdp +ave/S +avenge/ZGSRD +avenged/U +avenger/M +avenue/MS +average/DSPGYM +averred +averrer +averring +avers/V +averse/YNXP +averseness/M +aversion/M +avert/GSD +aves/C +avg +avian/S +aviary/SM +aviate/NX +aviation/M +aviator/SM +aviatrices +aviatrix/SM +avid/TPYR +avidity/MS +avionic/S +avionics/M +avitaminoses +avitaminosis/M +avocado/MS +avocation/SM +avocational +avoid/ZRDBGS +avoidable/U +avoidably/U +avoidance/SM +avoider/M +avoirdupois/MS +avouch/GDS +avow/GEDS +avowal/EMS +avowed/Y +avower/M +avuncular +aw/GD +await/SDG +awake/GS +awaken/SADG +awakened/U +awakener/M +awakening/S +award/RDSZG +awarder/M +aware/TRP +awareness/MSU +awash +away/PS +awe/SM +aweigh +awesome/PY +awesomeness/SM +awestruck +awful/YP +awfuller +awfullest +awfulness/SM +awhile/S +awkward/PRYT +awkwardness/MS +awl/MS +awn/MDJGS +awning/DM +awoke +awoken +awry/RT +ax/DRSZGM +axehead/S +axeman +axial/Y +axillary +axiological/Y +axiology/M +axiom/SM +axiomatic/S +axiomatically +axiomatization/MS +axiomatize/GDS +axion/SM +axis/SM +axle/MS +axletree/MS +axolotl/SM +axon/SM +ayah/M +ayahs +ayatollah +ayatollahs +aye/MZRS +azalea/SM +azimuth/M +azimuthal/Y +azimuths +azure/MS +b/KGD +baa/SDG +babbitt/GDS +babble/RSDGZ +babbler/M +babe/SM +babel/S +baboon/MS +babushka/MS +baby/TDSRMG +babyhood/MS +babyish +babysat +babysit/S +babysitter/S +babysitting +baccalaureate/MS +baccarat/SM +bacchanal/SM +bacchanalia +bacchanalian/S +bachelor/SM +bachelorhood/SM +bacillary +bacilli +bacillus/MS +back/GZDRMSJ +backache/SM +backarrow +backbench/ZR +backbencher/M +backbit/ZGJR +backbite/S +backbiter/M +backbitten +backboard/SM +backbone/SM +backbreaking +backchaining +backcloth/M +backdate/GDS +backdrop/MS +backdropped +backdropping +backed/U +backer/M +backfield/SM +backfill/SDG +backfire/GDS +backgammon/MS +background/SDRMZG +backhand/RDMSZG +backhanded/Y +backhander/M +backhoe/S +backing/M +backlash/GRSDM +backless +backlog/MS +backlogged +backlogging +backorder +backpack/ZGSMRD +backpacker/M +backpedal/DGS +backplane/MS +backplate/SM +backrest/MS +backscatter/SMDG +backseat/S +backside/SM +backslapper/MS +backslapping/M +backslash/DSG +backslid/RZG +backslide/S +backslider/M +backspace/GSD +backspin/SM +backstabber/M +backstabbing +backstage +backstair/S +backstitch/GDSM +backstop/MS +backstopped +backstopping +backstreet/M +backstretch/SM +backstroke/GMDS +backtalk/S +backtrack/SDRGZ +backup/SM +backward/YSP +backwardness/MS +backwash/SDMG +backwater/SM +backwood/S +backwoodsman/M +backwoodsmen +backyard/MS +bacon/SRM +baconer/M +bacteria/MS +bacterial/Y +bactericidal +bactericide/SM +bacteriologic +bacteriological +bacteriologist/MS +bacteriology/SM +bacterium/M +bad/PSNY +badder +baddest +baddie/MS +bade +badge/DSRGMZ +badger/DMG +badinage/DSMG +badland/S +badman/M +badmen +badminton/MS +badmouth/DG +badmouths +badness/SM +baffle/RSDGZL +bafflement/MS +baffler/M +baffling/Y +bag/SM +bagatelle/MS +bagel/SM +bagful/MS +baggage/SM +baggageman +baggagemen +bagged/M +bagger/SM +baggily +bagginess/MS +bagging/M +baggy/PRST +bagpipe/RSMZ +bagpiper/M +baguette/SM +bah +bahs +bail/GSMYDRB +bailiff/SM +bailiwick/MS +bailout/MS +bailsman/M +bailsmen +bairn/SM +bait/GSMDR +baiter/M +baize/GMDS +bake/ZGJDRS +baked/U +bakehouse/M +baker/M +bakery/SM +bakeshop/S +baking/M +baklava/M +baksheesh/SM +balaclava/MS +balalaika/MS +balance's +balance/USDG +balanced/A +balancedness +balancer/MS +balboa/SM +balcony/MSD +bald/PYDRGST +balderdash/MS +baldfaced +baldness/MS +baldric/SM +baldy +bale/MZGDRS +baleen/MS +baleful/YP +balefuller +balefullest +balefulness/MS +baler/M +balk/GDRS +balkanization +balkanize/DG +balker/M +balkiness/M +balky/PRT +ball/GZMSDR +ballad/SM +ballade/MS +balladeer/MS +balladry/MS +ballast/SGMD +ballcock/S +baller/M +ballerina/MS +ballet/MS +balletic +ballfields +ballgame/S +ballistic/S +ballistics/M +balloon/RDMZGS +balloonist/S +ballot/MRDGS +balloter/M +ballpark/SM +ballplayer/SM +ballpoint/SM +ballroom/SM +ballsy/TR +ballyhoo/SGMD +balm/MS +balminess/SM +balmy/PRT +baloney/SM +balsa/MS +balsam/GMDS +balsamic +baluster/MS +balustrade/SM +bamboo/SM +bamboozle/GSD +ban/SGMD +banal/TYR +banality/MS +banana/SM +band's +band/EDGS +bandage/RSDMG +bandager/M +bandanna/SM +bandbox/MS +bandeau/M +bandeaux +bander/M +banding/M +bandit/MS +banditry/MS +bandmaster/MS +bandoleer/SM +bandpass +bandsman/M +bandsmen +bandstand/SM +bandstop +bandwagon/MS +bandwidth/M +bandwidths +bandy/TGRSD +bane/MS +baneful/Y +banefuller +banefullest +bang/GDRZMS +banger/M +bangkok +bangle/MS +bani +banish/RSDGL +banisher/M +banishment/MS +banister/MS +banjo/MS +banjoist/SM +bank/GZJDRMBS +bankbook/SM +bankcard/S +banker/M +banking/M +banknote/S +bankroll/DMSG +bankrupt/DMGS +bankruptcy/MS +banned/U +banner/SDMG +banning/U +bannister's +bannock/SM +banns +banquet/SZGJMRD +banqueter/M +banquette/MS +bans/U +banshee/MS +bantam/MS +bantamweight/MS +banter/RDSG +banterer/M +bantering/Y +banyan/MS +banzai/S +baobab/SM +baptism/SM +baptismal/Y +baptist/MS +baptistery/MS +baptistry's +baptize/SRDZG +baptized/U +baptizer/M +baptizes/U +bar/TGMDRS +barb/DRMSGZ +barbarian/MS +barbarianism/MS +barbaric +barbarically +barbarism/MS +barbarity/SM +barbarize/SDG +barbarous/PY +barbarousness/M +barbecue/DRSMG +barbed/P +barbel/MS +barbell/SM +barbeque's +barber/DMG +barbered/U +barberry/MS +barbershop/MS +barbital/M +barbiturate/MS +barbwire/SM +barcarole/SM +bard/MDSG +bardic +bare/YSP +bareback/D +barefaced/YP +barefacedness/M +barefoot/D +barehanded +bareheaded +barelegged +bareness/MS +barf/YDSG +barfly/SM +bargain/ZGSDRM +bargainer/M +barge/DSGM +bargeman/M +bargemen +bargepole/M +barhop/S +barhopped +barhopping +baritone/MS +barium/MS +bark/GZDRMS +barked/C +barkeep/SRZ +barkeeper/M +barker/M +barks/C +barley/MS +barleycorn/MS +barmaid/SM +barman/M +barmen +barn/GDSM +barnacle/MDS +barnful +barnsful +barnstorm/DRGZS +barnstormer/M +barnyard/MS +barometer/MS +barometric +barometrically +baron/SM +baronage/MS +baroness/MS +baronet/MS +baronetcy/SM +baronial +barony/SM +baroque/SPMY +barque's +barrack/SDRG +barracker/M +barracuda/MS +barrage/MGSD +barre/GMDSJ +barred/ECU +barrel/SGMD +barren/SPRT +barrenness/SM +barrette/SM +barricade/SDMG +barrier/MS +barring/R +barrio/SM +barrister/MS +barroom/SM +barrow/MS +bars/ECU +barstool/SM +bartend/ZR +bartender/M +barter/SRDZG +barterer/M +barycenter +barycentre's +barycentric +baryon/SM +bas/DRSTG +basal/Y +basalt/SM +basaltic +base's +base/CGRSDL +baseball/MS +baseband +baseboard/MS +baseless +baseline/SM +basely +baseman/M +basemen +basement/CSM +baseness/MS +baseplate/M +basetting +bash/JGDSR +bashful/PY +bashfulness/MS +basic/S +basically +basil/MS +basilar +basilica/SM +basilisk/SM +basin/DMS +basinful/S +basis/M +bask/GSD +basket/SM +basketball/MS +basketry/MS +basketwork/SM +basophilic +bass/SM +basset/GMDS +bassinet/SM +bassist/MS +basso/MS +bassoon/MS +bassoonist/MS +basswood/SM +bast/SGZMDR +bastard/MYS +bastardization/MS +bastardize/SDG +bastardized/U +bastardy/MS +baste/NXS +baster/M +basting/M +bastion/DM +bat/SMDRG +batch/MRSDG +bate/KGSADC +bated/U +bater/AC +bath/JMDSRGZ +bathe +bather/M +bathetic +bathhouse/SM +bathmat/S +bathos/SM +bathrobe/MS +bathroom/SDM +baths +bathtub/MS +bathwater +bathyscaphe's +bathysphere/MS +batik/DMSG +batiste/SM +batman/M +batmen +baton/SM +batsman/M +batsmen +battalion/MS +batted +batten/SDMG +batter/SRDZG +battery/MS +batting/MS +battle/GMZRSDL +battledore/MS +battledress +battlefield/SM +battlefront/SM +battleground/SM +battlement/SMD +battler/M +battleship/MS +batty/RT +batwings +bauble/SM +baud/M +baulk/GSDM +bauxite/SM +bawd/SM +bawdily +bawdiness/MS +bawdy/PRST +bawl/SGDR +bawler/M +bay/GSMDY +bayberry/MS +bayonet/SGMD +bayou/MS +bazaar/MS +bazillion/S +bazooka/MS +bbl +bdrm +be/KS +beach/MSDG +beachcomber/SM +beachhead/SM +beachwear/M +beacon/DMSG +bead/SJGMD +beading/M +beadle/SM +beadsman/M +beadworker +beady/TR +beagle/SDGM +beak/ZSDRM +beaker/M +beam/MDRSGZ +bean/DRMGZS +beanbag/SM +beanie/SM +beanpole/MS +beanstalk/SM +bear/ZBRSJG +bearable/U +bearably/U +beard/DSGM +bearded/P +beardless +bearer/M +bearing/M +bearish/PY +bearishness/SM +bearlike +bearskin/MS +beast/SJMY +beasties +beastings/M +beastliness/MS +beastly/PTR +beat/NRGSBZJ +beatable/U +beatably/U +beaten/U +beater/M +beatific +beatifically +beatification/M +beatify/GNXDS +beating/M +beatitude/MS +beatnik/SM +beau/MS +beaut/SM +beauteous/YP +beauteousness/M +beautician/MS +beautification/M +beautifier/M +beautiful/PTYR +beautifully/U +beautifulness/M +beautify/SRDNGXZ +beauty/SM +beaux's +beaver/DMSG +bebop/MS +becalm/GDS +became +because +beck/GSDM +beckon/SDG +becloud/SGD +become/GJS +becoming/UY +bed/MS +bedaub/GDS +bedazzle/GLDS +bedazzlement/SM +bedbug/SM +bedchamber/M +bedclothes +bedded +bedder/MS +bedding/MS +bedeck/DGS +bedevil/DGLS +bedevilment/SM +bedfast +bedfellow/MS +bedim/S +bedimmed +bedimming +bedizen/DGS +bedlam/MS +bedlinen +bedmaker/SM +bedmate/MS +bedpan/SM +bedpost/SM +bedraggle/GSD +bedridden +bedrock/SM +bedroll/SM +bedroom/DMS +bedsheets +bedside/MS +bedsit +bedsitter/M +bedsore/MS +bedspread/SM +bedspring/SM +bedstead/SM +bedstraw/M +bedtime/SM +bee/MZGJRS +beebread/MS +beech/MRSN +beechnut/MS +beechwood +beef/GZSDRM +beefburger/SM +beefcake/MS +beefiness/MS +beefsteak/MS +beefy/TRP +beehive/MS +beekeeper/MS +beekeeping/SM +beeline/MGSD +been/S +beep/GZSMDR +beeper/M +beer/M +beermat/S +beery/TR +beeswax/DSMG +beet/SM +beetle/GMRSD +beetroot/M +beeves/M +befall/SGN +befell +befit/SM +befitted +befitting/Y +befog/S +befogged +befogging +before +beforehand +befoul/GSD +befriend/DGS +befuddle/GLDS +befuddlement/SM +beg/S +began +beget/S +begetting +beggar/DYMSG +beggarliness/M +beggarly/P +beggary/MS +begged +begging +begin/S +beginner/MS +beginning/MS +begone/S +begonia/SM +begot +begotten +begrime/SDG +begrudge/GDRS +begrudging/Y +beguile/RSDLZG +beguilement/SM +beguiler/M +beguiling/Y +beguine/SM +begum/MS +begun +behalf/M +behalves +behave/GRSD +behavior/SMD +behavioral/Y +behaviorism/MS +behaviorist/S +behavioristic/S +behead/GSD +beheld +behemoth/M +behemoths +behest/SM +behind/S +behindhand +behold/ZGRNS +beholder/M +behoofs +behoove/SDJMG +behooving/YM +beige/MS +being/M +bejewel/SDG +belabor/MDSG +belate/D +belated/PY +belatedness/M +belay/GSD +belch/GSD +beleaguer/GDS +belfry/SM +belie +belief/ESUM +belier/M +believability's +believability/U +believable/U +believably/U +believe/EZGDRS +believed/U +believer/MUSE +believing/U +belittle/RSDGL +belittlement/MS +belittler/M +bell/GSMD +belladonna/MS +bellboy/MS +belle/MS +belled/A +belletrist/SM +belletristic +bellflower/M +bellhop/MS +bellicose/YP +bellicoseness/M +bellicosity/MS +belligerence/SM +belligerency/MS +belligerent/SMY +belling/A +bellman/M +bellmen +bellow/DGS +bellows/M +bells/A +bellwether/MS +belly/SDGM +bellyache/SRDGM +bellyacher/M +bellybutton/MS +bellyful/MS +bellyfull +belong/DGJS +belonging/MP +belove/D +beloved/S +below/S +belt/GSMD +belted/U +belting/M +beltway/SM +beluga/SM +belvedere/M +bely/DSRG +beman +bemire/SDG +bemoan/GDS +bemuse/GSDL +bemused/Y +bemusement/SM +bench/MRSDG +bencher/M +benchmark/GDMS +bend/BUSG +bended +bender/MS +beneath +benediction/MS +benedictory +benefaction/MS +benefactor/MS +benefactress/S +benefice/MGSD +beneficence/SM +beneficent/Y +beneficial/PY +beneficialness/M +beneficiary/MS +benefit/SRDMZG +benefiter/M +benevolence/SM +benevolent/YP +benevolentness/M +benighted/YP +benightedness/M +benign/Y +benignant +benignity/MS +bent/U +bents +bentwood/SM +benumb/SGD +benzene/MS +benzine/SM +bequeath/GSD +bequeaths +bequest/MS +berate/GSD +bereave/GLSD +bereavement/MS +bereft +beret/SM +berg/NRSM +beribbon/D +beriberi/SM +berkelium/SM +berm/SM +berry/SDMG +berrylike +berserk/SR +berserker/M +berth/MDGJ +berths +beryl/SM +beryllium/MS +bes +beseech/RSJZG +beseecher/M +beseeching/Y +beseem/GDS +beset/S +besetting +beside/S +besiege/SRDZG +besieger/M +besmear/GSD +besmirch/GSD +besom/GMDS +besot/S +besotted +besotting +besought +bespangle/GSD +bespatter/SGD +bespeak/SG +bespectacled +bespoke +bespoken +best/DRSG +bestial/Y +bestiality/MS +bestiary/MS +bestir/S +bestirred +bestirring +bestow/SGD +bestowal/SM +bestrew/DGS +bestrewn +bestridden +bestride/SG +bestrode +bestseller/MS +bestselling +bestubble/D +bet/MS +beta/SM +betake/SG +betaken +betatron/M +betcha +betel/MS +beth/M +bethel/M +bethink/GS +bethought +betide/GSD +betimes +betoken/GSD +betook +betray/SRDZG +betrayal/SM +betrayer/M +betroth/GD +betrothal/SM +betrothed/U +betroths +better/SDLG +betterment/MS +betting +bettor/SM +between/SP +betweenness/M +betwixt +bevel/SJGMRD +beverage/MS +bevy/SM +bewail/GDS +beware/GSD +bewhisker/D +bewigged +bewilder/LDSG +bewildered/PY +bewildering/Y +bewilderment/SM +bewitch/LGDS +bewitching/Y +bewitchment/SM +bey/MS +beyond/S +bezel/MS +bf +bi/M +biannual/Y +bias/DSMPG +biased/U +biathlon/MS +biaxial/Y +bib/MS +bibbed +bibbing +bible/MS +biblical/Y +biblicists +bibliographer/MS +bibliographic/S +bibliographical/Y +bibliography/MS +bibliophile/MS +bibulous +bicameral +bicameralism/MS +bicarb/MS +bicarbonate/MS +bicentenary/S +bicentennial/S +bicep/S +biceps/M +bichromate/DM +bicker/SRDZG +bickerer/M +bickering/M +biconcave +biconnected +biconvex +bicuspid/S +bicycle/RSDMZG +bicycler/M +bicyclist/SM +bid/GMRS +biddable +bidden/U +bidder/MS +bidding/MS +biddy/SM +bide/S +bider/M +bidet/SM +bidiagonal +bidirectional/Y +bids/A +biennial/SY +biennium/SM +bier/M +bifocal/S +bifurcate/SDXGNY +bifurcation/M +big/PYS +bigamist/SM +bigamous +bigamy/SM +bigged +bigger +biggest +biggie/SM +bigging +biggish +bighead/MS +bighearted/P +bigheartedness/S +bighorn/MS +bight/SMDG +bigmouth/M +bigmouths +bigness/SM +bigot/MDSG +bigoted/Y +bigotry/MS +bigwig/MS +biharmonic +bijection/MS +bijective/Y +bijou/M +bijoux +bike/MZGDRS +biker/M +bikini/SMD +bilabial/S +bilateral/PY +bilateralness/M +bilayer/S +bilberry/MS +bile/SM +bilge/GMDS +biliary +bilinear +bilingual/SY +bilingualism/SM +bilious/P +biliousness/SM +bilk/GZSDR +bilker/M +bill/JGZSBMDR +billboard/MDGS +biller/M +billet/MDGS +billfold/MS +billiard/SM +billing/M +billingsgate/SM +billion/SHM +billionaire/MS +billionths +billow/DMGS +billowy/RT +billposters +billy/SM +bimbo/MS +bimetallic/S +bimetallism/MS +bimodal +bimolecular/Y +bimonthly/S +bin/SM +binary/S +binaural/Y +bind/JDRGZS +binder/M +bindery/MS +binding/MPY +bindingness/M +bindle/M +binds/AU +bindweed/MS +bing/GNDM +binge/MS +bingo/MS +binnacle/MS +binned +binning +binocular/SY +binodal +binomial/SYM +binuclear +biochemical/SY +biochemist/MS +biochemistry/MS +biodegradability/S +biodegradable +biodiversity/S +bioengineering/M +bioethics +biofeedback/SM +biog/S +biograph/RZ +biographer/M +biographic +biographical/Y +biography/MS +biol +biologic/S +biological/SY +biologist/SM +biology/MS +biomass/SM +biomedical +biomedicine/M +biometric/S +biometrics/M +biometry/M +biomolecule/S +biomorph +bionic/S +bionically +bionics/M +biophysic/S +biophysical/Y +biophysicist/SM +biophysics/M +biopic/S +biopsy/SDGM +biorhythm/S +bioscience/S +biosphere/MS +biostatistic/S +biosynthesized +biotechnological +biotechnologist +biotechnology/SM +biotic +biotin/SM +bipartisan +bipartisanship/MS +bipartite/YN +bipartition/M +biped/MS +bipedal +biplane/MS +bipolar +bipolarity/MS +biracial +birch/MRSDNG +bird/SMDRGZ +birdbath/M +birdbaths +birdbrain/SDM +birdcage/SM +birder/M +birdhouse/MS +birdie/MSD +birdieing +birdlike +birdlime/MGDS +birdseed/MS +birdsong +birdtables +birdwatch/GZR +birefringence/M +birefringent +biretta/SM +birth's/A +birth/MDG +birthday/SM +birthmark/MS +birthplace/SM +birthrate/MS +birthright/MS +births/A +birthstone/SM +bis +biscuit/MS +bisect/DSG +bisection/MS +bisector/MS +biserial +bisexual/YMS +bisexuality/MS +bishop/DGSM +bishopric/SM +bismuth/M +bismuths +bison/M +bisque/SM +bistable +bistate +bistro/SM +bisyllabic +bit's/C +bit/MRJSZG +bitblt/S +bitch/MSDG +bitchily +bitchiness/MS +bitchy/PTR +bite/S +biter/M +biting/Y +bitmap/SM +bits/C +bitser/M +bitted +bitten +bitter/PSRDYTG +bittern/SM +bitterness/SM +bitternut/M +bitterroot/M +bittersweet/YMSP +bitting +bitty/PRT +bitumen/MS +bituminous +bitwise +bivalent/S +bivalve/MSD +bivariate +bivouac/MS +bivouacked +bivouacking +biweekly/S +biyearly +biz/M +bizarre/YSP +bizarreness/M +bizzes +bk +bl/D +blab/S +blabbed +blabber/GMDS +blabbermouth/M +blabbermouths +blabbing +black/SJTXPYRDNG +blackamoor/SM +blackball/SDMG +blackberry/GMS +blackbird/SGDRM +blackbirder/M +blackboard/SM +blackbody/S +blackcurrant/M +blacken/GDR +blackener/M +blackguard/MDSG +blackhead/SM +blacking/M +blackish +blackjack/SGMD +blackleg/M +blacklist/DRMSG +blackmail/DRMGZS +blackmailer/M +blackness/MS +blackout/SM +blacksmith/MG +blacksmiths +blacksnake/MS +blackspot +blackthorn/MS +blacktop/MS +blacktopped +blacktopping +bladder/MS +bladdernut/M +bladderwort/M +blade/DSGM +blah/MDG +blahs +blame/DSRBGMZ +blameless/YP +blamelessness/SM +blamer/M +blameworthiness/SM +blameworthy/P +blanc/M +blanch/DRSG +blancher/M +blancmange/SM +bland/PYRT +blandish/SDGL +blandishment/MS +blandness/MS +blank/SPGTYRD +blanket/SDRMZG +blanketing/M +blankness/MS +blare/DSG +blarney/DMGS +blaspheme/RSDZG +blasphemer/M +blasphemous/PY +blasphemousness/M +blasphemy/SM +blast/SMRDGZ +blaster/M +blasting/M +blastoff/SM +blas� +blatancy/SM +blatant/YP +blather/DRGS +blatting +blaze/DSRGMZ +blazer/M +blazing/Y +blazon/SGDR +blazoner/M +bldg +bleach/DRSZG +bleached/U +bleacher/M +bleak/TPYRS +bleakness/MS +blear/GDS +blearily +bleariness/SM +bleary/PRT +bleat/RDGS +bleater/M +bleed/ZRJSG +bleeder/M +bleep/GMRDZS +blemish/DSMG +blemished/U +blench/DSG +blend/GZRDS +blender/M +bless/JGSD +blessed/PRYT +blessedness/MS +blessing/M +blew +blight/GSMDR +blighter/M +blimey/S +blimp/MS +blind/JGTZPYRDS +blinded/U +blinder/M +blindfold/SDG +blinding/MY +blindness/MS +blindside/SDG +blink/RDGSZ +blinker/MDG +blinking/U +blinks/M +blintz/SM +blintze/M +blip/MS +blipped +blipping +bliss/SDMG +blissful/PY +blissfulness/MS +blister/SMDG +blistering/Y +blistery +blithe/TYPR +blitheness/SM +blither/G +blithesome +blitz/GSDM +blitzkrieg/SM +blizzard/MS +bloat/SRDGZ +bloater/M +blob/MS +blobbed +blobbing +bloc/MS +block's +block/USDG +blockade/ZMGRSD +blockader/M +blockage/MS +blockbuster/SM +blockbusting/MS +blocker/MS +blockhead/MS +blockhouse/SM +blocky/R +blog +blog's +blogged +blogger +blogging +blogging's +blogs +bloke/SM +blond/SPMRT +blonde's +blondish +blondness/MS +blood/SMDG +bloodbath +bloodbaths +bloodcurdling +bloodhound/SM +bloodied/U +bloodiness/MS +bloodless/PY +bloodlessness/SM +bloodletting/MS +bloodline/SM +bloodmobile/MS +bloodroot/M +bloodshed/SM +bloodshot +bloodsport/S +bloodstain/MDS +bloodstock/SM +bloodstone/M +bloodstream/SM +bloodsucker/SM +bloodsucking/S +bloodthirstily +bloodthirstiness/MS +bloodthirsty/RTP +bloodworm/M +bloody/TPGDRS +bloodymindedness +bloom/SMRDGZ +bloomer/M +bloop/GSZRD +blooper/M +blossom/DMGS +blossomy +blot/MS +blotch/GMDS +blotchy/RT +blotted +blotter/MS +blotting +blotto +blouse/GMSD +blow/GZRS +blower/M +blowfish/M +blowfly/MS +blowgun/SM +blowing/M +blown/U +blowout/MS +blowpipe/SM +blowtorch/SM +blowup/MS +blowy/RST +blowzy/RT +blubber/GSDR +blubbery +bludgeon/GSMD +blue/JMYTGDRSP +blueback +bluebell/MS +blueberry/SM +bluebill/M +bluebird/MS +bluebonnet/SM +bluebook/M +bluebottle/MS +bluebush +bluefish/SM +bluegill/SM +bluegrass/MS +blueing's +blueish +bluejacket/MS +bluejeans +blueness/MS +bluenose/MS +bluepoint/SM +blueprint/GDMS +bluer/M +bluest/M +bluestocking/SM +bluesy/TR +bluet/MS +bluff/SPGTZYRD +bluffer/M +bluffness/MS +bluing/M +bluish/P +bluishness/M +blunder/GSMDRJZ +blunderbuss/MS +blunderer/M +blundering/Y +blunt/PSGTYRD +bluntness/MS +blur/MS +blurb/GSDM +blurred/Y +blurriness/S +blurring/Y +blurry/RPT +blurt/GSRD +blush/RSDGZ +blusher/M +blushing/UY +bluster/SDRZG +blusterer/M +blustering/Y +blusterous +blustery +blvd +boa/SM +boar/MS +board's +board/IS +boarded +boarder/SM +boardgames +boarding/SM +boardinghouse/SM +boardroom/MS +boardwalk/SM +boast/SJRDGZ +boaster/M +boastful/YP +boastfulness/MS +boat/MDRGZJS +boatclubs +boater/M +boathouse/SM +boating/M +boatload/SM +boatman/M +boatmen +boatswain/SM +boatyard/SM +bob/SM +bobbed +bobbin/MS +bobbing/M +bobble/SDGM +bobby/SM +bobbysoxer's +bobcat/MS +bobolink/SM +bobs/M +bobsled/MS +bobsledded +bobsledder/MS +bobsledding/M +bobsleigh/M +bobsleighs +bobtail/SGDM +bobwhite/SM +boccie/SM +bock/GDS +bockwurst +bod/SGMD +bode/S +bodega/MS +bodhisattva +bodice/SM +bodied/M +bodiless +bodily +boding/M +bodkin/SM +body/DSMG +bodybuilder/SM +bodybuilding/S +bodyguard/MS +bodying/M +bodysuit/S +bodyweight +bodywork/SM +bog/MS +bogey/SGMD +bogeyman/M +bogeymen +bogged +bogging +boggle/SDG +boggling/Y +boggy/RT +bogie's +bogus +bogy's +bogyman +bogymen +bohemian/S +bohemianism/S +boil/JSGZDR +boiled/AU +boiler/M +boilermaker/MS +boilerplate/SM +boils/A +boisterous/YP +boisterousness/MS +bola/SM +bold/YRPST +boldface/SDMG +boldness/MS +bole/MS +bolero/MS +bolivar/MS +bolivares +boll/MDSG +bollard/SM +bollix/GSD +bolo/MS +bologna/MS +bolometer/MS +boloney's +bolster/SRDG +bolsterer/M +bolt/MDRGS +bolted/U +bolter/M +bolts/U +bolus/SM +bomb/SGZDRJ +bombard/LDSG +bombardier/MS +bombardment/SM +bombast/RMS +bombastic +bombastically +bomber/M +bombproof +bombshell/SM +bona +bonanza/MS +bonbon/SM +bond/JMDRSGZ +bondage/SM +bonder/M +bondholder/SM +bondman/M +bondmen +bonds/A +bondsman/M +bondsmen +bondwoman/M +bondwomen +bone/MZDRSG +boned/U +bonehead/SDM +boneless +boner/M +bonfire/MS +bong/GDMS +bongo/MS +bonhomie/MS +boniness/MS +bonito/MS +bonjour +bonkers +bonnet/SGMD +bonneted/U +bonnie +bonny/RT +bonsai/SM +bonus/SM +bony/RTP +bonzes +boo/GSDH +boob/DMSG +booby/SM +boodle/GMSD +boogeyman's +boogie/SD +boogieing +boohoo/GDS +book/GZDRMJSB +bookbind/JRGZ +bookbinder/M +bookbindery/SM +bookbinding/M +bookcase/MS +booked/U +bookend/SGD +bookie/SM +booking/M +bookish/PY +bookishness/M +bookkeep/GZJR +bookkeeper/M +bookkeeping/M +booklet/MS +bookmaker/MS +bookmaking/MS +bookmark/MDGS +bookmobile/MS +bookplate/SM +bookseller/SM +bookshelf/M +bookshelves +bookshop/MS +bookstall/MS +bookstore/SM +bookwork/M +bookworm/MS +boolean/S +boom/DRGJS +boomer/M +boomerang/MDSG +boomtown/S +boon/MS +boondocks +boondoggle/DRSGZ +boondoggler/M +boonies +boor/MS +boorish/PY +boorishness/SM +boost/SGZMRD +booster/M +boosterism +boot's +boot/AGDS +bootblack/MS +bootee/MS +booth/M +booths +bootie's +bootlaces +bootleg/S +bootlegged/M +bootlegger/SM +bootlegging/M +bootless +bootprints +bootstrap/SM +bootstrapped +bootstrapping +booty/SM +booze/DSRGMZ +boozer/M +boozy/TR +bop/S +bopped +bopping +borate/MSD +borax/MS +bordello/MS +border/JRDMGS +borderer/M +borderland/SM +borderline/MS +bore/ZGJDRS +boredom/MS +boreholes +borer/M +boric +boring/YMP +born/AIU +borne/U +boron/SM +borosilicate/M +borough/M +boroughs +borrow/JZRDGBS +borrower/M +borrowing/M +borscht/SM +borstal/MS +borzoi/MS +bosh/MS +bosom's +bosom/SGUD +bosomy/RT +boson/SM +boss/DSRMG +bossily +bossiness/MS +bossism/MS +bossy/PTSR +bosun's +bot/S +botanic/S +botanical/SY +botanist/SM +botany/SM +botch/SRDGZ +botcher/M +botfly/M +both/ZR +bother/DG +bothersome +bothy/M +bottle/GMZSRD +bottleneck/GSDM +bottler/M +bottom/SMRDG +bottomless/YP +bottomlessness/M +bottommost +botulin/M +botulinus/M +botulism/SM +boudoir/MS +bouffant/S +bougainvillea/SM +bough/MD +boughs +bought/N +bouillabaisse/MS +bouillon/MS +boulder/GMDS +boulevard/MS +bounce/SRDGZ +bouncer/M +bouncily +bouncing/Y +bouncy/TRP +bound/AUDI +boundary/MS +bounded/UP +boundedness/MU +bounden +bounder/AM +bounders +bounding +boundless/YP +boundlessness/SM +bounds/IA +bounteous/PY +bounteousness/MS +bountiful/PY +bountifulness/SM +bounty/SDM +bouquet/SM +bourbon/SM +bourgeois/M +bourgeoisie/SM +bout/MS +boutique/MS +boutonni�re/MS +bovine/YS +bow/SZGNDR +bowdlerization/MS +bowdlerize/GRSD +bowed/U +bowel/GMDS +bower/DMG +bowie +bowing/M +bowl/GZSMDR +bowlder's +bowleg/SM +bowlegged +bowler/M +bowlful/S +bowline/MS +bowling/M +bowman/M +bowmen +bows/R +bowser/M +bowsprit/SM +bowstring/GSMD +bowwow/DMGS +box/DRSJZGM +boxcar/SM +boxer/M +boxful/M +boxing/M +boxlike +boxtops +boxwood/SM +boxy/TPR +boy/MRS +boycott/RDGS +boycotter/M +boyfriend/MS +boyhood/SM +boyish/PY +boyishness/MS +boyscout +boysenberry/SM +bozo/SM +bpi +bps +bra/MS +brace/DSRJGM +braced/U +bracelet/MS +bracer/M +brachia +brachium/M +bracken/SM +bracket/SGMD +bracketed/U +bracketing/M +brackish/P +brackishness/SM +bract/SM +brad/SM +bradawl/M +bradded +bradding +brae/SM +brag/S +braggadocio/SM +braggart/SM +bragged +bragger/MS +braggest +bragging +braid/RDSJG +braider/M +braiding/M +braille/DSG +brain/GSDM +braincell/S +brainchild/M +brainchildren +braininess/MS +brainless/YP +brainlessness/M +brainpower/M +brainstorm/DRMGJS +brainstorming/M +brainteaser/S +brainteasing +brainwash/JGRSD +brainwasher/M +brainwashing/M +brainwave/S +brainy/RPT +braise/SDG +brake/DSGM +brakeman/M +brakemen/M +bramble/DSGM +brambling/M +brambly/RT +bran/SM +branch/MDSJG +branched/U +branching/M +branchlike +brand/SMRDGZ +branded/U +brander/GDM +brandish/GSD +brandy/GDSM +brandywine +branned +branning +brash/PYSRT +brashness/MS +brass/GSDM +brasserie/SM +brassiere/MS +brassily +brassiness/SM +brassy/RSPT +brat/SM +bratty/RT +bratwurst/MS +bravado/M +bravadoes +brave/DSRGYTP +braveness/MS +bravery/MS +bravest/M +bravo/SDG +bravura/SM +brawl/MRDSGZ +brawler/M +brawn/MS +brawniness/SM +brawny/TRP +bray/SDRG +brayer/M +braze/GZDSR +brazen/PYDSG +brazenness/MS +brazer/M +brazier/SM +breach/MDRSGZ +breacher/M +bread/SMDHG +breadbasket/SM +breadboard/SMDG +breadbox/S +breadcrumb/S +breadfruit/MS +breadline/MS +breadth/M +breadths +breadwinner/MS +break/SZRBG +breakable/U +breakables +breakage/MS +breakaway/MS +breakdown/MS +breaker/M +breakfast/RDMGZS +breakfaster/M +breakfront/S +breaking/M +breakneck +breakout/MS +breakpoint/SMDG +breakthrough/SM +breakthroughs +breakup/SM +breakwater/SM +bream/SDG +breast/MDSG +breastbone/MS +breastfed +breastfeed/G +breasting/M +breastplate/SM +breaststroke/SM +breastwork/MS +breath/ZBJMDRSG +breathable/U +breathalyser/S +breathe +breather/M +breathing/M +breathless/PY +breathlessness/SM +breaths +breathtaking/Y +breathy/TR +bred/DG +bredes +breech/MDSG +breeching/M +breed/SZJRG +breeder's +breeder/I +breeding/IM +breeds/I +breeze/GMSD +breezeway/SM +breezily +breeziness/SM +breezy/RPT +bremsstrahlung/M +brethren +breve/SM +brevet/MS +brevetted +brevetting +breviary/SM +brevity/MS +brew/DRGZS +brewer/M +brewery/MS +brewing/M +brewpub/S +briar's +bribe/GZDSR +briber/M +bribery/MS +brick/GRDSM +brickbat/SM +bricklayer/MS +bricklaying/SM +brickmason/S +brickwork/SM +brickyard/M +bridal/S +bride/MS +bridegroom/MS +bridesmaid/MS +bridge/SDGM +bridgeable/U +bridged/U +bridgehead/MS +bridgework/MS +bridging/M +bridle/SDGM +bridled/U +bridleway/S +brief/YRDJPGTS +briefcase/SM +briefed/C +briefing/M +briefness/MS +briefs/C +brier/MS +brig/SM +brigade/GDSM +brigadier/MS +brigand/MS +brigandage/MS +brigantine/MS +bright/GXTPSYNR +brighten/RDZG +brightener/M +brightness/SM +brilliance/MS +brilliancy/MS +brilliant/PSY +brilliantine/MS +brilliantness/M +brim/SM +brimful +brimless +brimmed +brimming +brimstone/MS +brindle/DSM +brine/GMDSR +briner/M +bring/RGZS +bringer/M +brininess/MS +brink/MS +brinkmanship/SM +briny/PTSR +brioche/SM +briquet's +briquette/MGSD +brisk/YRDPGTS +brisket/SM +briskness/MS +bristle/DSGM +bristly/TR +bristol/S +britches +brittle/YTPDRSG +brittleness/MS +bro/SH +broach/DRSG +broacher/M +broad/TXSYRNP +broadband +broadcast/RSGZJ +broadcaster/M +broadcasts/A +broadcloth/M +broadcloths +broaden/JGRDZ +broadleaved +broadloom/SM +broadminded/P +broadness/S +broadsheet/MS +broadside/SDGM +broadsword/MS +brocade/DSGM +broccoli/MS +brochette/SM +brochure/SM +brogan/MS +brogue/MS +broil/RDSGZ +broiler/M +broke/RGZ +broken/YP +brokenhearted/Y +brokenness/MS +broker/DMG +brokerage/MS +bromide/MS +bromidic +bromine/MS +bronc/S +bronchi/M +bronchial +bronchiolar +bronchiole/MS +bronchiolitis +bronchitic/S +bronchitis/MS +broncho's +bronchus/M +bronco/SM +broncobuster/SM +brontosaur/SM +brontosaurus/SM +bronze/SRDGM +bronzed/M +bronzing/M +brooch/MS +brood/SMRDGZ +brooder/M +broodiness/M +brooding/Y +broodmare/SM +broody/PTR +brook/SGDM +brooklet/MS +brookside +broom/SMDG +broomstick/MS +bros/S +broth/ZMR +brothel/MS +brother/DYMG +brotherhood/SM +brotherliness/MS +brotherly/P +broths +brougham/MS +brought +brouhaha/MS +brow/MS +browbeat/NSG +brown/YRDMSJGTP +brownie/MTRS +browning/M +brownish +brownness/MS +brownout/MS +brownstone/MS +brows/SRDGZ +browse +browser/M +brr +brucellosis/M +bruin/MS +bruise/JGSRDZ +bruised/U +bruiser/M +bruit/DSG +brunch/MDSG +brunet/S +brunette/SM +brunt/GSMD +brush/MSRDG +brusher/M +brushfire/MS +brushlike +brushoff/S +brushwood/SM +brushwork/MS +brushy/R +brusque/PYTR +brusqueness/MS +brutal/Y +brutality/SM +brutalization/SM +brutalize/SDG +brutalized/U +brutalizes/AU +brute/DSRGM +brutish/YP +brutishness/SM +bu +bub/MS +bubble/RSDGM +bubblegum/S +bubbler/M +bubbly/TRS +bubo/M +buboes +bubonic +buccaneer/GMDS +buck/GSDRM +buckaroo/SM +buckboard/SM +bucker/M +bucket/SGMD +bucketful/MS +buckeye/SM +buckhorn/M +buckle/RSDGMZ +buckled/U +buckler/MDG +buckles/U +buckling's +buckling/U +buckram/GSDM +bucksaw/SM +buckshot/MS +buckskin/SM +buckteeth +bucktooth/DM +buckwheat/SM +bucolic/S +bucolically +bud/MS +budded +budding/S +buddy/GSDM +budge/GDS +budgerigar/MS +budget/GMRDZS +budgetary +budgeter/M +budgie/MS +budging/U +buff's +buff/ASGD +buffalo/MDG +buffaloes +buffer/RDMSGZ +buffered/U +bufferer/M +buffet/GMDJS +bufflehead/M +buffoon/SM +buffoonery/MS +buffoonish +bug's +bug/CS +bugaboo/SM +bugbear/SM +bugeyed +bugged/C +bugger/SCM! +buggered +buggering +buggery/M +bugging/C +buggy/RSMT +bugle/GMDSRZ +bugler/M +build/SAG +builder/SM +building/SM +buildup/MS +built/AUI +bulb/DMGS +bulblet +bulbous +bulge/DSGM +bulgy/RT +bulimarexia/S +bulimia/MS +bulimic/S +bulk/GDRMS +bulkhead/SDM +bulkiness/SM +bulky/RPT +bull/MDGS +bulldog/SM +bulldogged +bulldogger +bulldogging +bulldoze/GRSDZ +bulldozer/M +bullet/GMDS +bulletin/SGMD +bulletproof/SGD +bullfight/SJGZMR +bullfighter/M +bullfighting/M +bullfinch/MS +bullfrog/SM +bullhead/DMS +bullheaded/YP +bullheadedness/SM +bullhide +bullhorn/SM +bullied/M +bullion/SM +bullish/PY +bullishness/SM +bullock/MS +bullpen/MS +bullring/SM +bullseye +bullshit/MS! +bullshitted/! +bullshitter/S! +bullshitting/! +bullwhackers +bully/TRSDGM +bullyboy/MS +bullying/M +bulrush/SM +bulwark/GMDS +bum/SM +bumble/JGZRSD +bumblebee/MS +bumbler/M +bumbling/Y +bummed/M +bummer/MS +bummest +bumming/M +bump/GZDRS +bumper/DMG +bumpiness/MS +bumpkin/MS +bumptious/PY +bumptiousness/SM +bumpy/PRT +bun/SM +bunch/MSDG +bunchy/RT +bunco's +buncombe's +bundle/GMRSD +bundled/U +bundler/M +bung/GDMS +bungalow/MS +bungee/SM +bunghole/MS +bungle/GZRSD +bungler/M +bungling/Y +bunion/SM +bunk's +bunk/CSGDR +bunker's/C +bunker/SDMG +bunkhouse/SM +bunkmate/MS +bunko's +bunkum/SM +bunny/SM +bunt/GJZDRS +bunting/M +buoy/SMDG +buoyancy/MS +buoyant/Y +bur/MYS +burble/RSDG +burbler/M +burbs +burden's +burden/UGDS +burdensome/PY +burdensomeness/M +burdock/SM +bureau/MS +bureaucracy/MS +bureaucrat/MS +bureaucratic/U +bureaucratically +bureaucratization/MS +bureaucratize/SDG +burg/SZRM +burgeon/GDS +burger/M +burgess/MS +burgh/MRZ +burgher/M +burghs +burglar/SM +burglarize/GDS +burglarproof/DGS +burglary/MS +burgle/SDG +burgomaster/SM +burgundy/S +burial/ASM +buried/U +burier/M +burl/SMDRG +burlap/MS +burler/M +burlesque/SRDMYG +burlesquer/M +burley/M +burliness/SM +burly/PRT +burn/GZSDRBJ +burnable/S +burned/U +burner/M +burning/Y +burnish/GDRSZ +burnisher/M +burnoose/MS +burnout/MS +burnt/YP +burp/SGMD +burr/GSDRM +burrito/S +burro/SM +burrow/GRDMZS +burrower/M +bursa/M +bursae +bursar/MS +bursary/MS +bursitis/MS +burst/SRG +burster/M +bury/ASDG +bus's/A +bus/GMDSJ +busboy/MS +busby/SM +buses/A +busgirl/S +bush/JMDSRG +bushel/MDJSG +bushiness/MS +bushing/M +bushland +bushman/M +bushmaster/SM +bushmen +bushwhack/RDGSZ +bushwhacker/M +bushwhacking/M +bushy/PTR +busily +business/MS +businesslike +businessman/M +businessmen +businesspeople +businessperson/S +businesswoman/M +businesswomen +busk/GRM +busker/M +buskin/SM +buss/D +bust/MSDRGZ +bustard/MS +buster/M +bustle/GSD +bustling/Y +busty/RT +busy/DSRPTG +busybody/MS +busyness/MS +busywork/SM +but/ACS +butane/MS +butch/RSZ +butcher/MDRYG +butcherer/M +butchery/MS +butene/M +butler/SDMG +butt/SGZMDR +butte/MS +butted/A +butter/RDMGZ +butterball/MS +buttercup/SM +buttered/U +butterfat/MS +butterfingered +butterfingers/M +butterfly/MGSD +buttermilk/MS +butternut/MS +butterscotch/SM +buttery/TRS +butting/M +buttock/SGMD +button's +button/SUDG +buttoner/M +buttonhole/GMRSD +buttonholer/M +buttonweed +buttonwood/SM +buttress/MSDG +butyl/M +butyrate/M +buxom/TPYR +buxomness/M +buy/ZGRS +buyback/S +buyer/M +buyout/S +buzz/DSRMGZ +buzzard/MS +buzzer/M +buzzword/SM +buzzy +bx +bxs +by/ZR +bye/MZS +byelaw's +bygone/S +bylaw/SM +byline/RSDGM +byliner/M +bypass/GSDM +bypath/M +bypaths +byplay/S +byproduct/SM +byre/SM +byroad/MS +bystander/SM +byte/SM +byway/SM +byword/SM +byzantine +c/B +ca +cab/SMR +cabal/SM +cabala/MS +caballed +caballero/SM +caballing +cabana/MS +cabaret/SM +cabbage/MGSD +cabbed +cabbing +cabby's +cabdriver/SM +caber/M +cabin/GDMS +cabinet/MS +cabinetmaker/SM +cabinetmaking/MS +cabinetry/SM +cabinetwork/MS +cable/GMDS +cablecast/SG +cablegram/SM +cabochon/MS +caboodle/SM +caboose/MS +cabriolet/MS +cabstand/MS +cacao/SM +cacciatore +cache/DSRGM +cachepot/MS +cachet/MDGS +cackle/RSDGZ +cackler/M +cackly +cacophonist +cacophonous +cacophony/SM +cacti +cactus/M +cad/SM +cadaver/SM +cadaverous/Y +caddish/PY +caddishness/SM +caddy/GSDM +cadence/CSM +cadenced +cadencing +cadent/C +cadenza/MS +cadet/SM +cadge/DSRGZ +cadger/M +cadmium/MS +cadre/SM +caducei +caduceus/M +caesura/SM +cafeteria/SM +caffeine/SM +caftan/SM +caf�/MS +cage/MZGDRS +caged/U +cager/M +cagey/P +cagier +cagiest +cagily +caginess/MS +cahoot/MS +caiman's +cairn/SDM +caisson/SM +caitiff/MS +cajole/LGZRSD +cajolement/MS +cajoler/M +cajolery/SM +cake/MGDS +cakewalk/SMDG +cal/C +calabash/SM +calaboose/MS +calamari/S +calamine/GSDM +calamitous/YP +calamitousness/M +calamity/MS +calcareous/PY +calcareousness/M +calciferous +calcification/M +calcify/XGNSD +calcimine/GMSD +calcine/SDG +calcite/SM +calcium/SM +calculability/IM +calculable/IP +calculate/AXNGDS +calculated/PY +calculating/U +calculatingly +calculation/AM +calculative +calculator/SM +calculi +calculus/M +caldera/SM +caldron's +calendar/MDGS +calender/MDGS +calf/M +calfskin/SM +caliber/SM +calibrate/XNGSD +calibrated/U +calibrater's +calibrating/A +calibration/M +calibrator/MS +calico/M +calicoes +calif's +californium/SM +caliper/SDMG +caliph/M +caliphate/SM +caliphs +calisthenic/S +calisthenics/M +call/AGRDBS +calla/MS +callback/S +called/U +callee/M +caller/MS +calligraph/RZ +calligrapher/M +calligraphic +calligraphist/MS +calligraphy/MS +calling/SM +calliope/SM +callisthenics's +callosity/MS +callous/PGSDY +callousness/SM +callow/RTSP +callowness/MS +callus/SDMG +calm/PGTYDRS +calming/Y +calmness/MS +caloric/S +calorie/SM +calorific +calorimeter/MS +calorimetric +calorimetry/M +calumet/MS +calumniate/NGSDX +calumniation/M +calumniator/SM +calumnious +calumny/MS +calvary/M +calve/GDS +calves/M +calyces's +calypso/SM +calyx/MS +cam/MS +camaraderie/SM +camber/DMSG +cambial +cambium/SM +cambric/MS +camcorder/S +came/N +camel/SM +camelhair's +camellia/MS +cameo/GSDM +camera/MS +camerae +cameraman/M +cameramen +camerawoman +camerawomen +camion/M +camisole/MS +cammed +camomile's +camouflage/DRSGZM +camouflager/M +camp's +camp/SCGD +campaign/ZMRDSG +campaigner/M +campanile/SM +campanological +campanologist/SM +campanology/MS +camper/SM +campesinos +campest +campfire/SM +campground/MS +camphor/MS +camping/S +campsite/MS +campus/GSDM +campy/RT +camshaft/SM +can't +can/MDRSZGJ +canal/SGMD +canalization/MS +canalize/GSD +canap�/S +canard/MS +canary/SM +canasta/SM +cancan/SM +cancel/RDZGS +cancelate/D +canceled/U +canceler/M +cancellation/MS +cancer/MS +cancerous/Y +candelabra/S +candelabrum/M +candid/TRYPS +candidacy/MS +candidate/SM +candidature/S +candidly/U +candidness/SM +candle/GMZRSD +candlelight/SMR +candlelit +candlepower/SM +candler/M +candlestick/SM +candlewick/MS +candor/MS +candy/GSDM +cane/SM +canebrake/SM +caner/M +canine/S +caning/M +canister/SGMD +canker/SDMG +cankerous +cannabis/MS +canned +cannelloni +canner/SM +cannery/MS +cannibal/SM +cannibalism/MS +cannibalistic +cannibalization/SM +cannibalize/GSD +cannily/U +canniness/UM +canninesses +canning/M +cannister/SM +cannon/SDMG +cannonade/SDGM +cannonball/SGDM +cannot +canny/RPUT +canoe/DSGM +canoeist/SM +canon/SM +canonic +canonical/SY +canonicalization +canonicalize/GSD +canonist/M +canonization/MS +canonize/SDG +canonized/U +canopy/GSDM +canst +cant's +cant/CZGSRD +cantabile/S +cantaloupe/MS +cantankerous/PY +cantankerousness/SM +cantata/SM +canted/IA +canteen/MS +canter/CM +cantered +cantering +canticle/SM +cantilever/SDMG +canto/MS +canton/MGSLD +cantonal +cantonment/SM +cantor/MS +cants/A +canvas/RSDMG +canvasback/MS +canvass/RSDZG +canvasser/M +canyon/MS +cap/MDRSZB +capability/ISM +capable/PI +capableness/IM +capabler +capablest +capably/I +capacious/PY +capaciousness/MS +capacitance/SM +capacitate/V +capacitive/Y +capacitor/MS +capacity/IMS +caparison/SDMG +cape/SM +caper/GDM +capeskin/SM +capillarity/MS +capillary/S +capita/M +capital/SMY +capitalism/SM +capitalist/SM +capitalistic +capitalistically +capitalization/SMA +capitalize/RSDGZ +capitalized/AU +capitalizer/M +capitalizes/A +capitation/CSM +capitol/SM +capitulate/AXNGSD +capitulation/MA +caplet/S +capo/SM +capon/SM +capped/UA +capping/M +cappuccino/MS +caprice/MS +capricious/PY +capriciousness/MS +caps/AU +capsicum/MS +capsize/SDG +capstan/MS +capstone/MS +capsular +capsule/MGSD +capsulize/GSD +capt/V +captain/SGDM +captaincy/MS +caption/GSDRM +captious/PY +captiousness/SM +captivate/XGNSD +captivation/M +captivator/SM +captive/MS +captivity/SM +captor/SM +capture/AGSD +capturer/MS +car/ZGSMDR +caracul's +carafe/SM +caramel/MS +caramelize/SDG +carapace/SM +carapaxes +carat/SM +caravan/DRMGS +caravaner/M +caravansary/MS +caravanserai's +caravel/MS +caraway/MS +carbide/MS +carbine/MS +carbohydrate/MS +carbolic +carbon/MS +carbonaceous +carbonate/SDXMNG +carbonation/M +carbonic +carboniferous +carbonization/SAM +carbonize/ZGRSD +carbonizer's +carbonizer/AS +carbonizes/A +carbonyl/M +carborundum +carboy/MS +carbuncle/SDM +carbuncular +carburetor/MS +carburetter/S +carburettor/SM +carcase/MS +carcass/SM +carcinogen/SM +carcinogenic +carcinogenicity/MS +carcinoma/SM +card's +card/EDRSG +cardamom/MS +cardboard/MS +carder's/E +carder/MS +cardholders +cardiac/S +cardigan/SM +cardinal/SYM +cardinality/SM +carding/M +cardiogram/MS +cardiograph/M +cardiographs +cardioid/M +cardiologist/SM +cardiology/MS +cardiomegaly/M +cardiopulmonary +cardiovascular +cardsharp/ZSMR +care/S +cared/U +careen/DSG +career/SGRDM +careerism/M +careerist/MS +carefree +careful/PY +carefuller +carefullest +carefulness/MS +caregiver/S +careless/YP +carelessness/MS +carer/M +caress/SRDMVG +caresser/M +caressing/Y +caressive/Y +caret/SM +caretaker/SM +careworn +carfare/MS +cargo/M +cargoes +carhop/SM +carhopped +carhopping +caribou/MS +caricature/GMSD +caricaturisation +caricaturist/MS +caricaturization +caries/M +carillon/SM +carillonned +carillonning +caring/U +carious +carjack/GSJDRZ +carload/MSG +carmine/MS +carnage/MS +carnal/Y +carnality/SM +carnation/IMS +carnelian/SM +carney's +carnival/MS +carnivore/SM +carnivorous/YP +carnivorousness/MS +carny/SDG +carob/SM +carol/SGZMRD +caroler/M +carom/GSMD +carotene/MS +carotid/MS +carousal/MS +carouse/SRDZG +carousel/MS +carouser/M +carp/MDRSGZ +carpal/SM +carpel/SM +carpenter/DSMG +carpentering/M +carpentry/MS +carper/M +carpet/MDJGS +carpetbag/MS +carpetbagged +carpetbagger/MS +carpetbagging +carpeting/M +carpi/M +carping/Y +carpool/DGS +carport/MS +carpus/M +carrageen/M +carrel/SM +carriage/SM +carriageway/SM +carrier/M +carrion/SM +carrot/MS +carroty/RT +carrousel's +carry/RSDZG +carryall/MS +carryout/S +carryover/S +carsick/P +carsickness/SM +cart/MDRGSZ +cartage/MS +carte/M +cartel/SM +carter/M +carthorse/MS +cartilage/MS +cartilaginous +cartload/MS +cartographer/MS +cartographic +cartography/MS +carton/GSDM +cartoon/GSDM +cartoonist/MS +cartridge/SM +cartwheel/MRDGS +carve/DSRJGZ +carven +carver/M +carving/M +caryatid/MS +casaba/SM +casbah/M +cascade/MSDG +cascara/MS +case/DSJMGL +casebook/SM +cased/U +caseharden/SGD +casein/SM +caseload/MS +casement/SM +casework/ZMRS +caseworker/M +cash/GZMDSR +cashbook/SM +cashew/MS +cashier/SDMG +cashless +cashmere/MS +casing/M +casino/MS +cask/GSDM +casket/SGMD +cassava/MS +casserole/MGSD +cassette/SM +cassia/MS +cassino's +cassock/SDM +cassowary/SM +cast/GZSJMDR +castanet/SM +castaway/SM +caste/MHS +castellated +caster/M +castigate/XGNSD +castigation/M +castigator/SM +casting/M +castle/GMSD +castoff/S +castor's +castrate/DSNGX +castration/M +casts/A +casual/SYP +casualness/SM +casualty/SM +casuist/MS +casuistic +casuistry/SM +cat/SMRZ +cataclysm/MS +cataclysmal +cataclysmic +catacomb/MS +catafalque/SM +catalepsy/MS +cataleptic/S +catalog/SDRMZG +cataloger/M +catalpa/SM +catalysis/M +catalyst/SM +catalytic +catalytically +catalyze/DSG +catamaran/MS +catapult/MGSD +cataract/MS +catarrh/M +catarrhs +catastrophe/SM +catastrophic +catastrophically +catatonia/MS +catatonic/S +catbird/MS +catboat/SM +catcall/SMDG +catch/BRSJLGZ +catchable/U +catchall/MS +catcher/M +catchment/SM +catchpenny/S +catchphrase/S +catchup/MS +catchword/MS +catchy/TR +catechism/MS +catechist/SM +catechize/SDG +catecholamine/MS +categoric +categorical/Y +categorization/MS +categorize/RSDGZ +categorized/AU +category/MS +catenate/NF +catenation/MF +cater/GRDZ +catercorner +caterer/M +catering/M +caterpillar/SM +caterwaul/DSG +catfish/MS +catgut/SM +catharses +catharsis/M +cathartic/S +cathedral/SM +catheter/SM +catheterize/GSD +cathode/MS +cathodic +catholic/MS +catholicism +catholicity/MS +cation/MS +cationic +catkin/SM +catlike +catnap/SM +catnapped +catnapping +catnip/MS +catsup's +cattail/SM +catted +cattery/M +cattily +cattiness/SM +catting +cattle/M +cattleman/M +cattlemen +catty/PRST +catwalk/MS +caucus/SDMG +caudal/Y +caught/U +cauldron/MS +cauliflower/MS +caulk/JSGZRD +caulker/M +causal/YS +causality/SM +causate/XVN +causation/M +causative/SY +cause/DSRGMZ +caused/U +causeless +causer/M +causerie/MS +causeway/SGDM +caustic/YS +caustically +causticity/MS +cauterization/SM +cauterize/GSD +cauterized/U +caution/GJDRMSZ +cautionary +cautioner/M +cautious/PIY +cautiousness's/I +cautiousness/SM +cavalcade/MS +cavalier/SGYDP +cavalierness/M +cavalry/MS +cavalryman/M +cavalrymen +cave's +cave/GFRSD +caveat/SM +caveatted +caveatting +caveman/M +cavemen +caver/M +cavern/GSDM +cavernous/Y +caviar/MS +cavil/SJRDGZ +caviler/M +caving/MS +cavity/MFS +cavort/SDG +caw/SMDG +cay's +cay/SC +cayenne/SM +cayman/SM +cayuse/SM +cc +cease/DSCG +ceasefire/S +ceaseless/YP +ceaselessness/SM +ceasing/U +ceca +cecal +cecum/M +cedar/SM +cede/FRSDG +ceded/A +ceder's/F +ceder/SM +cedes/A +cedilla/SM +ceding/A +ceilidh/M +ceiling/MDS +celandine/MS +celebrant/MS +celebrate/XSDGN +celebrated/P +celebratedness/M +celebration/M +celebrator/MS +celebratory +celebrity/MS +celerity/SM +celery/SM +celesta/SM +celestial/YS +celibacy/MS +celibate/SM +cell/GMDS +cellar/RDMGS +cellarer/M +cellist/SM +cello/MS +cellophane/SM +cellphone/S +cellular/SY +cellulite/S +celluloid/SM +cellulose/SM +cement/ZGMRDS +cementa +cementer/M +cementum/SM +cemetery/MS +cenobite/MS +cenobitic +cenotaph/M +cenotaphs +censer/MS +censor/GDMS +censored/U +censorial +censorious/YP +censoriousness/MS +censorship/MS +censure/BRSDZMG +censurer/M +census/SDMG +cent/SZMR +centaur/SM +centavo/SM +centenarian/MS +centenary/S +centennial/YS +center's +center/AC +centerboard/SM +centered +centerer/S +centerfold/S +centering/SM +centerline/SM +centerpiece/SM +centigrade/S +centigram/SM +centiliter/MS +centime/SM +centimeter/SM +centipede/MS +central/STRY +centralism/M +centralist/M +centrality/MS +centralization/CAMS +centralize/CGSD +centralizer/SM +centralizes/A +centrefold's +centric/F +centrifugal/SY +centrifugate/NM +centrifugation/M +centrifuge/GMSD +centripetal/Y +centrist/MS +centroid/MS +centurion/MS +century/MS +cephalic/S +ceramic/MS +ceramicist/S +ceramist/MS +cerate/MD +cereal/MS +cerebellar +cerebellum/MS +cerebra +cerebral/SY +cerebrate/XSDGN +cerebration/M +cerebrum/MS +cerement/SM +ceremonial/YSP +ceremonious/YUP +ceremoniousness's/U +ceremoniousness/MS +ceremony/MS +cerise/SM +cerium/MS +cermet/SM +cert/FS +certain/UY +certainer +certainest +certainty/UMS +certifiable +certifiably +certificate/SDGM +certification/AMC +certified/U +certifier/M +certify/DRSZGNX +certiorari/M +certitude/ISM +cerulean/MS +cervical +cervices/M +cervix/M +cesarean/S +cesium/MS +cessation/SM +cession/FAMSK +cesspit/M +cesspool/SM +cetacean/S +cetera/S +cf +cg +ch/VT +chafe/GDSR +chafer/M +chaff/GRDMS +chaffer/DRG +chafferer/M +chaffinch/SM +chagrin/DGMS +chain's +chain/SGUD +chainlike +chainsaw/SGD +chair/SGDM +chairlady/M +chairlift/MS +chairman/MDGS +chairmanship/MS +chairmen +chairperson/MS +chairwoman/M +chairwomen +chaise/SM +chalcedony/MS +chalet/SM +chalice/DSM +chalk/DSMG +chalkboard/SM +chalkiness/S +chalkline +chalky/RPT +challenge/ZGSRD +challenged/U +challenger/M +challenging/Y +challis/SM +chamber/SZGDRM +chamberer/M +chamberlain/MS +chambermaid/MS +chamberpot/S +chambray/MS +chameleon/SM +chamfer/DMGS +chammy's +chamois/DSMG +chamomile/MS +champ/DGSZ +champagne/MS +champaign/M +champion/MDGS +championship/MS +chance/GMRSD +chanced/M +chancel/SM +chancellery/SM +chancellor/SM +chancellorship/SM +chancery/SM +chanciness/S +chancing/M +chancre/SM +chancy/RPT +chandelier/SM +chandler/MS +change/GZRSD +changeabilities +changeability/UM +changeable/U +changeableness/SM +changeably/U +changed/U +changeless +changeling/M +changeover/SM +changer/M +changing/U +channel/MDRZSG +channeler/M +channeling/M +channelization/SM +channelize/GDS +channellings +chanson/SM +chant/SJGZMRD +chanter/M +chanteuse/MS +chantey/SM +chanticleer/SM +chantry/MS +chanty's +chaos/SM +chaotic +chaotically +chap/MS +chaparral/MS +chapbook/SM +chapeau/MS +chapel/MS +chaperon/GMDS +chaperonage/MS +chaperone's +chaperoned/U +chaplain/MS +chaplaincy/MS +chaplet/SM +chapped +chapping +chapter/SGDM +char/GS +charabanc/MS +character/MDSG +characterful +characteristic/SM +characteristically/U +characterizable/MS +characterization/MS +characterize/DRSBZG +characterized/U +characterizer/M +characterless +charade/SM +charbroil/SDG +charcoal/MGSD +chard/SM +chardonnay/S +charge/EGRSDA +chargeable/P +chargeableness/M +charged/U +charger/AME +chargers +charily +chariness/MS +chariot/SMDG +charioteer/GSDM +charisma/M +charismata +charismatic/S +charismatically +charitable/UP +charitableness/UM +charitablenesses +charitably/U +charity/MS +charlady/M +charlatan/SM +charlatanism/MS +charlatanry/SM +charm/SGMZRD +charmer/M +charming/RYT +charmless +charred +charring +chart/SJMRDGBZ +charted/U +charter's +charter/AGDS +chartered/U +charterer/SM +chartist/SM +chartreuse/MS +chartroom/S +charwoman/M +charwomen +chary/PTR +chase/DSRGZ +chaser/M +chasing/M +chasm/SM +chassis/M +chaste/UTR +chastely +chasten/GSD +chasteness/SM +chastise/ZGLDRS +chastisement/SM +chastiser/M +chastity's/U +chastity/SM +chasuble/SM +chat/MS +chateaus +chatted +chattel/MS +chatter/SZGDRY +chatterbox/MS +chatterer/M +chattily +chattiness/SM +chatting +chatty/RTP +chauffeur/GSMD +chauvinism/MS +chauvinist/MS +chauvinistic +chauvinistically +chaw +cheap/YRNTXSP +cheapen/DG +cheapish +cheapness/MS +cheapskate/MS +cheat/RDSGZ +cheater/M +check's/A +check/GZBSRDM +checkable/U +checkbook/MS +checked/UA +checker/DMG +checkerboard/MS +checklist/S +checkmate/MSDG +checkoff/SM +checkout/S +checkpoint/MS +checkroom/MS +checks/A +checksum/SM +checksummed +checksumming +checkup/MS +cheddar/S +cheek/DMGS +cheekbone/SM +cheekily +cheekiness/SM +cheeky/PRT +cheep/GMDS +cheer/YRDGZS +cheerer/M +cheerful/YP +cheerfuller +cheerfullest +cheerfulness/MS +cheerily +cheeriness/SM +cheerio/S +cheerleader/SM +cheerless/PY +cheerlessness/SM +cheers/S +cheery/PTR +cheese/SDGM +cheeseburger/SM +cheesecake/SM +cheesecloth/M +cheesecloths +cheeseparing/S +cheesiness/SM +cheesy/PRT +cheetah/M +cheetahs +chef/SM +cheffed +cheffing +chelate/XDMNG +chelation/M +chem +chemic +chemical/SYM +chemiluminescence/M +chemiluminescent +chemise/SM +chemist/SM +chemistry/SM +chemotherapeutic/S +chemotherapy/SM +chemurgy/SM +chenille/SM +cherish/GDRS +cherisher/M +cheroot/MS +cherry/SM +chert/MS +cherub/SM +cherubic +cherubim/S +chervil/MS +chess/SM +chessboard/SM +chessman/M +chessmen +chest/MRDS +chesterfield/MS +chestful/S +chestnut/SM +chesty/TR +chevalier/SM +cheviot/S +chevron/DMS +chew/GZSDR +chewer/M +chewiness/S +chewy/RTP +chg +chge +chi/MS +chianti/M +chiaroscuro/SM +chic/SYRPT +chicane/MGDS +chicanery/MS +chichi/RTS +chick/XSNM +chickadee/SM +chicken/GDM +chickenfeed +chickenhearted +chickenpox/MS +chickpea/MS +chickweed/MS +chicle/MS +chicness/S +chicory/MS +chide/GDS +chiding/Y +chief/YRMST +chiefdom/MS +chieftain/SM +chiffon/MS +chiffonier/MS +chigger/MS +chignon/MS +chihuahua/S +chilblain/MS +child/GMYD +childbearing/MS +childbirth/M +childbirths +childcare/S +childes +childhood/MS +childish/YP +childishness/SM +childless/P +childlessness/SM +childlike/P +childlikeness/M +childminders +childproof/GSD +childrearing +children/M +chile's +chili/M +chilies +chill/MRDJGTZPS +chiller/M +chilli's +chilliness/MS +chilling/Y +chillness/MS +chilly/TPRS +chimaera's +chimaerical +chime/DSRGMZ +chimer/M +chimera/SM +chimeric +chimerical +chimney/SMD +chimp/MS +chimpanzee/SM +chin/SGDM +china/MS +chinchilla/SM +chine/MS +chink/DMSG +chinless +chinned +chinner/S +chinning +chino/MS +chinstrap/S +chintz/SM +chintzy/TR +chip/SM +chipboard/M +chipmunk/SM +chipped +chipper/DGS +chipping/MS +chiral +chirography/SM +chiropodist/SM +chiropody/MS +chiropractic/MS +chiropractor/SM +chirp/GDS +chirpy/RT +chirrup/DGS +chisel/ZGSJMDR +chiseler/M +chit/SM +chitchat/SM +chitchatted +chitchatting +chitin/SM +chitinous +chitterlings +chivalric +chivalrous/YP +chivalrously/U +chivalrousness/MS +chivalry/SM +chive/GMDS +chivvy/D +chivying +chlamydia/S +chlamydiae +chloral/MS +chlorate/M +chlordane/MS +chloride/MS +chlorinate/XDSGN +chlorinated/C +chlorinates/C +chlorination/M +chlorine/MS +chlorofluorocarbon/S +chloroform/DMSG +chlorophyll/SM +chloroplast/MS +chloroquine/M +chm +chock/SGRDM +chockablock +chocoholic/S +chocolate/MS +chocolaty +choice/RSMTYP +choiceness/M +choir/SDMG +choirboy/MS +choirmaster/SM +choke/DSRGZ +chokeberry/M +chokecherry/SM +choker/M +chokes/M +choking/Y +choler/SM +cholera/SM +choleric +cholesterol/SM +choline/M +cholinesterase/M +chomp/DSG +choose/GZRS +chooser/M +choosiness/S +choosy/RPT +chop/S +chophouse/SM +chopped +chopper/SDMG +choppily +choppiness/MS +chopping +choppy/RPT +chopstick/SM +choral/SY +chorale/MS +chord/SGMD +chordal +chordata +chordate/MS +chording/M +chore/DSGNM +chorea/MS +choreograph/ZGDR +choreographer/M +choreographic +choreographically +choreographs +choreography/MS +chorines +chorion/M +chorister/SM +choroid/S +chortle/ZGDRS +chortler/M +chorus/GDSM +chose/S +chosen/U +chow/DGMS +chowder/SGDM +chrism/SM +chrissake +christen/SAGD +christened/U +christening/SM +chroma/M +chromate/M +chromatic/PS +chromatically +chromaticism/M +chromaticness/M +chromatics/M +chromatin/MS +chromatogram/MS +chromatograph +chromatographic +chromatography/M +chrome/GMSD +chromic +chromite/M +chromium/SM +chromosomal +chromosome/MS +chromosphere/M +chronic/S +chronically +chronicle/SRDMZG +chronicled/U +chronicler/M +chronograph/M +chronographs +chronography +chronological/Y +chronologist/MS +chronology/MS +chronometer/MS +chronometric +chrysalids +chrysalis/SM +chrysanthemum/MS +chub/MS +chubbiness/SM +chubby/RTP +chuck/GSDM +chuckhole/SM +chuckle/DSG +chuckling/Y +chuff/DM +chug/MS +chugged +chugging +chukka/S +chum/MS +chummed +chummily +chumminess/MS +chumming +chummy/SRTP +chump/MDGS +chumping/M +chunk/SGDM +chunkiness/MS +chunky/RPT +chuntering +church/MDSYG +churchgoer/SM +churchgoing/SM +churchliness/M +churchly/P +churchman/M +churchmen +churchwarden/SM +churchwoman/M +churchwomen +churchyard/SM +churl/SM +churlish/YP +churlishness/SM +churn/SGZRDM +churner/M +churning/M +chute/DSGM +chutney/MS +chutzpa/SM +chutzpah/M +chutzpahs +chyme/SM +ch�teau/M +ch�teaux +ch�telaine/SM +ciao/S +cicada/MS +cicatrice/S +cicatrix's +cicerone/MS +ciceroni +cider's/C +cider/SM +cigar/SM +cigarette/MS +cigarillo/MS +cilantro/S +cilia/M +ciliate/FDS +ciliately +cilium/M +cinch/MSDG +cinchona/SM +cincture/MGSD +cinder/DMGS +cine/M +cinema/SM +cinematic +cinematographer/MS +cinematographic +cinematography/MS +cinnabar/MS +cinnamon/MS +cipher/MSGD +ciphered/C +ciphers/C +cir +circa +circadian +circle/RSDGM +circler/M +circlet/MS +circuit/GSMD +circuital +circuitous/YP +circuitousness/MS +circuitry/SM +circuity/MS +circulant +circular/PSMY +circularity/SM +circularize/GSD +circularness/M +circulate/ASDNG +circulation/MA +circulations +circulative +circulatory +circumcise/DRSXNG +circumcised/U +circumciser/M +circumcision/M +circumference/SM +circumferential/Y +circumflex/MSDG +circumlocution/MS +circumlocutory +circumnavigate/DSNGX +circumnavigation/M +circumnavigational +circumpolar +circumscribe/GSD +circumscription/SM +circumspect/Y +circumspection/SM +circumsphere +circumstance/SDMG +circumstantial/YS +circumvent/SBGD +circumvention/MS +circus/SM +cirque/SM +cirrhoses +cirrhosis/M +cirrhotic/S +cirri/M +cirrus/M +cistern/SM +cit/DSG +citadel/SM +citation/SMA +citations/I +cite/ISDAG +citified +citizen/SYM +citizenry/SM +citizenship/MS +citrate/DM +citric +citron/MS +citronella/MS +citrus/SM +city/DSM +cityscape/MS +citywide +civet/SM +civic/S +civics/M +civil/UY +civilian/SM +civility/IMS +civilization/AMS +civilizational/MS +civilize/DRSZG +civilized/PU +civilizedness/M +civilizer/M +civilizes/AU +civvies +ck/C +cl/GJ +clack/SDG +clad/U +cladding/SM +clads +claim/CDRSKAEGZ +claimable +claimant/MS +claimed/U +claimer/KMACE +clairvoyance/MS +clairvoyant/YS +clam/MS +clambake/MS +clamber/SDRZG +clamberer/M +clammed +clammily +clamminess/MS +clamming +clammy/TPR +clamor/GDRMSZ +clamorer/M +clamorous/PUY +clamorousness/UM +clamp/MRDGS +clampdown/SM +clamper/M +clamshell/MS +clan/MS +clandestine/YP +clandestineness/M +clang/SGZRD +clanger/M +clangor/MDSG +clangorous/Y +clank/SGDM +clanking/Y +clannish/PY +clannishness/SM +clansman/M +clansmen +clap/S +clapboard/SDGM +clapped +clapper/GMDS +clapping +claptrap/SM +claque/MS +claret/MDGS +clarification/M +clarifier/M +clarify/NGXDRS +clarinet/SM +clarinetist/SM +clarinettist's +clarion/GSMD +clarities +clarity/UM +clash/RSDG +clasher/M +clasp's +clasp/UGSD +clasped/M +clasper/M +class/GRSDM +classer/M +classic/S +classical/Y +classicism/SM +classicist/SM +classics/M +classifiable/U +classification/AMC +classificatory +classified/S +classifier/SM +classify/CNXASDG +classiness/SM +classless/P +classmate/MS +classroom/MS +classwork/M +classy/PRT +clatter/SGDR +clatterer/M +clattering/Y +clattery +clausal +clause/MS +claustrophobia/SM +claustrophobic +clave's/F +clave/RM +clavichord/SM +clavicle/MS +clavier/MS +claw/GDRMS +clawer/M +clay/MDGS +clayey +clayier +clayiest +claymore/MS +clean/UYRDPT +cleanable +cleaner/MS +cleaning/SM +cleanliness/UMS +cleanly/PRTU +cleanness/MSU +cleans/GDRSZ +cleanse +cleanser/M +cleanup/MS +clear/UTRD +clearance/MS +clearcut +clearer/M +clearheaded/PY +clearheadedness/M +clearing/MS +clearinghouse/S +clearly +clearness/MS +clears +clearway/M +cleat/MDSG +cleavage/MS +cleave/RSDGZ +cleaver/M +clef/SM +cleft/MDGS +clematis/MS +clemence +clemency/ISM +clement/IY +clements +clench/UD +clenches +clenching +clerestory/MS +clergy/MS +clergyman/M +clergymen +clergywoman +clergywomen +cleric/SM +clerical/YS +clericalism/SM +clerk/SGYDM +clerkship/MS +clever/RYPT +cleverness/SM +clevis/SM +clew/DMGS +clich�/SM +clich�d +click/GZSRDM +clicker/M +client/SM +client�le/SM +cliff/SM +cliffhanger/MS +cliffhanging +climacteric/SM +climactic +climate/MS +climatic +climatically +climatological/Y +climatologist/SM +climatology/MS +climax/MDSG +climb/BGZSJRD +climbable/U +climbdown +climbed/U +climber/M +clime/SM +clinch/DRSZG +clincher/M +clinching/Y +cling/U +clinger/MS +clinging +clingy/TR +clinic/MS +clinical/Y +clinician/MS +clink/RDGSZ +clinker/GMD +clinometer/MIS +cliometric/S +cliometrician/S +clip/SM +clipboard/SM +clipped/U +clipper/MS +clipping/SM +clique/SDGM +cliquey +cliquier +cliquiest +cliquish/YP +cliquishness/SM +clitoral +clitorides +clitoris/MS +cloaca/M +cloacae +cloak's +cloak/USDG +cloakroom/MS +clobber/DGS +cloche/MS +clock/SGZRDMJ +clocker/M +clockmaker/M +clockwatcher +clockwise +clockwork/MS +clod/MS +clodded +clodding +cloddish/P +cloddishness/M +clodhopper/SM +clog's +clog/US +clogged/U +clogging/U +cloisonnes +cloisonn� +cloister/MDGS +cloistral +clomp/MDSG +clonal +clone/DSRGMZ +clonk/SGD +clop/S +clopped +clopping +close/EDSRG +closed/U +closefisted +closely +closemouthed +closeness/MS +closeout/MS +closer/EM +closers +closest +closet/MDSG +closeup/S +closing/S +closure's/I +closure/EMS +closured +closuring +clot/MS +cloth/GJMSD +clothbound +clothe/UDSG +clothesbrush +clotheshorse/MS +clothesline/SDGM +clothesman +clothesmen +clothespin/MS +clothier/MS +clothing/M +cloths +clotted +clotting +cloture/MDSG +cloud/SGMD +cloudburst/MS +clouded/U +cloudiness/SM +cloudless/YP +cloudlessness/M +cloudscape/SM +cloudy/TPR +clout/GSMD +clove/SRMZ +cloven +clover/M +cloverleaf/MS +clown/DMSG +clownish/PY +clownishness/SM +cloy/DSG +cloying/Y +club/MS +clubbed/M +clubbing/M +clubfeet +clubfoot/DM +clubhouse/SM +clubroom/SM +cluck/GSDM +clue/MGDS +clueless +clump/MDGS +clumpy/RT +clumsily +clumsiness/MS +clumsy/PRT +clung +clunk/SGZRDM +clunky/PRYT +cluster/SGJMD +clustered/AU +clusters/A +clutch/DSG +clutter/GSD +cluttered/U +cm +cnidarian/MS +cnt +co/DES +coach/MSRDG +coacher/M +coachman/M +coachmen +coachwork/M +coadjutor/MS +coagulable +coagulant/SM +coagulate/GNXSD +coagulation/M +coagulator/S +coal/MDRGS +coaler/M +coalesce/GDS +coalescence/SM +coalescent +coalface/SM +coalfield/MS +coalition/MS +coalitionist/SM +coalminers +coarse/TYRP +coarsen/SGD +coarseness/SM +coast/SMRDGZ +coastal +coaster/M +coastguard/MS +coastline/SM +coat/MDRGZJS +coated/U +coating/M +coattail/S +coattest +coauthor/MDGS +coax/GZDSR +coaxer/M +coaxial/Y +coaxing/Y +cob/SM +cobalt/MS +cobbed +cobbing +cobble/SRDGMZ +cobbler/M +cobblestone/MSD +coble/M +cobra/MS +cobweb/SM +cobwebbed +cobwebbing +cobwebby/RT +coca/MS +cocaine/MS +cocci/MS +coccus/M +coccyges +coccyx/M +cochineal/SM +cochlea/SM +cochleae +cochlear +cock/GDRMS +cockade/SM +cockamamie +cockatoo/SM +cockatrice/MS +cockcrow/MS +cocker/M +cockerel/MS +cockeye/DM +cockeyed/PY +cockfight/MJSG +cockfighting/M +cockily +cockiness/MS +cockle/SDGM +cocklebur/M +cockleshell/SM +cockney/MS +cockpit/MS +cockroach/SM +cockscomb/SM +cockshies +cocksucker/S! +cocksure +cocktail/GDMS +cocky/RPT +coco/MS +cocoa/SM +coconut/SM +cocoon/GDMS +cod/MDRSZGJ +coda/SM +codded +codding +coddle/GSRD +coddler/M +code's +code/SCZGJRD +codebook/S +codebreak/R +coded/UA +codeine/MS +codename/D +codependency/S +codependent/S +coder/CM +codes/A +codetermine/S +codeword/SM +codex/M +codfish/SM +codger/MS +codices/M +codicil/SM +codification/M +codifier/M +codify/NZXGRSD +coding/M +codling/M +codpiece/MS +coed/SM +coedited +coediting +coeditor/MS +coedits +coeducation/SM +coeducational +coefficient/SYM +coelenterate/MS +coequal/SY +coerce/SRDXVGNZ +coercer/M +coercible/I +coercion/M +coercive/PY +coerciveness/M +coeval/YS +coexist/GDS +coexistence/MS +coexistent +coextensive/Y +cofactor/MS +coffee/SM +coffeecake/SM +coffeecup +coffeehouse/SM +coffeemaker/S +coffeepot/MS +coffer/DMSG +cofferdam/SM +coffin/DMGS +cog/MS +cogency/MS +cogent/Y +cogged +cogging +cogitate/DSXNGV +cogitation/M +cogitator/MS +cognac/SM +cognate/SXYN +cognation/M +cognition/SAM +cognitional +cognitive/SY +cognizable +cognizance/MAI +cognizances/A +cognizant/I +cognomen/SM +cognoscente +cognoscenti +cogwheel/SM +cohabit/SDG +cohabitant/MS +cohabitation/SM +cohabitational +coheir/MS +cohere/GSRD +coherence/SIM +coherencies +coherency/I +coherent/IY +coherer/M +cohesion/MS +cohesive/PY +cohesiveness/SM +coho/MS +cohoes +cohort/SM +coif/SM +coiffed +coiffing +coiffure/MGSD +coil/UGSAD +coin/GZSDRM +coinage's/A +coinage/SM +coincide/GSD +coincidence/MS +coincident/Y +coincidental/Y +coined/U +coiner/M +coinsurance/SM +cointreau +coital/Y +coitus/SM +coke/MGDS +col/SD +cola/SM +colander/SM +colatitude/MS +cold/YRPST +coldblooded +coldish +coldness/MS +coleslaw/SM +coleus/SM +colic/SM +colicky +coliform +coliseum/SM +colitis/MS +coll/G +collaborate/VGNXSD +collaboration/M +collaborative/SY +collaborator/SM +collage/MGSD +collagen/M +collapse/SDG +collapsibility/M +collapsible +collar/DMGS +collarbone/MS +collard/SM +collarless +collate/SDVNGX +collated/U +collateral/SYM +collation/M +collator/MS +colleague/SDGM +collect/SAGD +collected/PY +collectedness/M +collectible/S +collection/AMS +collective/SY +collectivism/SM +collectivist/MS +collectivity/MS +collectivization/MS +collectivize/DSG +collector/MS +colleen/SM +college/SM +collegiality/S +collegian/SM +collegiate/Y +collide/SDG +collie/MZSRD +collier/M +colliery/MS +collimate/C +collimated/U +collimates +collimating +collimation/M +collimator/M +collinear +collinearity/M +collision/SM +collisional +collocate/XSDGN +collocation/M +colloid/MS +colloidal/Y +colloq +colloquial/SY +colloquialism/MS +colloquies +colloquium/SM +colloquy/M +collude/SDG +collusion/SM +collusive +collying +cologne/MSD +colon/SM +colonel/MS +colonelcy/MS +colonial/SPY +colonialism/MS +colonialist/MS +colonist/SM +colonization/ACSM +colonize/ACSDG +colonized/U +colonizer/MS +colonizes/U +colonnade/MSD +colony/SM +colophon/SM +color/SRDMGZJ +colorant/SM +coloration/EMS +coloratura/SM +colorblind/P +colorblindness/S +colored/USE +colorer/M +colorfast/P +colorfastness/SM +colorful/PY +colorfulness/MS +colorimeter/SM +colorimetry +coloring/M +colorization/S +colorize/GSD +colorizing/C +colorless/PY +colorlessness/SM +colors/EA +colossal/Y +colossi +colossus/M +colostomy/SM +colostrum/SM +colt/MRS +colter/M +coltish/PY +coltishness/M +columbine/SM +column/SDM +columnar +columnist/MS +columnize/GSD +com/LJRTZG +coma/SM +comae +comaker/SM +comatose +comb/SGZDRMJ +combat/SVGMD +combatant/SM +combative/PY +combativeness/MS +combed/U +comber/M +combination/ASM +combinational/A +combinator/SM +combinatorial/Y +combinatoric/S +combine/ZGBRSD +combined/AU +combiner/M +combines/A +combining/A +combo/MS +combusted +combustibility/SM +combustible/SI +combustion/MS +combustive +come/IZSRGJ +comeback/SM +comedian/SM +comedic +comedienne/SM +comedown/MS +comedy/SM +comeliness/SM +comely/TPR +comer/IM +comes/M +comestible/MS +comet/SM +cometary +cometh +comeuppance/SM +comfit's +comfit/SE +comfort/ESMDG +comfortability/S +comfortable/U +comfortableness/MS +comfortably/U +comforted/U +comforter/MS +comforting/YE +comfy/RT +comic/MS +comical/Y +comicality/MS +comity/SM +comm +comma/MS +command/SZRDMGL +commandant/MS +commandeer/SDG +commander/M +commanding/Y +commandment/SM +commando/SM +commemorate/SDVNGX +commemoration/M +commemorative/YS +commemorator/S +commence/ALDSG +commencement/AMS +commencer/M +commend/GSADRB +commendably +commendation/ASM +commendatory/A +commender/AM +commensurable/I +commensurate/IY +commensurates +commensuration/SM +comment's +comment/SUGD +commentary/MS +commentate/GSD +commentator/SM +commenter/M +commerce/MGSD +commercial/PYS +commercialism/MS +commercialization/SM +commercialize/GSD +commie/SM +commingle/GSD +commiserate/VGNXSD +commiseration/M +commissar/MS +commissariat/MS +commissary/MS +commission's/A +commission/ASCGD +commissioner/SM +commit/SA +commitment/SM +committable +committal/MA +committals +committed/UA +committee/MS +committeeman/M +committeemen +committeewoman/M +committeewomen +committing/A +commode/MS +commodes/IE +commodious/YIP +commodiousness/MI +commodity/MS +commodore/SM +common/RYUPT +commonality/MS +commonalty/MS +commoner/MS +commonness/MSU +commonplace/SP +commonplaceness/M +commons/M +commonsense +commonweal/SHM +commonwealth/M +commonwealths +commotion/MS +communal/Y +communality/M +commune/XSDNG +communicability/MS +communicable/IU +communicably +communicant/MS +communicate/VNGXSD +communication/M +communicational +communicative/PY +communicativeness/M +communicator/SM +communion/M +communique/S +communism/MS +communist/MS +communistic +communitarian/M +community/MS +communize/SDG +commutable/I +commutate/XVGNSD +commutation/M +commutative/Y +commutativity +commutator/MS +commute/BZGRSD +commuter/M +comp/GSYD +compact/TZGSPRDY +compaction/M +compactness/MS +compactor/MS +companion/GBSMD +companionable/P +companionableness/M +companionably +companionship/MS +companionway/MS +company/MSDG +comparabilities +comparability/IM +comparable/P +comparableness/M +comparably/I +comparative/PYS +comparativeness/M +comparator/SM +compare/GRSDB +comparer/M +comparison/MS +compartment/SDMG +compartmental +compartmentalization/SM +compartmentalize/DSG +compass/MSDG +compassion/MS +compassionate/PSDGY +compassionateness/M +compatibility/IMS +compatible/SI +compatibleness/M +compatibly/I +compatriot/SM +compeer/DSGM +compel/S +compellable +compelled +compelling/YM +compendious +compendium/MS +compensable +compensate/XVNGSD +compensated/U +compensation/M +compensator/M +compensatory +compete/GSD +competence/ISM +competency's +competency/IS +competent/IY +competition/SM +competitive/YP +competitiveness/SM +competitor/MS +compilable/U +compilation/SAM +compile/ASDCG +compiler's +compiler/CS +complacence/S +complacency/SM +complacent/Y +complain/GZRDS +complainant/MS +complainer/M +complaining/YU +complaint/MS +complaisance/SM +complaisant/Y +complected +complement/ZSMRDG +complementariness/M +complementarity +complementary/SP +complementation/M +complementer/M +complete/BTYVNGPRSDX +completed/U +completely/I +completeness/ISM +completer/M +completion/MI +complex/TGPRSDY +complexion/DMS +complexional +complexity/MS +complexness/M +compliance/SM +compliant/Y +complicate/SDG +complicated/YP +complicatedness/M +complication/M +complicator/SM +complicit +complicity/MS +complier/M +compliment/ZSMRDG +complimentary/U +complimenter/M +comply/ZXRSDNG +component/SM +comport/GLSD +comportment/SM +compose/CGASDE +composed/PY +composedness/M +composer/CM +composers +composite/YSDXNG +composition/CMA +compositional/Y +compositions/C +compositor/MS +compost/DMGS +composure/ESM +compote/MS +compound/RDMBGS +compounded/U +compounder/M +comprehend/DGS +comprehending/U +comprehensibility/SIM +comprehensible/PI +comprehensibleness/IM +comprehensibly/I +comprehension/IMS +comprehensive/YPS +comprehensiveness/SM +compress/SDUGC +compressed/Y +compressibility/IM +compressible/I +compression/CSM +compressional +compressive/Y +compressor/MS +comprise/GSD +compromise/SRDGMZ +compromiser/M +compromising/UY +comptroller/SM +compulsion/SM +compulsive/PYS +compulsiveness/MS +compulsivity +compulsorily +compulsory/S +compunction/MS +computability/M +computable/UI +computably +computation/SM +computational/Y +compute/RSDZBG +computed/A +computer/M +computerese +computerization/MS +computerize/SDG +computes/A +computing/A +comrade/YMS +comradely/P +comradeship/MS +con/SGM +concatenate/XSDG +concave/YP +concaveness/MS +conceal/BSZGRDL +concealed/U +concealer/M +concealing/Y +concealment/MS +conceded/Y +conceit/SGDM +conceited/YP +conceitedness/SM +conceivable/IU +conceivably/I +conceive/BGRSD +conceiver/M +concentrate/VNGSDX +concentration/M +concentrator/MS +concentrically +concept/SVM +conception/MS +conceptional +conceptual/Y +conceptuality/M +conceptualization's +conceptualization/A +conceptualizations +conceptualize/DRSG +conceptualizing/A +concern/USGD +concerned/YU +concert's +concert/EDSG +concerted/PY +concertina/MDGS +concertize/GDS +concertmaster/MS +concerto/SM +concession/R +concessionaire/SM +concessional +concessionary +conch/MDG +conchs +concierge/SM +conciliar +conciliate/GNVX +conciliation/ASM +conciliator/MS +conciliatory/A +concise/TYRNPX +conciseness/SM +concision/M +conclave/S +conclude/RSDG +concluder/M +conclusion/SM +conclusive/IPY +conclusiveness/ISM +concoct/RDVGS +concocter/M +concoction/SM +concomitant/YS +concordance/MS +concordant/Y +concordat/SM +concourse +concrete/NGXRSDPYM +concreteness/MS +concretion/M +concubinage/SM +concubine/SM +concupiscence/SM +concupiscent +concur/S +concurrence/MS +concuss/VD +concussion/MS +condemn/ZSGRDB +condemnate/XN +condemnation/M +condemnatory +condemner/M +condensate/NMXS +condensation/M +condense/ZGSD +condenser/M +condensible +condescend +condescending/Y +condescension/MS +condign +condiment/SM +condition's +condition/AGSJD +conditional/UY +conditionals +conditioned/U +conditioner/MS +conditioning/M +condo/SM +condole +condolence/MS +condom/SM +condominium/MS +condone/GRSD +condoner/M +condor/MS +conduce/VGSD +conducive/P +conduciveness/M +conduct/V +conductance/SM +conductibility/SM +conductible +conduction/MS +conductive/Y +conductivity/MS +conductor/MS +conductress/MS +conduit/MS +coneflower/M +coney's +confab/MS +confabbed +confabbing +confabulate/XSDGN +confabulation/M +confect/S +confection/RDMGZS +confectioner/M +confectionery/SM +confectionist +confederacy/MS +confederate/M +confer/SB +conferee/MS +conference/DSGM +conferrable +conferral/SM +conferred +conferrer/SM +conferring +confessed/Y +confession/MS +confessional/SY +confessor/SM +confetti/M +confidant/SM +confidante/SM +confide/ZGRSD +confidence/SM +confident/Y +confidential/PY +confidentiality/MS +confidentialness/M +confider/M +confiding/PY +configuration/ASM +configure/AGSDB +confine/L +confined/U +confinement/MS +confiner/M +confirm/AGDS +confirmation/ASM +confirmatory +confirmed/YP +confirmedness/M +confiscate/DSGNX +confiscation/M +confiscator/MS +confiscatory +conflagration/MS +conflate/NGSDX +conflation/M +conflict/SVGDM +conflicting/Y +confluence/MS +conform/B +conformable/U +conformal +conformance/SM +conformational/Y +conformer/M +conformism/SM +conformist/SM +conformities +conformity/MUI +confound/R +confounded/Y +confront/Z +confrontation/SM +confrontational +confronter/M +confr�re/MS +confuse/RBZ +confused/PY +confusedness/M +confusing/Y +confutation/MS +confute/GRSD +confuter/M +conga/MDG +congeal/GSDL +congealment/MS +congenial/U +congeniality/UM +conger/SM +congeries/M +congest/VGSD +congestion/MS +conglomerate/XDSNGVM +conglomeration/M +congrats +congratulate/NGXSD +congratulation/M +congratulatory +congregate/DSXGN +congregation/M +congregational +congregationalism/MS +congregationalist/MS +congress/MSDG +congressional/Y +congressman/M +congressmen +congresspeople +congressperson/S +congresswoman/M +congresswomen +congruence/IM +congruences +congruency/M +congruent/YI +congruential +congruity/MSI +congruous/YIP +congruousness/IM +conic/S +conical/PSY +conicalness/M +conics/M +conifer/MS +coniferous +conjectural/Y +conjecture/GMDRS +conjecturer/M +conjoint +conjugacy +conjugal/Y +conjugate/XVNGYSDP +conjugation/M +conjunct/DSV +conjunctiva/MS +conjunctive/YS +conjunctivitis/SM +conjuration/MS +conjure/RSDZG +conjurer/M +conjuring/M +conk/ZDR +conker/M +conman +conn/GVDR +connect/ADGES +connected/U +connectedly/E +connectedness/ME +connectible +connection/AME +connectionless +connections/E +connective/SYM +connectivity/MS +connector/MS +connexion/MS +conniption/MS +connivance/MS +connive/ZGRSD +conniver/M +connoisseur/MS +connotative/Y +connubial/Y +conquer/RDSBZG +conquerable/U +conquered/AU +conqueror/MS +conquers/A +conquest/ASM +conquistador/MS +consanguineous/Y +consanguinity/SM +conscienceless +conscientious/YP +conscientiousness/MS +conscionable/U +conscious/UYSP +consciousness/MUS +conscription/SM +consecrate/XDSNGV +consecrated/AU +consecrates/A +consecrating/A +consecration/AMS +consecutive/YP +consecutiveness/M +consensus/SM +consent/SZGRD +consenter/M +consenting/Y +consequence +consequent/PSY +consequential/IY +consequentiality/S +consequentialness/M +consequently/I +conservancy/SM +conservation/SM +conservationism +conservationist/SM +conservatism/SM +conservative/SYP +conservativeness/M +conservator/MS +conservatory/MS +consider/GASD +considerable/I +considerables +considerably/I +considerate/XIPNY +considerateness/MSI +consideration/ASMI +considered/U +considerer/M +considering/S +consign/ASGD +consignee/SM +consignment/SM +consist/DSG +consistence/S +consistency/IMS +consistent/IY +consistory/MS +consolable/I +consolation's/E +consolation/MS +consolatory +console/ZBG +consoled/U +consoler/M +consolidate/NGDSX +consolidated/AU +consolidates/A +consolidation/M +consolidator/SM +consoling/Y +consomm�/S +consonance/IM +consonances +consonant/MYS +consonantal +consortia +consortium/M +conspectus/MS +conspicuous/YIP +conspicuousness/IMS +conspiracy/MS +conspirator/SM +conspiratorial/Y +constable +constabulary/MS +constance +constancy/IMS +constant/IY +constants +constellation/SM +consternate/XNGSD +consternation/M +constipate/XDSNG +constipation/M +constituency/MS +constituent/SYM +constitute/NGVXDS +constituted/A +constitutes/A +constituting/A +constitution/AMS +constitutional/SY +constitutionality's +constitutionality/US +constitutionally/U +constitutive/Y +constrain +constrained/U +constrainedly +constraint/MS +constrict/SDGV +constriction/MS +constrictor/MS +construable +construct/ASDGV +constructibility +constructible/A +construction/MAS +constructional/Y +constructionist/MS +constructions/C +constructive/YP +constructiveness/SM +constructor/MS +construe/GSD +consul/KMS +consular/S +consulate/MS +consulship/MS +consult/RDVGS +consultancy/S +consultant/MS +consultation/SM +consultative +consulted/A +consulter/M +consumable/S +consume/JZGSDB +consumed/Y +consumer/M +consumerism/MS +consumerist/S +consuming/Y +consummate/DSGVY +consummated/U +consumption/SM +consumptive/YS +cont +cont'd +contact's/A +contact/BGD +contacted/A +contacts/A +contagion/SM +contagious/YP +contagiousness/MS +contain/SLZGBRD +container/M +containerization/SM +containerize/GSD +containment/SM +contaminant/SM +contaminate/SDCXNG +contaminated/AU +contaminates/A +contaminating/A +contamination/CM +contaminative +contaminator/MS +contd +contemn/SGD +contemplate/DVNGX +contemplation/M +contemplative/PSY +contemplativeness/M +contemporaneity/MS +contemporaneous/PY +contemporaneousness/M +contempt/M +contemptible/P +contemptibleness/M +contemptibly +contemptuous/PY +contemptuousness/SM +content/EMDLSG +contented/YP +contentedly/E +contentedness/SM +contention/MS +contentious/PY +contentiousness/SM +contently +contentment's +contentment/ES +conterminous/Y +contestable/I +contestant/SM +contested/U +contextualize/GDS +contiguity/MS +contiguous/YP +contiguousness/M +continence/ISM +continent's +continent/IY +continental/SY +continents +contingency/SM +contingent/SMY +continua +continuable +continual/Y +continuance/ESM +continuant/M +continuation/ESM +continue/ESDG +continuer/M +continuity/SEM +continuous/YE +continuousness/M +continuum/M +contort/VGD +contortion/MS +contortionist/SM +contour +contra/S +contraband/SM +contrabass/M +contraception/SM +contraceptive/S +contract/DG +contractible +contractile +contractual/Y +contradict/GDS +contradiction/MS +contradictorily +contradictoriness/M +contradictory/PS +contradistinction/MS +contraflow/S +contrail/M +contraindicate/SDVNGX +contraindication/M +contralto/SM +contrapositive/S +contraption/MS +contrapuntal/Y +contrariety/MS +contrarily +contrariness/MS +contrariwise +contrary/PS +contrast/SRDVGZ +contrasting/Y +contrastive/Y +contravene/GSRD +contravener/M +contravention/MS +contretemps/M +contribute/XVNZRD +contribution/M +contributive/Y +contributor/SM +contributorily +contributory/S +contrite/NXP +contriteness/M +contrition/M +contrivance/SM +contrive/ZGRSD +contriver/M +control's +control/CS +controllability/M +controllable/IU +controllably/U +controlled/CU +controller/SM +controlling/C +controversial/UY +controversialists +controversy/MS +controvert/DGS +controvertible/I +contumacious/Y +contumacy/MS +contumelious +contumely/MS +contuse/NGXSD +contusion/M +conundrum/SM +conurbation/MS +convalesce/GDS +convalescence/SM +convalescent/S +convect/DSVG +convection/MS +convectional +convector +convene/ASDG +convener/MS +convenience/ISM +convenient/IY +conventicle/SM +convention/MA +conventional/UY +conventionalism/M +conventionalist/M +conventionality/SUM +conventionalize/GDS +conventions +convergence/MS +convergent +conversant/Y +conversation/SM +conversational/Y +conversationalist/SM +conversazione/M +converse/Y +conversion/AM +conversioning +convert/GADS +converted/U +converter/MS +convertibility's/I +convertibility/SM +convertible/PS +convertibleness/M +convex/Y +convexity/MS +convey/BDGS +conveyance/DRSGMZ +conveyancer/M +conveyancing/M +conveyor/MS +convict/SVGD +conviction/MS +convince/RSDZG +convinced/U +convincer/M +convincing/PUY +convincingness/M +convivial/Y +conviviality/MS +convoke/GSD +convolute/XDNY +convolution/M +convolve/C +convolved +convolves +convolving +convoy/GMDS +convulse/SDXVNG +convulsion/M +convulsive/YP +convulsiveness/M +cony/SM +coo/GSD +cook/GZDRMJS +cookbook/SM +cooked/AU +cooker/M +cookery/MS +cookie/SM +cooking/M +cookout/SM +cooks/A +cookware/SM +cooky's +cool/YDRPJGZTS +coolant/SM +cooled/U +cooler/M +coolheaded +coolie/MS +coolness/MS +coon/MS! +coonskin/MS +coop/MDRGZS +cooper/GDM +cooperage/MS +cooperate/VNGXSD +cooperation/M +cooperative/PSY +cooperativeness/SM +cooperator/MS +coordinate/XNGVYPDS +coordinated/U +coordinateness/M +coordination/M +coordinator/MS +coot/MS +cootie/SM +cop/SJMDRG +copay/S +cope/S +coper/M +copied/A +copier/M +copies/A +copilot/SM +coping/M +copious/YP +copiousness/SM +coplanar +copolymer/MS +copora +copped +copper/MSGD +copperhead/MS +copperplate/MS +coppersmith/M +coppersmiths +coppery +coppice's +copping +copra/MS +coprolite/M +coprophagous +cops/GDS +copse/M +copter/SM +copula/MS +copulate/XDSNGV +copulation/M +copulative/S +copy/MZBDSRG +copybook/MS +copycat/SM +copycatted +copycatting +copyist/SM +copyright/MSRDGZ +copyrighter/M +copywriter/MS +coquetry/MS +coquette/DSMG +coquettish/Y +coracle/SM +coral/SM +coralline +corbel/GMDJS +cord/FSAEM +cordage/MS +corded/AE +corder/AM +cordial/PYS +cordiality/MS +cordialness/M +cordillera/MS +cording/MA +cordite/MS +cordless +cordon/DMSG +cordovan/SM +corduroy/GDMS +core/MZGDRS +cored/A +corer/M +corespondent/MS +corgi/MS +coriander/SM +coring/M +cork/GZDRMS +corked/U +corker/M +corks/U +corkscrew/DMGS +corm/MS +cormorant/MS +corn/GZDRMS +cornball/SM +cornbread/S +corncob/SM +corncrake/M +cornea/SM +corneal +corner/GDM +cornerstone/MS +cornet/SM +cornfield/SM +cornflake/S +cornflour/M +cornflower/SM +cornice/GSDM +cornily +corniness/S +cornmeal/S +cornrow/GDS +cornstalk/MS +cornstarch/SM +cornucopia/MS +corny/RPT +corolla/MS +corollary/SM +corona/SM +coronal/MS +coronary/S +coronate/NX +coronation/M +coroner/MS +coronet/DMS +coroutine/SM +corp/S +corpora/MS +corporal/SYM +corporate/INVXS +corporately +corporation/MI +corporatism/M +corporatist +corporeal/IY +corporeality/MS +corporealness/M +corps/SM +corpse/M +corpsman/M +corpsmen +corpulence/MS +corpulent/YP +corpulentness/S +corpus/M +corpuscle/SM +corpuscular +corr +corral/MS +corralled +corralling +correct/BPSDRYTGV +correctable/U +corrected/U +correction/MS +correctional +corrective/YPS +correctly/I +correctness/MSI +corrector/MS +correlate/SDXVNG +correlated/U +correlation/M +correlative/YS +correspond/DSG +correspondence/MS +correspondent/SM +corresponding/Y +corridor/SM +corrigenda +corrigendum/M +corrigible/I +corroborate/GNVXDS +corroborated/U +corroboration/M +corroborative/Y +corroborator/MS +corroboratory +corrode/SDG +corrodible +corrosion/SM +corrosive/YPS +corrosiveness/M +corrugate/NGXSD +corrugation/M +corrupt/DRYPTSGV +corrupted/U +corrupter/M +corruptibility/SMI +corruptible/I +corruption/IM +corruptions +corruptive/Y +corruptness/MS +corsage/MS +corsair/SM +corset/GMDS +cortex/M +cortical/Y +cortices +corticosteroid/SM +cortisone/SM +cort�ge/MS +corundum/MS +coruscate/XSDGN +coruscation/M +corvette/MS +cos/GDS +cosign/SRDZG +cosignatory/MS +cosily +cosine/MS +cosiness/MS +cosmetic/SM +cosmetically +cosmetician/MS +cosmetologist/MS +cosmetology/MS +cosmic +cosmical/Y +cosmogonist/MS +cosmogony/SM +cosmological/Y +cosmologist/MS +cosmology/SM +cosmonaut/MS +cosmopolitan/SM +cosmopolitanism/MS +cosmos/SM +cosponsor/DSG +cossack/S +cosset/GDS +cost/MYGVJS +costar/S +costarred +costarring +costive/PY +costiveness/M +costless +costliness/SM +costly/RTP +costume/ZMGSRD +costumer/M +cot/SGMD +cotangent/SM +cote/MS +coterie/MS +coterminous/Y +cotillion/SM +cottage/ZMGSRD +cottager/M +cottar's +cotted +cotter/SDM +cotton/GSDM +cottonmouth/M +cottonmouths +cottonseed/MS +cottontail/SM +cottonwood/SM +cottony +cotyledon/MS +couch/MSDG +couching/M +cougar/MS +cough/RDG +cougher/M +coughs +could've +could/T +couldn't +coulomb/SM +coul�e/MS +council/SM +councilman/M +councilmen +councilor/MS +councilperson/S +councilwoman/M +councilwomen +counsel/GSDM +counsellings +counselor/MS +count/EGARDS +countability/E +countable/U +countably/U +countdown/SM +counted/U +countenance's +countenance/EGDS +countenancer/M +counter's/E +counter/GSMD +counteract/DSVG +counteraction/SM +counterargument/SM +counterattack/DRMGS +counterbalance/MSDG +counterclaim/GSDM +counterclockwise +counterculture/MS +countercyclical +counterespionage/MS +counterexample/S +counterfeit/ZSGRD +counterfeiter/M +counterflow +counterfoil/MS +counterforce/M +counterinsurgency/MS +counterintelligence/MS +counterintuitive +counterman/M +countermand/DSG +countermeasure/SM +countermen +counteroffensive/SM +counteroffer/SM +counterpane/SM +counterpart/SM +counterpoint/GSDM +counterpoise/GMSD +counterproductive +counterproposal/M +counterrevolution/MS +counterrevolutionary/MS +counters/E +countersign/SDG +countersignature/MS +countersink/SG +counterspy/MS +counterstrike +countersunk +countertenor/SM +countervail/DSG +counterweight/GMDS +countess/MS +countless/Y +countrify/D +country/MS +countryman/M +countrymen +countryside/MS +countrywide +countrywoman/M +countrywomen +county/SM +coup's +coup/ASDG +coupe/MS +couple's +couple/ACU +coupled/CU +coupler's +coupler/C +couplers +couples/CU +couplet/SM +coupling's/C +coupling/SM +coupon/SM +courage/MS +courageous/U +courageously +courageousness/MS +courages/E +courgette/MS +courier/GMDS +course's/AF +course/EGSRDM +courser's/E +courser/SM +courses/FA +coursework +coursing/M +court/GZMYRDS +courteous/PEY +courteousness/EM +courteousnesses +courtesan/MS +courtesied +courtesy/ESM +courtesying +courthouse/MS +courtier/SM +courtliness/MS +courtly/RTP +courtroom/MS +courtship/SM +courtyard/SM +couscous/MS +cousin/YMS +cousinly/U +couture/SM +couturier/SM +covalent/Y +covariance/SM +covariant/S +covariate/SN +covary +cove/DRSMZG +coven/SM +covenant/SGRDM +covenanted/U +covenanter/M +cover/AEGUDS +coverable/E +coverage/MS +coverall/DMS +coverer/AME +covering/MS +coverlet/MS +covers/M +coversheet +covert/YPS +covertness/SM +covet/SGRD +coveter/M +coveting/Y +covetous/PY +covetousness/SM +covey/SM +covington +cow/MDRSZG +coward/MYS +cowardice/MS +cowardliness/MS +cowardly/P +cowbell/MS +cowbird/MS +cowboy/MS +cowcatcher/SM +cowed/Y +cower/RDGZ +cowering/Y +cowgirl/MS +cowhand/S +cowherd/SM +cowhide/MGSD +cowl/SGMD +cowlick/MS +cowling/M +cowman/M +cowmen +coworker/MS +cowpoke/MS +cowpony +cowpox/MS +cowpunch/RZ +cowpuncher/M +cowrie/SM +cowshed/SM +cowslip/MS +cox/MDSG +coxcomb/MS +coxswain/GSMD +coy/CDSG +coyer +coyest +coyly +coyness/MS +coyote/SM +coypu/SM +cozen/SGD +cozenage/MS +cozily +coziness/MS +cozy/DSRTPG +cpd +cpl +cps +crab/MS +crabapple +crabbed/YP +crabbedness/M +crabber/MS +crabbily +crabbiness/S +crabbing/M +crabby/PRT +crabgrass/S +crablike +crack/ZSBYRDG +crackable/U +crackdown/MS +cracker/M +crackerjack/S +crackle/GJDS +crackling/M +crackly/RT +crackpot/SM +crackup/S +cradle/SRDGM +cradler/M +cradling/M +craft/MRDSG +craftily +craftiness/SM +craftsman/M +craftsmanship/SM +craftsmen +craftspeople +craftspersons +craftswoman +craftswomen +crafty/TRP +crag/SM +cragginess/SM +craggy/RTP +cram/S +crammed +crammer/M +cramming +cramp/MRDGS +cramper/M +crampon/SM +cranberry/SM +crane/DSGM +cranelike +cranial +cranium/MS +crank/SGTRDM +crankcase/MS +crankily +crankiness/MS +crankshaft/MS +cranky/TRP +cranny/DSGM +crap/SMDG! +crape/SM +crapped +crappie/M +crapping +crappy/RST +crapshooter/SM +crash/SRDGZ +crasher/M +crashing/Y +crass/TYRP +crassness/MS +crate/DSRGMZ +crater/DMG +cravat/SM +cravatted +cravatting +crave/DSRGJ +craven/SPYDG +cravenness/SM +craver/M +craving/M +craw/SYM +crawdad/S +crawfish's +crawl/RDSGZ +crawler/M +crawlspace/S +crawlway +crawly/TRS +crayfish/GSDM +crayon/GSDM +craze/GMDS +crazily +craziness/MS +crazy/SRTP +creak/SDG +creakily +creakiness/SM +creaky/PTR +cream/SMRDGZ +creamer/M +creamery/MS +creamily +creaminess/SM +creamy/TRP +crease's +crease/IDRSG +creased/CU +creases/C +creasing/C +create/XKVNGADS +created/U +creation/MAK +creationism/MS +creationist/MS +creative/YP +creativeness/SM +creativities +creativity's +creativity/K +creator/MS +creature/YMS +creatureliness/M +creaturely/P +credence/MS +credent +credential/SGMD +credenza/SM +credibility/IMS +credible/I +credibly/I +credit's +credit/EGBSD +creditability/M +creditable/P +creditableness/M +creditably/E +credited/U +creditor/MS +creditworthiness +credo/SM +credulity/ISM +credulous/IY +credulousness/SM +creed's +creed/C +creedal +creeds +creek/SM +creekside +creel/SMDG +creep/SGZR +creeper/M +creepily +creepiness/SM +creepy/PRST +cremate/XDSNG +cremation/M +crematoria +crematorium/MS +crematory/S +creme/S +crenelate/XGNSD +crenelation/M +creole/SM +creosote/MGDS +crepe/DSGM +crept +crescendo/SCM +crescendoed +crescendoing +crescent/MS +cress/S +crest/SGMD +crestfallen/PY +crestfallenness/M +cresting/M +crestless +cretaceous +cretin/MS +cretinism/MS +cretinous +cretonne/SM +crevasse/DSMG +crevice/SM +crew/DMGS +crewel/SM +crewelwork/SM +crewman/M +crewmen +crib/SM +cribbage/SM +cribbed +cribber/SM +cribbing/M +crick/GDSM +cricket/SMZRDG +cricketer/M +cried/C +crier/CM +cries/C +crime/GMDS +criminal/SYM +criminality/MS +criminalization/C +criminalize/GC +criminologist/SM +criminology/MS +crimp/RDGS +crimper/M +crimson/DMSG +cringe/SRDG +cringer/M +crinkle/DSG +crinkly/TRS +crinoline/SM +cripple/GMZDRS +crippler/M +crippling/Y +crises +crisis/M +crisp/PGTYRDS +crisper/M +crispiness/SM +crispness/MS +crispy/RPT +criss +crisscross/GDS +criteria +criterion/M +critic/MS +critical/YP +criticality +critically/U +criticalness/M +criticism/MS +criticize/GSRDZ +criticized/U +criticizer/M +criticizes/A +criticizing/UY +criticizingly/S +critique/MGSD +critter/SM +croak/SRDGZ +croaker/M +croaky/RT +crochet/RDSZJG +crocheter/M +crock/SGRDM +crockery/SM +crocodile/MS +crocus/SM +croft/MRGZS +crofter/M +croissant/MS +crone/SM +crony/SM +crook/SGDM +crooked/TPRY +crookedness/SM +crookneck/MS +croon/SRDGZ +crooner/M +crop/MS +cropland/MS +cropped +cropper/SM +cropping +croquet/MDSG +croquette/SM +crosier/SM +cross/ZTYSRDMPBJG +crossarm +crossbar/SM +crossbarred +crossbarring +crossbeam/MS +crossbones +crossbow/SM +crossbowman/M +crossbowmen +crossbred/S +crossbreed/SG +crosscheck/SGD +crosscurrent/SM +crosscut/SM +crosscutting +crossed/UA +crosses/UA +crossfire/SM +crosshatch/GDS +crossing/M +crossness/MS +crossover/MS +crosspatch/MS +crosspiece/SM +crosspoint +crossproduct/S +crossroad/GSM +crossroads/M +crosstalk/M +crosstown +crosswalk/MS +crossway/M +crosswind/SM +crosswise +crossword/MS +crotch/MDS +crotchet/MS +crotchetiness/M +crotchety/P +crotchless +crouch/DSG +croup/SMDG +croupier/M +croupy/TZR +crow/GDMS +crowbait +crowbar/SM +crowbarred +crowbarring +crowd/MRDSG +crowded/P +crowdedness/M +crowfeet +crowfoot/M +crown/RDMSJG +crowned/U +crowner/M +crozier's +cro�ton/MS +crucial/Y +crucible/MS +crucifiable +crucifix/SM +crucifixion/MS +cruciform/S +crucify/NGDS +crud/STMR +crudded +crudding +cruddy/TR +crude/YSP +crudeness/MS +crudity/MS +crudit�s +cruel/YRTSP +cruelness/MS +cruelty/SM +cruet/MS +cruft +crufty +cruise/GZSRD +cruiser/M +cruller/SM +crumb/GSYDM +crumble/DSJG +crumbliness/MS +crumbly/PTRS +crumby/RT +crumminess/S +crummy/SRTP +crump +crumpet/SM +crumple/DSG +crunch/DSRGZ +crunchiness/MS +crunchy/TRP +crupper/MS +crusade/GDSRMZ +crusader/M +cruse/MS +crush/SRDBGZ +crushable/U +crusher/M +crushing/Y +crushproof +crust/GMDS +crustacean/MS +crustal +crustily +crustiness/SM +crusty/SRTP +crutch/MDSG +crux/MS +cry/JGDRSZ +crybaby/MS +cryogenic/S +cryogenics/M +cryostat/M +cryosurgery/SM +crypt's +crypt/CS +cryptanalysis/M +cryptanalyst/M +cryptanalytic +cryptic +cryptically +cryptogram/MS +cryptographer/MS +cryptographic +cryptographically +cryptography/MS +cryptologic +cryptological +cryptologist/M +cryptology/M +crystal/SM +crystalline/S +crystallite/SM +crystallization/AMS +crystallize/SRDZG +crystallized/UA +crystallizes/A +crystallizing/A +crystallographer/MS +crystallographic +crystallography/M +cr�che/SM +cs's +cs/EA +ct +ctn +ctr +cu/DG +cub/MDRSZG +cubbed +cubbing +cubbyhole/MS +cube/SM +cuber/M +cubic/YS +cubical/Y +cubicle/SM +cubism/SM +cubist/MS +cubit/MS +cuboid +cuckold/GSDM +cuckoldry/MS +cuckoo/SGDM +cucumber/MS +cud/MS +cuddle/GSD +cuddly/TRP +cudgel/GSJMD +cue/MS +cuff/GSDM +cuisine/MS +culinary +cull/DRGS +cullender's +culler/M +culminate/XSDGN +culmination/M +culotte/S +culpa/SM +culpability/MS +culpable/I +culpableness/M +culpably +culprit/SM +cult/MS +cultism/SM +cultist/SM +cultivable +cultivate/XBSDGN +cultivated/U +cultivation/M +cultivator/SM +cultural/Y +culture/SDGM +cultured/U +culvert/SM +cum/S +cumber/DSG +cumbersome/YP +cumbersomeness/MS +cumbrous +cumin/MS +cummerbund/MS +cumquat's +cumulate/XVNGSD +cumulation/M +cumulative/Y +cumuli +cumulonimbi +cumulonimbus/M +cumulus/M +cuneiform/S +cunnilingus/SM +cunning/RYSPT +cunningness/M +cunt/SM! +cup/MS +cupboard/SM +cupcake/SM +cupful/SM +cupid/S +cupidinously +cupidity/MS +cupola/MDGS +cupped +cupping/M +cupric +cuprous +cur's +cur/IBS +curability/MS +curable/IP +curableness/MI +curably/I +curacy/SM +curare/MS +curate/VGMSD +curative/YS +curator/KMS +curatorial +curb/SJDMG +curbing/M +curbside +curbstone/MS +curd/SMDG +curdle/SDG +cure/KBDRSGZ +cured/U +curer/MK +curettage/SM +curfew/SM +curfs +curia/M +curiae +curie/SM +curio/SM +curiosity/SM +curious/TPRY +curiousness/SM +curium/MS +curl/UDSG +curler/SM +curlew/MS +curlicue/MGDS +curliness/SM +curling/M +curly/PRT +curlycue's +curmudgeon/MYS +currant/SM +curred/AFI +currency's +currency/SF +current/FSY +currently/A +currentness/M +curricle/M +curricula +curricular +curriculum/M +currier/M +curring/FAI +curry/RSDMG +currycomb/DMGS +curs/ASDVG +curse's +curse/A +cursed/YRPT +cursedness/M +cursive/EPYA +cursiveness/EM +cursives +cursor/DMSG +cursorily +cursoriness/SM +cursory/P +curt/TYRP +curtail/LSGDR +curtailer/M +curtailment/SM +curtain/GSMD +curtness/MS +curtsey's +curtsy/SDMG +curvaceous/YP +curvaceousness/S +curvature/MS +curve/DSGM +curved's +curved/A +curvilinear/Y +curvilinearity/M +curving/M +curvy/RT +cushion/SMDG +cushy/TR +cusp/MS +cuspid/MS +cuspidor/MS +cuss's +cuss/EGDSR +cussed/YP +cussedness/M +cusses/F +cussing/F +custard/MS +custodial +custodian/SM +custodianship/MS +custody/MS +custom/SMRZ +customarily +customariness/M +customary/PS +customer/M +customhouse/S +customization/SM +customize/ZGBSRD +cut/MRST +cutaneous/Y +cutaway/SM +cutback/SM +cute/SPY +cuteness/MS +cutesy/RT +cuticle/SM +cutlass/MS +cutler/SM +cutlery/MS +cutlet/SM +cutoff/MS +cutout/SM +cutter/SM +cutthroat/SM +cutting/MYS +cuttle/M +cuttlebone/SM +cuttlefish/MS +cutup/MS +cutworm/MS +cw +cwt +cyan/MS +cyanate/M +cyanic +cyanide/GMSD +cyanogen/M +cybernetic/S +cybernetics/M +cyberpunk/S +cyberspace/S +cyborg/S +cyclamen/MS +cycle's +cycle/ASDG +cycler +cycleway/S +cyclic +cyclical/SY +cycling/M +cyclist/MS +cyclohexanol +cycloid/SM +cycloidal +cyclometer/MS +cyclone/SM +cyclonic +cyclopean +cyclopedia/MS +cyclopes +cyclops +cyclotron/MS +cyder/SM +cygnet/MS +cylinder/GMDS +cylindric +cylindrical/Y +cymbal/SM +cymbalist/MS +cynic/MS +cynical/UY +cynicism/MS +cynosure/SM +cypher/MGSD +cypreses +cypress/SM +cyst/MS +cystic +cytochemistry/M +cytochrome/M +cytologist/MS +cytology/MS +cytolysis/M +cytoplasm/SM +cytoplasmic +cytosine/MS +cytotoxic +czar/SM +czarevitch/M +czarina/SM +czarism/M +czarist/S +czarship +d'Arezzo +d'Estaing +d'art +d'etat +d'etre +d'oeuvre +d's/A +d/JGVX +dB/M +dab/S +dabbed +dabber/MS +dabbing +dabble/RSDZG +dabbler/M +dace/MS +dacha/SM +dachshund/SM +dactyl/MS +dactylic/S +dad/SM +dadaism/S +dadaist/S +daddy/SM +dado/DMG +dadoes +daemon/SM +daemonic +daffiness/S +daffodil/MS +daffy/PTR +daft/TYRP +daftness/MS +dagger/DMSG +daguerreotype/MGDS +dahlia/MS +dailiness/MS +daily/PS +daintily +daintiness/MS +dainty/TPRS +daiquiri/SM +dairy/MJGS +dairying/M +dairyland +dairymaid/SM +dairyman/M +dairymen +dairywoman/M +dairywomen +dais/SM +daisy/SM +dale/SMH +daleth/M +dalliance/SM +dallier/M +dally/ZRSDG +dalmatian/S +dam/MDS +damage/MZGRSD +damageable +damaged/U +damager/M +damaging/Y +damask/DMGS +dame/SM +dammed +damming +dammit/S +damn/GSBRD +damnably +damnation/MS +damned/TR +damnedest/MS +damning/Y +damp/SGZTXYRDNP +damped/U +dampen/RDZG +dampener/M +damper/M +dampness/MS +damsel/MS +damselfly/MS +damson/MS +dance/SRDJGZ +dancelike +dancer/M +dandelion/MS +dander/DMGS +dandify/SDG +dandily +dandle/GSD +dandruff/MS +dandy/TRSM +dang/SGZRD +danger/DMG +dangerous/YP +dangerousness/M +dangle/ZGRSD +dangler/M +dangling/Y +danish/S +dank/TPYR +dankness/MS +danseuse/SM +dapper/PSTRY +dapperness/M +dapple/SDG +dare/ZGDRSJ +daredevil/MS +daredevilry/S +darer/M +daresay +daring/PY +daringness/M +dark/GTXYRDNSP +darken/RDZG +darkener/M +darkish +darkly/TR +darkness/MS +darkroom/SM +darling/YMSP +darlingness/M +darn/GRDZS +darned/TR +darner/M +darning/M +dart/MRDGZS +dartboard/SM +darter/M +dash/GZSRD +dashboard/SM +dasher/M +dashiki/SM +dashing/Y +dastard/MYS +dastardliness/SM +dastardly/P +data/M +database/DSMG +datafile +datagram/MS +dataset/S +date/DRSMZGV +dated/U +datedly +datedness +dateless +dateline/DSMG +dater/M +dative/S +datum/MS +daub/RDSGZ +dauber/M +daughter/MYS +daunt/DSG +daunted/U +daunting/Y +dauntless/PY +dauntlessness/SM +dauphin/SM +davenport/MS +davit/SM +dawdle/ZGRSD +dawdler/M +dawn/GSDM +day/SM +daybed/S +daybreak/SM +daycare/S +daydream/RDMSZG +daydreamer/M +daylight/GSDM +daysack +daytime/SM +daze/DSG +dazed/PY +dazzle/ZGJRSD +dazzler/M +dazzling/Y +db +dbl +deacon/DSMG +deaconess/MS +dead/PTXYRN +deadbeat/SM +deadbolt/S +deaden/RDG +deadener/M +deadening/MY +deadhead/MS +deadline/MGDS +deadliness/SM +deadlock/MGDS +deadly/RPT +deadness/M +deadpan/S +deadpanned +deadpanner +deadpanning +deadwood/SM +deaf/TXPYRN +deafen/JGD +deafening/MY +deafness/MS +deal/RSGZJ +dealer/M +dealership/MS +dealing/M +deallocator +dealt +dean/DMG +deanery/MS +deanship/SM +dear/TYRHPS +dearness/MS +dearth/M +dearths +deary/MS +deassign +death/MY +deathbed/MS +deathblow/SM +deathless/Y +deathlike +deathly/TR +deaths +deathtrap/SM +deathward +deathwatch/MS +deb/MS +debacle/SM +debar/L +debark/G +debarkation/SM +debarment/SM +debarring +debaser/M +debatable/U +debate/BMZ +debater/M +debauch/GDRS +debauched/PY +debauchedness/M +debauchee/SM +debaucher/M +debauchery/SM +debenture/MS +debilitate/NGXSD +debilitation/M +debility/MS +debit/DG +debonair/PY +debonairness/SM +debouch/DSG +debrief/GJ +debris/M +debt/SM +debtor/SM +debut/MDG +decade/MS +decadency/S +decadent/YS +decaf/S +decaffeinate/DSG +decagon/MS +decal/SM +decamp/L +decampment/MS +decapitate/GSD +decapitator/SM +decathlon/SM +decay/GRD +decease/M +decedent/MS +deceit/SM +deceitful/PY +deceitfulness/SM +deceive/ZGRSD +deceived/U +deceiver/M +deceives/U +deceiving/U +deceivingly +decelerate/XNGSD +deceleration/M +decelerator/SM +decency/ISM +decennial/SY +decent/TIYR +deception/SM +deceptive/YP +deceptiveness/SM +decertify/N +dechlorinate/N +decibel/MS +decidability/U +decidable/U +decide/GRSDB +decided/PY +decidedness/M +deciduous/YP +deciduousness/M +decile/SM +deciliter/SM +decimal/SYM +decimate/XNGDS +decimation/M +decimeter/MS +decipher/BRZG +decipherable/IU +decipherer/M +decision/ISM +decisional +decisioned +decisioning +decisive/IPY +decisiveness/MSI +deck/GRDMSJ +deckchair +decker/M +deckhand/S +decking/M +declamation/SM +declamatory +declarable +declaration's/A +declaration/MS +declarative/SY +declarator/MS +declaratory +declare/AGSD +declared/U +declarer/MS +declension/SM +declination/MS +decline/ZGRSD +decliner/M +declivity/SM +deco +decolletes +decolorising +decomposability/M +decomposable/IU +decompose/B +decompress/R +decongestant/S +deconstruction +deconvolution +decor/S +decorate/NGVDSX +decorated/AU +decorates/A +decorating/A +decoration/ASM +decorative/YP +decorativeness/M +decorator/SM +decorous/PIY +decorousness's/I +decorousness/MS +decorticate/GNDS +decortication/M +decorum/MS +decoupage/MGSD +decouple/G +decoy/M +decrease +decreasing/Y +decree/RSM +decreeing +decrement/DMGS +decremental +decrepit +decrepitude/SM +decriminalization/S +decriminalize/DS +decry/G +decrypt/GD +decryption +decustomised +dedicate/AGDS +dedicated/Y +dedication/MS +dedicative +dedicator/MS +dedicatory +deduce/RSDG +deducible +deduct/VG +deductibility/M +deductible/S +deduction/SM +deductive/Y +deed's +deed/IS +deeded +deeding +deejay/MDSG +deem/ADGS +deemphasis +deep/PTXSYRN +deepen/DG +deepish +deepness/MS +deer/SM +deerskin/MS +deerstalker/SM +deerstalking/M +def/Z +deface/LZ +defacement/SM +defaecate +defalcate/NGXSD +defalcation/M +defamation/SM +defamatory +defame/ZR +defamer/M +default/ZR +defaulter/M +defeat/ZGD +defeated/U +defeater/M +defeatism/SM +defeatist/SM +defecate/DSNGX +defecation/M +defect/MDSVG +defection/SM +defective/PYS +defectiveness/MS +defector/MS +defendant/SM +defended/U +defenestrate/GSD +defense/VGSDM +defenseless/PY +defenselessness/MS +defenses/U +defensibility/M +defensible/I +defensibly/I +defensive/PSY +defensiveness/MS +deference/MS +deferent/S +deferential/Y +deferrable +deferral/SM +deferred +deferrer/MS +deferring +deffer +defiance/MS +defiant/Y +defibrillator/M +deficiency/MS +deficient/SY +deficit/MS +defier/M +defile/L +defilement/MS +definable/UI +definably/I +define/AGDRS +defined/U +definer/SM +definite/IPY +definiteness/IMS +definition/ASM +definitional +definitive/SYP +definitiveness/M +defis +deflate/XNGRSDB +deflation/M +deflationary +deflect/DSGV +deflected/U +deflection/MS +deflector/MS +defocus +defocussing +defog +defogger/S +defoliant/SM +defoliator/SM +deform/B +deformational +deformed/U +deformity/SM +defraud/ZGDR +defrauder/M +defrayal/SM +defrost/RZ +defroster/M +deft/TYRP +deftness/MS +defunct/S +defy/RDG +defying/Y +deg +degassing +degauss/GD +degeneracy/MS +degenerate/PY +degenerateness/M +degrade/B +degraded/YP +degradedness/M +degrading/Y +degrease +degree/SM +degum +dehumanize +dehydrator/MS +deice/ZR +deicer/M +deictic +deification/M +deify/SDXGN +deign/DGS +deist/SM +deistic +deity/SM +deja +deject/DSG +dejected/PY +dejectedness/M +dejection/SM +delay/D +delayer/G +delectable/SP +delectableness/M +delectably +delectation/MS +delegable +delete/XBRSDNG +deleted/U +deleterious/PY +deleteriousness/M +deletion/M +delfs +delft/MS +delftware/S +deli/SM +deliberate/PVY +deliberateness/SM +deliberative/PY +deliberativeness/M +delicacy/IMS +delicate/IYP +delicateness/IM +delicatenesses +delicates +delicatessen/MS +delicious/YSP +deliciousness/MS +delicti +delighted/YP +delightedness/M +delightful/YP +delightfulness/M +delineate/SDXVNG +delineation/M +delinquency/MS +delinquent/SYM +deliquesce/GSD +deliquescent +delirious/PY +deliriousness/MS +delirium/SM +deliver/AGSD +deliverable/U +deliverables +deliverance/SM +delivered/U +deliverer/SM +delivery/AM +deliverymen/M +dell/SM +delphinium/SM +delta/MS +deltoid/SM +delude/RSDG +deluder/M +deluding/Y +deluge/SDG +delusion/SM +delusional +delusive/PY +delusiveness/M +deluxe +delve/GZSRD +delver/M +demagnify/N +demagogic +demagogue/GSDM +demagoguery/SM +demagogy/MS +demand/GSRD +demander/M +demanding/U +demandingly +demarcate/SDNGX +demarcation/M +demean/GDS +demeanor/SM +demented/YP +dementedness/M +dementia/MS +demesne/SM +demigod/MS +demijohn/MS +demimondaine/SM +demimonde/SM +demineralization/SM +demise/DMG +demit +demitasse/MS +demitted +demitting +demo/DMPG +democracy/MS +democrat/SM +democratic/U +democratically/U +democratization/MS +democratize/DRSG +democratizes/U +demographer/MS +demographic/S +demographical/Y +demography/MS +demolish/GSRD +demolisher/M +demolition/MS +demon/SM +demonetization/S +demoniac/S +demoniacal/Y +demonic +demonology/M +demonstrable/I +demonstrableness/M +demonstrably/I +demonstrate/XDSNGV +demonstration/M +demonstrative/YUP +demonstrativeness/UM +demonstrativenesses +demonstratives +demonstrator/MS +demoralization/M +demoralizer/M +demoralizing/Y +demote/DGX +demotic/S +demount/B +demulcent/S +demultiplex +demur/RTS +demure/YP +demureness/SM +demurral/MS +demurred +demurrer/MS +demurring +demythologization/M +demythologize/R +den +dendrite/MS +dengue/MS +deniable/U +denial/SM +denier/M +denigrate/VNGXSD +denigration/M +denim/SM +denizen/SMDG +denned +denning +denominate/V +denominational/Y +denote/B +denouement/MS +denounce/LZRSDG +denouncement/SM +denouncer/M +dens/RT +dense/FR +densely +denseness/SM +densitometer/MS +densitometric +densitometry/M +density/MS +dent's +dent/ISGD +dental/YS +dentifrice/SM +dentin/SM +dentine's +dentist/SM +dentistry/MS +dentition/MS +denture/IMS +denuclearize/GSD +denudation/SM +denude/DG +denuder/M +denunciate/VNGSDX +denunciation/M +deny/SRDZG +denying/Y +deodorant/SM +deodorization/SM +deodorize/GZSRD +deodorizer/M +deoxyribonucleic +depart/L +department/MS +departmental/Y +departmentalization/SM +departmentalize/DSG +departure/MS +depend/B +dependability/MS +dependable/P +dependableness/M +dependably +dependence/ISM +dependency/MS +dependent's +dependent/IYS +depict/RDSG +depicted/U +depicter/M +depiction/SM +depilatory/S +deplete/VGNSDX +depletion/M +deplorable/P +deplorableness/M +deplorably +deplore/SRDBG +deplorer/M +deploring/Y +deploy/AGDLS +deployable +deployment/SAM +depolarize +deponent/S +deport/LG +deportation/MS +deportee/SM +deportment/MS +depose +deposit/ADGS +depositary/M +deposition/A +depositor/SAM +depository/MS +deprave/GSRD +depraved/PY +depravedness/M +depraver/M +depravity/SM +deprecate/XSDNG +deprecating/Y +deprecation/M +deprecatory +depreciable +depreciate/XDSNGV +depreciating/Y +depreciation/M +depreciative/Y +depress/V +depressant/S +depressible +depression/MS +depressive/YS +depressor/MS +deprive/GSD +depth/M +depths +deputation/SM +depute/SDG +deputize/DSG +deputy/MS +dequeue +derail/L +derailment/MS +derange/L +derangement/MS +derby/SM +dereference/Z +derelict/S +dereliction/SM +deride/D +deriding/Y +derision/SM +derisive/PY +derisiveness/MS +derisory +derivable/U +derivate/XNV +derivation/M +derivative/SPYM +derivativeness/M +derive/B +derived/U +dermal +dermatitides +dermatitis/MS +dermatological +dermatologist/MS +dermatology/MS +dermis/SM +derogate/XDSNGV +derogation/M +derogatorily +derogatory +derrick/SMDG +derringer/SM +derri�re/S +dervish/SM +desalinate/NGSDX +desalination/M +desalinization/MS +desalinize/GSD +desalt/G +descant/M +descend/ZGSDR +descendant/SM +descended/FU +descendent's +descender/M +descending/F +descends/F +descent +describable/I +describe/ZB +description/MS +descriptive/SYP +descriptiveness/MS +descriptor/SM +descry/SDG +desecrate/SRDGNX +desecrater/M +desecration/M +desert/ZGMRDS +deserter/M +desertification +desertion/MS +deserve/J +deserved/YU +deservedness/M +deserving/Y +desiccant/S +desiccate/XNGSD +desiccation/M +desiccator/SM +desiderata +desideratum/M +design/ADGS +designable +designate/VNGSDX +designation/M +designational +designator/SM +designed/Y +designer/M +designing/U +desirabilia +desirability's +desirability/US +desirable/UPS +desirableness's/U +desirableness/SM +desirably/U +desire/BR +desired/U +desirer/M +desirous/PY +desirousness/M +desist/DSG +desk/SM +desktop/S +desolate/PXDRSYNG +desolateness/SM +desolater/M +desolating/Y +desolation/M +desorption/M +despair/SGDR +despairer/M +despairing/Y +desperado/M +desperadoes +desperate/YNXP +desperateness/SM +desperation/M +despicable +despicably +despise/SRDG +despiser/M +despoil/L +despoilment/MS +despond +despondence/S +despondency/MS +despondent/Y +despotic +despotically +despotism/SM +dessert/SM +dessicate/DN +destinate/NX +destination/M +destine/GSD +destiny/MS +destitute/NXP +destituteness/M +destitution/M +destroy/BZGDRS +destroyer/M +destruct/VGSD +destructibility/SMI +destructible/I +destruction/SM +destructive/YP +destructiveness/MS +destructor/M +desuetude/MS +desultorily +desultoriness/M +desultory/P +detach/LSRDBG +detached/YP +detachedness/M +detacher/M +detachment/SM +detailed/YP +detailedness/M +detain/LGRDS +detainee/S +detainer/M +detainment/MS +detect/DBSVG +detectability/U +detectable/U +detectably/U +detected/U +detection/SM +detective/MS +detector/MS +detentes +detention/SM +deter/SL +detergency/M +detergent/SM +deteriorate/XDSNGV +deterioration/M +determent/SM +determinability/M +determinable/IP +determinableness/IM +determinacy/I +determinant/MS +determinate/PYIN +determinateness/IM +determination/IM +determinative/P +determinativeness/M +determine/GASD +determined/U +determinedly +determinedness/M +determiner/SM +determinism's/I +determinism/MS +deterministic/I +deterministically +deterred/U +deterrence/SM +deterrent/SMY +deterring +deters/V +detersive/S +detestable/P +detestableness/M +detestably +detestation/SM +dethrone/L +dethronement/SM +detonable +detonate/XDSNGV +detonated/U +detonation/M +detonator/MS +detour/G +detox/SDG +detoxification/M +detoxify/NXGSD +detract/GVD +detractive/Y +detribalize/GSD +detriment/SM +detrimental/SY +detritus/M +deuce/SDGM +deuced/Y +deus +deuterium/MS +deuteron/M +devastate/XVNGSD +devastating/Y +devastation/M +devastator/SM +develop/ALZSGDR +developed/U +developer/MA +development/ASM +developmental/Y +deviance/MS +deviancy/S +deviant/YMS +deviate/XSDGN +deviated/U +deviating/U +deviation/M +devil/SLMDG +devilish/PY +devilishness/MS +devilment/SM +devilry/MS +deviltry/MS +devious/YP +deviousness/SM +devise/JR +deviser/M +devoice +devolution/MS +devolve/GSD +devote/XN +devoted/Y +devotee/MS +devotion/M +devotional/YS +devour/SRDZG +devourer/M +devout/PRYT +devoutness/MS +dew/MDGS +dewar +dewberry/MS +dewclaw/SM +dewdrop/MS +dewiness/MS +dewlap/MS +dewy/TPR +dexes/I +dexter +dexterity/MS +dexterous/PY +dexterousness/MS +dextrose/SM +dhoti/SM +dhow/MS +diabase/M +diabetes/M +diabetic/S +diabolic +diabolical/YP +diabolicalness/M +diabolism/M +diachronic/P +diacritic/MS +diacritical/YS +diadem/GMDS +diaereses +diaeresis/M +diagnometer/SM +diagnosable/U +diagnose/BGDS +diagnosed/U +diagnosis/M +diagnostic/MS +diagnostically +diagnostician/SM +diagnostics/M +diagonal/YS +diagonalize/GDSB +diagram/MS +diagrammable +diagrammatic +diagrammaticality +diagrammatically +diagrammed +diagrammer/SM +diagramming +dial/MRDSGZJ +dialect/MS +dialectal/Y +dialectic/MS +dialectical/Y +dialed/A +dialer/M +dialing/M +dialog/MS +dialogged +dialogging +dialogue/DS +dials/A +dialysis/M +dialyzed/U +dialyzes +diam +diamagnetic +diameter/MS +diametric +diametrical/Y +diamond/GSMD +diamondback/SM +diapason/MS +diaper/SGDM +diaphanous/YP +diaphanousness/M +diaphragm/SM +diaphragmatic +diarist/SM +diarrhea/MS +diarrheal +diary/MS +diaspora +diastase/SM +diastole/MS +diastolic +diathermy/SM +diathesis/M +diatom/SM +diatomic +diatonic +diatribe/MS +dibble/SDMG +dibs +dice/GDRS +dicer/M +dicey +dichloride/M +dichotomization/M +dichotomize/DSG +dichotomous/PY +dichotomy/SM +dicier +diciest +dicing/M +dick/GZXRDMS! +dickens/M +dicker/DG +dickey/SM +dickier +dickiest +dicky's +dicotyledon/SM +dicotyledonous +dicta/M +dictate/SDNGX +dictation/M +dictator/MS +dictatorial/YP +dictatorialness/M +dictatorship/SM +diction/MS +dictionary/SM +dictum/M +did/AU +didactic/S +didactically +didactics/M +diddle/ZGRSD +diddler/M +didn't +dido/M +didoes +didst +die/DS +dieing +dielectric/MS +diem +diereses +dieresis/M +dies's +dies/U +diesel/GMDS +diet/RDGZSM +dietary/S +dieter/M +dietetic/S +dietetics/M +diethylaminoethyl +diethylstilbestrol/M +dietitian/MS +differ/SZGRD +difference's/I +difference/DSGM +differences/I +different/YI +differentiability +differentiable +differential/SMY +differentiate/XSDNG +differentiated/U +differentiation/M +differentiator/SM +differentness +difficile +difficult/Y +difficulty/SM +diffidence/MS +diffident/Y +diffract/GSD +diffraction/SM +diffractometer/SM +diffuse/PRSDZYVXNG +diffuseness/MS +diffuser/M +diffusible +diffusion/M +diffusional +diffusive/YP +diffusiveness/M +diffusivity/M +dig/TS +digerati +digest/RDVGS +digested/IU +digester/M +digestibility/MS +digestible/I +digestifs +digestion/ISM +digestive/YSP +digger/MS +digging/S +digit/SM +digital/SY +digitalis/M +digitalization/MS +digitalized +digitalizes +digitalizing +digitization/M +digitize/ZGDRS +digitizer/M +dignified/U +dignify/DSG +dignitary/SM +dignity/ISM +digram +digraph/M +digraphs +digress/GVDS +digression/SM +digressive/PY +digressiveness/M +dihedral +dike/DRSMG +diker/M +diktat/SM +dilapidate/XGNSD +dilapidation/M +dilatation/SM +dilate/XVNGSD +dilated/YP +dilation/M +dilator/SM +dilatoriness/M +dilatory/P +dilemma/MS +dilettante/MS +dilettantish +dilettantism/MS +diligence/SM +diligent/YP +diligentness/M +dilithium +dill/SGMD +dilling/R +dillis +dilly/SM +dillydally/GSD +dilogarithm +diluent +dilute/RSDPXYVNG +diluted/U +diluteness/M +dilution/M +dim/RYPZS +dime/SM +dimension/MDGS +dimensional/Y +dimensionality/M +dimensionless +dimer/M +dimethyl/M +dimethylglyoxime +diminish/SDGBJ +diminished/U +diminuendo/SM +diminution/SM +diminutive/SYP +diminutiveness/M +dimity/MS +dimmed/U +dimmer/MS +dimmest +dimming +dimness/SM +dimorphism/M +dimple/MGSD +dimply/RT +dimwit/MS +dimwitted +din/MDRZGS +dinar/SM +dine/S +diner/M +dinette/MS +ding/GD +dingbat/MS +dinghy/SM +dingily +dinginess/SM +dingle/MS +dingo/MS +dingoes +dingus/SM +dingy/PRST +dinky/RST +dinned +dinner/SM +dinnertime/S +dinnerware/MS +dinning +dinosaur/MS +dint/SGMD +diocesan/S +diocese/SM +diode/SM +diopter/MS +diorama/SM +dioxalate +dioxide/MS +dioxin/S +dip/S +diphtheria/SM +diphthong/SM +diplexers +diploid/S +diploma/SMDG +diplomacy/SM +diplomat/MS +diplomata +diplomatic/S +diplomatically +diplomatics/M +diplomatist/SM +dipodic +dipody/M +dipole/MS +dipped +dipper/SM +dipping/S +dippy/TR +dipsomania/SM +dipsomaniac/MS +dipstick/MS +dipterous +diptych/M +diptychs +dire/YTRP +direct/RDYPTSVG +directed/IUA +direction/MIS +directional/SY +directionality +directions/A +directive/SM +directivity/M +directly/I +directness/ISM +director/AMS +directorate/SM +directorial +directorship/SM +directory/SM +directrix/MS +directs/IA +direful/Y +direness/M +dirge/GSDM +dirigible/S +dirk/GDMS +dirndl/MS +dirt/MS +dirtily +dirtiness/SM +dirty/GPRSDT +dis/MB +disable/LZGD +disablement/MS +disabler/M +disabuse +disadvantaged/P +disagreeable/S +disallow/D +disambiguate/DSGNX +disappointed/Y +disappointing/Y +disarming/Y +disarrange/L +disastrous/Y +disband/L +disbandment/SM +disbar/L +disbarment/MS +disbarring +disbelieving/Y +disbursal/S +disburse/GDRSL +disbursement/MS +disburser/M +disc/GDM +discern/SDRGL +discerner/M +discernibility +discernible/I +discernibly +discerning/Y +discernment/MS +discharged/U +disciple/DSMG +discipleship/SM +disciplinarian/SM +disciplinary +discipline/IDM +disciplined/U +discipliner/M +disciplines +disciplining +disclosed/U +disco/MG +discography/MS +discolor/G +discolored/MP +discoloreds/U +discombobulate/SDGNX +discomfit/DG +discomfiture/MS +discommode/DG +disconcerting/Y +disconnect/R +disconnected/P +disconnectedness/S +disconnecter/M +disconsolate/YN +discord/G +discordance/SM +discordant/Y +discorporate/D +discotheque/MS +discount/B +discourage/LGDR +discouragement/MS +discouraging/Y +discover/ADGS +discoverable/I +discovered/U +discoverer/S +discovery/SAM +discreet/TRYP +discreetly/I +discreetness's/I +discreetness/SM +discrepancy/SM +discrepant/Y +discrete/YPNX +discreteness/SM +discretion/IMS +discretionary +discretization +discretized +discriminable +discriminant/MS +discriminate/SDVNGX +discriminated/U +discriminating/YI +discrimination/MI +discriminator/MS +discriminatory +discursiveness/S +discus/SM +discussant/MS +discussed/UA +discusser/M +discussion/SM +disdain/MGSD +disdainful/YP +disdainfulness/M +disease/G +disembowel/SLGD +disembowelment/SM +disengage/L +disfigure/L +disfigurement/MS +disfranchise/L +disfranchisement/MS +disgorge +disgrace/R +disgracer/M +disgruntle/DSLG +disgruntlement/MS +disguise/R +disguised/UY +disguiser/M +disgust +disgusted/Y +disgustful/Y +disgusting/Y +dish/GD +dishabille/SM +disharmonious +dishcloth/M +dishcloths +dishevel/LDGS +dishevelment/MS +dishonest +dishonored/U +dishpan/MS +dishrag/SM +dishtowel/SM +dishwasher/MS +dishwater/SM +disillusion/LGD +disillusionment/SM +disinfectant/MS +disinherit +disinterested/P +disinterestedness/SM +disinvest/L +disjoin +disjointedness/S +disjunct/VS +disjunctive/YS +disk/D +diskette/S +dislike/G +dislodge/LG +dislodgement/M +dismal/PSTRY +dismalness/M +dismantle/L +dismantlement/SM +dismay/D +dismayed/U +dismaying/Y +dismember/LG +dismemberment/MS +dismiss/RZ +dismissive/Y +disoblige/G +disorder/Y +disordered/YP +disorderedness/M +disorderliness/M +disorderly/P +disorganize +disorganized/U +disparage/RSDLG +disparagement/MS +disparager/M +disparaging/Y +disparate/PSY +disparateness/M +dispatch/Z +dispel/S +dispelled +dispelling +dispensable/I +dispensary/MS +dispensate/NX +dispensation/M +dispense/ZGDRSB +dispenser/M +dispersal/MS +dispersant/M +disperse/XDRSZLNGV +dispersed/Y +disperser/M +dispersible +dispersion/M +dispersive/PY +dispersiveness/M +dispirit/DSG +displace/L +display/AGDS +displayed/U +displease/G +displeased/Y +displeasure +disport +disposable/S +disposal/SM +dispose/IGSD +disposition/ISM +dispositional +disproportional +disproportionate/N +disproportionation/M +disprove/B +disputable/I +disputably/I +disputant/SM +disputation/SM +disputatious/Y +dispute/ZBGSRD +disputed/U +disputer/M +disquiet/M +disquieting/Y +disquisition/SM +disregardful +disrepair/M +disreputable/P +disreputableness/M +disrepute/M +disrespect +disrupt/GVDRS +disrupted/U +disrupter/M +disruption/MS +disruptive/YP +disruptor/M +dissatisfy +dissect/DG +dissed +dissemble/ZGRSD +dissembler/M +disseminate/XGNSD +dissemination/M +dissension/SM +dissent/ZGSDR +dissenter/M +dissertation/SM +disservice +disses +dissever +dissidence/SM +dissident/MS +dissimilar/S +dissing +dissipate/XRSDVNG +dissipated/U +dissipatedly +dissipatedness/M +dissipater/M +dissipation/M +dissociable/I +dissociate/DSXNGV +dissociated/U +dissociation/M +dissociative/Y +dissoluble/I +dissolute/PY +dissoluteness/SM +dissolve/ASDG +dissolved/U +dissonance/SM +dissonant/Y +dissuade/GDRS +dissuader/M +dissuasive +dist +distaff/SM +distal/Y +distance/DSMG +distant/YP +distantness/M +distaste +distemper +distend +distension +distention/SM +distillate/XNMS +distillation/M +distillery/MS +distinct/IYVP +distincter +distinctest +distinction/MS +distinctive/YP +distinctiveness/MS +distinctness/MSI +distinguish/BDRSG +distinguishable/I +distinguishably/I +distinguished/U +distinguisher/M +distort/BGDR +distorted/U +distorter/M +distortion/MS +distract/DG +distracted/YP +distractedness/M +distracting/Y +distrait +distraught/Y +distress +distressful +distressing/Y +distribute/ADXSVNGB +distributed/U +distributer +distribution/AM +distributional +distributive/SPY +distributiveness/M +distributivity +distributor/SM +distributorship/M +district's +district/GSAD +distrust/G +disturb/ZGDRS +disturbance/SM +disturbed/U +disturber/M +disturbing/Y +disulfide/M +disuse/M +disyllable/M +ditch/MRSDG +ditcher/M +dither/RDZSG +ditsy/TR +ditto/DMGS +ditty/SDGM +ditz/S +diuresis/M +diuretic/S +diurnal/SY +div/TZGJDRS +diva/MS +divalent/S +divan/SM +dive/S +dived/M +diver/M +diverge/SDG +divergence/SM +divergent/Y +diverse/XYNP +diverseness/MS +diversification/M +diversifier/M +diversify/GSRDNX +diversion/M +diversionary +diversity/SM +divert/GSD +diverticulitis/SM +divertimento/M +divest/LDGS +divestiture/MS +divestment/S +dividable +divide/AGDS +divided/U +dividend/MS +divider/MS +divination/SM +divine/RSDTZYG +diviner/M +divinity/MS +divisibility/IMS +divisible/I +division/SM +divisional +divisive/PY +divisiveness/MS +divisor/SM +divorce/GSDLM +divorcement/MS +divorc�e/MS +divot/MS +divulge/GSD +divvy/GSDM +dixieland +dizzily +dizziness/SM +dizzy/PGRSDT +dizzying/Y +djellaba/S +djellabah's +do/TZRHGJ +doable +dobbin/MS +doc/MS +docent/SM +docile/Y +docility/MS +dock/GZSRDM +docker/M +docket/GSMD +dockland/MS +dockside/M +dockworker/S +dockyard/SM +doctor/GSDM +doctoral +doctorate/SM +doctrinaire/S +doctrinal/Y +doctrine/SM +docudrama/S +document/RDMZGS +documentary/MS +documentation/MS +documented/U +dodder/DGS +dodecahedra +dodecahedral +dodecahedron/M +dodge/GZSRD +dodgem/S +dodger/M +dodo/SM +doe/MS +doer/MU +does/AU +doeskin/MS +doesn't +doff/SGD +dog/SM +dogcart/SM +dogcatcher/MS +doge/SM +dogeared +dogfight/GMS +dogfish/SM +dogfought +dogged/PY +doggedness/SM +doggerel/SM +dogging +doggone/RSDTG +doggy/SRMT +doghouse/SM +dogie/SM +dogleg/SM +doglegged +doglegging +dogma/MS +dogmatic/S +dogmatically/U +dogmatics/M +dogmatism/SM +dogmatist/SM +dogsbody/M +dogtooth/M +dogtrot/MS +dogtrotted +dogtrotting +dogwood/SM +dogy's +doh's +doily/SM +doing/MU +doldrum/S +doldrums/M +dole/MGDS +doled/F +doleful/PY +dolefuller +dolefullest +dolefulness/MS +doles/F +doling/F +doll/MDGS +dollar/SM +dollop/GSMD +dolly/SDMG +dolmen/MS +dolomite/SM +dolomitic +dolor/SM +dolorous/Y +dolphin/SM +dolt/MS +doltish/YP +doltishness/SM +domain/MS +dome/DSMG +domestic/S +domestically +domesticate/DSXGN +domesticated/U +domestication/M +domesticity/MS +domicile/SDMG +domiciliary +dominance/MS +dominant/YS +dominate/VNGXSD +domination/M +dominator/M +dominatrices +dominatrix +domineer/DSG +domineering/YP +domineeringness/M +dominion/MS +domino/M +dominoes +don't +don/S +dona/MS +donate/XVGNSD +donation/M +donative/M +done/AUF +dong/GDMS +dongle/S +donkey/MS +donned +donning +donnish/YP +donnishness/M +donnybrook/MS +donor/MS +donut/MS +donutted +donutting +doodad/MS +doodle/SRDZG +doodlebug/MS +doodler/M +doohickey/MS +doom/MDGS +doomsday/SM +door/GDMS +doorbell/SM +doorhandles +doorkeep/RZ +doorkeeper/M +doorknob/SM +doorman/M +doormat/SM +doormen +doornail/M +doorplate/SM +doors/I +doorstep/MS +doorstepped +doorstepping +doorstop/MS +doorway/MS +dooryard/SM +dopa/SM +dopamine +dopant/M +dope/DRSMZG +doper/M +dopey +dopier +dopiest +dopiness/S +dork/S +dorky/RT +dorm/MRZS +dormancy/MS +dormant/S +dormer/M +dormice +dormitory/SM +dormouse/M +dorsal/YS +dory/SM +dos/GDS +dosage/SM +dose/M +dosimeter/MS +dosimetry/M +dossier/MS +dost +dot/MDRSJZG +dotage/SM +dotard/MS +dote/S +doter/M +doting/Y +dotted +dottiness/M +dotting +dotty/PRT +double/GPSRDZ +doubled/UA +doubleheader/MS +doubleness/M +doubler/M +doubles/M +doublespeak/S +doublet/MS +doublethink/M +doubleton/M +doubling/A +doubloon/MS +doubly +doubt/AGSDMB +doubted/U +doubter/SM +doubtful/YP +doubtfulness/SM +doubting/Y +doubtless/YP +doubtlessness/M +douche/GSDM +dough/M +doughs +doughty/RT +doughy/RT +dour/TYRP +dourness/MS +douse/SRDG +douser/M +dove/RSM +dovecote/MS +dovetail/GSDM +dovish +dowager/SM +dowdily +dowdiness/MS +dowdy/TPSR +dowel/GMDS +dower/GDMS +down/GZSRD +downbeat/SM +downcast/S +downdraft/M +downer/M +downfall/NMS +downgrade/GSD +downhearted/PY +downheartedness/MS +downhill/RS +downland +download/DGS +downpipes +downplay/GDS +downpour/MS +downrange +downright/YP +downrightness/M +downriver +downscale/GSD +downside/S +downsize/DSG +downslope +downspout/SM +downstage/S +downstairs +downstate/SR +downstream +downswing/MS +downtime/SM +downtown/MRS +downtowner/M +downtrend/M +downtrodden +downturn/MS +downward/YPS +downwardness/M +downwind +downy/RT +dowry/SM +dowse/GZSRD +dowser/M +doxology/MS +doyen/SM +doyenne/SM +doz/XGNDRS +doze +dozen/GHD +dozenths +dozer/M +dozy +dpt +drab/YSP +drabbed +drabber +drabbest +drabbing +drabness/MS +drachma/MS +draconian +draft/AMDGS +draftee/SM +drafter/MS +draftily +draftiness/SM +drafting/S +draftsman/M +draftsmanship/SM +draftsmen +draftsperson +draftswoman +draftswomen +drafty/PTR +drag/MS +dragged +dragger/M +dragging/Y +draggy/RT +dragnet/MS +dragon/SM +dragonfly/SM +dragonhead/M +dragoon/DMGS +drain/SZGRDM +drainage/MS +drainboard/SM +drained/U +drainer/M +drainpipe/MS +drake/SM +dram/MS +drama/SM +dramatic/S +dramatical/Y +dramatically/U +dramatics/M +dramatist/MS +dramatization/MS +dramatize/SRDZG +dramatized/U +dramatizer/M +dramaturgy/M +drammed +dramming +drank +drape/SRDGZ +draper/M +drapery/MS +drastic +drastically +drat/S +dratted +dratting +draw/ASG +drawable +drawback/MS +drawbridge/SM +drawer/SM +drawing/SM +drawl/RDSG +drawler/M +drawling/Y +drawly +drawn/AI +drawnly +drawnness +drawstring/MS +dray/SMDG +dread/SRDG +dreadful/YPS +dreadfulness/SM +dreadlocks +dreadnought/SM +dream/SMRDZG +dreamboat/SM +dreamed/U +dreamer/M +dreamily +dreaminess/SM +dreaming/Y +dreamland/SM +dreamless/PY +dreamlessness/M +dreamlike +dreamworld/S +dreamy/PTR +drear/S +drearily +dreariness/SM +dreary/TRSP +dredge/MZGSRD +dredger/M +dreg/MS +drench/GDRS +drencher/M +dress/ADRSG +dressage/MS +dressed/U +dresser's/A +dresser/MS +dresses/U +dressiness/SM +dressing/MS +dressmaker/MS +dressmaking/SM +dressy/PTR +drew/A +drib/SM +dribble/DRSGZ +dribbler/M +driblet/SM +dried/U +drier/M +drift/RDZSG +drifter/M +drifting/Y +driftwood/SM +drill/MRDZGS +driller/M +drilling/M +drillmaster/SM +drink/BRSZG +drinkable/S +drinker/M +drip/SM +dripped +dripping/MS +drippy/RT +drive/SRBGZJ +drivel/GZDRS +driveler/M +driven/P +driver/M +driveway/MS +drizzle/DSGM +drizzling/Y +drizzly/TR +drogue/MS +droll/RDSPTG +drollery/SM +drollness/MS +drolly +dromedary/MS +drone/SRDGM +droning/Y +drool/GSRD +droop/SGD +droopiness/MS +drooping/Y +droopy/PRT +drop/SM +drophead +dropkick/S +droplet/SM +dropout/MS +dropped +dropper/SM +dropping/MS +dropsical +dropsy/MS +drosophila/M +dross/SM +drought/SM +drove/SRDGZ +drover/M +drown/RDSJG +drowner/M +drowse/SDG +drowsily +drowsiness/SM +drowsy/PTR +drub/S +drubbed +drubber/MS +drubbing/SM +drudge/MGSRD +drudger/M +drudgery/SM +drudging/Y +drug/SM +drugged +druggie/SRT +drugging +druggist/SM +drugless +drugstore/SM +druid/MS +druidism/MS +drum/SM +drumbeat/SGM +drumhead/M +drumlin/MS +drummed +drummer/SM +drumming +drumstick/SM +drunk/SRNYMT +drunkard/SM +drunken/YP +drunkenness/SM +drupe/SM +druthers +dry/GYDRSTZ +dryad/MS +dryer/MS +dryish +dryness/SM +drys +drystone +drywall/GSD +dual/YS +dualism/MS +dualist/M +dualistic +duality/MS +dub/S +dubbed +dubber/S +dubbin/MS +dubbing/M +dubiety/MS +dubious/YP +dubiousness/SM +ducal +ducat/SM +duce's +duce/CAIKF +duchess/MS +duchy/SM +duck/GSRDM +duckbill/SM +ducker/M +duckling/SM +duckpins +duckpond +duckweed/MS +ducky/RSMT +duct's/A +duct/KMSF +ducted/CFI +ductile/I +ductility/SM +ducting/F +ductless +ducts/CI +ductwork/M +dud/GMDS +dudder +dude/MS +dudgeon/SM +due/PMS +duel/MRDGZSJ +duelist/MS +dueness/M +duenna/MS +duet/MS +duetted +duetting +duff/GZSRDM +duffel/M +duffer/M +dug/S +dugout/SM +duh +duke/DSMG +dukedom/SM +dulcet/SY +dulcify +dulcimer/MS +dull/SRDPGT +dullard/MS +dullness/MS +dully +dulness's +duly/U +dumb/PSGTYRD +dumbbell/MS +dumbfound/GSDR +dumbness/MS +dumbstruck +dumbwaiter/SM +dumdum/MS +dummy/SDMG +dump/SGZRD +dumper/UM +dumpiness/MS +dumpling/MS +dumpster/S +dumpy/PRST +dun/S +dunce/MS +dunderhead/MS +dune/SM +dung/SGDM +dungaree/SM +dungeon/GSMD +dunghill/MS +dunk/GSRD +dunker/M +dunned +dunner +dunnest +dunning +dunno/M +duo/MS +duodecimal/S +duodena +duodenal +duodenum/M +duologue/M +duopolist +duopoly/M +dupe/NGDRSMZ +duper/M +dupion/M +duple +duplex/MSRDG +duplexer/M +duplicability/M +duplicable +duplicate/ADSGNX +duplication/AM +duplicative +duplicator/MS +duplicitous +duplicity/SM +durability/MS +durable/PS +durableness/M +durably +durance/SM +duration/MS +durational +duress/SM +during +durst +durum/MS +dusk/GDMS +duskiness/MS +dusky/RPT +dust/MRDGZS +dustbin/MS +dustcart/M +dustcover +duster/M +dustily +dustiness/MS +dusting/M +dustless +dustman/M +dustmen +dustpan/SM +dusty/RPT +dutch/MS +duteous/Y +dutiable +dutiful/UPY +dutifulness/S +duty/SM +duvet/SM +duxes +dwarf/MTGSPRD +dwarfish +dwarfism/MS +dweeb/S +dwell/IGS +dweller/SM +dwelling/MS +dwelt/I +dwindle/GSD +dyad/MS +dyadic +dybbuk/SM +dybbukim +dye/JDRSMZG +dyed/A +dyeing/M +dyer/M +dyes/A +dyestuff/SM +dying/UA +dyke's +dynamic/S +dynamical/Y +dynamics/M +dynamism/SM +dynamite/RSDZMG +dynamiter/M +dynamized +dynamo/MS +dynastic +dynasty/MS +dyne/M +dysentery/SM +dysfunction/MS +dysfunctional +dyslectic/S +dyslexia/MS +dyslexic/S +dyslexically +dyspepsia/MS +dyspeptic/S +dysprosium/MS +dystopia/M +dystrophy/M +dz +d�butante/SM +d�colletage/S +d�collet� +d�mod� +d�railleur/MS +d�shabill�'s +d�tente +e'en +e'er +e's +e/FMDS +ea +each +eager/TSPRYM +eagerness/MS +eagle/SDGM +eaglet/SM +ear/GSMDYH +earache/SM +eardrum/SM +earful/MS +earing/M +earl/MS +earldom/MS +earliness/SM +earlobe/S +early/PRST +earmark/DGSJ +earmuff/SM +earn/GRDZTSJ +earned/U +earner/M +earnest/PYS +earnestness/MS +earning/M +earphone/MS +earpieces +earplug/MS +earring/MS +earshot/MS +earsplitting +earth/MDNYG +earthbound +earthed/U +earthenware/MS +earthiness/SM +earthliness/M +earthling/MS +earthly/TPR +earthmen +earthmover/M +earthmoving +earthquake/SDGM +earths/U +earthshaking +earthward/S +earthwork/MS +earthworm/MS +earthy/PTR +earwax/MS +earwig/MS +earwigged +earwigging +ease's/EU +ease/LDRSMG +eased/E +easel/MS +easement/MS +easer/M +eases/UE +easies +easily/U +easiness/MSU +easing/M +east/GSMR +eastbound +easter/Y +easterly/S +eastern/ZR +easterner/M +easternmost +easting/M +eastward/S +easy/PUTR +easygoing/P +easygoingness/M +eat/SJZGNRB +eatable/U +eatables +eaten/U +eater/M +eatery/MS +eating/M +eave/SM +eavesdrop/S +eavesdropped +eavesdropper/MS +eavesdropping +ebb/DSG +ebony/SM +ebullience/SM +ebullient/Y +ebullition/SM +eccentric/MS +eccentrically +eccentricity/SM +eccl +ecclesiastic/MS +ecclesiastical/Y +echelon/SGDM +echinoderm/SM +echo/DMG +echoed/A +echoes/A +echoic +echolocation/SM +eclectic/S +eclectically +eclecticism/MS +eclipse/MGSD +ecliptic/MS +eclogue/MS +ecocide/SM +ecol +ecologic +ecological/Y +ecologist/MS +ecology/MS +econ +econometric/S +econometricians +econometrics/M +economic/S +economical/YU +economics/M +economist/MS +economization +economize/GZSRD +economizer/M +economizing/U +economy/MS +ecosystem/MS +ecru/SM +ecstasy/MS +ecstatic/S +ecstatically +ectoplasm/M +ecumenic/MS +ecumenical/Y +ecumenicism/SM +ecumenicist/MS +ecumenics/M +ecumenism/SM +ecumenist/MS +eczema/MS +ed/ASC +eddy/SDMG +edelweiss/MS +edema/SM +edematous +eden +edge/DRSMZGJ +edgeless +edger/M +edgewise +edgily +edginess/MS +edging/M +edgy/TRP +edibility/MS +edible/SP +edibleness/SM +edict/SM +edification/M +edifice/SM +edifier/M +edify/ZNXGRSD +edifying/U +edit/SADG +editable +edited/IU +edition/SM +editor/MS +editorial/YS +editorialist/M +editorialize/DRSG +editorializer/M +editorship/MS +eds +educ/DBG +educability/SM +educable/S +educate/XASDGN +educated/YP +education/AM +educational/Y +educationalists +educationists +educative +educator/MS +educe/S +eduction/M +edutainment/S +eek/S +eel/MS +eelgrass/M +eerie/RT +eerily +eeriness/MS +efface/SRDLG +effaceable/I +effacement/MS +effacer/M +effect/SMDGV +effective/YIP +effectiveness/ISM +effectives +effector/MS +effectual/IYP +effectualness/MI +effectuate/SDGN +effectuation/M +effeminacy/MS +effeminate/SY +effendi/MS +efferent/SY +effervesce/GSD +effervescence/SM +effervescent/Y +effete/YP +effeteness/SM +efficacious/IPY +efficaciousness/MI +efficacy/IMS +efficiency/MIS +efficient/ISY +effigy/SM +effloresce +efflorescence/SM +efflorescent +effluence/SM +effluent/MS +effluvia +effluvium/M +efflux/M +effluxion +effort/MS +effortless/PY +effortlessness/SM +effrontery/MS +effulgence/SM +effulgent +effuse/XSDVGN +effusion/M +effusive/YP +effusiveness/MS +egad +egalitarian/I +egalitarianism/MS +egalitarians +egg/GMDRS +eggbeater/SM +eggcup/MS +egger/M +egghead/SDM +eggheaded/P +eggnog/SM +eggplant/MS +eggshell/SM +egis's +eglantine/MS +ego/SM +egocentric/S +egocentrically +egocentricity/SM +egoism/SM +egoist/SM +egoistic +egoistical/Y +egomania/MS +egomaniac/MS +egotism/SM +egotist/MS +egotistic +egotistical/Y +egregious/PY +egregiousness/MS +egress/SDMG +egret/SM +eh +eider/SM +eiderdown/SM +eidetic +eigenfunction/MS +eigenstate/S +eigenvalue/SM +eigenvector/MS +eight/SM +eighteen/MHS +eighteenths +eightfold +eighth/MS +eighths +eightieths +eightpence +eighty/SHM +einsteinium/MS +eisteddfod/M +either +ejaculate/SDXNG +ejaculation/M +ejaculatory +eject/VGSD +ejecta +ejection/SM +ejector/SM +eke/DSG +eked/A +el/AS +elaborate/SDYPVNGX +elaborateness/SM +elaboration/M +elaborators +eland/SM +elans +elapse/SDG +elastic/S +elastically/I +elasticated +elasticity/SM +elasticize/GDS +elastodynamics +elastomer/M +elate/SRDXGN +elated/PY +elatedness/M +elater/M +elation/M +elbow/GDMS +elbowroom/SM +elder/SY +elderberry/MS +elderflower +elderliness/M +elderly/PS +eldest +elect/ASGD +electable/U +elected/U +election/SAM +electioneer/GSD +elective/SPY +electiveness/M +elector/SM +electoral/Y +electorate/SM +electress/M +electric/S +electrical/PY +electricalness/M +electrician/SM +electricity/SM +electrification/M +electrifier/M +electrify/ZXGNDRS +electro/M +electrocardiogram/MS +electrocardiograph/M +electrocardiographs +electrocardiography/MS +electrochemical/Y +electrocute/GNXSD +electrocution/M +electrode/SM +electrodynamic/YS +electrodynamics/M +electroencephalogram/SM +electroencephalograph/M +electroencephalographic +electroencephalographs +electroencephalography/MS +electrologist/MS +electroluminescent +electrolysis/M +electrolyte/SM +electrolytic +electrolytically +electrolyze/SDG +electromagnet/SM +electromagnetic +electromagnetically +electromagnetism/SM +electromechanical +electromechanics +electromotive +electromyograph +electromyographic +electromyographically +electromyography/M +electron/MS +electronegative +electronic/S +electronically +electronics/M +electrophoresis/M +electrophorus/M +electroplate/DSG +electroscope/MS +electroscopic +electroshock/GDMS +electrostatic/S +electrostatics/M +electrotherapist/M +electrotype/GSDZM +electroweak +eleemosynary +elegance/ISM +elegant/YI +elegiac/S +elegiacal +elegy/SM +elem +element/MS +elemental/YS +elementarily +elementariness/M +elementary/P +elephant/SM +elephantiases +elephantiasis/M +elephantine +elev/NX +elevate/XDSNG +elevated/S +elevation/M +elevator/SM +eleven/HM +elevens/S +elevenths +elf/M +elfin/S +elfish +elicit/GSD +elicitation/MS +elide/GSD +eligibility/ISM +eligible/SI +eliminate/XSDYVGN +elimination/M +eliminator/SM +elision/SM +elite/MPS +elitism/SM +elitist/SM +elixir/MS +elk/MS +ell/MS +ellipse/MS +ellipsis/M +ellipsoid/MS +ellipsoidal +ellipsometer/MS +ellipsometry +elliptic +elliptical/YS +ellipticity/M +elm/MRS +elocution/SM +elocutionary +elocutionist/MS +elodea/S +elongate/NGXSD +elongation/M +elope/SRDLG +elopement/MS +eloper/M +eloquence/SM +eloquent/IY +els +else/M +elsewhere +eluate/SM +elucidate/SDVNGX +elucidation/M +elude/GSD +elusive/YP +elusiveness/SM +elute/DGN +elution/M +elven +elver/SM +elves/M +elvish +elysian +em/M +emaciate/NGXDS +emaciation/M +emacs/M +email/SMDG +emanate/XSDVNG +emanation/M +emancipate/DSXGN +emancipation/M +emancipator/MS +emasculate/GNDSX +emasculation/M +embalm/ZGRDS +embalmer/M +embank/GLDS +embankment/MS +embarcadero +embargo/GMD +embargoes +embark/ADESG +embarkation/EMS +embarrass/SDLG +embarrassed/U +embarrassedly +embarrassing/Y +embarrassment/MS +embassy/MS +embattle/DSG +embed/S +embeddable +embedded +embedder +embedding/MS +embellish/LGRSD +embellished/U +embellisher/M +embellishment/MS +ember/MS +embezzle/LZGDRS +embezzlement/MS +embezzler/M +embitter/LGDS +embitterment/SM +emblazon/DLGS +emblazonment/SM +emblem/GSMD +emblematic +embodier/M +embodiment/ESM +embody/ESDGA +embolden/DSG +embolism/SM +embosom +emboss/ZGRSD +embosser/M +embouchure/SM +embower/GSD +embrace/RSDVG +embraceable +embracer/M +embracing/Y +embrasure/MS +embrittle +embrocation/SM +embroider/SGZDR +embroiderer/M +embroidery/MS +embroil/SLDG +embroilment/MS +embryo/SM +embryologist/SM +embryology/MS +embryonic +emcee/SDM +emceeing +emend/SRDGB +emendation/MS +emerald/SM +emerge/ADSG +emergence/MAS +emergency/SM +emergent/S +emerita +emeritae +emeriti +emeritus +emery/MGSD +emetic/S +emf/S +emigrant/MS +emigrate/SDXNG +emigration/M +eminence/MS +eminent/Y +emir/SM +emirate/SM +emissary/SM +emission/AMS +emissivity/MS +emit/S +emittance/M +emitted +emitter/SM +emitting +emollient/S +emolument/SM +emote/SDVGNX +emotion/M +emotional/UY +emotionalism/MS +emotionality/M +emotionalize/GDS +emotionless +emotive/Y +empaneled +empaneling +empath +empathetic +empathetical/Y +empathic +empathize/SDG +empathy/MS +emperor/MS +emphases +emphasis/M +emphasize/ZGCRSDA +emphatic/U +emphatically/U +emphysema/SM +emphysematous +empire/MS +empiric/SM +empirical/Y +empiricism/SM +empiricist/SM +emplace/L +emplacement/MS +employ/LAGDS +employability/UM +employable/US +employed/U +employee/SM +employer/SM +employment/UMAS +emporium/MS +empower/GLSD +empowerment/MS +empress/MS +emptier/M +emptily +emptiness/SM +empty/GRSDPT +empyrean/SM +ems/C +emu/SM +emulate/SDVGNX +emulation/M +emulative/Y +emulator/MS +emulsification/M +emulsifier/M +emulsify/NZSRDXG +emulsion/SM +en/BM +enable/SRDZG +enabler/M +enact/SGALD +enactment/ASM +enamel/ZGJMDRS +enameler/M +enamelware/SM +enamor/DSG +enc +encamp/LSDG +encampment/MS +encapsulate/SDGNX +encapsulation/M +encase/GSDL +encasement/SM +encephalitic +encephalitides +encephalitis/M +encephalographic +encephalopathy/M +enchain/SGD +enchant/ESLDG +enchanter/MS +enchanting/Y +enchantment/MSE +enchantress/MS +enchilada/SM +encipher/SRDG +encipherer/M +encircle/GLDS +encirclement/SM +encl +enclave/MGDS +enclose/GDS +enclosed/U +enclosure/SM +encode/ZJGSRD +encoder/M +encomium/SM +encompass/GDS +encore/GSD +encounter/GSD +encourage/SRDGL +encouragement/SM +encourager/M +encouraging/Y +encroach/LGRSD +encroacher/M +encroachment/MS +encrust/DSG +encrustation/MS +encrypt/DGS +encrypted/U +encryption/SM +encumber/SEDG +encumbered/U +encumbrance/SRM +encumbrancer/M +ency +encyclical/SM +encyclopaedia's +encyclopedia/SM +encyclopedic +encyst/GSLD +encystment/MS +end/ZGVMDRSJ +endanger/DGSL +endangerment/SM +endear/GSLD +endearing/Y +endearment/MS +endeavor/GZSMRD +endeavored/U +endeavorer/M +endemic/S +endemically +endemicity +ender/M +endgame/M +ending/M +endive/SM +endless/PY +endlessness/MS +endmost +endnote/MS +endocrine/S +endocrinologist/SM +endocrinology/SM +endogamous +endogamy/M +endogenous/Y +endomorphism/SM +endorse/DRSZGL +endorsement/MS +endorser/M +endoscope/MS +endoscopic +endoscopy/SM +endosperm/M +endothelial +endothermic +endow/GSDL +endowment/SM +endpoint/MS +endue/SDG +endungeoned +endurable/U +endurably/U +endurance/SM +endure/BSDG +enduring/YP +enduringness/M +endways +enema/SM +enemy/SM +energetic/S +energetically +energetics/M +energize/ZGDRS +energized/U +energizer/M +energy/MS +enervate/XNGVDS +enervation/M +enfeeble/GLDS +enfeeblement/SM +enfilade/MGDS +enfold/SGD +enforce/LDRSZG +enforceability/M +enforceable/U +enforced/Y +enforcement/SM +enforcer/M +enforcible/U +enfranchise/ELDRSG +enfranchisement/EMS +enfranchiser/M +engage/ADSGE +engagement/SEM +engaging/Y +engender/DGS +engine/MGSD +engineer/GSMDJ +engineering/MY +england/ZR +engorge/LGDS +engorgement/MS +engram/MS +engrave/ZGDRSJ +engraver/M +engraving/M +engross/GLDRS +engrossed/Y +engrosser/M +engrossing/Y +engrossment/SM +engulf/GDSL +engulfment/SM +enhance/LZGDRS +enhanceable +enhancement/MS +enhancer/M +enharmonic +enigma/MS +enigmatic +enigmatically +enjambement's +enjambment/MS +enjoin/GSD +enjoinder +enjoy/GBDSL +enjoyability +enjoyable/P +enjoyableness/M +enjoyably +enjoyment/SM +enlarge/LDRSZG +enlargeable +enlargement/MS +enlarger/M +enlighten/GDSL +enlightened/U +enlightening/U +enlightenment/SM +enlist/SAGDL +enlistee/MS +enlister/M +enlistment/SAM +enliven/LDGS +enlivenment/SM +enmesh/DSLG +enmeshment/SM +enmity/MS +ennoble/LDRSG +ennoblement/SM +ennobler/M +ennui/SM +enormity/SM +enormous/YP +enormousness/MS +enough +enoughs +enplane/DSG +enqueue/DS +enquirer/S +enquiringly +enrage/SDG +enrapture/GSD +enrich/LDSRG +enricher/M +enrichment/SM +enrobed +enroll/LGSD +enrollee/SM +enrollment/SM +ens +ensconce/DSG +ensemble/MS +enshrine/DSLG +enshrinement/SM +enshroud/DGS +ensign/SM +ensilage/DSMG +enslave/ZGLDSR +enslavement/MS +enslaver/M +ensnare/GLDS +ensnarement/SM +ensue/SDG +ensure/SRDZG +ensurer/M +entail/SDRLG +entailer/M +entailment/MS +entangle/EGDRSL +entanglement/ESM +entangler/EM +entente/MS +enter/ASDG +entered/U +enterer/M +enteritides +enteritis/SM +enterprise/GMSR +enterpriser/M +enterprising/Y +entertain/SGZRDL +entertainer/M +entertaining/Y +entertainment/SM +enthalpy/SM +enthrall/GDSL +enthrallment/SM +enthrone/GDSL +enthronement/MS +enthuse/DSG +enthusiasm/SM +enthusiast/MS +enthusiastic/U +enthusiastically/U +entice/SRDJLZG +enticement/SM +enticing/Y +entire/SY +entirety/SM +entitle/GLDS +entitlement/MS +entity/SM +entomb/GDSL +entombment/MS +entomological +entomologist/S +entomology/MS +entourage/SM +entr'acte/S +entrails +entrain/GSLDR +entrainer/M +entrance/MGDSL +entrancement/MS +entranceway/M +entrancing/Y +entrant/MS +entrap/SL +entrapment/SM +entrapped +entrapping +entreat/SGD +entreating/Y +entreaty/SM +entrench/LSDG +entrenchment/MS +entrepreneur/MS +entrepreneurial +entrepreneurship/M +entropic +entropy/MS +entrust/DSG +entry/ASM +entryway/SM +entr�e/S +entwine/DSG +enumerable +enumerate/AN +enumerated/U +enumerates +enumerating +enumeration's/A +enumeration/SM +enumerative +enumerator/SM +enunciable +enunciate/XGNSD +enunciated/U +enunciation/M +enureses +enuresis/M +envelop/ZGLSDR +envelope/MS +enveloper/M +envelopment/MS +envenom/SDG +enviable/U +enviableness/M +enviably +envied/U +envier/M +envious/PY +enviousness/SM +environ/LGSD +environment/MS +environmental/Y +environmentalism/SM +environmentalist/SM +envisage/DSG +envision/GSD +envoy/SM +envy/SRDMG +envying/Y +enzymatic +enzymatically +enzyme/SM +enzymology/M +eohippus/M +eolian +eon/SM +epaulet/SM +ephedrine/MS +ephemera/MS +ephemeral/SY +ephemerids +ephemeris/M +epic/SM +epically +epicenter/SM +epicure/SM +epicurean/S +epicycle/MS +epicyclic +epicyclical/Y +epicycloid/M +epidemic/MS +epidemically +epidemiological/Y +epidemiologist/MS +epidemiology/MS +epidermal +epidermic +epidermis/MS +epidural +epigenetic +epiglottis/SM +epigram/MS +epigrammatic +epigraph/RM +epigrapher/M +epigraphs +epigraphy/MS +epilepsy/SM +epileptic/S +epilogue/SDMG +epinephrine/SM +epiphany/SM +epiphenomena +episcopacy/MS +episcopal/Y +episcopalian +episcopate/MS +episode/SM +episodic +episodically +epistemic +epistemological/Y +epistemology/M +epistle/MRS +epistolary/S +epistolatory +epitaph/GMD +epitaphs +epitaxial/Y +epitaxy/M +epithelial +epithelium/MS +epithet/MS +epitome/MS +epitomize/SRDZG +epitomized/U +epitomizer/M +epoch/M +epochal/Y +epochs +eponymous +epoxy/GSD +epsilon/SM +equability/MS +equable/P +equableness/M +equably +equal/USDY +equaling +equality/ISM +equalization/MS +equalize/DRSGJZ +equalized/U +equalizer/M +equalizes/U +equanimity/MS +equate/NGXBSD +equation/M +equator/SM +equatorial/S +equerry/MS +equestrian/S +equestrianism/SM +equestrienne/SM +equiangular +equidistant/Y +equilateral/S +equilibrate/GNSD +equilibration/M +equilibrium/MSE +equine/S +equinoctial/S +equinox/MS +equip/AS +equipage/SM +equipartition/M +equipment/SM +equipoise/GMSD +equipotent +equipped/AU +equipping/A +equiproportional +equiproportionality +equiproportionate +equitable/I +equitableness/M +equitably/I +equitation/SM +equity/IMS +equiv +equivalence/DSMG +equivalent/SY +equivocal/UY +equivocalness/MS +equivocate/NGSDX +equivocation/M +equivocator/SM +era/MS +eradicable/I +eradicate/SDXVGN +eradication/M +eradicator/SM +eras/SRDBGZ +erase/N +eraser/M +erasion/M +erasure/MS +erbium/SM +ere +erect/GPSRDY +erectile +erection/SM +erectness/MS +erector/SM +erelong +eremite/MS +erg/SM +ergo +ergodic +ergodicity/M +ergonomic/U +ergonomically +ergonomics/M +ergophobia +ergosterol/SM +ergot/SM +eris +ermine/MSD +erode/SDG +erodible +erogenous +erosible +erosion/SM +erosional +erosive/P +erosiveness/M +erotic/S +erotica/M +erotically +eroticism/MS +err/DGS +errancy/MS +errand/MS +errant/YS +errantry/M +errata/SM +erratic/S +erratically +erratum/MS +erring/UY +erroneous/YP +erroneousness/M +error/SM +ersatz/S +erst +erstwhile +eruct/DGS +eructation/MS +erudite/NYX +erudition/M +erupt/DSVG +eruption/SM +eruptive/SY +erysipelas/SM +erythrocyte/SM +es +escadrille/M +escalate/CDSXGN +escalation/MC +escalator/SM +escallop/SGDM +escapable/I +escapade/SM +escape/LGSRDB +escapee/MS +escapement/MS +escaper/M +escapism/SM +escapist/S +escapology +escarole/MS +escarpment/MS +eschatology/M +eschew/SGD +escort/SGMD +escritoire/SM +escrow/DMGS +escudo/MS +escutcheon/SM +esophageal +esophagi +esophagus/M +esoteric +esoterica +esoterically +esp +espadrille/MS +espalier/SMDG +especial/Y +espionage/SM +esplanade/SM +espousal/MS +espouse/SRDG +espouser/M +espresso/SM +esprit/SM +espy/GSD +esquire/GMSD +essay/SZMGRD +essayer/M +essayist/SM +essence/MS +essential/USI +essentialist/M +essentially +essentialness/M +est/RZ +establish/LAEGSD +established/U +establisher/M +establishment/EMAS +estate/GSDM +esteem/EGDS +ester/M +esthete's +esthetic's +esthetically +esthetics's +estimable/I +estimableness/M +estimate/XDSNGV +estimating/A +estimation/M +estimator/SM +estoppal +estrange/DRSLG +estrangement/SM +estranger/M +estrogen/SM +estrous +estrus/SM +estuarine +estuary/SM +et +eta/SM +etc +etcetera/SM +etch/GZJSRD +etcher/M +etching/M +eternal/PSY +eternalness/SM +eternity/SM +ethane/SM +ethanol/MS +ether/SM +ethereal/PY +etherealness/M +etherized +ethic/MS +ethical/PYS +ethically/U +ethicalness/M +ethicist/S +ethnic/S +ethnically +ethnicity/MS +ethnocentric +ethnocentrism/MS +ethnographers +ethnographic +ethnography/M +ethnological +ethnologist/SM +ethnology/SM +ethnomethodology +ethological +ethologist/MS +ethology/SM +ethos/SM +ethyl/SM +ethylene/MS +etiologic +etiological +etiology/SM +etiquette/SM +etymological/Y +etymologist/SM +etymology/MS +eucalypti +eucalyptus/SM +euchre/MGSD +euclidean +eugenic/S +eugenically +eugenicist/SM +eugenics/M +eulogist/MS +eulogistic +eulogize/GRSDZ +eulogized/U +eulogizer/M +eulogy/MS +eunuch/M +eunuchs +euphemism/MS +euphemist/M +euphemistic +euphemistically +euphonious/Y +euphonium/M +euphony/SM +euphoria/SM +euphoric +euphorically +eureka/S +europium/MS +eutectic +euthanasia/SM +euthenics/M +evacuate/DSXNGV +evacuation/M +evacuee/MS +evade/SRDBGZ +evader/M +evaluable +evaluate/ADSGNX +evaluated/U +evaluation/MA +evaluational +evaluative +evaluator/MS +evanescence/MS +evanescent +evangelic +evangelical/YS +evangelicalism/SM +evangelism/SM +evangelist/MS +evangelistic +evangelize/GDS +evaporate/VNGSDX +evaporation/M +evaporative/Y +evaporator/MS +evasion/SM +evasive/PY +evasiveness/SM +eve's/A +eve/RSM +even/PUYRT +evened +evener/M +evenhanded/YP +evening/SM +evenness/MSU +evens +evensong/MS +event/SGM +eventful/YU +eventfulness/SM +eventide/SM +eventual/Y +eventuality/MS +eventuate/GSD +ever/T +everglade/MS +evergreen/S +everlasting/PYS +everlastingness/M +everliving +evermore +every +everybody/M +everyday/P +everydayness/M +everyman +everyone/MS +everyplace +everything +everywhere +eves/A +evict/DGS +eviction/SM +evidence/MGSD +evident/YS +evidential/Y +evil/YRPTS +evildoer/SM +evildoing/MS +evilness/MS +evince/SDG +eviscerate/GNXDS +evisceration/M +evocable +evocate/NVX +evocation/M +evocative/YP +evocativeness/M +evoke/SDG +evolute/NMXS +evolution/M +evolutionarily +evolutionary +evolutionist/MS +evolve/SDG +ewe/MZRS +ewer/M +ex/S +exacerbate/NGXDS +exacerbation/M +exact/TGSPRDY +exacter/M +exacting/YP +exactingness/M +exaction/SM +exactitude/ISM +exactly/I +exactness/MSI +exaggerate/DSXNGV +exaggerated/YP +exaggeration/M +exaggerative/Y +exaggerator/MS +exalt/ZRDGS +exaltation/SM +exalted/Y +exalter/M +exam/MNS +examen/M +examination's +examination/AS +examine/BGZDRS +examined/AU +examinees +examiner/M +examines/A +examining/A +example/DSGM +exampled/U +exasperate/DSXGN +exasperated/Y +exasperating/Y +exasperation/M +excavate/NGDSX +excavation/M +excavator/SM +exceed/SGDR +exceeder/M +exceeding/Y +excel/S +excelled +excellence/SM +excellency/MS +excellent/Y +excelling +excelsior/S +except/DSGV +exception/BMS +exceptionable/U +exceptional/YU +exceptionalness/M +excerpt/GMDRS +excerpter/M +excess/GVDSM +excessive/PY +excessiveness/M +exchange/GDRSZ +exchangeable +exchanger/M +exchequer/SM +excise/XMSDNGB +excision/M +excitability/MS +excitable/P +excitableness/M +excitably +excitation/SM +excitatory +excite/RSDLBZG +excited/Y +excitement/MS +exciter/M +exciting/U +excitingly +exciton/M +exclaim/SZDRG +exclaimer/M +exclamation/MS +exclamatory +exclude/DRSG +excluder/M +exclusion/SZMR +exclusionary +exclusioner/M +exclusive/SPY +exclusiveness/SM +exclusivity/MS +excommunicate/XVNGSD +excommunication/M +excoriate/GNXSD +excoriation/M +excrement/SM +excremental +excrescence/MS +excrescent +excreta +excrete/NGDRSX +excreter/M +excretion/M +excretory/S +excruciate/NGDS +excruciating/Y +excruciation/M +exculpate/XSDGN +exculpation/M +exculpatory +excursion/MS +excursionist/SM +excursive/PY +excursiveness/SM +excursus/MS +excusable/IP +excusableness/IM +excusably/I +excuse/BGRSD +excused/U +excuser/M +exec/MS +execrable/P +execrableness/M +execrably +execrate/DSXNGV +execration/M +executable/MS +execute/NGVZBXDRS +executer/M +execution/ZMR +executional +executioner/M +executive/SM +executor/SM +executrices +executrix/M +exegeses +exegesis/M +exegete/M +exegetic/S +exegetical +exemplar/MS +exemplariness/M +exemplary/P +exemplification/M +exemplifier/M +exemplify/ZXNSRDG +exempt/SDG +exemption/MS +exercise/ZDRSGB +exerciser/M +exert/SGD +exertion/MS +exeunt +exhalation/SM +exhale/GSD +exhaust/VGRDS +exhausted/Y +exhauster/M +exhaustible/I +exhausting/Y +exhaustion/SM +exhaustive/YP +exhaustiveness/MS +exhibit/VGSD +exhibition/ZMRS +exhibitioner/M +exhibitionism/MS +exhibitionist/MS +exhibitor/SM +exhilarate/XSDVNG +exhilarating/Y +exhilaration/M +exhort/DRSG +exhortation/SM +exhorter/M +exhumation/SM +exhume/GRSD +exhumer/M +exigence/S +exigency/SM +exigent/SY +exiguity/SM +exiguous +exile/SDGM +exist/SDG +existence/MS +existent/I +existential/Y +existentialism/MS +existentialist/MS +existentialistic +existents +exit/MDSG +exobiology/MS +exocrine +exodus/SM +exogamous +exogamy/M +exogenous/Y +exonerate/SDVGNX +exoneration/M +exorbitance/MS +exorbitant/Y +exorcise/SDG +exorcism/SM +exorcist/SM +exorcizer/M +exoskeleton/MS +exosphere/SM +exothermic +exothermically +exotic/PS +exotica +exotically +exoticism/SM +exoticness/M +exp +expand/DRSGZB +expandability/M +expanded/U +expander/M +expanse/DSXGNVM +expansible +expansion/M +expansionary +expansionism/MS +expansionist/MS +expansive/YP +expansiveness/S +expatiate/XSDNG +expatiation/M +expatriate/SDNGX +expatriation/M +expect/SBGD +expectancy/MS +expectant/YS +expectation/MS +expectational +expected/UPY +expecting/Y +expectorant/S +expectorate/NGXDS +expectoration/M +expedience/IS +expediency/IMS +expedient/YI +expedients +expedite/ZDRSNGX +expediter/M +expedition/M +expeditionary +expeditious/YP +expeditiousness/MS +expeditor's +expel/S +expellable +expelled +expelling +expend/SDRGB +expendable/S +expended/U +expender/M +expenditure/SM +expense/DSGVM +expensive/IYP +expensiveness/SMI +experience/ISDM +experienced/U +experiencing +experiential/Y +experiment/GSMDRZ +experimental/Y +experimentalism/M +experimentalist/SM +experimentation/SM +experimenter/M +expert's +expert/PISY +experted +experting +expertise/SM +expertize/GD +expertness/IM +expertnesses +expiable/I +expiate/XGNDS +expiation/M +expiatory +expiration/MS +expire/SDG +expired/U +expiry/MS +explain/ADSG +explainable/UI +explained/U +explainer/SM +explanation/MS +explanatory +expletive/SM +explicable/I +explicate/VGNSDX +explication/M +explicative/Y +explicit/PSY +explicitness/SM +explode/DSRGZ +exploded/U +exploder/M +exploit/ZGVSMDRB +exploitation/MS +exploitative +exploited/U +exploiter/M +exploration/MS +exploratory +explore/DSRBGZ +explored/U +explorer/M +explosion/MS +explosive/YPS +explosiveness/SM +expo/MS +exponent/MS +exponential/SY +exponentiate/XSDNG +exponentiation/M +export's +export/AGSD +exportability +exportable +exportation/SM +exporter/MS +expos/RSDZG +expose +exposed/U +exposer/M +exposit/D +exposition/SM +expositor/MS +expository +expostulate/DSXNG +expostulation/M +exposure/SM +expound/ZGSDR +expounder/M +express/GVDRSY +expressed/U +expresser/M +expressibility/I +expressible/I +expressibly/I +expression/MS +expressionism/SM +expressionist/S +expressionistic +expressionless/YP +expressive/IYP +expressiveness's/I +expressiveness/MS +expressway/SM +expropriate/XDSGN +expropriation/M +expropriator/SM +expulsion/MS +expunge/GDSR +expunger/M +expurgate/SDGNX +expurgated/U +expurgation/M +exquisite/YPS +exquisiteness/SM +ext +extant +extemporaneous/YP +extemporaneousness/MS +extempore/S +extemporization/SM +extemporize/ZGSRD +extemporizer/M +extend/SGZDR +extendability/M +extended/U +extendedly +extendedness/M +extender/M +extendibility/M +extendibles +extensibility/M +extensible/I +extension/SM +extensional/Y +extensive/PY +extensiveness/SM +extensor/MS +extent/SM +extenuate/XSDGN +extenuation/M +exterior/MYS +exterminate/XNGDS +extermination/M +exterminator/SM +extern/M +external/YS +externalities +externalization/SM +externalize/GDS +extinct/DGVS +extinction/MS +extinguish/BZGDRS +extinguishable/I +extinguisher/M +extirpate/XSDVNG +extirpation/M +extol/S +extolled +extoller/M +extolling +extort/DRSGV +extorter/M +extortion/ZSRM +extortionate/Y +extortioner/M +extortionist/SM +extra/S +extracellular/Y +extract/GVSBD +extraction/SM +extractive/Y +extractor/SM +extracurricular/S +extradite/XNGSDB +extradition/M +extragalactic +extralegal/Y +extramarital +extramural +extraneous/YP +extraneousness/M +extraordinarily +extraordinariness/M +extraordinary/PS +extrapolate/XVGNSD +extrapolation/M +extrasensory +extraterrestrial/S +extraterritorial +extraterritoriality/MS +extravagance/MS +extravagant/Y +extravaganza/SM +extravehicular +extravert's +extrema +extremal +extreme/DSRYTP +extremeness/MS +extremism/SM +extremist/MS +extremity/SM +extricable/I +extricate/XSDNG +extrication/M +extrinsic +extrinsically +extroversion/SM +extrovert/GMDS +extrude/GDSR +extruder/M +extrusion/MS +extrusive +exuberance/MS +exuberant/Y +exudate/XNM +exudation/M +exude/GSD +exult/DGS +exultant/Y +exultation/SM +exulting/Y +exurb/MS +exurban +exurbanite/SM +exurbia/MS +eye/GDRSMZ +eyeball/GSMD +eyebrow/MS +eyed/P +eyedropper/MS +eyeful/MS +eyeglass/MS +eyelash/MS +eyeless +eyelet/GSMD +eyelid/SM +eyeliner/MS +eyeopener/MS +eyeopening +eyepiece/SM +eyer/M +eyeshadow +eyesight/MS +eyesore/SM +eyestrain/MS +eyeteeth +eyetooth/M +eyewash/MS +eyewitness/SM +eyrie's +f's/KA +f/IRAC +fa/M +fable/GMSRD +fabler/M +fabric/MS +fabricate/SDXNG +fabrication/M +fabricator/MS +fabulists +fabulous/YP +fabulousness/M +facade/GMSD +face's +face/AGCSD +facecloth +facecloths +faceless/P +faceplate/M +facer/CM +facet/SGMD +facetious/YP +facetiousness/MS +facial/YS +facile/YP +facileness/M +facilitate/VNGXSD +facilitation/M +facilitator/SM +facilitatory +facility/MS +facing/MS +facsimile/MSD +facsimileing +fact/MS +faction/SM +factional +factionalism/SM +factious/PY +factiousness/M +factitious +facto +factoid/S +factor/SDMJG +factorial/MS +factoring's +factoring/A +factorisable +factorization/SM +factorize/GSD +factory/MS +factotum/MS +factual/PY +factuality/M +factualness/M +faculty/MS +fad/ZGSMDR +faddish +faddist/SM +fade/S +faded/U +fadedly +fadeout +fader/M +fading's +fading/U +faerie/MS +faery's +fag/MS +fagged +fagging +faggoting's +fagot/MDSJG +fagoting/M +fail/JSGD +failing's +failing/UY +faille/MS +failsafe +failure/SM +fain/GTSRD +faint/YRDSGPT +fainter/M +fainthearted +faintness/MS +fair/TURYP +faired +fairgoer/S +fairground/MS +fairing/MS +fairish +fairless +fairness's +fairness/US +fairs +fairway/MS +fairy/MS +fairyland/MS +fairytale +faith's +faith/U +faithed +faithful/UYP +faithfulness/MSU +faithfuls +faithing +faithless/YP +faithlessness/SM +faiths +fajitas +fake/ZGDRS +faker/M +fakir/SM +falafel +falcon/ZSRM +falconer/M +falconry/MS +fall/SGZMRN +fallacious/PY +fallaciousness/M +fallacy/MS +faller/M +fallibility/MSI +fallible/I +fallibleness/MS +fallibly/I +falloff/S +fallopian +fallout/MS +fallow/PSGD +fallowness/M +false/PTYR +falsehood/SM +falseness/SM +falsetto/SM +falsie/MS +falsifiability/M +falsifiable/U +falsification/M +falsifier/M +falsify/ZRSDNXG +falsity/MS +falter/RDSGJ +falterer/M +faltering/UY +fame/DSMG +famed/C +fames/C +familial +familiar/YPS +familiarity/MUS +familiarization/MS +familiarize/ZGRSD +familiarized/U +familiarizer/M +familiarizing/Y +familiarly/U +familiarness/M +family/MS +famine/SM +faming/C +famish/GSD +famous/PY +famously/I +famousness/M +fan/SM +fanatic/SM +fanatical/YP +fanaticalness/M +fanaticism/MS +fancied +fancier/SM +fanciest +fanciful/YP +fancifulness/MS +fancily +fanciness/SM +fancy/IS +fancying +fancywork/SM +fandango/SM +fanfare/SM +fanfold/M +fang/DMS +fangled +fanlight/SM +fanned +fanning +fanny/SM +fanout +fantail/SM +fantasia/SM +fantasist/M +fantasize/SRDG +fantastic/S +fantastical/Y +fantasy/GMSD +fanzine/S +far/GDR +farad/SM +faraway +farce/SDGM +farcical/Y +fare/MS +farer/M +farewell/DGMS +farfetchedness/M +farina/MS +farinaceous +farm/MRDGZSJ +farmer/M +farmhand/S +farmhouse/SM +farming/M +farmland/SM +farmstead/SM +farmworker/S +farmyard/MS +faro/MS +farrago/M +farragoes +farrier/SM +farrow/DMGS +farseeing +farsighted/YP +farsightedness/SM +fart/MDGS! +farther +farthermost +farthest +farthing/SM +fas +fascia/SM +fascicle/DSM +fasciculate/DNX +fasciculation/M +fascinate/SDNGX +fascinating/Y +fascination/M +fascism/MS +fascist/SM +fascistic +fashion's +fashion/ADSG +fashionable/PS +fashionableness/M +fashionably/U +fashioner/SM +fast/GTXSPRND +fastback/MS +fastball/S +fasten/AGUDS +fastener/MS +fastening/SM +fastidious/PY +fastidiousness/MS +fastness/MS +fat/PSGMDY +fatal/SY +fatalism/MS +fatalist/MS +fatalistic +fatalistically +fatality/MS +fatback/SM +fate/MS +fateful/YP +fatefulness/MS +fathead/SMD +fatheaded/P +father/DYMGS +fathered/U +fatherhood/MS +fatherland/SM +fatherless +fatherliness/M +fatherly/P +fathom/MDSBG +fathomable/U +fathomless +fatigue/MGSD +fatigued/U +fatiguing/Y +fatness/SM +fatso/M +fatted +fatten/JZGSRD +fattener/M +fatter +fattest/M +fattiness/SM +fatting +fatty/RSPT +fatuity/MS +fatuous/YP +fatuousness/SM +fatwa/SM +faucet/SM +fault/CGSMD +faultfinder/MS +faultfinding/MS +faultily +faultiness/MS +faultless/PY +faultlessness/SM +faulty/RTP +faun/MS +fauna/MS +fauvism/S +favor/ESMRDGZ +favorable/UMPS +favorableness/MU +favorably/U +favored's/U +favored/YPSM +favoredness/M +favorer/EM +favoring/MYS +favorings/U +favorite/SMU +favoritism/MS +favors/A +fawn/GZRDMS +fawner/M +fawning/Y +fax/GMDS +fay/MDRGS +faze/DSG +fa�ence/S +fealty/MS +fear/RDMSG +fearful/YP +fearfuller +fearfullest +fearfulness/MS +fearless/PY +fearlessness/MS +fearsome/PY +fearsomeness/M +feasibility/SM +feasible/UI +feasibleness/M +feasibly/U +feast/GSMRD +feaster/M +feat/MYRGTS +feater/C +feather/ZMDRGS +featherbed +featherbedding/SM +featherbrain/MD +feathered/U +feathering/M +featherless +featherlight +feathertop +featherweight/SM +feathery/TR +feats/C +feature/MGSD +featureless +febrile +fecal +feces +feckless/PY +fecklessness/M +fecund/I +fecundability +fecundate/XSDGN +fecundation/M +fecundity/SM +fed/U +federal/YS +federalism/SM +federalist/MS +federalization/MS +federalize/GSD +federate/FSDXVNG +federated/U +federation/FM +federative/Y +fedora/SM +feds +fee/MDS +feeble/TPR +feebleness/SM +feebly +feed/GRZJS +feedback/SM +feedbag/MS +feeder/M +feeding/M +feedlot/SM +feedstock +feedstuffs +feeing +feel/GZJRS +feeler/M +feeling/MYP +feelingly/U +feelingness/M +feet/M +feign/RDGS +feigned/U +feigner/M +feint/MDSG +feisty/RT +feldspar/MS +felicitate/XGNSD +felicitation/M +felicitous/IY +felicitousness/M +felicity/IMS +feline/SY +fell/PSGZTRD +fella/S +fellatio/SM +felled/A +feller/M +felling/A +fellness/M +fellow/SGDYM +fellowman +fellowmen +fellowship/SM +fellowshipped +fellowshipping +felon/MS +felonious/PY +feloniousness/M +felony/MS +felt/GSD +felting/M +fem/S +female/MPS +femaleness/SM +feminine/PYS +feminineness/M +femininity/MS +feminism/MS +feminist/MS +femme/MS +femoral +femur/MS +fen/MS +fence/SRDJGMZ +fenced/U +fencepost/M +fencer/M +fencing/M +fend/RDSCZG +fender/CM +fenestration/CSM +fenland/M +fennel/SM +fer/FLC +feral +ferment/FSCM +fermentation/MS +fermented +fermenter +fermenting +fermion/MS +fermium/MS +fern/MS +fernery/M +ferny/TR +ferocious/YP +ferociousness/MS +ferocity/MS +ferret/SMRDG +ferreter/M +ferric +ferris +ferrite/M +ferro +ferroelectric +ferromagnet/M +ferromagnetic +ferrous +ferrule/MGSD +ferry/SDMG +ferryboat/MS +ferryman/M +ferrymen +fertile/YP +fertileness/M +fertility/IMS +fertilization/ASM +fertilize/SRDZG +fertilized/U +fertilizer/M +fertilizes/A +ferule/SDGM +fervency/MS +fervent/Y +fervid/YP +fervidness/M +fervor/MS +fess's +fess/KGFSD +fest/RVZ +festal/S +fester/GD +festival/SM +festive/PY +festiveness/SM +festivity/SM +festoon/SMDG +feta/MS +fetal +fetch/RSDGZ +fetcher/M +fetching/Y +feted +fetich's +fetid/YP +fetidness/SM +feting +fetish/MS +fetishism/SM +fetishist/SM +fetishistic +fetlock/MS +fetter's +fetter/UGSD +fettle/GSD +fettling/M +fettuccine/S +fetus/SM +feud/MDSG +feudal/Y +feudalism/MS +feudalistic +feudatory/M +fever/SDMG +feverish/PY +feverishness/SM +few/PTRS +fewness/MS +fey/RT +fez/M +fezzes +ff +fianc�/MS +fianc�e/S +fiasco/M +fiascoes +fiat/MS +fib/SZMR +fibbed +fibber/MS +fibbing +fiber/DM +fiberboard/MS +fiberfill/S +fiberglass/DSMG +fibril/MS +fibrillate/XGNDS +fibrillation/M +fibrin/MS +fibroblast/MS +fibroid/S +fibroses +fibrosis/M +fibrous/YP +fibrousness/M +fibula/M +fibulae +fibular +fices +fiche/SM +fichu/SM +fickle/RTP +fickleness/MS +ficos +fiction/SM +fictional/Y +fictionalization/MS +fictionalize/DSG +fictitious/PY +fictitiousness/M +fictive/Y +ficus +fiddle/GMZJRSD +fiddler/M +fiddlestick/SM +fiddly +fide/F +fidelity/IMS +fidget/DSG +fidgety +fiducial/Y +fiduciary/MS +fie/S +fief/MS +fiefdom/S +field/ZISMR +fielded +fielder/IM +fielding +fieldstone/M +fieldwork/ZMRS +fieldworker/M +fiend/MS +fiendish/YP +fiendishness/M +fierce/RPTY +fierceness/SM +fierily +fieriness/MS +fiery/PTR +fies/C +fiesta/MS +fife/DRSMZG +fifer/M +fifteen/HRMS +fifteenths +fifth/Y +fifths +fiftieths +fifty/HSM +fig/MLS +figged +figging +fight/ZSJRG +fightback +fighter/MIS +fighting/IS +figment/MS +figural +figuration/FSM +figurative/YP +figurativeness/M +figure's +figure/GFESD +figurehead/SM +figurer/SM +figurine/SM +figuring/S +filament/MS +filamentary +filamentous +filbert/MS +filch/SDG +file/KDRSGMZ +filed/AC +filename/SM +filer/KMCS +files/AC +filet's +filial/UY +filibuster/MDRSZG +filibusterer/M +filigree/MSD +filigreeing +filing/AC +filings +fill/BAJGSD +filled/U +filler/MS +fillet/MDSG +filleting/M +filling/M +fillip/MDGS +filly/SM +film/SGMD +filmdom/M +filminess/SM +filming/M +filmmaker/S +filmstrip/SM +filmy/RTP +filter/RDMSZGB +filtered/U +filterer/M +filth/M +filthily +filthiness/SM +filths +filthy/TRSDGP +filtrate/SDXMNG +filtrated/I +filtrates/I +filtrating/I +filtration/IMS +fin/TGMDRS +finagle/RSDZG +finagler/M +final/SY +finale/MS +finalist/MS +finality/MS +finalization/SM +finalize/GSD +finance/MGSDJ +financed/A +finances/A +financial/Y +financier/DMGS +financing/A +finch/MS +find/BRJSGZ +findable/U +finder/M +finding/M +fine's +fine/FGSCRDA +finely +fineness/MS +finery/MAS +finespun +finesse/SDMG +finger/SGRDMJ +fingerboard/SM +fingerer/M +fingering/M +fingerless +fingerling/M +fingernail/MS +fingerprint/SGDM +fingertip/MS +finial/SM +finical +finickiness/S +finicky/RPT +fining/M +finis/SM +finish/JZGRSD +finished/UA +finisher/M +finishes/A +finite/ISPY +finitely/C +finiteness/MIC +fink/GDMS +finned +finner +finning +finny/RT +fiord's +fir/ZGJMDRHS +fire/MS +firearm/SM +fireball/SM +fireboat/M +firebomb/MDSG +firebox/MS +firebrand/MS +firebreak/SM +firebrick/SM +firebug/SM +firecracker/SM +fired/U +firedamp/SM +firefight/JRGZS +firefly/MS +fireguard/M +firehouse/MS +firelight/GZSM +fireman/M +firemen +fireplace/MS +fireplug/MS +firepower/SM +fireproof/SGD +firer/M +firesafe +fireside/SM +firestorm/SM +firetrap/SM +firetruck/S +firewall/S +firewater/SM +firewood/MS +firework/MS +firing/M +firkin/M +firm's +firm/ISFDG +firmament/MS +firmer +firmest +firmly/I +firmness/MS +firmware/MS +firring +first/SY +firstborn/S +firsthand +firth/M +firths +fiscal/YS +fish/JGZMSRD +fishbowl/MS +fishcake/S +fisher/M +fisherman/M +fishermen/M +fishery/MS +fishhook/MS +fishily +fishiness/MS +fishing/M +fishmeal +fishmonger/MS +fishnet/SM +fishpond/SM +fishtail/DMGS +fishtanks +fishwife/M +fishwives +fishy/TPR +fissile +fission/BSDMG +fissionable/S +fissure/MGSD +fist/MDGS +fistfight/SM +fistful/MS +fisticuff/SM +fistula/SM +fistulous +fit's/K +fit/UYPS +fitful/PY +fitfulness/SM +fitments +fitness/USM +fits/AK +fitted/UA +fitter/SM +fittest +fitting/AU +fittingly +fittingness/M +fittings +five/MRS +fivefold +fiver/M +fix/USDG +fixable +fixate/VNGXSD +fixatifs +fixation/M +fixative/S +fixed/YP +fixedness/M +fixer/SM +fixes/I +fixing/SM +fixity/MS +fixture/SM +fizz/SRDG +fizzer/M +fizzle/GSD +fizzy/RT +fjord/SM +fl/GJD +flab/MS +flabbergast/GSD +flabbergasting/Y +flabbily +flabbiness/SM +flabby/TPR +flaccid/Y +flaccidity/MS +flack/SGDM +flag/MS +flagella/M +flagellate/DSNGX +flagellation/M +flagellum/M +flagged +flagging/SMY +flaggingly/U +flagman/M +flagmen +flagon/SM +flagpole/SM +flagrance/MS +flagrancy/SM +flagrant/Y +flagship/MS +flagstaff/MS +flagstone/SM +flail/SGMD +flair/SM +flak/RDMGS +flake/SM +flaker/M +flakiness/MS +flaky/PRT +flam/MRNDJGZ +flambeing +flambes +flamboyance/MS +flamboyancy/MS +flamboyant/YS +flamb�/D +flame's +flame/SIGDR +flamen/M +flamenco/SM +flameproof/DGS +flamer/IM +flamethrower/SM +flaming/Y +flamingo/SM +flammability/ISM +flammable/SI +flan/MS +flange/GMSD +flank/SGZRDM +flanker/M +flannel/DMGS +flannelet/MS +flannelette's +flap/MS +flapjack/SM +flapped +flapper/SM +flapping +flaps/M +flare/SDG +flareup/S +flaring/Y +flash/JMRSDGZ +flashback/SM +flashbulb/SM +flashcard/S +flashcube/MS +flasher/M +flashgun/S +flashily +flashiness/SM +flashing/M +flashlight/MS +flashy/TPR +flask/SM +flat/MYPS +flatbed/S +flatboat/MS +flatcar/MS +flatfeet +flatfish/SM +flatfoot/SGDM +flathead/M +flatiron/SM +flatland/RS +flatmate/M +flatness/MS +flatted +flatten/SDRG +flattener/M +flatter/DRSZG +flatterer/M +flattering/YU +flattery/SM +flattest/M +flatting +flattish +flattop/MS +flatulence/SM +flatulent/Y +flatus/SM +flatware/MS +flatworm/SM +flaunt/SDG +flaunting/Y +flautist/SM +flavor/SJDRMZG +flavored/U +flavorer/M +flavorful +flavoring/M +flavorless +flavorsome +flaw/GDMS +flawless/PY +flawlessness/MS +flax/MSN +flaxseed/M +flay/RDGZS +flayer/M +flea/SM +fleabag/MS +fleabites +fleawort/M +fleck/GRDMS +fledge/GSD +fledged/U +fledgling/SM +flee/RS +fleece/RSDGMZ +fleecer/M +fleeciness/SM +fleecy/RTP +fleeing +fleet/MYRDGTPS +fleeting/YP +fleetingly/M +fleetingness/SM +fleetness/MS +flesh/JMYRSDG +flesher/M +fleshiness/M +fleshless +fleshly/TR +fleshpot/SM +fleshy/TPR +fletch/DRSGJ +fletcher/M +fletching/M +flew/S +flews/M +flex/MSDAG +flexed/I +flexibility/MSI +flexible/I +flexibly/I +flexitime's +flextime/S +flexural +flexure/M +flibbertigibbet/MS +flick/GZSRD +flicker/GD +flickering/Y +flickery +flier/M +flight/GMDS +flightiness/SM +flightless +flightpath +flighty/RTP +flimflam/MS +flimflammed +flimflamming +flimsily +flimsiness/MS +flimsy/PTRS +flinch/GDRS +flincher/M +flinching/U +fling/RMG +flinger/M +flint/MDSG +flintiness/M +flintless +flintlock/MS +flinty/TRP +flip/S +flipflop +flippable +flippancy/MS +flippant/Y +flipped +flipper/SM +flippest +flipping +flirt/GRDS +flirtation/SM +flirtatious/PY +flirtatiousness/MS +flit/S +flitted +flitting +float/SRDGJZ +floater/M +floaty +flocculate/GNDS +flocculation/M +flock/SJDMG +floe/MS +flog/S +flogged +flogger/SM +flogging/SM +flood/SMRDG +floodgate/MS +floodlight/DGMS +floodlit +floodplain/S +floodwater/SM +floor/SJRDMG +floorboard/MS +floorer/M +flooring/M +floorspace +floorwalker/SM +floozy/SM +flop/MS +flophouse/SM +flopped +flopper/M +floppily +floppiness/SM +flopping +floppy/TMRSP +flora/SM +floral/SY +florescence/MIS +florescent/I +floret/MS +florid/YP +floridness/SM +florin/MS +florist/MS +floss/GSDM +flossy/RST +flotation/SM +flotilla/SM +flotsam/SM +flounce/GDS +flouncing/M +flouncy/RT +flounder/SDG +flour/SGDM +flourish/GSRD +flourisher/M +flourishing/Y +floury/TR +flout/GZSRD +flouter/M +flow/ISG +flowchart/SG +flowed +flower's +flower/CSGD +flowerbed/SM +flowerer/M +floweriness/SM +flowerless +flowerpot/MS +flowery/TRP +flowing/Y +flown +flowstone +flt +flu/MS +flub/S +flubbed +flubbing +fluctuate/XSDNG +fluctuation/M +flue/SM +fluency/MS +fluent/SF +fluently +fluff/SGDM +fluffiness/SM +fluffy/PRT +fluid/MYSP +fluidity/SM +fluidized +fluidness/M +fluke/SDGM +fluky/RT +flume/SDGM +flummox/DSG +flung +flunk/SRDG +flunkey's +flunky/MS +fluoresce/GSRD +fluorescence/MS +fluorescent/S +fluoridate/XDSGN +fluoridation/M +fluoride/SM +fluorimetric +fluorinated +fluorine/SM +fluorite/MS +fluorocarbon/MS +fluoroscope/MGDS +fluoroscopic +flurry/GMDS +flush/TRSDPBG +flushness/M +fluster/DSG +flute/SRDGMJ +fluter/M +fluting/M +flutist/MS +flutter/DRSG +flutterer/M +fluttery +flux/IMS +fluxed/A +fluxes/A +fluxing +fly/JGBDRSTZ +flyaway +flyblown +flyby/M +flybys +flycatcher/MS +flyer's +flyleaf/M +flyleaves +flyover/MS +flypaper/MS +flysheet/S +flyspeck/MDGS +flyswatter/S +flyway/MS +flyweight/MS +flywheel/MS +foal/MDSG +foam/MRDSG +foaminess/MS +foamy/RPT +fob/SM +fobbed +fobbing +focal/F +focally +foci/M +focus/SRDMBG +focused/AU +focuser/M +focuses/A +fodder/GDMS +foe/SM +foetid +fog/SM +fogbound +fogged/C +foggily +fogginess/MS +fogging/C +foggy/RPT +foghorn/SM +fogs/C +fogy/SM +fogyish +foible/MS +foil/GSD +foist/GDS +fol/Y +fold/RDJSGZ +foldable/U +foldaway/S +folded/AU +folder/M +foldout/MS +folds/UA +foliage/MSD +foliate/CSDXGN +foliation/CM +folio/SDMG +folk/MS +folklike +folklore/MS +folkloric +folklorist/SM +folksiness/MS +folksinger/S +folksinging/S +folksong/S +folksy/TPR +folktale/S +folkway/S +foll +follicle/SM +follicular +follow/JSZBGRD +follower/M +followup's +folly/SM +foment/RDSG +fomentation/SM +fomenter/M +fond/PMYRDGTS +fondant/SM +fondle/GSRD +fondler/M +fondness/MS +fondue/MS +font/MS +fontanel/MS +fontanelle's +food/MS +foodie/S +foodstuff/MS +fool/MDGS +foolery/MS +foolhardily +foolhardiness/SM +foolhardy/PTR +foolish/PRYT +foolishness/SM +foolproof +foolscap/MS +foot/SMRDGZJ +footage/SM +football/SRDMGZ +footbridge/SM +footer/M +footfall/SM +foothill/SM +foothold/MS +footing/M +footless +footlights +footling +footlocker/SM +footloose +footman/M +footmarks +footmen +footnote/MSDG +footpad/SM +footpath/M +footpaths +footplate/M +footprint/MS +footrace/S +footrest/MS +footsie/SM +footsore +footstep/SM +footstool/SM +footwear/M +footwork/SM +fop/MS +fopped +foppery/MS +fopping +foppish/YP +foppishness/SM +for/HT +forage/GSRDMZ +forager/M +foray/SGMRD +forayer/M +forbade +forbear/MRSG +forbearance/SM +forbearer/M +forbid/S +forbidden +forbidding/YPS +forbiddingness/M +forbore +forborne +force/SRDGM +forced/Y +forcefield/MS +forceful/PY +forcefulness/MS +forceps/M +forcer/M +forcible/P +forcibleness/M +forcibly +ford/SMDBG +fordable/U +fore/S +forearm/GSDM +forebear/MS +forebode/GJDS +foreboding/PYM +forebodingness/M +forecast/SZGR +forecaster/M +forecastle/MS +foreclose/GSD +foreclosure/MS +forecourt/SM +foredoom/SDG +forefather/SM +forefeet +forefinger/MS +forefoot/M +forefront/SM +foregoer/M +foregoing/S +foregone +foregos +foreground/MGDS +forehand/S +forehead/MS +foreign/PRYZS +foreigner/M +foreignness/SM +foreknew +foreknow/GS +foreknowledge/MS +foreknown +foreleg/MS +forelimb/MS +forelock/MDSG +foreman/M +foremast/SM +foremen +foremost +forename/DSM +forenoon/SM +forensic/S +forensically +forensics/M +foreordain/DSG +forepart/MS +forepaws +forepeople +foreperson/S +foreplay/MS +forequarter/SM +forerunner/MS +foresail/SM +foresaw +foresee/ZSRB +foreseeable/U +foreseeing +foreseen/U +foreseer/M +foreshadow/SGD +foreshore/M +foreshorten/DSG +foresight/SMD +foresighted/PY +foresightedness/SM +foreskin/SM +forest's +forest/CSAGD +forestall/LGSRD +forestaller/M +forestallment/M +forestation/MCS +forestations/A +forester/SM +forestland/S +forestry/MS +foretaste/MGSD +foretell/RGS +foreteller/M +forethought/MS +foretold +forever/PS +forevermore +forewarn/GSJRD +forewarner/M +forewent +forewoman/M +forewomen +foreword/SM +forfeit/ZGDRMS +forfeiter/M +forfeiture/MS +forfend/GSD +forgather/GSD +forgave +forge/JVGMZSRD +forged/A +forger/M +forgery/MS +forges/A +forget/SV +forgetful/PY +forgetfulness/SM +forgettable/U +forgettably/U +forgetting +forging/M +forgivable/U +forgivably/U +forgive/SRPBZG +forgiven +forgiveness/SM +forgiver/M +forgiving/UP +forgivingly +forgivingness/M +forgo/RSGZ +forgoer/M +forgoes +forgone +forgot +forgotten/U +fork/GSRDM +forkful/S +forklift/DMSG +forlorn/PTRY +forlornness/M +form's +form/CGSAFDI +formability/AM +formal/IY +formaldehyde/SM +formalin/M +formalism/SM +formalist/SM +formalistic +formality/SMI +formalization/SM +formalize/ZGSRD +formalized/U +formalizer/M +formalizes/I +formalness/M +formals +formant/MIS +format's +format/AVS +formate/MXGNSD +formation/AFSCIM +formative/SYP +formatively/I +formativeness/IM +formatted/UA +formatter's +formatter/A +formatters +formatting/A +formed/U +former/FSAI +formerly +formfitting +formic +formidable/P +formidableness/M +formidably +formless/PY +formlessness/MS +formula/SM +formulaic +formulate/AGNSDX +formulated/U +formulation/AM +formulator/SM +fornicate/GNXSD +fornication/M +fornicator/SM +forsake/SG +forsaken +forsook +forsooth +forswear/SG +forswore +forsworn +forsythia/MS +fort/SM +forte/MS +forthcome/JG +forthcoming/U +forthright/PYS +forthrightness/SM +forthwith +fortieths +fortification/MS +fortified/U +fortifier/SM +fortify/ADSG +fortiori +fortissimo/S +fortitude/SM +fortnight/MYS +fortnightly/S +fortress/GMSD +fortuitous/YP +fortuitousness/SM +fortuity/MS +fortunate/YUS +fortunateness/M +fortune/MGSD +fortuneteller/SM +fortunetelling/SM +forty/SRMH +forum/MS +forward/PTZSGDRY +forwarder/M +forwarding/M +forwardness/MS +forwent +fossil/MS +fossiliferous +fossilization/MS +fossilize/GSD +fossilized/U +foster/SRDG +fosterer/M +fought +foul/SYRDGTP +foulard/SM +foulmouth/D +foulness/MS +fouls/M +found/RDGZS +foundation/SM +foundational +founded/UF +founder's/F +founder/MDG +founding/F +foundling/MS +foundry/MS +founds/KF +fount/MS +fountain/SMDG +fountainhead/SM +four/SHM +fourfold +fourpence/M +fourpenny +fourposter/SM +fourscore/S +foursome/SM +foursquare +fourteen/SMRH +fourteener/M +fourteenths +fourth/Y +fourths +fovea/M +fowl/SGMRD +fowler/M +fowling/M +fox/MDSG +foxfire/SM +foxglove/SM +foxhole/SM +foxhound/SM +foxily +foxiness/MS +foxing/M +foxtail/M +foxtrot/MS +foxtrotted +foxtrotting +foxy/TRP +foyer/SM +fps +fr +fracas/SM +fractal/SM +fraction/ISMA +fractional/Y +fractionate/DNG +fractionation/M +fractioned +fractioning +fractious/PY +fractiousness/SM +fracture/MGDS +fragile/Y +fragility/MS +fragment/SDMG +fragmentarily +fragmentariness/M +fragmentary/P +fragmentation/MS +fragrance/SM +fragrant/Y +frail/STPYR +frailness/MS +frailty/MS +frame/SRDJGMZ +framed/U +framer/M +framework/SM +framing/M +franc/SM +franchise's +franchise/ESDG +franchisee/S +franchiser/SM +francium/MS +francophone/M +frangibility/SM +frangible +frank/SGTYRDP +franker/M +frankfurter/MS +frankincense/MS +franklin/M +frankness/MS +frantic/PY +frantically +franticness/M +frappeed +frappeing +frappes +frapp� +frat/MS +fraternal/Y +fraternity/MSF +fraternization/SM +fraternize/GZRSD +fraternizer/M +fraternizing/U +fratricidal +fratricide/MS +fraud's +fraud/CS +fraudsters +fraudulence/S +fraudulent/YP +fraught/SGD +fray's +fray/CSDG +frazzle/GDS +freak/SGDM +freakish/YP +freakishness/SM +freaky/RT +freckle/GMDS +freckly/RT +free/YTDRSP +freebase/GDS +freebie/MS +freeboot/ZR +freebooter/M +freeborn +freedman/M +freedmen +freedom/MS +freehand/D +freehanded/Y +freehold/ZSRM +freeholder/M +freeing/S +freelance/SRDGZM +freeload/SRDGZ +freeloader/M +freeman/M +freemasonry/M +freemen +freeness/M +freestanding +freestone/SM +freestyle/SM +freethinker/MS +freethinking/S +freeway/MS +freewheel/SRDMGZ +freewheeler/M +freewheeling/P +freewill +freezable +freeze/UGSA +freezer/SM +freezing/S +freight/ZGMDRS +freighter/M +frenetic/S +frenetically +frenzied/Y +frenzy/MDSG +freon/S +freq +frequency/ISM +frequent/IY +frequented/U +frequenter/MS +frequentest +frequenting +frequentness/M +frequents +fresco/DMG +frescoes +fresh/AZSRNDG +freshen/SZGDR +freshener/M +fresher/MA +freshest +freshet/SM +freshly +freshman/M +freshmen +freshness/MS +freshwater/SM +fret/S +fretboard +fretful/PY +fretfulness/MS +fretsaw/S +fretted +fretting +fretwork/MS +friable/P +friableness/M +friar/YMS +friary/MS +fricassee/MSD +fricasseeing +frication/M +fricative/MS +friction/MS +frictional/Y +frictionless/Y +fridge/SM +fried/A +friedcake/SM +friend/SGMYD +friendless/P +friendlessness/M +friendlies +friendlily +friendliness/USM +friendly/PUTR +friendship/MS +frier's +fries/M +frieze/SDGM +frig/S +frigate/SM +frigged +frigging/S +fright/GXMDNS +frighten/DG +frightening/Y +frightful/PY +frightfulness/MS +frigid/YP +frigidity/MS +frigidness/SM +frill/MDGS +frilly/RST +fringe's +fringe/IGSD +frippery/SM +frisk/RDGS +frisker/M +friskily +friskiness/SM +frisky/RTP +frisson/M +fritter/RDSG +fritterer/M +fritz/SM +frivolity/MS +frivolous/PY +frivolousness/SM +frizz/GYSD +frizzle/DSG +frizzly/RT +frizzy/RT +fro/HS +frock's +frock/SUDGC +frocking/M +frog/MS +frogged +frogging +frogman/M +frogmarched +frogmen +frolic/SM +frolicked +frolicker/SM +frolicking +frolicsome +from +frond/SM +front's +front/GSFRD +frontage/MS +frontal/SY +frontier/SM +frontiersman/M +frontiersmen +frontispiece/SM +frontrunner's +frontward/S +frosh/M +frost's +frost/CDSG +frostbit/G +frostbite/MS +frostbiting/M +frostbitten +frosted/U +frosteds +frostily +frostiness/SM +frosting/MS +frosty/PTR +froth/GMD +frothiness/SM +froths +frothy/TRP +froufrou/MS +froward/P +frowardness/MS +frown/RDSG +frowner/M +frowning/Y +frowzily +frowziness/SM +frowzy/RPT +froze/UA +frozen/YP +frozenness/M +fructify/GSD +fructose/MS +frugal/Y +frugality/SM +fruit/GMRDS +fruitcake/SM +fruiter/RM +fruiterer/M +fruitful/UYP +fruitfuller +fruitfullest +fruitfulness/MS +fruitiness/MS +fruition/SM +fruitless/YP +fruitlessness/MS +fruity/RPT +frump/MS +frumpish +frumpy/TR +frustrate/RSDXNG +frustrater/M +frustrating/Y +frustration/M +frustum/SM +fry/NGDS +fryer/MS +ft/C +fuchsia/MS +fuck/GZJRDMS! +fucker/M! +fuddle/GSD +fudge/GMSD +fuel's +fuel/ASDG +fueler/SM +fugal +fugitive/SYMP +fugitiveness/M +fugue/GMSD +fuhrer/S +fulcrum/SM +fulfill/GLSRD +fulfilled/U +fulfiller/M +fulfillment/MS +full/RDPSGZT +fullback/SMG +fuller/DMG +fullish +fullness/MS +fullstops +fullword/SM +fully +fulminate/XSDGN +fulmination/M +fulness's +fulsome/PY +fulsomeness/SM +fumble/GZRSD +fumbler/M +fumbling/Y +fume/DSG +fumigant/MS +fumigate/NGSDX +fumigation/M +fumigator/SM +fuming/Y +fumy/TR +fun/MS +function/GSMD +functional/YS +functionalism/M +functionalist/SM +functionality/S +functionary/MS +functor/SM +fund/ASMRDZG +fundamental/SY +fundamentalism/SM +fundamentalist/SM +funded/U +fundholders +fundholding +funding/S +funeral/MS +funerary +funereal/Y +funfair/M +fungal/S +fungi/M +fungible/M +fungicidal +fungicide/SM +fungoid/S +fungous +fungus/M +funicular/SM +funk/GSDM +funkiness/S +funky/RTP +funned +funnel/SGMD +funner +funnest +funnily/U +funniness/SM +funning +funny/RSPT +fur/PMS +furbelow/MDSG +furbish/GDRSA +furbisher/M +furious/RYP +furiousness/M +furl/UDGS +furlong/MS +furlough/DGM +furloughs +furn +furnace/GMSD +furnish/GASD +furnished/U +furnisher/MS +furnishing/SM +furniture/SM +furor/MS +furore/MS +furred +furrier/M +furriness/SM +furring/SM +furrow/DMGS +furry/RTZP +further/TGDRS +furtherance/MS +furtherer/M +furthermore +furthermost +furthest +furtive/PY +furtiveness/SM +fury/SM +furze/SM +fuse's/A +fuse/FSDAGCI +fusebox/S +fusee/SM +fuselage/SM +fusibility/SM +fusible/I +fusiform +fusilier/MS +fusillade/SDMG +fusion/KMFSI +fuss/SRDMG +fussbudget/MS +fusser/M +fussily +fussiness/MS +fusspot/SM +fussy/PTR +fustian/MS +fustiness/MS +fusty/RPT +fut +futile/PY +futileness/M +futility/MS +futon/S +future/SM +futurism/SM +futurist/S +futuristic/S +futurity/MS +futurologist/S +futurology/MS +futz/GSD +fuze's +fuzz/SDMG +fuzzily +fuzziness/SM +fuzzy/PRT +fwd +fwy +f�te/MS +g's +g/VBX +gab/S +gabardine/SM +gabbed +gabbiness/S +gabbing +gabble/SDG +gabby/TRP +gaberdine's +gabfest/MS +gable/GMSRD +gad/S +gadabout/MS +gadded +gadder/MS +gadding +gadfly/MS +gadget/SM +gadgetry/MS +gadolinium/MS +gaff/SGZRDM +gaffe/MS +gaffer/M +gag/DRSG +gaga +gage/SM +gager/M +gagged +gagging +gaggle/SDG +gagwriter/S +gaiety/MS +gaily +gain/ADGS +gainer/SM +gainful/YP +gainfulness/M +gaining/S +gainly/U +gainsaid +gainsay/RSZG +gainsayer/M +gait/GSZMRD +gaiter/M +gal's +gal/AS +gala/SM +galactic +galaxy/MS +gale's +gale/AS +galen +galena/MS +galenite/M +gall/SGMD +gallant/UY +gallanted +gallanting +gallantry/MS +gallants +gallbladder/MS +galleon/SM +galleria/S +gallery/MSDG +galley/MS +gallimaufry/MS +galling/Y +gallium/SM +gallivant/GDS +gallon/SM +gallonage/M +gallop/GSRDZ +galloper/M +gallows/M +gallstone/MS +galoot/MS +galore/S +galosh/GMSD +galumph/GD +galumphs +galvanic +galvanism/MS +galvanization/SM +galvanize/SDG +galvanometer/SM +galvanometric +gambit/MS +gamble/GZRSD +gambler/M +gambol/SGD +game/PJDRSMYTZG +gamecock/SM +gamekeeper/MS +gameness/MS +gamesmanship/SM +gamesmen +gamest/RZ +gamester/M +gamete/MS +gametic +gamin/MS +gamine/SM +gaminess/MS +gaming/M +gamma/MS +gammon/DMSG +gamut/MS +gamy/TRP +gander/DMGS +gang/GRDMS +gangbusters +ganger/M +gangland/SM +ganglia/M +gangling +ganglion/M +ganglionic +gangplank/SM +gangrene/SDMG +gangrenous +gangster/SM +gangway/MS +gannet/SM +gantlet/GMDS +gantry/MS +gaol/MRDGZS +gaoler/M +gap/SJMDRG +gape/S +gaper/M +gaping/Y +gapped +gapping +gar/SLM +garage/GMSD +garb/DMGS +garbage/SDMG +garbageman/M +garbanzo/MS +garble/RSDG +garbler/M +garden/ZGRDMS +gardener/M +gardenia/SM +gardening/M +garfish/MS +gargantuan +gargle/SDG +gargoyle/DSM +garish/YP +garishness/MS +garland/SMDG +garlic/SM +garlicked +garlicking +garlicky +garment/MDGS +garner/SGD +garnet/SM +garnish/DSLG +garnishee/SDM +garnisheeing +garnishment/MS +garote's +garotte's +garred +garret/SM +garring +garrison/SGMD +garrote/SRDMZG +garroter/M +garrotte's +garrulity/SM +garrulous/PY +garrulousness/MS +garter/SGDM +gar�on/SM +gas's +gas/FC +gasbag/MS +gaseous/YP +gaseousness/M +gases/C +gash/GTMSRD +gasification/M +gasifier/M +gasify/SRDGXZN +gasket/SM +gaslight/DMS +gasohol/S +gasoline/MS +gasometer/M +gasp/GZSRD +gasper/M +gasping/Y +gassed/C +gasser/MS +gassiness/M +gassing/SM +gassy/PTR +gastric +gastritides +gastritis/MS +gastroenteritides +gastroenteritis/M +gastrointestinal +gastronome/SM +gastronomic +gastronomical/Y +gastronomy/MS +gastropod/SM +gasworks/M +gate/MGDS +gateau/MS +gateaux +gatecrash/GZSRD +gatehouse/MS +gatekeeper/SM +gatepost/SM +gateway/MS +gather/JRDZGS +gathered/IA +gatherer/M +gathering/M +gathers/A +gator/MS +gauche/TYPR +gaucheness/SM +gaucherie/SM +gaucho/SM +gaudily +gaudiness/MS +gaudy/PRST +gauge/SM +gaugeable +gauger/M +gaunt/PYRDSGT +gauntlet/GSDM +gauntness/MS +gauss's +gauss/C +gausses +gauze/SDGM +gauziness/MS +gauzy/TRP +gave +gavel/GMDS +gavotte/MSDG +gawk/SGRDM +gawkily +gawkiness/MS +gawky/RSPT +gay/RTPS +gayety's +gayness/SM +gaze/DRSZG +gazebo/SM +gazelle/MS +gazer/M +gazette/MGSD +gazetteer/SGDM +gazillion/S +gazpacho/MS +gear/DMJSG +gearbox/SM +gearing/M +gearshift/MS +gearstick +gearwheel/SM +gecko/MS +gee/TDS +geegaw's +geeing +geek/SM +geeky/RT +geese/M +geest/M +geezer/MS +geisha/M +gel/MBS +gelatin/SM +gelatinous/PY +gelatinousness/M +gelcap +geld/JSGD +gelding/M +gelid +gelignite/MS +gelled +gelling +gem/MS +gemlike +gemmed +gemming +gemological +gemologist/MS +gemology/MS +gemstone/SM +gen +gendarme/MS +gender/DMGS +genderless +gene/MS +genealogical/Y +genealogist/SM +genealogy/MS +genera/M +general/MSPY +generalissimo/SM +generalist/MS +generality/MS +generalizable/SM +generalization/MS +generalize/GZBSRD +generalized/U +generalizer/M +generalness/M +generalship/SM +generate/CXAVNGSD +generation/MCA +generational +generative/AY +generator/SM +generators/A +generic/PS +generically +generosity/MS +generous/PY +generously/U +generousness/SM +genes/S +genesis/M +genetic/S +genetically +geneticist/MS +genetics/M +genial/PY +geniality/FMS +genially/F +genialness/M +genie/SM +genies/K +genii/M +genital/YF +genitalia +genitals +genitive/SM +genitourinary +genius/SM +genocidal +genocide/SM +genome/SM +genotype/MS +genre/MS +gent/AMS +genteel/PRYT +genteelness/MS +gentian/SM +gentile/S +gentility/MS +gentle/PRSDGT +gentlefolk/S +gentleman/YM +gentlemanliness/M +gentlemanly/U +gentlemen +gentleness/SM +gentlewoman/M +gentlewomen/M +gently +gentrification/M +gentrify/NSDGX +gentry/MS +genuflect/GDS +genuflection/MS +genuine/PY +genuineness/SM +genus +geocentric +geocentrically +geocentricism +geochemical/Y +geochemistry/MS +geochronology/M +geode/SM +geodesic/S +geodesy/MS +geodetic/S +geog +geographer/MS +geographic +geographical/Y +geography/MS +geologic +geological/Y +geologist/MS +geology/MS +geom +geomagnetic +geomagnetically +geomagnetism/SM +geometer/MS +geometric/S +geometrical/Y +geometrician/M +geometry/MS +geomorphological +geomorphology/M +geophysical/Y +geophysicist/MS +geophysics/M +geopolitic/S +geopolitical/Y +geopolitics/M +geostationary +geosynchronous +geosyncline/SM +geothermal +geothermic +geranium/SM +gerbil/MS +geriatric/S +geriatrics/M +germ/MNS +germane +germanium/SM +germanized +germen/M +germicidal +germicide/MS +germinal/Y +germinate/XVGNSD +germinated/U +germination/M +germinative/Y +gerontocracy/M +gerontological +gerontologist/SM +gerontology/SM +gerrymander/SGD +gerund/SVM +gerundive/M +gestalt/M +gestapo/S +gestate/SDGNX +gestation/M +gestational +gesticulate/XSDVGN +gesticulation/M +gesticulative/Y +gestural +gesture/SDMG +gesundheit +get/S +getaway/SM +getter/SDM +getting +getup/MS +gewgaw/MS +geyser/GDMS +ghastliness/MS +ghastly/TPR +ghat/MS +gherkin/SM +ghetto/DGMS +ghettoize/SDG +ghost/SMYDG +ghostlike +ghostliness/MS +ghostly/TRP +ghostwrite/RSGZ +ghostwritten +ghostwrote +ghoul/SM +ghoulish/PY +ghoulishness/SM +giant/SM +giantess/MS +giantkiller +gibber/DGS +gibberish/MS +gibbet/MDSG +gibbon/MS +gibbous/YP +gibbousness/M +gibe/GDRS +giber/M +giblet/MS +giddap +giddily +giddiness/SM +giddy/GPRSDT +gift/SGMD +gifted/PY +giftedness/M +gig/MS +gigabyte/S +gigacycle/MS +gigahertz/M +gigantic/P +gigantically +giganticness/M +gigavolt +gigawatt/M +gigged +gigging +giggle/RSDGZ +giggler/M +giggling/Y +giggly/TR +gigolo/MS +gila +gilbert/M +gild/JSGZRD +gilder/M +gilding/M +gill/SGMRD +gilt/S +gimbaled +gimbals +gimcrack/S +gimcrackery/SM +gimlet/MDSG +gimme/S +gimmick/GDMS +gimmickry/MS +gimmicky +gimp/GSMD +gimpy/RT +gin/MS +ginger/SGDYM +gingerbread/SM +gingerliness/M +gingerly/P +gingersnap/SM +gingery +gingham/SM +gingivitis/SM +ginkgo/M +ginkgoes +ginmill +ginned +ginning +ginseng/SM +giraffe/MS +gird/RDSGZ +girded/U +girder/M +girdle/GMRSD +girdler/M +girl/MS +girlfriend/MS +girlhood/SM +girlie/M +girlish/YP +girlishness/SM +giro/M +girt/GDS +girth/MDG +girths +gist/MS +git/M +give/HZGRS +giveaway/SM +giveback/S +given/SP +giver/M +giving/Y +gizmo's +gizzard/SM +glacial/Y +glaciate/XNGDS +glaciation/M +glacier/SM +glaciological +glaciologist/M +glaciology/M +glac�/DGS +glad/YSP +gladded +gladden/GDS +gladder +gladdest +gladding +gladdy +glade/SM +gladiator/SM +gladiatorial +gladiola/MS +gladioli +gladiolus/M +gladly/RT +gladness/MS +gladsome/RT +glamor/DMGS +glamorization/MS +glamorize/SRDZG +glamorizer/M +glamorous/PY +glamorousness/M +glance/GJSD +glancing/Y +gland/ZSM +glanders/M +glandes +glandular/Y +glans/M +glare/SDG +glaring/YP +glaringness/M +glasnost/S +glass/GSDM +glassblower/S +glassblowing/MS +glassful/MS +glasshouse/SM +glassily +glassiness/SM +glassless +glassware/SM +glasswort/M +glassy/PRST +glaucoma/SM +glaucous +glaze/SRDGZJ +glazed/U +glazer/M +glazier/SM +glazing/M +gleam/MDGS +glean/RDGZJS +gleaner/M +gleaning/M +glee/DSM +gleed/M +gleeful/YP +gleefulness/MS +gleeing +glen/SM +glib/YP +glibber +glibbest +glibness/MS +glide/JGZSRD +glider/M +glim/M +glimmer/DSJG +glimmering/M +glimpse/DRSZMG +glimpser/M +glint/DSG +glissandi +glissando/M +glisten/DSG +glister/DGS +glitch/MS +glitter/GDSJ +glittering/Y +glittery +glitz/GSD +glitzy/TR +gloaming/MS +gloat/SRDG +gloater/M +gloating/Y +glob/GDMS +global/SY +globalism/S +globalist/S +globe/SM +globetrotter/MS +globular/PY +globularity/M +globularness/M +globule/MS +globulin/MS +glockenspiel/SM +glommed +gloom/GSMD +gloomily +gloominess/MS +gloomy/RTP +glop/MS +glopped +glopping +gloppy/TR +glorification/M +glorifier/M +glorify/XZRSDNG +glorious/IYP +gloriousness/IM +glory/SDMG +gloss/GSDM +glossary/MS +glossily +glossiness/SM +glossolalia/SM +glossy/RSPT +glottal +glottalization/M +glottis/MS +glove/SRDGMZ +gloveless +glover/M +glow/GZRDMS +glower/GD +glowing/Y +glowworm/SM +glucose/SM +glue/DRSMZG +glued/U +gluer/M +gluey +gluier +gluiest +glum/SYP +glummer +glummest +glumness/MS +gluon/M +glut/SMNX +glutamate/M +gluten/M +glutenous +glutinous/PY +glutinousness/M +glutted +glutting +glutton/MS +gluttonous/Y +gluttony/SM +glyceride/M +glycerin/SM +glycerinate/MD +glycerine's +glycerol/SM +glycerolized/C +glycine/M +glycogen/SM +glycol/MS +glyph/M +glyphs +gm +gnarl/SMDG +gnash/SDG +gnat/MS +gnaw/GRDSJ +gnawer/M +gnawing/M +gneiss/SM +gnome/SM +gnomelike +gnomic +gnomish +gnomonic +gnostic/K +gnosticism +gnu/MS +go/MRHZGJ +goad/MDSG +goal/MDSG +goalie/SM +goalkeeper/MS +goalkeeping/M +goalless +goalmouth/M +goalpost/S +goalscorer +goalscoring +goaltender/SM +goat/MS +goatee/SM +goatherd/MS +goatskin/SM +gob/SM +gobbed +gobbet/MS +gobbing +gobble/SRDGZ +gobbledegook's +gobbledygook/S +gobbler/M +goblet/MS +goblin/SM +god/SMY +godchild/M +godchildren +goddammit +goddamn/GS +goddaughter/SM +godded +goddess/MS +godding +godfather/GSDM +godforsaken +godhead/S +godhood/SM +godless/P +godlessness/MS +godlike/P +godlikeness/M +godliness/UMS +godly/UTPR +godmother/MS +godparent/SM +godsend/MS +godson/MS +goer/MG +goes +gofer/SM +goggle/SRDGZ +goggler/M +going/M +goiter/SM +gold/MRNGTS +goldbrick/GZRDMS +goldbricker/M +golden/TRYP +goldenness/M +goldenrod/SM +goldenseal/M +goldfinch/MS +goldfish/SM +goldmine/S +goldsmith/M +goldsmiths +golf/RDMGZS +golfer/M +golly/S +gonad/SM +gonadal +gondola/SM +gondolier/MS +gone/RZN +goner/M +gong/SGDM +gonion/M +gonna +gonorrhea/MS +gonorrheal +goo/MS +goober/MS +good/SYP +goodbye/MS +goodhearted +goodie's +goodish +goodly/TR +goodness/MS +goodnight +goodwill/MS +goody/SM +gooey +goof/SDMG +goofiness/MS +goofy/RPT +gooier +gooiest +gook/SM +goon/SM +goop/SM +goos/SDG +goose/M +gooseberry/MS +goosebumps +gopher/SM +gore/DSMG +gorge/GMSRD +gorged/E +gorgeous/YP +gorgeousness/SM +gorger/EM +gorges/E +gorging/E +gorgon/S +gorilla/MS +gorily +goriness/MS +goring/M +gormandize/SRDGZ +gormandizer/M +gormless +gorp/S +gorse/SM +gory/PRT +gos +gosh/S +goshawk/MS +gosling/M +gospel/MRSZ +gospeler/M +gossamer/SM +gossip/ZGMRDS +gossipy +got/IU +gotcha/SM +goto +gotta +gotten/U +gouge/GZSRD +gouger/M +goulash/SM +gourd/MS +gourde/SM +gourmand/MS +gourmet/MS +gout/SM +gouty/RT +gov/S +govern/LBGSD +governable/U +governance/SM +governed/U +governess/SM +government/MS +governmental/Y +governor/MS +governorship/SM +govt +gown/GSDM +gr +grab/S +grabbed +grabber/SM +grabbing/S +grace/ESDMG +graceful/EYPU +gracefuller +gracefullest +gracefulness/ESM +graceless/PY +gracelessness/MS +gracious/UY +graciousness/SM +grackle/SM +grad/MRDGZJS +gradate/DSNGX +gradation/MCS +grade's +grade/ACSDG +graded/U +gradely +grader/MC +gradient/RMS +gradual/SYP +gradualism/MS +gradualist/MS +gradualness/MS +graduand/SM +graduate/MNGDSX +graduation/M +graffiti +graffito/M +graft/MRDSGZ +grafter/M +grafting/M +graham/SM +grail/S +grain's +grain/IGSD +grainer/M +graininess/MS +graining/M +grainy/RTP +gram/KSM +grammar/MS +grammarian/SM +grammatic/K +grammatical/UY +grammaticality/M +grammaticalness/M +gramme/SM +gramophone/SM +grampus/SM +granary/MS +grand/TPSYR +grandam/SM +grandaunt/MS +grandchild/M +grandchildren +granddad/SM +granddaddy/MS +granddaughter/MS +grandee/SM +grandeur/MS +grandfather/MYDSG +grandiloquence/SM +grandiloquent/Y +grandiose/YP +grandiosity/MS +grandkid/SM +grandma/MS +grandmaster/MS +grandmother/MYS +grandnephew/MS +grandness/MS +grandniece/SM +grandpa/MS +grandparent/MS +grandson/MS +grandstand/SRDMG +grandstander/M +granduncle/MS +grange/MSR +granite/MS +granitic +granny/MS +granola/S +grant/SGZMRD +grantee/MS +granter/M +grantor's +grantsmanship/S +granular/Y +granularity/SM +granulate/SDXVGN +granulation/M +granule/SM +granulocytic +grape/SDGM +grapefruit/SM +grapeshot/M +grapevine/MS +graph/GMD +grapheme/M +graphic/PS +graphical/Y +graphicness/M +graphics/M +graphite/SM +graphologist/SM +graphology/MS +graphs +grapnel/SM +grapple/DRSG +grappler/M +grappling/M +grasp/SRDBG +grasper/M +grasping/PY +graspingness/M +grass/GZSDM +grasshopper/SM +grassland/MS +grassroots +grassy/RT +grate/SRDJGZ +grateful/YPU +gratefuller +gratefullest +gratefulness/USM +grater/M +grates/I +graticule/M +gratification/M +gratified/U +gratify/NDSXG +gratifying/Y +grating/YM +gratis +gratitude/IMS +gratuitous/PY +gratuitousness/MS +gratuity/SM +gravamen/SM +grave/SRDPGMZTY +gravedigger/SM +gravel/SGMYD +graven +graveness/MS +graver/M +graveside/S +gravestone/SM +graveyard/MS +gravid/PY +gravidness/M +gravimeter/SM +gravimetric +gravitas +gravitate/XVGNSD +gravitation/M +gravitational/Y +graviton/SM +gravity/MS +gravy/SM +gray/PYRDGTS +graybeard/MS +grayish +grayness/S +graze/GZSRD +grazer/M +grazing/M +grease/GMZSRD +greasepaint/MS +greaseproof +greaser/M +greasily +greasiness/SM +greasy/PRT +great/SPTYRN +greatcoat/DMS +greaten/DG +greathearted +greatness/MS +grebe/MS +greed's +greed/C +greedily +greediness/SM +greeds +greedy/RTP +green/SYRDMPGT +greenback/MS +greenbelt/S +greenery/MS +greenfield +greenfly/M +greengage/SM +greengrocer/SM +greengrocery/M +greenhorn/SM +greenhouse/SM +greening/M +greenish/P +greenmail/GDS +greenness/MS +greenroom/SM +greensward/SM +greenwood/MS +greet/SRDJGZ +greeter/M +greeting/M +greets/A +gregarious/PY +gregariousness/MS +gremlin/SM +grenade/MS +grenadier/SM +grenadine/SM +grew/A +greybeard/M +greyhound/MS +greyness/M +grid/SGM +gridded +griddle/DSGM +griddlecake/SM +gridiron/GSMD +gridlock/DSG +grids/A +grief/MS +grievance/SM +grieve/SRDGZ +griever/M +grieving/Y +grievous/PY +grievousness/SM +griffin/SM +griffon's +grill/RDGS +grille/SM +griller/M +grillwork/M +grim/PGYD +grimace/DRSGM +grimacer/M +grime/MS +griminess/MS +grimmer +grimmest +grimness/MS +grimy/TPR +grin/S +grind/ASG +grinder/MS +grinding/SY +grindstone/SM +gringo/SM +grinned +grinner/M +grinning/Y +grip/SGZMRD +gripe/S +griper/M +grippe/GMZSRD +gripper/M +gripping/Y +grisliness/SM +grisly/RPT +grist/MYS +gristle/SM +gristliness/M +gristly/TRP +gristmill/MS +grit/MS +gritted +gritter/MS +grittiness/SM +gritting +gritty/PRT +grizzle/DSG +grizzling/M +grizzly/TRS +groan/GZSRDM +groaner/M +groat/SM +grocer/MS +grocery/MS +grog/MS +groggily +grogginess/SM +groggy/RPT +groin/MGSD +grok/S +grokked +grokking +grommet/GMDS +groofs +groom/GZSMRD +groomer/M +groomsman/M +groomsmen +groove/SRDGM +groover/M +groovy/TR +grope/SRDJGZ +groper/M +grosbeak/SM +grosgrain/MS +gross/GTYSRDP +grossness/MS +grotesque/PSY +grotesqueness/MS +grotto/M +grottoes +grouch/GDS +grouchily +grouchiness/MS +grouchy/RPT +ground/JGZMDRS +groundbreaking/S +grounded/U +grounder/M +groundhog/SM +groundless/YP +groundlessness/M +groundnut/MS +groundsheet/M +groundskeepers +groundsman/M +groundswell/S +groundwater/S +groundwork/SM +group/ZJSMRDG +grouped/A +grouper/M +groupie/MS +grouping/M +groups/A +grouse/GMZSRD +grouser/M +grout/GSMRD +grouter/M +grove/SRMZ +grovel/SDRGZ +groveler/M +grovelike +groveling/Y +grow/GZYRHS +grower/M +growing/I +growingly +growl/RDGZS +growler/M +growling/Y +growly/RP +grown/IA +grownup/MS +grows/A +growth/IMA +growths/IA +grub/MS +grubbed +grubber/SM +grubbily +grubbiness/SM +grubbing +grubby/RTP +grubstake/MSDG +grudge/GMSRDJ +grudger/M +grudging/Y +gruel/MDGJS +grueling/Y +gruesome/RYTP +gruesomeness/SM +gruff/PSGTYRD +gruffness/MS +grumble/GZJDSR +grumbler/M +grumbling/Y +grump/MDGS +grumpily +grumpiness/MS +grumpy/TPR +grunge/S +grungy/RT +grunion/SM +grunt/SGRD +grunter/M +gryphon's +gs/A +gt +guacamole/MS +guanine/MS +guano/MS +guarani/SM +guarantee/RSDZM +guaranteeing +guarantor/SM +guaranty/MSDG +guard/RDSGZ +guarded/UYP +guardedness/UM +guarder/M +guardhouse/SM +guardian/SM +guardianship/MS +guardrail/SM +guardroom/SM +guardsman/M +guardsmen +guava/SM +gubernatorial +gudgeon/M +guernsey/S +guerrilla/MS +guess/BGZRSD +guessable/U +guessed/U +guesser/M +guesstimate/DSMG +guesswork/MS +guest/SGMD +guff/SM +guffaw/GSDM +guidance/MS +guide/GZSRD +guidebook/SM +guided/U +guideline/SM +guidepost/MS +guider/M +guild/SZMR +guilder/M +guildhall/SM +guile/SDGM +guileful +guileless/YP +guilelessness/MS +guillemot/MS +guillotine/SDGM +guilt/SM +guiltily +guiltiness/MS +guiltless/YP +guiltlessness/M +guilty/PTR +guinea/SM +guise's +guise/SDEG +guitar/SM +guitarist/SM +gulag/S +gulch/MS +gulden/MS +gulf/DMGS +gull/MDSG +gullet/MS +gulley's +gullibility/MS +gullible +gully/SDMG +gulp/RDGZS +gum/MS +gumbo/MS +gumboil/MS +gumboots +gumdrop/SM +gummed +gumminess/M +gumming/C +gummy/RTP +gumption/SM +gumshoe/SDM +gumshoeing +gumtree/MS +gun/MS +gunboat/MS +gunfight/SRMGZ +gunfighter/M +gunfire/SM +gunflint/M +gunfought +gunk/SM +gunky/RT +gunman/M +gunmen +gunmetal/MS +gunned +gunnel's +gunner/SM +gunnery/MS +gunning/M +gunny/SM +gunnysack/SM +gunpoint/MS +gunpowder/SM +gunrunner/MS +gunrunning/MS +gunship/S +gunshot/SM +gunsling/GZR +gunslinger/M +gunsmith/M +gunsmiths +gunwale/MS +guppy/SM +gurgle/SDG +gurney/S +guru/MS +gush/SRDGZ +gusher/M +gushy/TR +gusset/MDSG +gussy/GSD +gust/MDGS +gustatory +gusted/E +gustily +gustiness/M +gusting/E +gusto/M +gustoes +gusts/E +gusty/RPT +gut/SM +gutless/P +gutlessness/S +guts/R +gutser/M +gutsiness/M +gutsy/PTR +gutted +gutter/GSDM +guttering/M +guttersnipe/M +gutting +guttural/SPY +gutturalness/M +gutty/RSMT +guy/MDRZGS +guzzle/GZRSD +guzzler/M +gym/MS +gymkhana/SM +gymnasia's +gymnasium/SM +gymnast/SM +gymnastic/S +gymnastically +gymnastics/M +gymnosperm/SM +gynecologic +gynecological/MS +gynecologist/SM +gynecology/MS +gyp/S +gypped +gypper/S +gypping +gypsite +gypster/S +gypsum/MS +gypsy/SDMG +gyrate/XNGSD +gyration/M +gyrator/MS +gyrfalcon/SM +gyro/MS +gyrocompass/M +gyroscope/SM +gyroscopic +gyve/GDS +h'm +h's +h/EMS +ha/H +habeas +haberdasher/SM +haberdashery/SM +habiliment/SM +habit's +habit/IBDGS +habitability/MS +habitable/P +habitableness/M +habitant/ISM +habitat/MS +habitation/MI +habitations +habitual/SYP +habitualness/SM +habituate/SDNGX +habituation/M +habitu�/MS +hacienda/MS +hack/GZSDRBJ +hacker/M +hackle/RSDMG +hackler/M +hackney/SMDG +hacksaw/SDMG +hackwork/S +had/GD +haddock/MS +hades +hadj's +hadji's +hadn't +hadron/MS +hadst +haemoglobin's +haemophilia's +haemorrhage's +hafnium/MS +haft/GSMD +hag/SMN +haggard/SYP +haggardness/MS +hagged +hagging +haggis/SM +haggish +haggle/RSDZG +haggler/M +hagiographer/SM +hagiography/MS +hahnium/S +haiku/M +hail/SGMDR +hailer/M +hailstone/SM +hailstorm/SM +hair/SDM +hairball/SM +hairbreadth/M +hairbreadths +hairbrush/SM +haircare +haircloth/M +haircloths +haircut/MS +haircutting +hairdo/SM +hairdresser/SM +hairdressing/SM +hairdryer/S +hairiness/MS +hairless/P +hairlessness/M +hairlike +hairline/SM +hairnet/MS +hairpiece/MS +hairpin/MS +hairsbreadth +hairsbreadths +hairsplitter/SM +hairsplitting/MS +hairspray +hairspring/SM +hairstyle/SMG +hairstylist/S +hairy/PTR +hajj/M +hajjes +hajji/MS +hake/MS +halal/S +halalled +halalling +halberd/SM +halcyon/S +hale/ISRDG +haler/IM +halest +half/PM +halfback/SM +halfbreed +halfhearted/PY +halfheartedness/MS +halfpence/S +halfpenny/MS +halfpennyworth +halftime/S +halftone/MS +halfway +halfword/MS +halibut/SM +halide/SM +halite/MS +halitoses +halitosis/M +hall/SMR +hallelujah +hallelujahs +halliard's +hallmark/SGMD +hallo/GDS +halloo's +hallow/UD +hallowing +hallows +hallucinate/VNGSDX +hallucination/M +hallucinatory +hallucinogen/SM +hallucinogenic/S +hallway/SM +halo/SDMG +halocarbon +halogen/SM +halogenated +halon +halt/GZJSMDR +halter/GDM +halting/Y +halve/GZDS +halves/M +halyard/MS +ham/SM +hamburg/SZRM +hamburger/M +hamlet/MS +hammed +hammer/ZGSRDM +hammerer/M +hammerhead/SM +hammering/M +hammerless +hammerlock/MS +hammertoe/SM +hamming +hammock/MS +hammy/RT +hamper/GSD +hampered/U +hamster/MS +hamstring/MGS +hamstrung +hand's +hand/UDSG +handbag/MS +handbagged +handbagging +handball/SM +handbarrow/MS +handbasin +handbill/MS +handbook/SM +handbrake/M +handcar/SM +handcart/MS +handclasp/MS +handcraft/GMDS +handcuff/GSD +handcuffs/M +handed/PY +handedness/M +hander/S +handful/SM +handgun/SM +handhold/M +handicap/SM +handicapped +handicapper/SM +handicapping +handicraft/SMR +handicraftsman/M +handicraftsmen +handily/U +handiness/SM +handiwork/MS +handkerchief/MS +handle/MZGRSD +handleable +handlebar/SM +handler/M +handless +handling/M +handmade +handmaid/NMSX +handmaiden/M +handout/SM +handover +handpick/GDS +handrail/SM +handsaw/SM +handset/SM +handshake/GMSR +handshaker/M +handshaking/M +handsome/RPTY +handsomely/U +handsomeness/MS +handspike/SM +handspring/SM +handstand/MS +handwork/SM +handwoven +handwrite/GSJ +handwriting/M +handwritten +handy/URT +handyman/M +handymen +hang/GDRZBSJ +hangar/SGDM +hangdog/S +hanged/A +hanger/M +hanging/M +hangman/M +hangmen +hangnail/MS +hangout/MS +hangover/SM +hangs/A +hangup/S +hank/GZDRMS +hanker/GRDJ +hankerer/M +hankering/M +hankie/SM +hanky's +hansom/MS +hap/SMY +haphazard/SPY +haphazardness/SM +hapless/YP +haplessness/MS +haploid/S +happed +happen/JDGS +happening/M +happenstance/SM +happily/U +happiness/UMS +happing +happy/UTPR +harangue/GDRS +haranguer/M +harass/LSRDZG +harasser/M +harassment/SM +harbinger/DMSG +harbor/ZGRDMS +harborer/M +hard/YNRPJGXTS +hardback/SM +hardball/SM +hardboard/SM +hardboiled +hardbound +hardcore/MS +hardcover/SM +harden/ZGRD +hardened/U +hardener/M +hardening/M +hardhat/S +hardheaded/YP +hardheadedness/SM +hardhearted/YP +hardheartedness/SM +hardihood/MS +hardily +hardiness/SM +hardliner/S +hardness/MS +hardscrabble +hardshell +hardship/MS +hardstand/S +hardtack/MS +hardtop/MS +hardware/SM +hardwire/DSG +hardwood/MS +hardworking +hardy/PTRS +hare/MGDS +harebell/MS +harebrained +harelip/MS +harelipped +harem/SM +hark/GDS +harlequin/MS +harlot/SM +harlotry/MS +harm/MDRGS +harmed/U +harmer/M +harmful/PY +harmfulness/MS +harmless/YP +harmlessness/SM +harmonic/S +harmonica/MS +harmonically +harmonics/M +harmonious/IPY +harmoniousness's/I +harmoniousness/MS +harmonium/MS +harmonization's +harmonization/A +harmonizations +harmonize/ZGSRD +harmonized/U +harmonizer/M +harmonizes/UA +harmony/EMS +harness/DRSMG +harnessed/U +harnesser/M +harnesses/U +harp/MDRJGZS +harper/M +harping/M +harpist/SM +harpoon/SZGDRM +harpooner/M +harpsichord/SM +harpsichordist/MS +harpy/SM +harridan/SM +harrier/M +harrow/RDMGS +harrower/M +harrumph/SDG +harry/RSDGZ +harsh/TRNYP +harshen/GD +harshness/SM +hart/MS +harvest/MDRZGS +harvested/U +harvester/M +harvestman/M +has +hash's +hash/AGSD +hasher/M +hashing/M +hashish/MS +hasn't +hasp/GMDS +hassle/MGRSD +hassock/MS +hast/GXJDN +haste/MS +hasten/GRD +hastener/M +hastily +hastiness/MS +hasty/RPT +hat/MDRSZG +hatch/RSDJG +hatchback/SM +hatcheck/S +hatched/U +hatcher/M +hatchery/MS +hatchet/MDSG +hatching/M +hatchway/MS +hate/S +hateful/YP +hatefulness/MS +hater/M +hatless +hatred/SM +hatstands +hatted +hatter/SM +hatting +hauberk/SM +haughtily +haughtiness/SM +haughty/TPR +haul/SDRGZ +haulage/MS +hauler/M +haunch/GMSD +haunt/JRDSZG +haunter/M +haunting/Y +hauteur/MS +have/ZGSR +haven't +haven/DMGS +haver/G +haversack/SM +havoc/SM +havocked +havocking +haw/MDSG +hawk/GZSDRM +hawker/M +hawking/M +hawkish/P +hawkishness/S +haws/RZ +hawser/M +hawthorn/MS +hay/GSMDR +haycock/SM +hayfield/MS +hayloft/MS +haymow/MS +hayrick/MS +hayride/MS +hayseed/MS +haystack/SM +haywain +haywire/MS +hazard/MDGS +hazardous/PY +hazardousness/M +haze/DSRJMZG +hazel/MS +hazelnut/SM +hazer/M +hazily +haziness/MS +hazing/M +hazy/PTR +hdqrs +he'd +he'll +he/VMZ +head/SJGZMDR +headache/MS +headband/SM +headboard/MS +headcount +headdress/MS +header/M +headfirst +headgear/SM +headhunt/ZGSRDMJ +headhunter/M +headhunting/M +headily +headiness/S +heading/M +headlamp/S +headland/MS +headless/P +headlessness/M +headlight/MS +headline/DRSZMG +headliner/M +headlock/MS +headlong +headman/M +headmaster/MS +headmastership/M +headmen +headmistress/MS +headphone/SM +headpiece/SM +headpin/MS +headquarter/GDS +headrest/MS +headroom/SM +headscarf/M +headset/SM +headship/SM +headshrinker/MS +headsman/M +headsmen +headstall/SM +headstand/MS +headstock/M +headstone/MS +headstrong +headwaiter/SM +headwall/S +headwater/S +headway/MS +headwind/SM +headword/MS +heady/PTR +heal/DRHSGZ +healed/U +healer/M +health/M +healthful/U +healthfully +healthfulness/SM +healthily/U +healthiness/MSU +healths +healthy/URPT +heap/SMDG +hear/ZTSRHJG +heard/UA +hearer/M +hearing/AM +hearken/SGD +hears/SDAG +hearsay/SM +hearse/M +heart/SMDNXG +heartache/SM +heartbeat/MS +heartbreak/GMS +heartbreaking/Y +heartbroke +heartbroken +heartburn/SGM +heartburning/M +hearted/Y +hearten/EGDS +heartening/EY +heartfelt +hearth/M +hearthrug +hearths +hearthstone/MS +heartily +heartiness/SM +heartland/SM +heartless/YP +heartlessness/SM +heartrending/Y +heartsick/P +heartsickness/MS +heartstrings +heartthrob/MS +heartwarming +heartwood/SM +hearty/TRSP +heat/SMDRGZBJ +heated/UA +heatedly +heater/M +heath/MRNZX +heathen/M +heathendom/SM +heathenish/Y +heathenism/MS +heather/M +heathery +heathland +heaths +heatproof +heats/A +heatstroke/MS +heatwave +heave/DSRGZ +heaven/SYM +heavenliness/M +heavenly/PTR +heavenward/S +heaver/M +heaves/M +heavily +heaviness/MS +heavy/TPRS +heavyhearted +heavyset +heavyweight/SM +hebephrenic +hecatomb/M +heck/S +heckle/RSDZG +heckler/M +hectare/MS +hectic/S +hectically +hectogram/MS +hectometer/SM +hector/SGD +hedge/DSRGMZ +hedgehog/MS +hedgehop/S +hedgehopped +hedgehopping +hedger/M +hedgerow/SM +hedging/Y +hedonism/SM +hedonist/MS +hedonistic +heed/SMGD +heeded/U +heedful/PY +heedfulness/M +heeding/U +heedless/YP +heedlessness/SM +heehaw/DGS +heel/SGZMDR +heeler/M +heeling/M +heelless +heft/GSD +heftily +heftiness/SM +hefty/TRP +hegemonic +hegemony/MS +hegira/S +heifer/MS +height/SMNX +heighten/GD +heinous/PY +heinousness/SM +heir/SDMG +heiress/MS +heirloom/MS +heist/GSMRD +heister/M +held +helical/Y +helices/M +helicon/M +helicopter/GSMD +heliocentric +heliography/M +heliosphere +heliotrope/SM +heliport/MS +helium/MS +helix/M +hell/GSMDR +hellbender/M +hellbent +hellcat/SM +hellebore/SM +heller/M +hellfire/M +hellhole/SM +hellion/SM +hellish/PY +hellishness/SM +hello/GMS +helluva +helm's +helm/U +helmed +helmet/GSMD +helming +helms +helmsman/M +helmsmen +helot/S +help/GZSJDR +helper/M +helpful/UY +helpfulness/MS +helping/M +helpless/YP +helplessness/SM +helpline/S +helpmate/SM +helpmeet's +helve/GMDS +hem/MS +hematite/MS +hematologic +hematological +hematologist/SM +hematology/MS +heme/MS +hemisphere/MSD +hemispheric +hemispherical +hemline/SM +hemlock/MS +hemmed +hemmer/SM +hemming +hemoglobin/MS +hemolytic +hemophilia/SM +hemophiliac/SM +hemorrhage/GMDS +hemorrhagic +hemorrhoid/MS +hemostat/SM +hemp/MNS +hemstitch/DSMG +hen/MS +hence/S +henceforth +henceforward +henchman/M +henchmen +henge/M +henna/MDSG +henning +henpeck/GSD +henry/M +hep/S +heparin/MS +hepatic/S +hepatitides +hepatitis/M +hepper +heppest +heptagon/SM +heptagonal +heptane/M +heptathlon/S +her +herald/MDSG +heralded/U +heraldic +heraldry/MS +herb/MS +herbaceous +herbage/MS +herbal/S +herbalism +herbalist/MS +herbicidal +herbicide/MS +herbivore/SM +herbivorous/Y +herculean +herd/MDRGZS +herder/M +herdsman/M +herdsmen +here's +here/IS +hereabout/S +hereafter/S +hereby +hereditary +heredity/MS +herein +hereinafter +hereof +hereon +heres/M +heresy/SM +heretic/SM +heretical +hereto +heretofore +hereunder +hereunto +hereupon +herewith +heritable +heritage/MS +heritor/IM +hermaphrodite/SM +hermaphroditic +hermeneutic/S +hermeneutics/M +hermetic/S +hermetical/Y +hermit/MS +hermitage/SM +hermitian +hernia/MS +hernial +herniate/NGXDS +hero/M +heroes +heroic/U +heroically +heroics +heroin/MS +heroine/SM +heroism/SM +heron/SM +herpes/M +herpetologist/SM +herpetology/MS +herring/SM +herringbone/SDGM +herself +hertz/M +hes +hesitance/S +hesitancy/SM +hesitant/U +hesitantly +hesitate/XDRSNG +hesitater/M +hesitating/UY +hesitation/M +heterodox +heterodoxy/MS +heterodyne +heterogamous +heterogamy/M +heterogeneity/SM +heterogeneous/PY +heterogeneousness/M +heterosexual/YMS +heterosexuality/SM +heterostructure +heterozygous +heuristic/SM +heuristically +hew/DRZGS +hewer/M +hex/DSRG +hexachloride/M +hexadecimal/YS +hexafluoride/M +hexagon/SM +hexagonal/Y +hexagram/SM +hexameter/SM +hexer/M +hey +heyday/MS +hf +hgt +hgwy +hi/D +hiatus/SM +hibachi/MS +hibernate/XGNSD +hibernation/M +hibernator/SM +hibiscus/MS +hiccup/MDGS +hick/SM +hickey/SM +hickory/MS +hid/ZDRGJ +hidden/U +hide/S +hideaway/SM +hidebound +hideous/YP +hideousness/SM +hideout/MS +hider/M +hiding/M +hie/S +hieing +hierarchal +hierarchic +hierarchical/Y +hierarchy/SM +hieratic +hieroglyph +hieroglyphic/S +hieroglyphics/M +hieroglyphs +hifalutin +high/PYRT +highball/GSDM +highborn +highboy/MS +highbrow/SM +highchair/SM +highfalutin +highhanded/PY +highhandedness/SM +highish +highland/ZSRM +highlight/GZRDMS +highness/MS +highpoint +highroad/MS +highs +hight +hightail/DGS +highway/MS +highwayman/M +highwaymen +hijack/JZRDGS +hijacker/M +hike/ZGDSR +hiker/M +hilarious/YP +hilariousness/MS +hilarity/MS +hill/GSMDR +hillbilly/MS +hiller/M +hilliness/SM +hillman +hillmen +hillock/SM +hillside/SM +hilltop/MS +hillwalking +hilly/TRP +hilt/MDGS +him/S +himself +hind/RSZ +hinder/GRD +hindered/U +hinderer/M +hindmost +hindquarter/SM +hindrance/SM +hindsight/SM +hinge's +hinge/UDSG +hinger +hint/GZMDRS +hinter/M +hinterland/MS +hip/PSM +hipbone/SM +hipness/S +hipped +hipper +hippest +hippie/MTRS +hipping/M +hippo/MS +hippodrome/MS +hippopotamus/SM +hippy's +hipster/MS +hiragana +hire/AGSD +hireling/SM +hirer/SM +hiring/S +hirsute/P +hirsuteness/MS +his +hiss/DSRMJG +hisser/M +hissing/M +hist/SDG +histamine/SM +histidine/SM +histochemic +histochemical +histochemistry/M +histogram/MS +histological +histologist/MS +histology/SM +historian/MS +historic +historical/PY +historicalness/M +historicism/M +historicist/M +historicity/MS +historiographer/SM +historiography/MS +history/MS +histrionic/S +histrionically +histrionics/M +hit/MS +hitch/UGSD +hitcher/MS +hitchhike/RSDGZ +hither +hitherto +hitless +hittable +hitter/SM +hitting +hive/MGDS +ho/DRYZ +hoar/M +hoard/RDJZSGM +hoarder/M +hoarding/M +hoarfrost/SM +hoariness/MS +hoarse/RTYP +hoarseness/SM +hoary/TPR +hoax/GZMDSR +hoaxer/M +hob/SM +hobbed +hobbing +hobbit +hobble/ZSRDG +hobbler/M +hobby/SM +hobbyhorse/SM +hobbyist/SM +hobgoblin/MS +hobnail/GDMS +hobnob/S +hobnobbed +hobnobbing +hobo/SDMG +hoc +hock/GDRMS +hocker/M +hockey/SM +hockshop/SM +hod/SM +hodge/MS +hodgepodge/SM +hoe/SM +hoecake/SM +hoedown/MS +hoeing +hoer/M +hog/SM +hogan/SM +hogback/MS +hogged +hogger +hogging +hoggish/Y +hogshead/SM +hogtie/SD +hogtying +hogwash/SM +hoist/GRDS +hoister/M +hoke/DSG +hokey/PRT +hokier +hokiest +hokum/MS +hold/NRBSJGZ +holdall/MS +holder/M +holding's +holding/IS +holdout/SM +holdover/SM +holdup/MS +hole/MGDS +holey +holiday/GRDMS +holidaymaker/S +holier/U +holiness/MSU +holistic +holistically +hollandaise +holler/GDS +hollow/RDYTGSP +hollowness/MS +hollowware/M +holly/SM +hollyhock/MS +holmium/MS +holocaust/MS +hologram/SM +holograph/GMD +holographic +holographs +holography/MS +holster/MDSG +holy/SRTP +holystone/MS +homage/MGSRD +homager/M +hombre/SM +homburg/SM +home/DSRMYZG +homebody/MS +homebound +homeboy/S +homebuilder/S +homebuilding +homebuilt +homecoming/MS +homegrown +homeland/SM +homeless/P +homelessness/SM +homelike +homeliness/SM +homely/RPT +homemade +homemake/JRZG +homemaker/M +homemaking/M +homeomorph/M +homeomorphic +homeomorphism/MS +homeopath +homeopathic +homeopaths +homeopathy/MS +homeostases +homeostasis/M +homeostatic +homeowner/S +homeownership +homepage +homer/GDM +homerists +homeroom/MS +homeschooling/S +homesick/P +homesickness/MS +homespun/S +homestead/GZSRDM +homesteader/M +homestretch/SM +hometown/SM +homeward +homework/ZSMR +homeworker/M +homey/PS +homeyness/MS +homicidal/Y +homicide/SM +homier +homiest +homiletic/S +homily/SM +hominess's +homing/M +hominid/MS +hominy/SM +homo/SM +homogamy/M +homogenate/MS +homogeneity/ISM +homogeneous/PY +homogenization/MS +homogenize/DRSGZ +homogenizer/M +homograph/M +homographs +homological +homologous +homologue/M +homology/MS +homomorphic +homomorphism/SM +homonym/SM +homophobia/S +homophobic +homophone/MS +homopolymers +homosexual/YMS +homosexuality/SM +homotopy +homozygous/Y +hon/MDRSZTG +honcho/DSG +hone/SM +honest/RYT +honestly/E +honesty/ESM +honey/GSMD +honeybee/SM +honeycomb/SDMG +honeydew/SM +honeylocust +honeymoon/RDMGZS +honeymooner/M +honeysuckle/MS +hong/M +honk/GZSDRM +honker/M +honky/SM +honor's +honor/ERDBZGS +honorable/PSM +honorableness/SM +honorables/U +honorablies/U +honorably/UE +honorarily +honorarium/SM +honorary/S +honored/U +honoree/S +honorer/EM +honorific/S +honors/A +hooch/MS +hood/MDSG +hooded/P +hoodedness/M +hoodlum/SM +hoodoo/DMGS +hoodwink/SRDG +hoodwinker/M +hooey/SM +hoof/DRMSG +hoofer/M +hoofmark/S +hook/GZDRMS +hookah/M +hookahs +hooked/P +hookedness/M +hooker/M +hookey's +hooks/U +hookup/SM +hookworm/MS +hooky/SRMT +hooligan/SM +hooliganism/SM +hoop/MDRSG +hooper/M +hoopla/SM +hooray/SMDG +hoosegow/MS +hoot/MDRSGZ +hootch's +hootenanny/SM +hooter/M +hooves/M +hop/SMDRG +hope/SM +hoped/U +hopeful/SPY +hopefulness/MS +hopeless/YP +hopelessness/SM +hoper/M +hopped +hopper/MS +hopping/M +hoppled +hopples +hopscotch/MDSG +horde/DSGM +horehound/MS +horizon/MS +horizontal/YS +hormonal/Y +hormone/MS +horn/GDRMS +hornbeam/M +hornblende/MS +horned/P +hornedness/M +hornet/MS +horniness/M +hornless +hornlike +hornpipe/MS +horny/TRP +horologic +horological +horologist/MS +horology/MS +horoscope/MS +horrendous/Y +horrible/SP +horribleness/SM +horribly +horrid/PY +horridness/M +horrific +horrifically +horrify/DSG +horrifying/Y +horror/MS +hors/DSGX +horse's +horse/UGDS +horseback/MS +horsedom +horseflesh/M +horsefly/MS +horsehair/SM +horsehide/SM +horselaugh/M +horselaughs +horseless +horselike +horsely +horseman/M +horsemanship/MS +horsemen +horseplay/SMR +horseplayer/M +horsepower/SM +horseradish/SM +horseshoe/MRSD +horseshoeing +horseshoer/M +horsetail/SM +horsewhip/SM +horsewhipped +horsewhipping +horsewoman/M +horsewomen +horsey +horsier +horsiest +horsing/M +hortatory +horticultural +horticulture/SM +horticulturist/SM +hos/GDS +hosanna/SDG +hose/M +hosepipe +hosier/MS +hosiery/SM +hosp +hospice/MS +hospitable/I +hospitably/I +hospital/MS +hospitality's/I +hospitality/MS +hospitalization/MS +hospitalize/GSD +host/MYDGS +hostage/MS +hostel/SZGMRD +hosteler/M +hostelry/MS +hostess/MDSG +hostile/YS +hostility/SM +hostler/MS +hot/PSY +hotbed/MS +hotblooded +hotbox/MS +hotcake/S +hotchpotch/M +hotel/MS +hotelier/MS +hotelman/M +hotfoot/DGS +hothead/DMS +hotheaded/PY +hotheadedness/SM +hothouse/MGDS +hotness/MS +hotplate/SM +hotpot/M +hotrod +hotshot/S +hotted +hotter +hottest +hotting +hough/M +hound/MRDSG +hounder/M +hounding/M +hour/YMS +hourglass/MS +houri/MS +hourly/S +house's +house/ASDG +houseboat/SM +housebound +houseboy/SM +housebreak/JSRZG +housebreaker/M +housebreaking/M +housebroke +housebroken +housebuilding +houseclean/JDSG +housecleaning/M +housecoat/MS +housefly/MS +houseful/SM +household/ZRMS +householder/M +househusband/S +housekeep/JRGZ +housekeeper/M +housekeeping/M +houselights +housemaid/MS +houseman/M +housemen +housemother/MS +housemoving +houseparent/SM +houseplant/S +houser +housetop/MS +housewares +housewarming/MS +housewife/YM +housewifeliness/M +housewifely/P +housewives +housework/ZSMR +houseworker/M +housing/MS +hove/ZR +hovel/GSMD +hover/GRD +hovercraft/M +hoverer/M +how/SM +howbeit +howdah/M +howdahs +howdy/GSD +however +howitzer/MS +howl/GZSMDR +howler/M +howsoever +hoy/M +hoyden/DMGS +hoydenish +hp +hr +hrs +ht +huarache/SM +hub/MS +hubba +hubbub/SM +hubby/SM +hubcap/SM +hubris/SM +huckleberry/SM +huckster/SGMD +huddle/RSDMG +huddler/M +hue/MDS +huff/SGDM +huffily +huffiness/SM +huffy/TRP +hug/RTS +huge/YP +hugeness/MS +hugged +hugger +hugging/S +huh +huhs +hula/MDSG +hulk/GDMS +hull/MDRGZS +hullabaloo/SM +huller/M +hulling/M +hullo/GSDM +hum/S +human/IPY +humane/IY +humaneness/SM +humaner +humanest +humanism/SM +humanist/SM +humanistic +humanitarian/S +humanitarianism/SM +humanity/ISM +humanization/CSM +humanize/RSDZG +humanized/C +humanizer/M +humanizes/IAC +humanizing/C +humankind/M +humanness/IM +humannesses +humanoid/S +humans +humble/TZGPRSDJ +humbleness/SM +humbly +humbug/MS +humbugged +humbugging +humdinger/MS +humdrum/S +humeral/S +humeri +humerus/M +humid/Y +humidification/MC +humidifier/CM +humidify/RSDCXGNZ +humidistat/M +humidity/MS +humidor/MS +humiliate/SDXNG +humiliating/Y +humiliation/M +humility/MS +hummed +hummer/SM +humming +hummingbird/SM +hummock/MDSG +hummocky +hummus/S +humongous +humor/RDMZGS +humored/U +humorist/MS +humorless/PY +humorlessness/MS +humorous/YP +humorousness/MS +hump/GSMD +humpback/SMD +humph/DG +humphs +humus/SM +hunch/GMSD +hunchback/DSM +hundred/SHRM +hundredfold/S +hundredths +hundredweight/SM +hung/A +hunger/SDMG +hungover +hungrily +hungriness/SM +hungry/RTP +hunk/ZRMS +hunker/DG +hunky/RST +hunt/GZJDRS +hunter/M +hunting/M +huntress/MS +huntsman/M +huntsmen +hurdle/JMZGRSD +hurdler/M +hurl/DRGZJS +hurler/M +hurling/M +hurray/SDG +hurricane/MS +hurried/UY +hurriedness/M +hurry/RSDG +hurt/U +hurter/M +hurtful/PY +hurtfulness/MS +hurting/Y +hurtle/SDG +hurts +husband/GSDRYM +husbander/M +husbandman/M +husbandmen +husbandry/SM +hush/DSG +husk/SGZDRM +husker/M +huskily +huskiness/MS +husking/M +husky/RSPT +hussar/MS +hussy/SM +hustings/M +hustle/RSDZG +hustler/M +hut/MS +hutch/MSDG +hutted +hutting +huzzah/GD +huzzahs +hwy +hyacinth/M +hyacinths +hyaena's +hybrid/MS +hybridism/SM +hybridization/S +hybridize/GSD +hydra/MS +hydrangea/SM +hydrant/SM +hydrate's +hydrate/CSDNGX +hydration/MC +hydraulic/S +hydraulically +hydraulicked +hydraulicking +hydraulics/M +hydrazine/M +hydride/MS +hydro/SM +hydrocarbon/SM +hydrocephali +hydrocephalus/MS +hydrochemistry +hydrochloric +hydrochloride/M +hydrodynamic/S +hydrodynamical +hydrodynamics/M +hydroelectric +hydroelectrically +hydroelectricity/SM +hydrofluoric +hydrofoil/MS +hydrogen/MS +hydrogenate's +hydrogenate/CDSGN +hydrogenation/MC +hydrogenations +hydrogenous +hydrological/Y +hydrologist/MS +hydrology/SM +hydrolysis/M +hydrolyze/GSD +hydrolyzed/U +hydromagnetic +hydromechanics/M +hydrometer/SM +hydrometry/MS +hydrophilic +hydrophobia/SM +hydrophobic +hydrophone/SM +hydroplane/DSGM +hydroponic/S +hydroponics/M +hydrosphere/MS +hydrostatic/S +hydrostatics/M +hydrotherapy/SM +hydrothermal/Y +hydrous +hydroxide/MS +hydroxy +hydroxyl/SM +hydroxylate/N +hydroxyzine/M +hyena/MS +hygiene/MS +hygienic/S +hygienically +hygienics/M +hygienist/MS +hygrometer/SM +hygroscopic +hying +hymen/MS +hymeneal/S +hymn/GSDM +hymnal/SM +hymnbook/S +hype/MZGDSR +hyperactive/S +hyperactivity/SM +hyperbola/MS +hyperbole/MS +hyperbolic +hyperbolically +hyperboloid/SM +hyperboloidal +hypercellularity +hypercritical/Y +hypercube/MS +hyperemia/M +hyperemic +hyperfine +hypergamous/Y +hypergamy/M +hyperglycemia/MS +hyperinflation +hypermarket/SM +hypermedia/S +hyperplane/SM +hyperplasia/M +hypersensitive/P +hypersensitiveness/MS +hypersensitivity/MS +hypersonic +hyperspace/M +hypersphere/M +hypertension/MS +hypertensive/S +hypertext/SM +hyperthyroid +hyperthyroidism/MS +hypertrophy/MSDG +hypervelocity +hyperventilate/XSDGN +hyperventilation/M +hyphen/DMGS +hyphenate/NGXSD +hyphenated/U +hyphenation/M +hypnoses +hypnosis/M +hypnotherapy/SM +hypnotic/S +hypnotically +hypnotism/MS +hypnotist/SM +hypnotize/SDG +hypo/DMSG +hypoactive +hypoallergenic +hypocellularity +hypochondria/MS +hypochondriac/SM +hypocrisy/SM +hypocrite/MS +hypocritical/Y +hypodermic/S +hypoglycemia/SM +hypoglycemic/S +hypophyseal +hypophysectomized +hypotenuse/MS +hypothalami +hypothalamic +hypothalamically +hypothalamus/M +hypothermia/SM +hypotheses +hypothesis/M +hypothesize/ZGRSD +hypothesizer/M +hypothetic +hypothetical/Y +hypothyroid +hypothyroidism/SM +hypoxia/M +hyssop/MS +hysterectomy/MS +hysteresis/M +hysteria/SM +hysteric/SM +hysterical/YU +i +i's +iamb/MS +iambi +iambic/S +iambus/SM +ibex/MS +ibid +ibidem +ibis/SM +ibuprofen/S +ice's +ice/GDSC +iceberg/SM +iceboat/MS +icebound +icebox/MS +icebreaker/SM +icecap/SM +iceman/M +icemen +icepack +icepick/S +ichneumon/M +ichthyologist/MS +ichthyology/MS +icicle/SM +icily +iciness/SM +icing/MS +icky/RT +icon/MS +iconic +iconoclasm/MS +iconoclast/MS +iconoclastic +iconography/MS +icosahedra +icosahedral +icosahedron/M +ictus/SM +icy/RPT +id/MY +idea/SM +ideal/MYS +idealism/MS +idealist/MS +idealistic +idealistically +idealization/MS +idealize/GDRSZ +idealized/U +idealizer/M +idealogical +ideate/SN +ideation/M +idem +idempotent/S +identical/YP +identicalness/M +identifiability +identifiable/U +identifiably +identification/M +identified/U +identifier/M +identify/XZNSRDG +identity/SM +ideogram/MS +ideograph/M +ideographic +ideographs +ideological/Y +ideologist/SM +ideologue/S +ideology/SM +ides +idiocy/MS +idiolect/M +idiom/MS +idiomatic/P +idiomatically +idiopathic +idiosyncrasy/SM +idiosyncratic +idiosyncratically +idiot/MS +idiotic +idiotically +idle/PZTGDSR +idleness/MS +idler/M +idol/MS +idolater/MS +idolatress/S +idolatrous +idolatry/SM +idolization/SM +idolize/ZGDRS +idolized/U +idolizer/M +ids +idyll/MS +idyllic +idyllically +if +iffiness/S +iffy/TPR +ifs +igloo/MS +igneous +ignitable +ignite/ASDG +igniter/M +ignition/MS +ignoble/P +ignobleness/M +ignobly +ignominious/Y +ignominy/MS +ignoramus/SM +ignorance/MS +ignorant/SPY +ignorantness/M +ignore/SRDGB +ignorer/M +iguana/MS +ii +iii +ikon's +ilea +ileitides +ileitis/M +ileum/M +ilia +iliac +ilium/M +ilk/MS +ill/PS +illegal/YS +illegality/MS +illegibility/MS +illegible +illegibly +illegitimacy/SM +illegitimate/SDGY +illiberal/Y +illiberality/SM +illicit/YP +illicitness/MS +illimitable/P +illimitableness/M +illiquid +illiteracy/MS +illiterate/PSY +illiterateness/M +illness/MS +illogic/M +illogical/PY +illogicality/SM +illogicalness/M +illume/DG +illuminate/XSDVNG +illuminating/U +illuminatingly +illumination/M +illumine/BGSD +illus/V +illusion's +illusion/ES +illusionary +illusionist/MS +illusive/PY +illusiveness/M +illusoriness/M +illusory/P +illustrate/VGNSDX +illustrated/U +illustration/M +illustrative/Y +illustrator/SM +illustrious/PY +illustriousness/SM +illy +image/DSGM +imagery/MS +imaginable/U +imaginableness +imaginably/U +imaginariness/M +imaginary/PS +imagination/MS +imaginative/UY +imaginativeness/M +imagine/RSDJBG +imagined/U +imaginer/M +imago/M +imagoes +imam/MS +imbalance/SDM +imbecile/YMS +imbecilic +imbecility/MS +imbibe/ZRSDG +imbiber/M +imbrication/SM +imbroglio/MS +imbruing +imbue/GDS +imitable/I +imitate/SDVNGX +imitation/M +imitative/YP +imitativeness/MS +imitator/SM +immaculate/YP +immaculateness/SM +immanence/S +immanency/MS +immanent/Y +immaterial/PY +immateriality/MS +immaterialness/MS +immature/SPY +immatureness/M +immaturity/MS +immeasurable/P +immeasurableness/M +immeasurably +immediacy/MS +immediate/YP +immediateness/SM +immemorial/Y +immense/PRTY +immenseness/M +immensity/MS +immerse/RSDXNG +immersible +immersion/M +immigrant/SM +immigrate/NGSDX +immigration/M +imminence/SM +imminent/YP +imminentness/M +immobile +immobility/MS +immobilization/MS +immobilize/DSRG +immoderate/NYP +immoderateness/M +immoderation/M +immodest/Y +immodesty/SM +immolate/SDNGX +immolation/M +immoral/Y +immorality/MS +immortal/SY +immortality/SM +immortalize/GDS +immortalized/U +immovability/SM +immovable/PS +immovableness/M +immovably +immune/S +immunity/SM +immunization/MS +immunize/GSD +immunoassay/M +immunodeficiency/S +immunodeficient +immunologic +immunological/Y +immunologist/SM +immunology/MS +immure/GSD +immutability/MS +immutable/P +immutableness/M +immutably +imp/SGMDRY +impact/VGMRDS +impaction/SM +impactor/SM +impair/LGRDS +impaired/U +impairer/M +impairment/SM +impala/MS +impale/GLRSD +impalement/SM +impaler/M +impalpable +impalpably +impanel/DGS +impart/GDS +impartation/M +impartial/Y +impartiality/SM +impassable/P +impassableness/M +impassably +impasse/SXBMVN +impassibility/SM +impassible +impassibly +impassion/DG +impassioned/U +impassive/YP +impassiveness/MS +impassivity/MS +impasto/SM +impatience/SM +impatiens/M +impatient/Y +impeach/DRSZGLB +impeachable/U +impeacher/M +impeachment/MS +impeccability/SM +impeccable/S +impeccably +impecunious/PY +impecuniousness/MS +imped/GRD +impedance/MS +impede/S +impeded/U +impeder/M +impediment/SM +impedimenta +impel/S +impelled +impeller/MS +impelling +impend/DGS +impenetrability/MS +impenetrable/P +impenetrableness/M +impenetrably +impenitence/MS +impenitent/YS +imperative/PSY +imperativeness/M +imperceivable +imperceptibility/MS +imperceptible +imperceptibly +imperceptive +imperf +imperfect/YSVP +imperfectability +imperfection/MS +imperfectness/SM +imperial/YS +imperialism/MS +imperialist/SM +imperialistic +imperialistically +imperil/GSLD +imperilment/SM +imperious/YP +imperiousness/MS +imperishable/SP +imperishableness/M +imperishably +impermanence/MS +impermanent/Y +impermeability/SM +impermeable/P +impermeableness/M +impermeably +impermissible +impersonal/Y +impersonality/M +impersonalized +impersonate/XGNDS +impersonation/M +impersonator/SM +impertinence/SM +impertinent/YS +imperturbability/SM +imperturbable +imperturbably +impervious/PY +imperviousness/M +impetigo/MS +impetuosity/MS +impetuous/YP +impetuousness/MS +impetus/MS +impiety/MS +imping/GD +impinge/LS +impingement/MS +impious/PY +impiousness/SM +impish/YP +impishness/MS +implacability/SM +implacable/P +implacableness/M +implacably +implant/BGSDR +implantation/SM +implanter/M +implausibility/MS +implausible +implausibly +implement/SMRDGZB +implementability +implementable/U +implementation's +implementation/A +implementations +implemented/AU +implementer/M +implementing/A +implementor/MS +implicant/SM +implicate/VGSD +implication/M +implicative/PY +implicit/YP +implicitness/SM +implied/Y +implode/GSD +implore/GSD +imploring/Y +implosion/SM +implosive/S +imply/GNSDX +impolite/YP +impoliteness/MS +impolitic/PY +impoliticness/M +imponderable/PS +imponderableness/M +import/SZGBRD +importance/SM +important/Y +importation/MS +importer/M +importing/A +importunate/PYGDS +importunateness/M +importune/SRDZYG +importuner/M +importunity/SM +imposable +impose/ASDG +imposer/SM +imposing/U +imposingly +imposition/SM +impossibility/SM +impossible/PS +impossibleness/M +impossibly +impost/SGMD +imposter's +impostor/SM +imposture/SM +impotence/MS +impotency/S +impotent/SY +impound/GDS +impoundments +impoverish/LGDRS +impoverisher/M +impoverishment/SM +impracticable/P +impracticableness/M +impracticably +impractical/PY +impracticality/SM +impracticalness/M +imprecate/NGXSD +imprecation/M +imprecise/PYXN +impreciseness/MS +imprecision/M +impregnability/MS +impregnable/P +impregnableness/M +impregnably +impregnate/DSXNG +impregnation/M +impresario/SM +impress/DRSGVL +impressed/U +impresser/M +impressibility/MS +impressible +impression/BMS +impressionability/SM +impressionable/P +impressionableness/M +impressionism/SM +impressionist/MS +impressionistic +impressive/YP +impressiveness/MS +impressment/M +imprimatur/SM +imprint/SZDRGM +imprinter/M +imprinting/M +imprison/GLDS +imprisonment/MS +improbability/MS +improbable/P +improbableness/M +improbably +impromptu/S +improper/PY +improperness/M +impropitious +impropriety/SM +improve/SRDGBL +improved/U +improvement/MS +improver/M +improvidence/SM +improvident/Y +improvisation/MS +improvisational +improvisatory +improvise/RSDZG +improviser/M +imprudence/SM +imprudent/Y +impudence/MS +impudent/Y +impugn/SRDZGB +impugner/M +impulse/XMVGNSD +impulsion/M +impulsive/YP +impulsiveness/MS +impunity/SM +impure/RPTY +impureness/M +impurity/MS +imputation/SM +impute/SDBG +in/AS +inaction +inactive +inadequate/S +inadvertence/MS +inadvertent/Y +inalienability/MS +inalienably +inalterable/P +inalterableness/M +inamorata/MS +inane/SRPYT +inanimate/P +inanimateness/S +inanity/MS +inappeasable +inappropriate/P +inarticulate/P +inasmuch +inaugural/S +inaugurate/XSDNG +inauguration/M +inauthenticity +inbound/G +inbred/S +inbreed/JG +inc/T +incalculableness/M +incalculably +incandescence/SM +incandescent/YS +incant +incantation/SM +incantatory +incapable/S +incapacitate/GNSD +incapacitation/M +incarcerate/XGNDS +incarceration/M +incarnadine/GDS +incarnate/AGSDNX +incarnation/AM +incendiary/S +incense/MGDS +incentive/ESM +incentively +incept/DGVS +inception/MS +inceptive/Y +inceptor/M +incessant/Y +incest/SM +incestuous/PY +incestuousness/MS +inch/GMDS +inchoate/DSG +inchworm/MS +incidence/MS +incident/SM +incidental/YS +incinerate/XNGSD +incineration/M +incinerator/SM +incipience/SM +incipiency/M +incipient/Y +incise/SDVGNX +incision/M +incisive/YP +incisiveness/MS +incisor/MS +incite/RZL +incitement/MS +inciter/M +incl +inclination/ESM +incline/EGSD +incliner/M +inclining/M +include/GDS +inclusion/MS +inclusive/PY +inclusiveness/MS +incognito/S +incoherency/M +income/M +incommode/DG +incommunicado +incomparable +incompetent/MS +incomplete/P +inconceivability/MS +inconceivable/P +inconceivableness/M +incondensable +incongruousness/S +inconsiderable/P +inconsiderableness/M +inconsistence +inconsolable/P +inconsolableness/M +inconsolably +incontestability/SM +incontestably +incontrovertibly +inconvenience/DG +inconvertibility +inconvertible +incorporable +incorporate/GASDXN +incorporated/UE +incorrect/P +incorrigibility/MS +incorrigible/SP +incorrigibleness/M +incorrigibly +incorruptible/S +incorruptibly +increase/JB +increaser/M +increasing/Y +incredible/P +incredibleness/M +increment/DMGS +incremental/Y +incrementation +incriminate/XNGSD +incrimination/M +incriminatory +incrustation/SM +incubate/XNGVDS +incubation/M +incubator/MS +incubus/MS +inculcate/SDGNX +inculcation/M +inculpate/SDG +incumbency/MS +incumbent/S +incunabula +incunabulum +incurable/S +incurious +incursion/SM +ind +indebted/P +indebtedness/SM +indefatigable/P +indefatigableness/M +indefatigably +indefeasible +indefeasibly +indefinable/PS +indefinableness/M +indefinite/S +indelible +indelibly +indemnification/M +indemnify/NXSDG +indemnity/SM +indent/R +indentation/SM +indented/U +indenter/M +indention/SM +indenture/DG +indescribable/PS +indescribableness/M +indescribably +indestructible/P +indestructibleness/M +indestructibly +indeterminably +indeterminacy/MS +indeterminism +index/MRDZGB +indexation/S +indexer/M +indicant/MS +indicate/DSNGVX +indication/M +indicative/SY +indicator/MS +indices's +indict/SGLBDR +indicter/M +indictment/SM +indifference +indigence/MS +indigenous/YP +indigenousness/M +indigent/SY +indigestible/S +indignant/Y +indignation/MS +indigo/SM +indirect/PG +indiscreet/P +indiscriminate/PY +indiscriminateness/M +indispensability/MS +indispensable/SP +indispensableness/M +indispensably +indisputable/P +indisputableness/M +indissoluble/P +indissolubleness/M +indissolubly +indistinguishable/P +indistinguishableness/M +indite/SDG +indium/SM +individual/YMS +individualism/MS +individualist/MS +individualistic +individualistically +individuality/MS +individualization/SM +individualize/DRSGZ +individualized/U +individualizer/M +individualizes/U +individualizing/Y +individuate/DSXGN +individuation/M +indivisible/SP +indivisibleness/M +indivisibly +indoctrinate/GNXSD +indoctrination/M +indoctrinator/SM +indolence/SM +indolent/Y +indomitable/P +indomitableness/M +indomitably +indoor +indubitable/P +indubitableness/M +indubitably +induce/ZGLSRD +inducement/MS +inducer/M +inducible +induct/GV +inductance/MS +inductee/SM +induction/SM +inductive/PY +inductiveness/M +inductor/MS +indulge/GDRS +indulgence/SDGM +indulgent/Y +indulger/M +industrial/SY +industrialism/MS +industrialist/MS +industrialization/MS +industrialize/SDG +industrialized/U +industrious/YP +industriousness/SM +industry/SM +inebriate/NGSDX +inebriation/M +inedible +ineducable +ineffability/MS +ineffable/P +ineffableness/M +ineffably +inelastic +ineligibly +ineluctable +ineluctably +inept/YP +ineptitude/SM +ineptness/MS +inequivalent +inerrant +inert/SPY +inertia/SM +inertial/Y +inertness/MS +inescapably +inestimably +inevitability/MS +inevitable/P +inevitableness/M +inevitably +inexact/P +inexhaustible/P +inexhaustibleness/M +inexhaustibly +inexorability/M +inexorable/P +inexorableness/M +inexorably +inexpedience/M +inexplicable/P +inexplicableness/M +inexplicably +inexplicit +inexpressibility/M +inexpressible/PS +inexpressibleness/M +inextricably +inf/ZT +infamous +infamy/SM +infancy/M +infant/MS +infanticide/MS +infantile +infantry/SM +infantryman/M +infantrymen +infarct/SM +infarction/SM +infatuate/XNGSD +infatuation/M +infauna +infect/ESGDA +infected/U +infecter +infection/EASM +infectious/PY +infectiousness/MS +infective +infer/B +inference/GMSR +inferential/Y +inferior/SMY +inferiority/MS +infernal/Y +inferno/MS +inferred +inferring +infertile +infest/GSDR +infestation/MS +infester/M +infidel/SM +infighting/M +infill/MG +infiltrate/V +infiltrator/MS +infinite/V +infinitesimal/SY +infinitival +infinitive/YMS +infinitude/MS +infinitum +infinity/SM +infirmary/SM +infirmity/SM +infix/M +inflammable/P +inflammableness/M +inflammation/MS +inflammatory +inflatable/MS +inflate/NGBDRSX +inflater/M +inflation/ESM +inflationary +inflect/GVDS +inflection/SM +inflectional/Y +inflexible/P +inflexibleness/M +inflexion/SM +inflict/DRSGV +inflicter/M +infliction/SM +inflow/M +influence/SRDGM +influenced/U +influencer/M +influent +influential/SY +influenza/MS +info/SM +infomercial/S +informatics +information/ES +informational +informative/UY +informativeness/S +informatory +informed/U +informer/M +infotainment/S +infra +infrared/SM +infrasonic +infrastructural +infrastructure/MS +infrequence/S +infringe/LR +infringement/SM +infringer/M +infuriate/GNYSD +infuriating/Y +infuriation/M +infuse/RZ +infuser/M +infusible/P +infusibleness/M +ingenious/YP +ingeniousness/MS +ingenuity/SM +ingenuous/EY +ingenuousness/MS +ingest/DGVS +ingestible +ingestion/SM +inglenook/MS +ingoing +ingot/SMDG +ingrained/Y +ingrate/M +ingratiate/DSGNX +ingratiating/Y +ingratiation/M +ingredient/SM +ingress/MS +ingression/M +ingrown/P +inguinal +ing�nue/S +inhabit/R +inhabitable/U +inhabitance +inhabited/U +inhabiter/M +inhalant/S +inhalation/SM +inhalator/SM +inhale/Z +inhere/DG +inherent/Y +inherit/BDSG +inheritable/P +inheritableness/M +inheritance/EMS +inherited/E +inheriting/E +inheritor/S +inheritress/MS +inheritrix/MS +inherits/E +inhibit/DVGS +inhibited/U +inhibiter's +inhibition/MS +inhibitor/MS +inhibitory +inhomogeneous +inhospitable/P +inhospitableness/M +inhospitality +inimical/Y +inimitable/P +inimitableness/M +inimitably +inion +iniquitous/PY +iniquitousness/M +iniquity/MS +initial/GSPRDY +initialer/M +initialization's +initialization/A +initializations +initialize/ASDG +initialized/U +initializer/S +initiate/UD +initiates +initiating +initiation/SM +initiative/SM +initiator/MS +initiatory +inject/GVSDB +injectable/U +injection/MS +injector/SM +injunctive +injure/SRDZG +injured/U +injurer/M +injurious/YP +injuriousness/M +ink/ZDRJ +inkblot/SM +inker/M +inkiness/MS +inkling/SM +inkstand/SM +inkwell/SM +inky/TP +inland +inlander/M +inlay/RG +inletting +inly/G +inmost +inn/ZGDRSJ +innards +innate/YP +innateness/SM +inner/Y +innermost/S +innersole/S +innerspring +innervate/GNSDX +innervation/M +inning/M +innkeeper/MS +innocence/SM +innocent/SYRT +innocuous/PY +innocuousness/MS +innovate/SDVNGX +innovation/M +innovative/P +innovator/MS +innovatory +innuendo/MDGS +innumerability/M +innumerable/P +innumerableness/M +innumerably +innumerate +inoculate/ASDG +inoculation/MS +inoculative +inoffensive/P +inopportune/P +inopportuneness/M +inordinate/PY +inordinateness/M +inorganic +inpatient +input/MRDG +inquire/ZR +inquirer/M +inquiring/Y +inquiry/MS +inquisition/MS +inquisitional +inquisitive/YP +inquisitiveness/MS +inquisitor/MS +inquisitorial/Y +inrush/M +ins +insalubrious +insanitary +insatiability/MS +insatiable/P +insatiableness/M +insatiably +inscribe/Z +inscription/SM +inscrutability/SM +inscrutable/P +inscrutableness/SM +inscrutably +inseam +insecticidal +insecticide/MS +insectivore/SM +insectivorous +insecure/P +insecureness/M +inseminate/NGXSD +insemination/M +insensate/P +insensateness/M +insensible/P +insentient +inseparable/S +insert/ADSG +inserter/M +insertion/AMS +insetting +inshore +inside/Z +insider/M +insidious/YP +insidiousness/MS +insightful/Y +insigne's +insignia/SM +insignificant +insinuate/VNGXSD +insinuating/Y +insinuation/M +insinuator/SM +insipid/Y +insipidity/MS +insist/SGD +insistence/SM +insistent/Y +insisting/Y +insociable +insofar +insole/M +insolence/SM +insolent/YS +insoluble/P +insolubleness/M +insolubly +insomnia/MS +insomniac/S +insomuch +insouciance/SM +insouciant/Y +inspect/AGSD +inspection/SM +inspective +inspector/SM +inspectorate/MS +inspiration/MS +inspirational/Y +inspire/R +inspired/U +inspirer/M +inspiring/U +inspirit/DG +inst/B +install/ADRSG +installable +installation/SM +installer/MS +installment/MS +instance/GD +instant/SRYMP +instantaneous/PY +instantaneousness/M +instantiate/SDXNG +instantiated/U +instantiation/M +instate/AGSD +instead +instigate/XSDVGN +instigation/M +instigator/SM +instillation/SM +instinct/VMS +instinctive/Y +instinctual +institute/ZXVGNSRD +instituter/M +institutes/M +institution/AM +institutional/Y +institutionalism/M +institutionalist/M +institutionalization/SM +institutionalize/GDS +institutor's +instr +instruct/DSVG +instructed/U +instruction/MS +instructional +instructive/PY +instructiveness/M +instructor/MS +instrument/GMDS +instrumental/SY +instrumentalist/MS +instrumentality/SM +instrumentation/SM +insubordinate +insubstantial +insufferable +insufferably +insular/YS +insularity/MS +insulate/DSXNG +insulated/U +insulation/M +insulator/MS +insulin/MS +insult/DRSG +insulter/M +insulting/Y +insuperable +insuperably +insupportable/P +insupportableness/M +insurance's/A +insurance/MS +insure/BZGS +insured/S +insurer/M +insurgence/SM +insurgency/MS +insurgent/MS +insurmountably +insurrection/SM +insurrectionist/SM +int/ZR +intact/P +intactness/M +intaglio/GMDS +intake/M +intangible/M +integer/MS +integrability/M +integrable +integral/SYM +integrand/MS +integrate/AGNXEDS +integration/EMA +integrative/E +integrator/MS +integrity/SM +integument/SM +intellect/MVS +intellective/Y +intellectual/YPS +intellectualism/MS +intellectuality/M +intellectualize/GSD +intellectualness/M +intelligence/MSR +intelligencer/M +intelligent/UY +intelligentsia/MS +intelligibilities +intelligibility/UM +intelligible/PU +intelligibleness/MU +intelligibly/U +intemperate/P +intendant/MS +intended/SYP +intendedness/M +intender/M +intensification/M +intensifier/M +intensify/GXNZRSD +intensional/Y +intensive/PSY +intensiveness/MS +intent/YP +intention/SDM +intentional/UY +intentionality/M +intentness/SM +inter/ESTL +interact/VGDS +interaction/MS +interactive/PY +interactivity +interaxial +interbank +interbred +interbreed/GS +intercalate/GNVDS +intercalation/M +intercase +intercaste +intercede/SRDG +interceder/M +intercensal +intercept/DGS +interception/MS +interceptor/MS +intercession/MS +intercessor/SM +intercessory +interchange/DSRGJ +interchangeability/M +interchangeable/P +interchangeableness/M +interchangeably +interchanger/M +intercity +interclass +intercohort +intercollegiate +intercom/SM +intercommunicate/SDXNG +intercommunication/M +interconnect/GDS +interconnected/P +interconnectedness/M +interconnection/SM +interconnectivity +intercontinental +interconversion/M +intercorrelated +intercourse/SM +interdenominational +interdepartmental/Y +interdependence/MS +interdependency/SM +interdependent/Y +interdict/MDVGS +interdiction/MS +interdisciplinary +interest/GEMDS +interested/UYE +interesting/YP +interestingly/U +interestingness/M +interface/SRDGM +interfacing/M +interfaith +interfere/SRDG +interference/MS +interferer/M +interfering/Y +interferometer/SM +interferometric +interferometry/M +interferon/MS +interfile/GSD +intergalactic +intergeneration/M +intergenerational +interglacial +intergovernmental +intergroup +interim/S +interindex +interindustry +interior/SMY +interj +interject/GDS +interjection/MS +interjectional +interlace/GSD +interlard/SGD +interlayer/G +interleave/SDG +interleukin/S +interlibrary +interline/JGSD +interlinear/S +interlingua/M +interlingual +interlining/M +interlink/GDS +interlisp/M +interlobular +interlock/RDSG +interlocker/M +interlocutor/MS +interlocutory +interlope/GZSRD +interloper/M +interlude/MSDG +intermarriage/MS +intermarry/GDS +intermediary/MS +intermediate/YMNGSDP +intermediateness/M +intermediation/M +interment/SME +intermeshed +intermetrics +intermezzi +intermezzo/SM +interminably +intermingle/DSG +intermission/MS +intermittent/Y +intermix/GSRD +intermodule +intermolecular/Y +intern/L +internal/SY +internalization/SM +internalize/GDS +international/YS +internationalism/SM +internationalist/SM +internationality/M +internationalization/MS +internationalize/DSG +interne's +internecine +internee/SM +internetwork +internist/SM +internment/SM +internship/MS +internuclear +interocular +interoffice +interoperability +interpenetrates +interpersonal/Y +interplanetary +interplay/GSMD +interpol +interpolate/XGNVBDS +interpolation/M +interpose/GSRD +interposer/M +interposition/MS +interpret/AGSD +interpretable/U +interpretation/MSA +interpretative/Y +interpreted/U +interpreter/SM +interpretive/Y +interpretor/S +interprocess +interprocessor +interquartile +interracial +interred/E +interregional +interregnum/MS +interrelate/GNDSX +interrelated/PY +interrelatedness/M +interrelation/M +interrelationship/SM +interring/E +interrogate/DSXGNV +interrogation/M +interrogative/SY +interrogator/SM +interrogatory/S +interrupt/VGZRDS +interrupted/U +interrupter/M +interruptibility +interruptible +interruption/MS +interscholastic +intersect/GDS +intersection/MS +intersession/MS +interspecies +intersperse/GNDSX +interspersion/M +interstage +interstate/S +interstellar +interstice/SM +interstitial/SY +intersurvey +intertask +intertwine/GSD +interurban/S +interval/MS +intervene/GSRD +intervener/M +intervenor/M +intervention/MS +interventionism/MS +interventionist/S +interview/AMD +interviewed/U +interviewee/SM +interviewer/SM +interviewing +interviews +intervocalic +interweave/GS +interwove +interwoven +intestacy/SM +intestinal/Y +intestine/SM +inti +intifada +intimacy/SM +intimal +intimate/XYNGPDRS +intimateness/M +intimater/M +intimation/M +intimidate/SDXNG +intimidating/Y +intimidation/M +into +intolerable/P +intolerableness/M +intolerant/PS +intonate/NX +intonation/M +intoxicant/MS +intoxicate/DSGNX +intoxicated/Y +intoxication/M +intra +intracellular +intracity +intraclass +intracohort +intractability/M +intractable/P +intractableness/M +intradepartmental +intrafamily +intragenerational +intraindustry +intraline +intrametropolitan +intramural/Y +intramuscular/Y +intranasal +intransigence/MS +intransigent/YS +intransitive/S +intraoffice +intraprocess +intrapulmonary +intraregional +intrasectoral +intrastate +intratissue +intrauterine +intravenous/YS +intrepid/YP +intrepidity/SM +intrepidness/M +intricacy/SM +intricate/PY +intricateness/M +intrigue/DRSZG +intriguer/M +intriguing/Y +intrinsic/S +intrinsically +intro/S +introduce/ADSG +introducer/M +introduction/ASM +introductory +introit/SM +introject/SD +introspect/SGVD +introspection/MS +introspective/YP +introspectiveness/M +introversion/SM +introvert/SMDG +intrude/ZGDSR +intruder/M +intrusion/SM +intrusive/SYP +intrusiveness/MS +intubate/NGDS +intubation/M +intuit/GVDSB +intuitionist/M +intuitive/YP +intuitiveness/MS +inundate/SXNG +inundation/M +inure/GDS +invade/ZSRDG +invader/M +invalid/GSDM +invalidism/MS +invariable/P +invariant/M +invasion/SM +invasive/P +invective/PSMY +invectiveness/M +inveigh/DRG +inveigher/M +inveighs +inveigle/DRSZG +inveigler/M +invent/ADGS +invented/U +invention/ASM +inventive/YP +inventiveness/MS +inventor/MS +inventory/SDMG +inverse/YV +invert/ZSGDR +inverter/M +invertible +invest/ADSLG +investigate/XDSNGV +investigation/MA +investigator/MS +investigatory +investiture/SM +investment's/A +investment/ESA +investor/SM +inveteracy/MS +inveterate/Y +inviability +invidious/YP +invidiousness/MS +invigilate/GD +invigilator/SM +invigorate/ANGSD +invigorating/Y +invigoration/AM +invigorations +invincibility/SM +invincible/P +invincibleness/M +invincibly +inviolability/MS +inviolably +inviolate/YP +inviolateness/M +inviscid +invisible/S +invisibleness/M +invitation/MS +invitational/S +invite/SRDG +invited/U +invitee/S +inviter/M +inviting/Y +invocable +invocate +invoke/GSRDBZ +invoked/A +invoker/M +invokes/A +involuntariness/S +involuntary/P +involute/XYN +involution/M +involutorial +involve/GDSRL +involved/U +involvedly +involvement/SM +involver/M +invulnerability/M +invulnerableness/M +inward/PY +inwardness/M +ioctl +iodate/MGND +iodation/M +iodide/MS +iodinate/DNG +iodine/MS +iodize/GSD +ion's/I +ion/SMU +ionic/S +ionization's +ionization/SU +ionize/GNSRDJXZ +ionized/UC +ionizer's +ionizer/US +ionizes/U +ionizing/U +ionosphere/SM +ionospheric +iota/SM +ipecac/MS +ipso +irascibility/SM +irascible +irascibly +irate/RPYT +irateness/S +ire/MGDS +ireful +irenic/S +irides/M +iridescence/SM +iridescent/Y +iridium/MS +irids +iris/GDSM +irk/GDS +irksome/YP +irksomeness/SM +iron/DRMPSGJ +ironclad/S +ironer/M +ironic +ironical/YP +ironicalness/M +ironing/M +ironmonger/M +ironmongery/M +ironside/MS +ironstone/MS +ironware/SM +ironwood/SM +ironwork/MRS +ironworker/M +irony/SM +irradiate/XSDVNG +irradiation/M +irrational/YSP +irrationality/MS +irrationalness/M +irreclaimable +irreconcilability/MS +irreconcilable/PS +irreconcilableness/M +irreconcilably +irrecoverable/P +irrecoverableness/M +irrecoverably +irredeemable/S +irredeemably +irredentism/M +irredentist/M +irreducibility/M +irreducible +irreducibly +irreflexive +irrefutable +irrefutably +irregardless +irregular/YS +irregularity/SM +irrelevance/SM +irrelevancy/MS +irrelevant/Y +irreligious +irremediable/P +irremediableness/M +irremediably +irremovable +irreparable/P +irreparableness/M +irreparably +irreplaceable/P +irrepressible +irrepressibly +irreproachable/P +irreproachableness/M +irreproachably +irreproducibility +irreproducible +irresistibility/M +irresistible/P +irresistibleness/M +irresistibly +irresolute/PNXY +irresoluteness/SM +irresolution/M +irresolvable +irrespective/Y +irresponsibility/SM +irresponsible/PS +irresponsibleness/M +irresponsibly +irretrievable +irretrievably +irreverence/MS +irreverent/Y +irreversible +irreversibly +irrevocable/P +irrevocableness/M +irrevocably +irrigable +irrigate/DSXNG +irrigation/M +irritability/MS +irritable/P +irritableness/M +irritably +irritant/S +irritate/DSXNGV +irritated/Y +irritating/Y +irritation/M +irrupt/GVSD +irruption/SM +is +isinglass/MS +isl/GD +island/GZMRDS +islander/M +isle/MS +islet/SM +ism/MCS +isn't +isobar/MS +isobaric +isochronal/Y +isochronous/Y +isocline/M +isocyanate/M +isodine +isolate/SDXNG +isolation/M +isolationism/SM +isolationist/SM +isolationistic +isolator/MS +isomer/SM +isomeric +isomerism/SM +isometric/S +isometrically +isometrics/M +isomorph/M +isomorphic +isomorphically +isomorphism/MS +isoperimetrical +isopleth/M +isopleths +isosceles +isostatic +isotherm/MS +isothermal/Y +isotonic +isotope/SM +isotopic +isotropic +isotropically +isotropy/M +ispell/M +issuable +issuance/MS +issuant +issue/GMZDSR +issued/A +issuer/AMS +issues/A +issuing/A +isthmian/S +isthmus/SM +it'd +it'll +it/MUS +ital +italic/S +italicization/MS +italicize/GSD +italicized/U +itch/GMDS +itchiness/MS +itchy/RTP +item/MDSG +itemization/SM +itemize/GZDRS +itemized/U +itemizer/M +itemizes/A +iterate/ASDXVGN +iteration/M +iterative/YA +iterator/MS +itinerant/SY +itinerary/MS +its +itself +iv/M +ivory/SM +ivy/MDS +ix +j's +j/F +jab/SM +jabbed +jabber/JRDSZG +jabberer/M +jabbing +jabot/MS +jacaranda/MS +jack/GDRMS +jackal/SM +jackass/SM +jackboot/DMS +jackdaw/SM +jacket/GSMD +jacketed/U +jackhammer/MDGS +jackknife/MGSD +jackknives +jackpot/MS +jackrabbit/DGS +jackstraw/MS +jacquard/MS +jacuzzi +jade/MGDS +jaded/PY +jadedness/SM +jadeite/SM +jag/S +jagged/RYTP +jaggedness/SM +jaggers +jagging +jaguar/MS +jail/GZSMDR +jailbird/MS +jailbreak/SM +jailer/M +jalape�o/S +jalopy/SM +jalousie/MS +jam/SM +jamb/DMGS +jambalaya/MS +jamboree/MS +jammed/U +jamming/U +jangle/RSDGZ +jangler/M +jangly +janissary/MS +janitor/SM +janitorial +japan/SM +japanned +japanner +japanning +jape/DSMG +jar/MS +jardini�re/MS +jarful/S +jargon/SGDM +jarred +jarring/SY +jasmine/MS +jasper/MS +jato/SM +jaundice/DSMG +jaundiced/U +jaunt/MDGS +jauntily +jauntiness/MS +jaunty/SRTP +javelin/SDMG +jaw/SMDG +jawbone/SDMG +jawbreaker/SM +jawline +jay/SM +jaybird/SM +jaywalk/JSRDZG +jaywalker/M +jazz/MGDS +jazziness/M +jazzmen +jazzy/PTR +jct +jealous/PY +jealousness/M +jealousy/MS +jean/MS +jeep/GZSMD +jeer/SJDRMG +jeerer/M +jeering/Y +jeez +jehad's +jejuna +jejune/PY +jejuneness/M +jejunum/M +jell/GSD +jello's +jelly/SDMG +jellybean/SM +jellyfish/MS +jellying/M +jellylike +jellyroll/S +jemmy/M +jennet/SM +jenny/SM +jeopard +jeopardize/GSD +jeopardy/MS +jeremiad/SM +jerk/GSDRJ +jerker/M +jerkily +jerkin/SM +jerkiness/SM +jerkwater/S +jerky/RSTP +jerry/M +jerrybuilt +jersey/MS +jess/M +jessamine's +jest/DRSGZM +jester/M +jesting/Y +jet/MS +jetliner/MS +jetport/SM +jetsam/MS +jetted/M +jetting/M +jettison/DSG +jetty/RSDGMT +jewel/GZMRDS +jeweler/M +jewelery/S +jewellery's +jewelry/MS +jg/M +jib/MDSG +jibbed +jibbing +jibe/S +jiff/S +jiffy/SM +jig/MS +jigged +jigger/SDMG +jigging/M +jiggle/SDG +jiggly/TR +jigsaw/GSDM +jihad/SM +jilt/DRGS +jilter/M +jimmy/GSDM +jimsonweed/S +jingle/RSDG +jingler/M +jingly/TR +jingo/M +jingoism/SM +jingoist/SM +jingoistic +jinn/MS +jinni's +jinrikisha/SM +jinx/GMDS +jitney/MS +jitter/S +jitterbug/SM +jitterbugged +jitterbugger +jitterbugging +jittery/TR +jiujitsu's +jive/MGDS +job/SM +jobbed +jobber/MS +jobbery/M +jobbing/M +jobholder/SM +jobless/P +joblessness/MS +jock/GDMS +jockey/SGMD +jockstrap/MS +jocose/YP +jocoseness/MS +jocosity/SM +jocular/Y +jocularity/SM +jocund/Y +jocundity/SM +jodhpurs +joey/M +jog/S +jogged +jogger/SM +jogging/S +joggle/SRDG +joggler/M +john/SM +johnny/SM +johnnycake/SM +join/ADGFS +joined/U +joiner/FSM +joinery/MS +joint's +joint/EGDYPS +jointed/EYP +jointedness/ME +jointer/M +jointly/F +jointures +joist/GMDS +joke/MZDSRG +joker/M +jokey +jokier +jokiest +jokily +joking/Y +jollification/MS +jollily +jolliness/SM +jollity/MS +jolly/TSRDGP +jolt/DRGZS +jolter/M +jonquil/MS +josh/DSRGZ +josher/M +joss/M +jostle/SDG +jot/S +jotted +jotter/SM +jotting/SM +joule/SM +jounce/SDG +jouncy/RT +journal/GSDM +journalese/MS +journalism/SM +journalist/SM +journalistic +journalize/DRSGZ +journalized/U +journalizer/M +journey/DRMZSGJ +journeyer/M +journeyman/M +journeymen +joust/ZSMRDG +jouster/M +jovial/Y +joviality/SM +jowl/SMD +jowly/TR +joy/MDSG +joyful/PY +joyfuller +joyfullest +joyfulness/SM +joyless/PY +joylessness/MS +joyous/YP +joyousness/MS +joyridden +joyride/SRZMGJ +joyrode +joystick/S +jubilant/Y +jubilate/XNGDS +jubilation/M +jubilee/SM +juddered +juddering +judge's +judge/AGDS +judger/M +judgeship/SM +judgment/MS +judgmental/Y +judicable +judicatory/S +judicature/MS +judicial/Y +judiciary/S +judicious/IYP +judiciousness/SMI +judo/MS +jug/MS +jugate/F +jugful/SM +jugged +juggernaut/SM +jugging +juggle/RSDGZ +juggler/M +jugglery/MS +jugular/S +juice/GMZDSR +juicer/M +juicily +juiciness/MS +juicy/TRP +jujitsu/MS +juju/M +jujube/SM +jujutsu's +juke/GS +jukebox/SM +julep/SM +julienne/GSD +jumble/GSD +jumbo/MS +jump/GZDRS +jumper/M +jumpily +jumpiness/MS +jumpsuit/S +jumpy/PTR +jun +junco/MS +junction/IMESF +juncture/SFM +jungle/SDM +junior/MS +juniority/M +juniper/SM +junk/GZDRMS +junkerdom +junket/SMDG +junketeer/SGDM +junkie/RSMT +junkyard/MS +junta/MS +juridic +juridical/Y +juried +jurisdiction/SM +jurisdictional/Y +jurisprudence/SM +jurisprudent +jurisprudential/Y +jurist/MS +juristic +juror/MS +jury/IMS +jurying +juryman/M +jurymen +jurywoman/M +jurywomen +just/UPY +justed +juster/M +justest +justice/MIS +justiciable +justifiability/M +justifiable/U +justifiably/U +justification/M +justified/UA +justifier/M +justify/GDRSXZN +justing +justness's/U +justness/MS +justs +jut/S +jute/SM +jutted +jutting +juvenile/SM +juxtapose/SDG +juxtaposition/SM +k's/IE +k/FGEIS +kHz/M +kW +kWh +kabob/SM +kaboom +kabuki/SM +kaddish/S +kaffeeklatch +kaffeeklatsch/S +kaftan's +kaiser/MS +kale/MS +kaleidescope +kaleidoscope/SM +kaleidoscopic +kaleidoscopically +kamikaze/SM +kangaroo/SGMD +kaolin/MS +kaolinite/M +kapok/SM +kappa/MS +kaput/M +karakul/MS +karaoke/S +karat/SM +karate/MS +karma/SM +karmic +kart/MS +katakana +katydid/SM +kayak/SGDM +kayo/DMSG +kazoo/SM +kc/M +kcal/M +kebab/SM +keel/GSMDR +keelhaul/SGD +keen/GTSPYDR +keener/M +keening/M +keenness/MS +keep/GZJSR +keeper/M +keeping/M +keepsake/SM +keg/MS +kegged +kegging +kelp/GZMDS +kelvin/MS +ken/MS +kenned +kennel/GSMD +kenning +keno/M +kepi/SM +kept +keratin/MS +kerbside +kerchief/MDSG +kerned +kernel/GSMD +kerning +kerosene/MS +kestrel/SM +ketch/MS +ketchup/SM +ketone/M +ketosis/M +kettle/SM +kettledrum/SM +kettleful +key/SGMD +keyboard/RDMZGS +keyboardist/S +keyclick/SM +keyhole/MS +keynote/SRDZMG +keynoter/M +keypad/MS +keypunch/ZGRSD +keypuncher/M +keyring +keystone/SM +keystroke/SDMG +keyword/SM +kg +khaki/SM +khan/MS +kibble/GMSD +kibbutz/M +kibbutzim +kibitz/GRSDZ +kibitzer/M +kibosh/GMSD +kick/GZDRS +kickback/SM +kickball/MS +kicker/M +kickoff/SM +kickstand/MS +kicky/RT +kid/MS +kidded +kidder/SM +kiddie/SD +kidding/YM +kiddish +kiddo/SM +kiddy's +kiddying +kidless +kidnap/MSJ +kidnaper's +kidnaping's +kidnapped +kidnapper/SM +kidnapping/S +kidney/MS +kidskin/SM +kielbasa/SM +kielbasi +kier/I +kill/BJGZSDR +killdeer/SM +killer/M +killing/Y +killjoy/S +kiln/GDSM +kilo/SM +kilobaud/M +kilobit/S +kilobuck +kilobyte/S +kilocycle/MS +kilogauss/M +kilogram/MS +kilohertz/M +kilohm/M +kilojoule/MS +kiloliter/MS +kilometer/SM +kiloton/SM +kilovolt/SM +kilowatt/SM +kiloword +kilt/MDRGZS +kilter/M +kimono/MS +kin/MS +kind/PSYRT +kinda +kinder/U +kindergarten/MS +kinderg�rtner/SM +kindhearted/YP +kindheartedness/MS +kindle/AGRSD +kindler/M +kindliness's/U +kindliness/SM +kindling/M +kindly/TUPR +kindness's +kindness/US +kindred/S +kine/SM +kinematic/S +kinematics/M +kinesics/M +kinesthesis +kinesthetic/S +kinesthetically +kinetic/S +kinetically +kinetics/M +kinfolk/S +king/SGYDM +kingbird/M +kingdom/SM +kingfisher/MS +kinglet/M +kingliness/M +kingly/TPR +kingpin/MS +kingship/SM +kink/GSDM +kinkily +kinkiness/SM +kinky/PRT +kinsfolk/S +kinship/SM +kinsman/M +kinsmen/M +kinswoman/M +kinswomen +kiosk/SM +kip/MS +kipped +kipper/DMSG +kipping +kirk/GDMS +kirsch/S +kismet/SM +kiss/DSRBJGZ +kisser/M +kit/MDRGS +kitbag's +kitchen/GDRMS +kitchener/M +kitchenette/SM +kitchenware/SM +kite/SM +kiter/M +kith/MDG +kiths +kitsch/MS +kitschy +kitted +kitten/SGDM +kittenish/YP +kittenishness/M +kitting +kittiwakes +kitty/SM +kiwi/SM +kiwifruit/S +kl +klaxon/M +kleptomania/MS +kleptomaniac/SM +kludge/RSDGMZ +kludger/M +kludgey +klutz/SM +klutziness/S +klutzy/TRP +klystron/MS +km +kn +knack/SGZRDM +knacker/M +knackwurst/MS +knapsack/MS +knave/SM +knavery/MS +knavish/Y +knead/GZRDS +kneader/M +knee/DSM +kneecap/MS +kneecapped +kneecapping +kneeing +kneel/GRS +kneeler/M +kneepad/SM +knell/SMDG +knelt +knew +knick/ZR +knickerbocker/S +knickknack/SM +knife/DSGM +knight/MDYSG +knighthood/MS +knightliness/MS +knightly/P +knish/MS +knit/AU +knits +knitted +knitter/MS +knitting/SM +knitwear/M +knives/M +knob/MS +knobbly +knobby/RT +knock/GZSJRD +knockabout/M +knockdown/S +knocker/M +knockoff/S +knockout/MS +knockwurst's +knoll/MDSG +knot/MS +knothole/SM +knotted +knottiness/M +knotting/M +knotty/TPR +know/GRBSJ +knowable/U +knower/M +knowhow +knowing/RYT +knowingly/U +knowings/U +knowledge/SM +knowledgeable/P +knowledgeableness/M +knowledgeably +known/SU +knuckle/DSMG +knuckleball/R +knuckleduster +knucklehead/MS +knurl/DSG +koala/SM +kohlrabi/M +kohlrabies +kola/SM +kook/GDMS +kookaburra/SM +kookiness/S +kooky/PRT +kopeck/MS +kosher/DGS +kowtow/SGD +kph +kraal/SMDG +kraft/M +kraut/S! +kriegspiel/M +krill/MS +krone/RM +kronor +krypton/SM +kr�na/M +kr�nur +ks +kt +kuchen/MS +kudos/M +kudzu/SM +kumquat/SM +kurtosis/M +kvetch/DSG +kw +kyle/M +l's +l/JGVXT +la/MHLG +lab/SM +label's +label/GAZRDS +labeled/U +labeler/M +labellings/A +labia/M +labial/YS +labile +labiodental +labium/M +labor/RDMJSZG +laboratory/MS +labored's/U +labored/PMY +laboredness/M +laborer/M +laboring/MY +laborings/U +laborious/PY +laboriousness/MS +laborsaving +laburnum/SM +labyrinth/M +labyrinthine +labyrinths +lac/SGMDR +lace/MS +laced/U +lacer/M +lacerate/NGVXDS +laceration/M +laces/U +lacewing/MS +lachrymal/S +lachrymose +lacing/M +lack/GRDMS +lackadaisic +lackadaisical/Y +lacker/M +lackey/SMDG +lackluster/S +laconic +laconically +lacquer/ZGDRMS +lacquerer/M +lacrosse/MS +lactate/MNGSDX +lactation/M +lactational/Y +lacteal +lactic +lactose/MS +lacuna/M +lacunae +lacy/RT +lad/XGSJMND +ladder/GDMS +laddie/MS +lade/S +laded/U +laden/U +ladened +ladening +lading/M +ladle/SDGM +lady/SM +ladybird/SM +ladybug/MS +ladyfinger/SM +ladylike/U +ladylove/MS +ladyship/SM +laetrile/S +lag/ZSR +lager/DMG +laggard/MYSP +laggardness/M +lagged +lagging/MS +lagniappe/SM +lagoon/MS +laid/AI +lain +lair/GDMS +laird/MS +laissez +laity/SM +lake/DSRMG +laker/M +lakeside +lallygag/S +lallygagged +lallygagging +lam/MDRSTG +lama/SM +lamasery/MS +lamb/SRDMG +lambada/S +lambaste/SDG +lambda/SM +lambency/MS +lambent/Y +lambkin/MS +lambskin/MS +lambswool +lame/SPY +lamebrain/SM +lamed/M +lameness/MS +lament/DGSB +lamentable/P +lamentableness/M +lamentably +lamentation/SM +lamented/U +lamina/M +laminae +laminar +laminate/XNGSD +lamination/M +lammed +lammer +lamming +lamp/SGMRD +lampblack/SM +lamplight/ZRMS +lamplighter/M +lampoon/RDMGS +lampooner/M +lamppost/SM +lamprey/MS +lampshade/MS +lanai/SM +lance/SRDGMZ +lancer/M +lancet/MS +land/SMRDJGZ +landau/MS +lander/I +landfall/SM +landfill/DSG +landforms +landhold/JGZR +landholder/M +landing/M +landlady/MS +landless +landlines +landlocked +landlord/MS +landlubber/SM +landmark/GSMD +landmass/MS +landowner/MS +landownership/M +landowning/SM +lands/I +landscape/GMZSRD +landscaper/M +landslid/G +landslide/MS +landslip +landsman/M +landsmen +landward/S +lane/SM +language/MS +languid/PY +languidness/MS +languish/SRDG +languisher/M +languishing/Y +languor/SM +languorous/Y +lank/PTYR +lankiness/SM +lankness/MS +lanky/PRT +lanolin/MS +lantern/GSDM +lanthanide/M +lanthanum/MS +lanyard/MS +lap/SM +lapboard/MS +lapdog/S +lapel/MS +lapidary/MS +lapin/MS +lapped +lappet/MS +lapping +laps/SRDG +lapse/KSDMG +lapsed/A +lapser/MA +lapses/A +lapsing/A +laptop/SM +lapwing/MS +larboard/MS +larcenist/S +larcenous +larceny/MS +larch/MS +lard/MRDSGZ +larder/M +lardy/RT +large/SRTYP +largehearted +largemouth +largeness/SM +largess/SM +largish +largo/S +lariat/MDGS +lark/GRDMS +larker/M +larkspur/MS +larva/M +larvae +larval +laryngeal/YS +larynges +laryngitides +laryngitis/M +larynx/M +las/SRZG +lasagna/S +lasagne's +lascivious/YP +lasciviousness/MS +lase +laser/M +lash/JGMSRD +lashed/U +lasher/M +lashing/M +lass/SM +lassie/SM +lassitude/MS +lasso/GRDMS +lassoer/M +last/JGSYRD +laster/M +lasting/PY +lastingness/M +lat/SDRT +latch's +latch/UGSD +latching/M +latchkey/SM +late/KA +latecomer/SM +lated/A +lately +latency/MS +lateness/MS +latent/YS +later/A +lateral/GDYS +lateralization +latest/S +latex/MS +lath/MSRDGZ +lathe/M +lather/RDMG +latherer/M +lathery +lathing/M +laths +latices/M +latish +latitude/SM +latitudinal/Y +latitudinarian/S +latitudinary +latrine/MS +latte/SR +latter/YM +lattice/SDMG +latticework/MS +latticing/M +laud/RDSBG +laudably +laudanum/MS +laudatory +lauder/M +lauds/M +laugh/BRDZGJ +laughable/P +laughableness/M +laughably +laugher/M +laughing/MY +laughingstock/SM +laughs +laughter/MS +launch/AGSD +launcher/MS +launching/S +launchpad/S +launder/SDRZJG +laundered/U +launderer/M +launderette/MS +laundress/MS +laundrette/S +laundromat/S +laundry/MS +laundryman/M +laundrymen +laundrywoman/M +laundrywomen +laura/M +laureate/DSNG +laureateship/SM +laurel/SGMD +lava/SM +lavage/MS +lavaliere/MS +lavatory/MS +lave/GDS +lavender/MDSG +lavish/SRDYPTG +lavishness/MS +law/SMDG +lawbreaker/SM +lawbreaking/MS +lawful/PUY +lawfulness/SMU +lawgiver/MS +lawgiving/M +lawless/PY +lawlessness/MS +lawmaker/MS +lawmaking/SM +lawman/M +lawmen +lawn/SM +lawnmower/S +lawrencium/SM +lawsuit/MS +lawyer/DYMGS +lax/PTSRY +laxative/PSYM +laxativeness/M +laxer/A +laxes/A +laxity/SM +laxness/SM +lay/CZGSR +layabout/MS +layaway/S +layer's/IC +layer/GJDM +layered/C +layering/M +layette/SM +layman/M +laymen +layoff/MS +layout/SM +layover/SM +laypeople +layperson/S +lays/AI +layup/MS +laywoman/M +laywomen +laze/DSG +lazily +laziness/MS +lazuli/M +lazy/PTSRDG +lazybones/M +lb +lbs +lea/MS +leach/SDG +leachate +lead/SGZXJRDN +leaded/U +leaden/PGDY +leadenness/M +leader/M +leaderless +leadership/MS +leadsman/M +leadsmen +leaf/GSDM +leafage/MS +leafhopper/M +leafiness/M +leafless +leaflet/SDMG +leafstalk/SM +leafy/PTR +league/RSDMZG +leaguer/M +leak/GSRDM +leakage/SM +leaker/M +leakiness/MS +leaky/PRT +lean/YRDGTJSP +leaner/M +leaning/M +leanness/MS +leap/RDGZS +leaper/M +leapfrog/SM +leapfrogged +leapfrogging +learn/SZGJRD +learned/UA +learnedly +learnedness/M +learner/M +learning/M +learns/UA +leas/SRDGZ +lease's +lease/ARSDG +leaseback/MS +leasehold/SRMZ +leaseholder/M +leaser/MA +leash's +leash/UGSD +leasing/M +least/S +leastwise +leather/MDSG +leatherette/S +leathern +leatherneck/SM +leathery +leave/SRDJGZ +leaven/DMJGS +leavened/U +leavening/M +leaver/M +leaves/M +leaving/M +lebensraum +lecher/DMGS +lecherous/YP +lecherousness/MS +lechery/MS +lecithin/SM +lectern/SM +lecture/RSDZMG +lecturer/M +lectureship/SM +led +ledge/SRMZ +ledger/DMG +lee/MZRS +leech/MSDG +leek/SM +leer/DG +leeriness/MS +leering/Y +leery/PTR +leeward/S +leeway/MS +left/TRS +leftism/SM +leftist/SM +leftmost +leftover/MS +leftward/S +lefty/SM +leg/MS +legacy/MS +legal/SY +legalese/MS +legalism/SM +legalistic +legality/MS +legalization/MS +legalize/DSG +legalized/U +legate's/C +legate/AXCNGSD +legatee/MS +legation/AMC +legato/SM +legend/SM +legendarily +legendary/S +legerdemain/SM +legged +legginess/MS +legging/MS +leggy/PRT +leghorn/SM +legibility/MS +legible +legibly +legion/SM +legionary/S +legionnaire/SM +legislate/SDXVNG +legislation/M +legislative/SY +legislator/SM +legislature/MS +legit/S +legitimacy/MS +legitimate/SDNGY +legitimation/M +legitimatize/SDG +legitimization/MS +legitimize/RSDG +legless +legman/M +legmen +legroom/MS +legstraps +legume/SM +leguminous +legwork/SM +lei/MS +leisure/SDYM +leisureliness/MS +leisurely/P +leisurewear +leitmotif/SM +leitmotiv/MS +lemma/MS +lemme/GJ +lemming/M +lemon/GSDM +lemonade/SM +lemony +lemur/MS +lend/SRGZ +lender/M +length/MNYX +lengthen/GRD +lengthener/M +lengthily +lengthiness/MS +lengths +lengthwise +lengthy/TRP +lenience/S +leniency/MS +lenient/SY +lenitive/S +lens/SRDMJGZ +lent/A +lenticular +lentil/SM +lento/S +leonine +leopard/MS +leopardess/SM +leopardskin +leotard/MS +leper/SM +leprechaun/SM +leprosy/MS +leprous +lepta +lepton/SM +lesbian/MS +lesbianism/MS +lesion/DMSG +less/U +lessee/MS +lessen/GDS +lesser +lesses +lessing +lesson/DMSG +lessor/MS +lest/R +let/ISM +letdown/SM +lethal/YS +lethality/M +lethargic +lethargically +lethargy/MS +letter/JSZGRDM +letterbox/S +lettered/U +letterer/M +letterhead/SM +lettering/M +letterman/M +lettermen +letterpress/MS +letting/S +lettuce/SM +letup/MS +leukemia/SM +leukemic/S +leukocyte/MS +levee/SDM +leveeing +level/STZGRDYP +leveled/U +leveler/M +levelheaded/P +levelheadedness/S +leveling/U +levelness/SM +lever/SDMG +leverage/MGDS +leviathan/MS +levier/M +levitate/XNGDS +levitation/M +levity/MS +levy/SRDZG +lewd/PYRT +lewdness/MS +lewis/M +lex +lexeme/MS +lexical/Y +lexicographer/MS +lexicographic +lexicographical/Y +lexicography/SM +lexicon/SM +lg +liability/SAM +liable/AP +liaise/GSD +liaison/SM +liar/MS +lib/MS +libation/SM +libbed +libbing +libel/GMRDSZ +libeler/M +libelous/Y +liberal/YSP +liberalism/MS +liberality/MS +liberalization/SM +liberalize/GZSRD +liberalized/U +liberalizer/M +liberalness/MS +liberate/NGDSCX +liberation/MC +liberationists +liberator/SCM +libertarian/MS +libertarianism/M +libertine/MS +liberty/MS +libidinal +libidinous/PY +libidinousness/M +libido/MS +librarian/MS +library/MS +libretoes +libretos +librettist/MS +libretto/MS +lice/M +license/MGBRSD +licensed/AU +licensee/SM +licenser/M +licenses/A +licensing/A +licensor/M +licentiate/MS +licentious/PY +licentiousness/MS +lichee's +lichen/DMGS +licit/Y +lick/GRDSJ +licked/U +licker/M +lickerish +licking/M +licorice/SM +lid/MS +lidded +lidding +lidless +lido/MS +lie/DRS +lied/MR +lief/TSR +liefs/A +liege/SR +lien/SM +lier/IMA +lies/A +lieu/SM +lieut +lieutenancy/MS +lieutenant/SM +life/MZR +lifeblood/SM +lifeboat/SM +lifebuoy/S +lifeforms +lifeguard/MDSG +lifeless/PY +lifelessness/SM +lifelike/P +lifelikeness/M +lifeline/SM +lifelong +lifer/M +lifesaver/SM +lifesaving/S +lifespan/S +lifestyle/S +lifetaking +lifetime/MS +lifework/MS +lift/GZMRDS +lifter/M +liftoff/MS +ligament/MS +ligand/MS +ligate/XSDNG +ligation/M +ligature/DSGM +light's +light/ADSCG +lighted/U +lighten/ZGDRS +lightener/M +lightening/M +lighter/CM +lightered +lightering +lighters +lightest +lightface/SDM +lightheaded +lighthearted/PY +lightheartedness/MS +lighthouse/MS +lighting/MS +lightly +lightness/MS +lightning/SMD +lightproof +lightship/SM +lightweight/S +ligneous +lignite/MS +lignum +likability/MS +likable/P +likableness/MS +like/USPBY +likeability's +liked/E +likelihood/MSU +likely/UPRT +liken/GSD +likeness/MSU +liker's +liker/E +likes/E +likest +likewise +liking/SM +lilac/MS +lilliputian/S +lilt/MDSG +lilting/YP +lily/MSD +limb/SGZRDM +limber/RDYTGP +limbered/U +limberness/SM +limbers/U +limbic +limbless +limbo/GDMS +lime/DSMG +limeade/SM +limekiln/M +limelight/DMGS +limerick/SM +limestone/SM +limit's +limit/CSZGRD +limitability +limitably +limitation/MCS +limited/PSY +limitedly/U +limitedness/M +limiter/M +limiting/S +limitless/PY +limitlessness/SM +limn/GSD +limo/S +limousine/SM +limp/SGTPYRD +limper/M +limpet/SM +limpid/YP +limpidity/MS +limpidness/SM +limpness/MS +limy/TR +linage/MS +linchpin/MS +linden/MS +line's +line/AGDS +lineage/SM +lineal/Y +lineament/MS +linear/Y +linearity/MS +linearize/SDGNB +linebacker/SM +lined/U +linefeed +lineman/M +linemen +linen/SM +liner/SM +linesman/M +linesmen +lineup/S +ling/ZR +linger/ZGJRD +lingerer/M +lingerie/SM +lingering/Y +lingo/M +lingoes +lingua/M +lingual/SY +linguine +linguini's +linguist/SM +linguistic/S +linguistically +linguistics/M +liniment/MS +lining/SM +link's +link/USGD +linkable +linkage/SM +linked/A +linker/S +linking/S +linkup/S +linnet/SM +lino/M +linoleum/SM +linseed/SM +lint/SMR +lintel/SM +linter/M +linty/RST +lion/MS +lioness/SM +lionhearted +lionization/SM +lionize/ZRSDG +lionizer/M +lip/MS +lipase/M +lipid/MS +liposuction/S +lipped +lipper +lipping +lippy/TR +lipread/GSRJ +lipstick/MDSG +liq +liquefaction/SM +liquefier/M +liquefy/DRSGZ +liqueur/DMSG +liquid/SPMY +liquidate/GNXSD +liquidation/M +liquidator/SM +liquidity/SM +liquidize/ZGSRD +liquidizer/M +liquidness/M +liquor/SDMG +liquorice/SM +liquorish +lira/M +lire +lisle/SM +lisp/MRDGZS +lisper/M +lissome/P +lissomeness/M +lissomness/M +list/JMRDNGZXS +listed/U +listen/ZGRD +listener/M +lister/M +listing/M +listless/PY +listlessness/SM +lit/RZS +litany/MS +litchi/SM +lite/S +liter/M +literacy/MS +literal/PYS +literalism/M +literalistic +literalness/MS +literariness/SM +literary/P +literate/YNSP +literati +literation/M +literature/SM +lithe/PRTY +litheness/SM +lithesome +lithium/SM +lithograph/DRMGZ +lithographer/M +lithographic +lithographically +lithographs +lithography/MS +lithology/M +lithosphere/MS +lithospheric +litigant/MS +litigate/NGXDS +litigation/M +litigator/SM +litigious/PY +litigiousness/MS +litmus/SM +litotes/M +litter/SZGRDM +litterbug/SM +little/RSPT +littleneck/M +littleness/SM +littoral/S +litt�rateur/S +liturgic/S +liturgical/Y +liturgics/M +liturgist/MS +liturgy/SM +livability/MS +livable/U +livableness/M +livably +live/YHZTGJDSRPB +lived/A +livelihood/SM +liveliness/SM +livelong/S +lively/RTP +liven/SDG +liveness/M +liver's +liver/CSGD +liveried +liverish +liverwort/SM +liverwurst/SM +livery/CMS +liveryman/MC +liverymen/C +lives's +lives/A +livestock/SM +livid/YP +lividness/M +living/YP +livingness/M +lizard/MS +ll/C +llama/SM +llano/SM +lo +load's/A +load/SURDZG +loadable +loaded/A +loader/MU +loading/MS +loads/A +loadstar's +loadstone's +loaf/SRDMGZ +loafer/M +loam/SMDG +loamy/RT +loan/SGZRDMB +loaner/M +loaning/M +loansharking/S +loanword/S +loath/JPSRDYZG +loathe +loather/M +loathing/M +loathness/M +loathsome/PY +loathsomeness/MS +loaves/M +lob/MDSG +lobar +lobbed +lobber/MS +lobbing +lobby/GSDM +lobbyist/MS +lobe/SM +lobotomist +lobotomize/GDS +lobotomy/MS +lobster/MDGS +lobular/Y +lobularity +lobule/SM +local/SGDY +locale/MS +localisms +locality/MS +localization/MS +localize/ZGDRS +localized/U +localizer/M +localizes/U +locatable +locate/AXESDGN +locater/M +location/EMA +locational/Y +locative/S +locator's +loch/M +lochs +loci/M +lock's +lock/UGSD +lockable +locked/A +locker/SM +locket/SM +locking/S +lockjaw/SM +locknut/M +lockout/MS +locksmith/MG +locksmithing/M +locksmiths +lockstep/S +lockup/MS +loco/SDMG +locomotion/SM +locomotive/YMS +locomotor +locomotory +locoweed/MS +locus/M +locust/SM +locution/MS +lode/SM +lodestar/MS +lodestone/MS +lodge/GMZSRDJ +lodged/E +lodgepole +lodger/M +lodges/E +lodging/M +lodgment/M +loft/SGMRD +lofter/M +loftily +loftiness/SM +lofty/PTR +log's/K +log/SM +loganberry/SM +logarithm/MS +logarithmic +logarithmically +logbook/MS +loge/SMNX +logged/U +logger/SM +loggerhead/SM +loggia/SM +logging/MS +logic/SM +logical/SPY +logicality/MS +logicalness/M +logician/SM +login/S +logion/M +logistic/MS +logistical/Y +logjam/SM +logo/SM +logotype/MS +logout +logrolling/SM +logy/RT +loin/SM +loincloth/M +loincloths +loiter/RDJSZG +loiterer/M +loll/RDGS +loller/M +lollipop/MS +lolly/SM +lone/PYZR +loneliness/SM +lonely/TRP +loneness/M +loner/M +lonesome/PSY +lonesomeness/MS +long/JGTYRDPS +longboat/MS +longbow/SM +longed/K +longeing +longer/K +longevity/MS +longhair/SM +longhand/SM +longhorn/SM +longing/MY +longish +longitude/MS +longitudinal/Y +longness/M +longs/K +longshoreman/M +longshoremen +longsighted +longstanding +longsword +longterm +longtime +longueur/SM +longways +longword/SM +loofah/M +loofahs +look/GZRDS +lookahead +lookalike/S +looker/M +lookout/MS +lookup/SM +loom/MDGS +looming/M +loon/MS +loony/SRT +loop/MRDGS +looper/M +loophole/MGSD +loopy/TR +loose/SRDPGTY +loosed/U +looseleaf +loosen/UDGS +loosener/M +looseness/MS +looses/U +loosing/M +loot/MRDGZS +looter/M +lop/SDRG +lope/S +loper/M +lopped +lopper/MS +lopping +lopsided/YP +lopsidedness/SM +loquacious/YP +loquaciousness/MS +loquacity/SM +lord/MYDGS +lording/M +lordliness/SM +lordly/PTR +lordship/SM +lore/MS +lorgnette/SM +loris/SM +lorn +lorry/SM +lorryload/S +lose/ZGJBSR +loser/M +loss/SM +lossage +lossless +lossy/RT +lost/P +lot/MS +lotion/MS +lotted +lotter +lottery/MS +lotting +lotto/MS +lotus/SM +loud/YRNPT +louden/DG +loudhailer/S +loudly/RT +loudmouth/DM +loudmouths +loudness/MS +loudspeaker/SM +loudspeaking +lounge/SRDZG +lounger/M +lour/GSD +louse's +louse/CSDG +lousewort/M +lousily +lousiness/MS +lousy/PRT +lout/SGMD +loutish/YP +loutishness/M +louver/DMS +lovable/U +lovableness/MS +lovably +love/DSRMYZGJB +lovebird/SM +lovechild +loved/U +loveless/YP +lovelessness/M +lovelies +loveliness/UM +lovelinesses +lovelorn/P +lovelornness/M +lovely/URPT +lovemaking/SM +lover/YMG +lovesick +lovestruck +loving/U +lovingly +lovingness/M +low/PDRYSZTG +lowborn +lowboy/SM +lowbrow/MS +lowdown/S +lower/DG +lowercase/GSD +lowermost +lowish +lowland/RMZS +lowlife/SM +lowlight/MS +lowliness/MS +lowly/PTR +lowness/MS +lox/MDSG +loyal/EY +loyaler +loyalest +loyalism/SM +loyalist/SM +loyalty/EMS +lozenge/SDM +ls +ltd +luau/MS +lubber/YMS +lube/DSMG +lubricant/SM +lubricate/VNGSDX +lubrication/M +lubricator/MS +lubricious/Y +lubricity/SM +lucent/Y +lucid/YP +lucidity/MS +lucidness/MS +luck/GSDM +luckier/U +luckily/U +luckiness/UMS +luckless +lucky/RSPT +lucrative/YP +lucrativeness/SM +lucre/MS +lucubrate/GNSDX +lucubration/M +ludicrous/PY +ludicrousness/SM +ludo/M +luff/GSDM +lug/RS +luge/MC +luggage/SM +lugged +lugger/SM +lugging +lugsail/SM +lugubrious/YP +lugubriousness/MS +lukewarm/PY +lukewarmness/SM +lull/SDG +lullaby/GMSD +lulu/M +lumbago/SM +lumbar/S +lumber/RDMGZSJ +lumberer/M +lumbering/M +lumberjack/MS +lumberman/M +lumbermen +lumberyard/MS +lumen/M +luminance/M +luminary/MS +luminescence/SM +luminescent +luminosity/MS +luminous/YP +luminousness/M +lummox/MS +lump/SGMRDN +lumper/M +lumpiness/MS +lumpish/YP +lumpishness/M +lumpy/TPR +lunacy/MS +lunar/S +lunary +lunate/YND +lunatic/S +lunation/M +lunch/GMRSD +luncheon/SMDG +luncheonette/SM +luncher/M +lunchpack +lunchroom/MS +lunchtime/MS +lune/M +lung/SGRDM +lunge/MS +lunger/M +lungfish/SM +lungful +lunkhead/SM +lupine/SM +lupus/SM +lurch/RSDG +lurcher/M +lure/DSRG +lurer/M +lurex +lurid/YP +luridness/SM +lurk/GZSRD +lurker/M +luscious/PY +lusciousness/MS +lush/YSRDGTP +lushness/MS +lust/MRDGZS +luster/GDM +lustering/M +lusterless +lustful/PY +lustfulness/M +lustily +lustiness/MS +lustrous/PY +lustrousness/M +lusty/PRT +lutanist/MS +lute/DSMG +lutenist/MS +lutetium/MS +luting/M +luxe/MS +luxuriance/MS +luxuriant/Y +luxuriate/GNSDX +luxuriation/M +luxurious/PY +luxuriousness/SM +luxury/MS +lyceum/MS +lychee's +lycopodium/M +lye/JSMG +lying/Y +lymph/M +lymphatic/S +lymphocyte/SM +lymphoid +lymphoma/MS +lymphs +lynch/ZGRSDJ +lyncher/M +lynching/M +lynx/MS +lyre/SM +lyrebird/MS +lyric/S +lyrical/YP +lyricalness/M +lyricism/SM +lyricist/SM +lysine/M +m's/K +m/ASK +ma'am +ma/MH +mac/SGMDR +macabre/Y +macadam/SM +macadamize/SDG +macaque/SM +macaroni/SM +macaroon/MS +macaw/SM +mace/MS +macer/M +macerate/DSXNG +maceration/M +machete/SM +machinate/SDXNG +machination/M +machine/MGSDB +machinelike +machinery/SM +machinist/MS +machismo/SM +macho/S +macintosh's +mack/M +mackerel/SM +mackinaw/SM +mackintosh/SM +macram�/S +macro/SM +macrobiotic/S +macrobiotics/M +macrocosm/MS +macrodynamic +macroeconomic/S +macroeconomics/M +macromolecular +macromolecule/SM +macron/MS +macrophage/SM +macroscopic +macroscopically +macrosimulation +macrosocioeconomic +mad/PSY +madam/SM +madame/M +madcap/S +madded +madden/GSD +maddening/Y +madder/MS +maddest +madding +made/AU +mademoiselle/MS +madhouse/SM +madman/M +madmen +madness/SM +madras/SM +madrigal/MSG +madwoman/M +madwomen +maelstrom/SM +maestro/MS +mafia/S +mafiosi +mafioso/M +mag/S +magazine/DSMG +magenta/MS +magged +magging +maggot/MS +maggoty/RT +magi +magic/SM +magical/Y +magician/MS +magicked +magicking +magisterial/Y +magistracy/MS +magistrate/MS +magma/SM +magnanimity/SM +magnanimosity +magnanimous/PY +magnate/SM +magnesia/MS +magnesite/M +magnesium/SM +magnet/SM +magnetic/S +magnetically +magnetics/M +magnetism/SM +magnetite/SM +magnetizable +magnetization/ASCM +magnetize/CGDS +magnetized/U +magneto/MS +magnetodynamics +magnetohydrodynamical +magnetohydrodynamics/M +magnetometer/MS +magnetosphere/M +magnetron/M +magnification/M +magnificence/SM +magnificent/Y +magnified/U +magnify/DRSGNXZ +magniloquence/MS +magniloquent +magnitude/SM +magnolia/SM +magnum/SM +magpie/SM +maharajah/M +maharajahs +maharanee's +maharani/MS +maharishi/SM +mahatma/SM +mahjong's +mahogany/MS +mahout/SM +maid/SMNX +maiden/YM +maidenhair/MS +maidenhead/SM +maidenhood/SM +maidenly/P +maidservant/MS +maier +mail/BSJGZMRD +mailbag/MS +mailbox/MS +mailer/M +maillot/SM +mailman/M +mailmen +maim/SGZRD +maimed/P +maimedness/M +maimer/M +main/SA +mainbrace/M +mainframe/MS +mainland/SRMZ +mainlander/M +mainline/RSDZG +mainliner/M +mainly +mainmast/SM +mains/M +mainsail/SM +mainspring/SM +mainstay/MS +mainstream/DRMSG +maintain/BRDZGS +maintainability +maintainable/U +maintained/U +maintainer/M +maintenance/SM +maintop/SM +maiolica's +maisonette/MS +maize/MS +majestic +majestically +majesty/MS +majolica/SM +major/DMGS +majordomo/S +majorette/SM +majority/SM +makable +make/UGSA +makefile/S +makeover/S +maker/SM +makeshift/S +makeup/MS +making/SM +malachite/SM +maladapt/DV +maladjust/DLV +maladjustment/MS +maladministration +maladroit/YP +maladroitness/MS +malady/MS +malaise/SM +malamute/SM +malaprop +malapropism/SM +malaria/MS +malarial +malarious +malarkey/SM +malathion/S +malcontent/SMD +malcontented/PY +malcontentedness/M +male/PSM +maledict +malediction/MS +malefaction/MS +malefactor/MS +malefic +maleficence/MS +maleficent +maleness/MS +malevolence/S +malevolencies +malevolent/Y +malfeasance/SM +malfeasant +malformation/MS +malformed +malfunction/SDG +malice/MGSD +malicious/YU +maliciousness/MS +malign/GSRDYZ +malignancy/SM +malignant/YS +malignity/MS +malinger/GZRDS +malingerer/M +mall/SGMD +mallard/SM +malleability/SM +malleable/P +malleableness/M +mallet/MS +mallow/MS +malnourished +malnutrition/SM +malocclusion/MS +malodorous +malposed +malpractice/SM +malt/SGMD +malted/S +malting/M +maltose/SM +maltreat/GDSL +maltreatment/S +malty/RT +mama/SM +mamba/SM +mambo/GSDM +mamma's +mammal/SM +mammalian/SM +mammary +mammogram/S +mammography/S +mammon/SM +mammoth/M +mammoths +mammy/SM +man's +man/USY +manacle/SDMG +manage/ZLGRSD +manageability/S +manageable/U +manageableness +managed/U +management/SM +manager/M +manageress/M +managerial/Y +managership/M +mananas +manatee/SM +manciple/M +mandala/SM +mandamus/GMSD +mandarin/MS +mandate/SDMG +mandatory/S +mandible/MS +mandibular +mandolin/MS +mandrake/MS +mandrel/SM +mandrill/SM +mane/MDS +maneuver/MRDSGB +maneuverability/MS +maneuverer/M +manful/Y +manganese/MS +mange/GMSRDZ +manger/M +manginess/S +mangle/RSDG +mangler/M +mango/M +mangoes +mangrove/MS +mangy/PRT +manhandle/GSD +manhole/MS +manhood/MS +manhunt/SM +mania/SM +maniac/SM +maniacal/Y +manic/S +manically +manicure/MGSD +manicurist/SM +manifest/YDPGS +manifestation/SM +manifesto/GSDM +manifold/GPYRDMS +manifolder/M +manifoldness/M +manikin/MS +manila/S +manilla's +manioc/SM +manipulability +manipulable +manipulate/SDXBVGN +manipulative/PM +manipulator/MS +manipulatory +mankind/M +manlike +manliness's/U +manliness/SM +manly/URPT +manna/MS +manned/U +mannequin/MS +manner/SDYM +mannered/U +mannerism/SM +mannerist/M +mannerliness/MU +mannerly/UP +mannikin's +manning/U +mannish/YP +mannishness/SM +manometer/SM +manor/MS +manorial +manpower/SM +manqu�/M +mans/S +mansard/SM +manse/XNM +manservant/M +mansion/M +manslaughter/SM +manta/MS +mantel/SM +mantelpiece/MS +mantes +mantilla/MS +mantis/SM +mantissa/SM +mantle's +mantle/ESDG +mantling/M +mantra/MS +mantrap/SM +manual/SMY +manufacture/JZGDSR +manufacturer/M +manumission/MS +manumit/S +manumitted +manumitting +manure/RSDMZG +manuscript/MS +many +man�ge/GSD +map/SM +maple/MS +mapmaker/S +mappable +mapped/UA +mapper/S +mapping/MS +maps/AU +mar/S +marabou/MS +marabout's +maraca/MS +maraschino/SM +marathon/MRSZ +marathoner/M +maraud/ZGRDS +marauder/M +marble/JRSDMG +marbleize/GSD +marbler/M +marbling/M +march/RSDZG +marcher/M +marchioness/SM +mare/MS +margarine/MS +margarita/SM +margin/GSDM +marginal/YS +marginalia +marginality +marginalization +marginalize/SDG +maria/M +mariachi/SM +marigold/MS +marijuana/SM +marimba/SM +marina/MS +marinade/MGDS +marinara/SM +marinate/NGXDS +marination/M +marine/ZRS +mariner/M +marionette/MS +marital/Y +maritime/R +marjoram/SM +mark/GZRDMBSJ +markdown/SM +marked/AU +markedly +marker/M +market/GSMRDJBZ +marketability/SM +marketable/U +marketeer/S +marketer/M +marketing/M +marketplace/MS +marking/M +markka/M +markkaa +marks/A +marksman/M +marksmanship/S +marksmen +markup/SM +marl/MDSG +marlin/SM +marlinespike/SM +marmalade/MS +marmoreal +marmoset/MS +marmot/SM +maroon/GRDS +marque/SM +marquee/MS +marquess/MS +marquetry/SM +marquis/SM +marquise/M +marquisette/MS +marred/U +marriage/ASM +marriageability/SM +marriageable +married/US +marring +marrow/GDMS +marrowbone/MS +marry/SDGA +marsh/MS +marshal/GMDRSZ +marshaller +marshallings +marshiness/M +marshland/MS +marshmallow/SM +marshy/PRT +marsupial/MS +mart/MDNGXS +marten/M +martial/Y +martin/SM +martinet/SM +martingale/MS +martini/MS +martyr/GDMS +martyrdom/SM +marvel/DGS +marvelous/PY +marzipan/SM +mas/SRZ +masc +mascara/SGMD +mascot/SM +masculine/PYS +masculineness/M +masculinity/SM +maser/M +mash/JGZMSRD +mask/GZSRDMJ +masked/U +masker/M +masks/U +masochism/MS +masochist/MS +masochistic +masochistically +mason/SDMG +masonic +masonry/MS +masque/RSMZ +masquer/M +masquerade/RSDGMZ +masquerader/M +mass/VGSD +massacre/DRSMG +massage/SRDMG +massager/M +masseur/MS +masseuse/SM +massif/SM +massing/R +massive/YP +massiveness/SM +massless +mast/GZSMRD +mastectomy/MS +master/JGDYM +masterclass +mastered/A +masterful/YP +masterfulness/M +masterliness/M +masterly/P +mastermind/GDS +masterpiece/MS +mastership/M +masterstroke/MS +masterwork/S +mastery/MS +masthead/SDMG +mastic/SM +masticate/SDXGN +mastication/M +mastiff/MS +mastodon/MS +mastoid/S +masturbate/SDNGX +masturbation/M +masturbatory +mat/SJGMDR +matador/SM +match's/A +match/BMRSDZGJ +matchable/U +matchbook/SM +matchbox/SM +matched/UA +matcher/M +matches/A +matchless/Y +matchlock/MS +matchmake/GZJR +matchmaker/M +matchmaking/M +matchplay +matchstick/MS +matchwood/SM +mate/IMS +mated/U +mater/M +material/SPYM +materialism/SM +materialist/SM +materialistic +materialistically +materiality/M +materialization/SM +materialize/CDS +materialized/A +materializer/SM +materializes/A +materializing +materialness/M +maternal/Y +maternity/MS +mates/U +math/M +mathematic/S +mathematical/Y +mathematician/SM +mathematics/M +maths +mating/M +matins/M +matin�e/S +matriarch/M +matriarchal +matriarchs +matriarchy/MS +matrices +matricidal +matricide/MS +matriculate/XSDGN +matriculation/M +matrimonial/Y +matrimony/SM +matrix/M +matron/YMS +matt's +matte/JGMZSRD +matter/GDM +matting/M +mattins's +mattock/MS +mattress/MS +maturate/DSNGVX +maturation/M +maturational +mature/RSDTPYG +matureness/M +maturer/M +maturity/MS +matzo/SHM +matzot +mat�riel/MS +maudlin/Y +maul/RDGZS +mauler/M +maunder/GDS +mausoleum/SM +mauve/SM +maven/S +maverick/SMDG +mavin's +maw/SGMD +mawkish/PY +mawkishness/SM +max/GDS +maxi/S +maxilla/M +maxillae +maxillary/S +maxim/SM +maxima's +maximal/SY +maximality +maximization/SM +maximize/RSDZG +maximizer/M +maximum/MYS +maxwell/M +may/EGS +maybe/S +mayday/S +mayer +mayest +mayflower/SM +mayfly/MS +mayhap +mayhem/MS +mayn't +mayo/S +mayonnaise/MS +mayor/MS +mayoral +mayoralty/MS +mayoress/MS +mayorship/M +maypole/MS +mayst +maze/MGDSR +mazed/YP +mazedness/SM +mazurka/SM +ma�ana/M +mdse +me/G +mead/SM +meadow/MS +meadowland +meadowlark/SM +meadowsweet/M +meager/PY +meagerness/SM +meagres +meal/MDGS +mealiness/MS +mealtime/MS +mealy/PRST +mealybug/S +mealymouthed +mean/YRGJTPS +meander/JDSG +meaneing +meanie/MS +meaning/M +meaningful/YP +meaningfulness/SM +meaningless/PY +meaninglessness/SM +meanness/S +means/M +meant/U +meantime/SM +meanwhile/S +meany's +meas/Y +measle/SD +measles/M +measly/TR +measurable/U +measurably +measure/BLMGRSD +measured/Y +measureless +measurement/SM +measurer/M +measures/A +measuring/A +meat/MS +meataxe +meatball/MS +meatiness/MS +meatless +meatloaf +meatloaves +meatpacking/S +meaty/RPT +mecca/S +mechanic/MS +mechanical/YS +mechanism/SM +mechanist/M +mechanistic +mechanistically +mechanization/SM +mechanize/RSDZGB +mechanized/U +mechanizer/M +mechanizes/U +mechanochemically +med +medal/SGMD +medalist/MS +medallion/MS +meddle/GRSDZ +meddlesome +media/SM +mediaeval's +medial/AY +medials +median/YMS +mediate/PSDYVNGX +mediateness/M +mediation/ASM +mediator/SM +medic/SM +medical/YS +medicament/MS +medicate/DSXNGV +medication/M +medicinal/SY +medicine/DSMG +medico/SM +medieval/YMS +medievalist/MS +mediocre +mediocrity/MS +meditate/NGVXDS +meditation/M +meditative/PY +meditativeness/M +medium/SM +mediumistic +medley/SM +medulla/SM +meed/MS +meek/TPYR +meekness/MS +meerschaum/MS +meet/JGSYR +meeter/M +meeting/M +meetinghouse/S +mega +megabit/MS +megabuck/S +megabyte/S +megacycle/MS +megadeath/M +megadeaths +megahertz/M +megalith/M +megalithic +megaliths +megalomania/SM +megalomaniac/SM +megalopolis/SM +megaphone/SDGM +megaton/MS +megavolt/M +megawatt/SM +megaword/S +megohm/MS +meioses +meiosis/M +meiotic +melamine/SM +melancholia/SM +melancholic/S +melancholy/MS +melange/S +melanin/MS +melanoma/SM +meld/SGD +meliorate/XSDVNG +melioration/M +mellifluous/YP +mellifluousness/SM +mellow/TGRDYPS +mellowness/MS +melodic/S +melodically +melodious/YP +melodiousness/S +melodrama/SM +melodramatic/S +melodramatically +melody/MS +melon/MS +melt/SAGD +meltdown/S +melter/M +melting/Y +member/DMS +membered/AE +members/EA +membership/SM +membrane/MSD +membranous +memento/SM +memo/SM +memoir/MS +memorabilia +memorability/SM +memorable/P +memorableness/M +memorably +memorandum/SM +memorial/SY +memorialize/DSG +memorialized/U +memoriam +memorization/MS +memorize/RSDZG +memorized/U +memorizer/M +memorizes/A +memory/MS +memoryless +men/MS +menace/GSD +menacing/Y +menage/S +menagerie/SM +menarche/MS +mend/RDSJGZ +mendacious/PY +mendaciousness/M +mendacity/MS +mendelevium/SM +mender/M +mendicancy/MS +mendicant/S +mending/M +menfolk/S +menhaden/M +menial/YS +meningeal +meninges +meningitides +meningitis/M +meninx +menisci +meniscus/M +menopausal +menopause/SM +menorah/M +menorahs +mens/SDG +mensch/S +menservants/M +menstrual +menstruate/NGDSX +menstruation/M +mensurable/P +mensuration/MS +menswear/M +mental/Y +mentalist/MS +mentality/MS +menthol/SM +mentholated +mention/ZGBRDS +mentionable/U +mentioned/U +mentioner/M +mentor/DMSG +menu/SM +meow/DSG +mer/TGDR +mercantile +mercenariness/M +mercenary/SMP +mercer/SM +mercerize/SDG +merchandise/SRDJMZG +merchandiser/M +merchant/SBDMG +merchantability +merchantman/M +merchantmen +merciful/YP +mercifully/U +mercifulness/M +merciless/YP +mercilessness/SM +mercurial/SPY +mercuric +mercury/MS +mercy/SM +mere/YS +meretricious/YP +meretriciousness/SM +merganser/MS +merge/SRDGZ +merger/M +meridian/MS +meridional +meringue/MS +merino/MS +merit/SCGMD +merited/U +meritocracy/MS +meritocratic +meritocrats +meritorious/PY +meritoriousness/MS +merlin/M +mermaid/MS +merman/M +mermen +meromorphic +merrily +merriment/MS +merriness/S +merry/RPT +merrymaker/MS +merrymaking/SM +mes/S +mesa/SM +mescal/SM +mescaline/SM +mesdames/M +mesdemoiselles/M +mesh/GMSD +meshed/U +mesmeric +mesmerism/SM +mesmerize/SRDZG +mesmerized/U +mesmerizer/M +mesomorph/M +mesomorphs +meson/MS +mesosphere/MS +mesozoic +mesquite/MS +mess/GSDM +message/SDMG +messeigneurs +messenger/GSMD +messiah +messiahs +messianic +messieurs/M +messily +messiness/MS +messmate/MS +messy/PRT +mestizo/MS +met/U +meta +metabolic +metabolically +metabolism/MS +metabolite/SM +metabolize/GSD +metacarpal/S +metacarpi +metacarpus/M +metacircular +metacircularity +metal/SGMD +metalanguage/MS +metalization/SM +metalized +metallic/S +metalliferous +metallings +metallography/M +metalloid/M +metallurgic +metallurgical/Y +metallurgist/S +metallurgy/MS +metalsmith/MS +metalwork/RMJGSZ +metalworking/M +metamathematical +metamorphic +metamorphism/SM +metamorphose/GDS +metamorphosis/M +metaphor/MS +metaphoric +metaphorical/Y +metaphosphate/M +metaphysic/SM +metaphysical/Y +metastability/M +metastable +metastases +metastasis/M +metastasize/DSG +metastatic +metatarsal/S +metatarsi +metatarsus/M +metatheses +metathesis/M +metathesized +metathesizes +metathesizing +metavariable +mete/ZDGSR +metempsychoses +metempsychosis/M +meteor/SM +meteoric +meteorically +meteorite/SM +meteoritic/S +meteoritics/M +meteoroid/SM +meteorologic +meteorological +meteorologist/S +meteorology/MS +meter/GDM +methadone/SM +methane/MS +methanol/SM +methinks +methionine/M +method/MS +methodical/YP +methodicalness/SM +methodism +methodist/MS +methodological/Y +methodologists +methodology/MS +methought +methyl/SM +methylated +methylene/M +meticulous/YP +meticulousness/MS +metonymy/M +metric/SM +metrical/Y +metricate/SDNGX +metricize/GSD +metrics/M +metro/SM +metronome/MS +metropolis/SM +metropolitan/S +metropolitanization +mets +mettle/SDM +mettlesome +mew/SGD +mewl/GSD +mews/SM +mezzanine/MS +mezzo/S +mfg +mfr/S +mg +mgr +mi/MNX +miasma/SM +miasmal +mica/MS +mice/M +micelles +mickey/SM +micra's +micro/S +microamp +microanalysis/M +microanalytic +microbe/MS +microbial +microbicidal +microbicide/M +microbiological +microbiologist/MS +microbiology/SM +microbrewery/S +microchemistry/M +microchip/S +microcircuit/MS +microcode/GSD +microcomputer/MS +microcosm/MS +microcosmic +microdensitometer +microdot/MS +microeconomic/S +microeconomics/M +microelectronic/S +microelectronics/M +microfiber/S +microfiche/M +microfilm/DRMSG +microfossils +micrography/M +microgroove/MS +microhydrodynamics +microinstruction/SM +microjoule +microlevel +microlight/S +micromanage/GDSL +micromanagement/S +micrometeorite/MS +micrometeoritic +micrometer/SM +micron/MS +microorganism/SM +microphone/SGM +microprocessing +microprocessor/SM +microprogram/SM +microprogrammed +microprogramming +micros/M +microscope/SM +microscopic +microscopical/Y +microscopy/MS +microsecond/MS +microsimulation/S +microsomal +microstore +microsurgery/SM +microvolt/SM +microwave/BMGSD +microwaveable +microword/S +mid/S +midair/MS +midas +midband/M +midday/MS +midden/SM +middest +middle/GJRSD +middlebrow/SM +middleman/M +middlemen +middlemost +middleweight/SM +middling/Y +middy/SM +midfield/RM +midge/SM +midget/MS +midi/S +midland/MRS +midlife +midlives +midmorn/G +midmost/S +midnight/SYM +midpoint/MS +midrange +midrib/MS +midriff/MS +midscale +midsection/M +midship/S +midshipman/M +midshipmen +midspan +midst/SM +midstream/MS +midsummer/MS +midterm/MS +midtown/MS +midway/S +midweek/SYM +midwicket +midwife/SDMG +midwifery/SM +midwinter/YMS +midwives +midyear/MS +mien/M +miff/GDS +might/S +mightily +mightiness/MS +mightn't +mighty/TPR +mignon +mignonette/SM +migraine/SM +migrant/MS +migrate/ASDG +migration/MS +migrative +migratory/S +mikado/MS +mike/DSMG +mil/MRSZ +milady/MS +milch/M +mild/STYRNP +mildew/DMGS +mildness/MS +mile/SM +mileage/SM +milepost/SM +miler/M +milestone/MS +milieu/SM +militancy/MS +militant/YPS +militantness/M +militarily +militarism/SM +militarist/MS +militaristic +militarization/SCM +militarize/SDCG +military +militate/SDG +militia/SM +militiaman/M +militiamen +milk/GZSRDM +milker/M +milkiness/MS +milkmaid/SM +milkman/M +milkmen +milkshake/S +milksop/SM +milkweed/MS +milky/RPT +mill/SGZMRD +millage/S +millenarian +millenarianism/M +millennial +millennialism +millennium/MS +millepede's +miller/M +millet/MS +milliamp +milliampere/S +milliard/MS +millibar/MS +millidegree/S +milligram/MS +millijoule/S +milliliter/MS +millimeter/SM +milliner/SM +millinery/MS +milling/M +million/HDMS +millionaire/MS +millionth/M +millionths +millipede/SM +millisecond/MS +millivolt/SM +millivoltmeter/SM +milliwatt/S +millpond/MS +millrace/SM +millstone/SM +millstream/SM +millwright/MS +milquetoast/SM +milt/MDSG +mime/DSRMG +mimeograph/GMDS +mimeographs +mimer/M +mimesis/M +mimetic +mimetically +mimic/S +mimicked +mimicker/SM +mimicking +mimicry/MS +mimosa/SM +min/DRZGJ +minaret/MS +minatory +mince/SRDGZJ +mincemeat/MS +mincer/M +mincing/Y +mind's +mind/ARDSZG +mindbogglingly +minded/P +minder/M +mindful/U +mindfully +mindfulness/MS +mindless/YP +mindlessness/SM +mindset/S +mine/SNX +minefield/MS +miner/M +mineral/SM +mineralization/C +mineralized/U +mineralogical +mineralogist/SM +mineralogy/MS +mineshaft +minestrone/MS +minesweeper/MS +mineworkers +mingle/SDG +mini/S +miniature/GMSD +miniaturist/SM +miniaturization/MS +miniaturize/SDG +minibike/S +minibus/SM +minicab/M +minicam/MS +minicomputer/SM +minidress/SM +minify/GSD +minim/SM +minima's +minimal/SY +minimalism/S +minimalist/MS +minimalistic +minimality +minimax/M +minimization/MS +minimize/RSDZG +minimized/U +minimizer/M +minimum/MS +mining/M +minion/M +miniseries +miniskirt/MS +minister/MDGS +ministerial/Y +ministrant/S +ministration/SM +ministry/MS +minivan/S +miniver/M +mink/SM +minke +minnesinger/MS +minnow/SM +minor/DMSG +minority/MS +minotaur/S +minoxidil/S +minster/SM +minstrel/SM +minstrelsy/MS +mint/GZSMRD +mintage/SM +minter/M +minty/RT +minuend/SM +minuet/SM +minus/S +minuscule/SM +minute/RSDPMTYG +minuteman +minutemen +minuteness/SM +minutia/M +minutiae +minx/MS +miracle/MS +miraculous/PY +miraculousness/M +mirage/GSDM +mire/MGDS +mirror/DMGS +mirth/M +mirthful/PY +mirthfulness/SM +mirthless/YP +mirthlessness/M +mirths +miry/RT +mis/SRZ +misaddress/SDG +misadventure/SM +misalign/DSGL +misalignment/MS +misalliance/MS +misanalysed +misandrist +misandry +misanthrope/MS +misanthropic +misanthropically +misanthropist/S +misanthropy/SM +misapplier/M +misapply/GNXRSD +misapprehend/GDS +misapprehension/MS +misappropriate/GNXSD +misbegotten +misbehave/RSDG +misbehaver/M +misbehavior/SM +misbrand/DSG +misc +miscalculate/XGNSD +miscalculation/M +miscall/SDG +miscarriage/MS +miscarry/SDG +miscast/GS +miscegenation/SM +miscellanea +miscellaneous/PY +miscellany/MS +mischance/MGSD +mischief/MDGS +mischievous/PY +mischievousness/MS +miscibility/S +miscible/C +misclassification/M +misclassified +misclassifying +miscode/SDG +miscommunicate/NDS +miscomprehended +misconceive/GDS +misconception/MS +misconduct/GSMD +misconfiguration +misconstruction/MS +misconstrue/DSG +miscopying +miscount/DGS +miscreant/MS +miscue/MGSD +misdeal/SG +misdealt +misdeed/MS +misdemeanant/SM +misdemeanor/SM +misdiagnose/GSD +misdid +misdirect/GSD +misdirection/MS +misdirector/S +misdo/JG +misdoes +misdone +miser/KM +miserable/SP +miserableness/SM +miserably +miserliness/MS +miserly/P +misery/MS +mises/KC +misfeasance/MS +misfeature/M +misfield +misfile/SDG +misfire/SDG +misfit/MS +misfitted +misfitting +misfortune/SM +misgauge/GDS +misgiving/MYS +misgovern/LDGS +misgovernment/S +misguidance/SM +misguide/DRSG +misguided/PY +misguidedness/M +misguider/M +mishandle/SDG +mishap/MS +mishapped +mishapping +mishear/GS +misheard +mishitting +mishmash/SM +misidentification/M +misidentify/GNSD +misinform/GDS +misinformation/SM +misinterpret/RDSZG +misinterpretation/MS +misinterpreter/M +misjudge/DSG +misjudging/Y +misjudgment/MS +mislabel/DSG +mislaid +mislay/GS +mislead/GRJS +misleader/M +misleading/Y +misled +mismanage/LGSD +mismanagement/MS +mismatch/GSD +misname/GSD +misnomer/GSMD +misogamist/MS +misogamy/MS +misogynist/MS +misogynistic +misogynous +misogyny/MS +misperceive/SD +misplace/GLDS +misplacement/MS +misplay/GSD +mispositioned +misprint/SGDM +misprision/SM +mispronounce/DSG +mispronunciation/MS +misquotation/MS +misquote/GDS +misread/RSGJ +misreader/M +misrelated +misremember/DG +misreport/DGS +misrepresent/SDRG +misrepresentation/MS +misrepresenter/M +misroute/DS +misrule/SDG +miss/SDEGV +missal/ESM +misshape/DSG +misshapen/PY +misshapenness/SM +missile/MS +missilery/SM +mission/AMS +missionary/MS +missioned +missioner/SM +missioning +missis's +missive/MS +misspeak/SG +misspecification +misspecified +misspell/SGJD +misspelling/M +misspend/GS +misspent +misspoke +misspoken +misstate/GLDRS +misstatement/MS +misstater/M +misstep/MS +misstepped +misstepping +missus/SM +mist/MRDGZS +mistakable/U +mistake/BMGSR +mistaken/Y +mistaker/M +mistaking/Y +mister/GDM +mistily +mistime/GSD +mistiness/S +mistletoe/MS +mistook +mistral/MS +mistranslated +mistranslates +mistranslating +mistranslation/SM +mistreat/DGSL +mistreatment/SM +mistress/MSY +mistrial/SM +mistrust/SRDG +mistruster/M +mistrustful/Y +misty/PRT +mistype/SDGJ +misunderstand/JSRZG +misunderstander/M +misunderstanding/M +misunderstood +misuse/RSDMG +misuser/M +miswritten +mite/SRMZ +miter/GRDM +miterer/M +mitigate/XNGVDS +mitigated/U +mitigation/M +mitoses +mitosis/M +mitotic +mitt/XSMN +mitten/M +mitzvahs +mix/AGSD +mixable +mixed/U +mixer/SM +mixture/SM +mizzen/MS +mizzenmast/SM +mks +ml +mm +mnemonic/SM +mnemonically +mnemonics/M +mo/CSK +moan/GSZRDM +moat/SMDG +mob/MS +mobbed +mobber +mobbing +mobcap/SM +mobile/S +mobility/MS +mobilizable +mobilization/AMCS +mobilize/CGDS +mobilized/U +mobilizer/MS +mobilizes/A +mobster/MS +moccasin/SM +mocha/SM +mock/GZSRD +mockers/M +mockery/MS +mocking/Y +mockingbird/MS +mod/TSR +modal/Y +modality/MS +mode/MS +model/ZGSJMRD +modeled/A +modeler/M +modeling/M +models/A +modem/SM +moderate/PNGDSXY +moderated/U +moderateness/SM +moderation/M +moderator/MS +modern/PTRYS +modernism/MS +modernist/S +modernistic +modernity/SM +modernization/MS +modernize/SRDGZ +modernized/U +modernizer/M +modernizes/U +modernness/SM +modest/TRY +modesty/MS +modicum/SM +modifiability/M +modifiable/U +modifiableness/M +modification/M +modified/U +modifier/M +modify/NGZXRSD +modish/YP +modishness/MS +modular/SY +modularity/SM +modularization +modularize/SDG +modulate/ADSNCG +modulation/CMS +modulator/ACSM +module/SM +moduli +modulo +modulus/M +modus +mogul/MS +mohair/SM +moiety/MS +moil/SGD +moire/MS +moist/TXPRNY +moisten/ZGRD +moistener/M +moistness/MS +moisture/MS +moisturize/GZDRS +molal +molar/MS +molarity/SM +molasses/MS +mold/MRDJSGZ +moldboard/SM +molder/DG +moldiness/SM +molding/M +moldy/PTR +mole/MTS +molecular/Y +molecularity/SM +molecule/MS +molehill/SM +moleskin/MS +molest/RDZGS +molestation/SM +molested/U +molester/M +moll/MS +mollification/M +mollify/XSDGN +mollusc's +mollusk/S +molly/SM +mollycoddle/SRDG +mollycoddler/M +molt/RDNGZS +molter/M +molybdenite/M +molybdenum/MS +mom/SM +moment/MYS +momenta +momentarily +momentariness/SM +momentary/P +momentous/YP +momentousness/MS +momentum/SM +momma/S +mommy/SM +monad/SM +monadic +monarch/M +monarchic +monarchical +monarchism/MS +monarchist/MS +monarchistic +monarchs +monarchy/MS +monastery/MS +monastic/S +monastical/Y +monasticism/MS +monaural/Y +monetarily +monetarism/S +monetarist/MS +monetary +monetization/CMA +monetize/CGADS +money/SMRD +moneybag/SM +moneychangers +moneyer/M +moneylender/SM +moneymaker/MS +moneymaking/MS +monger/SGDM +mongolism/SM +mongoloid/S +mongoose/SM +mongrel/SM +monies/M +moniker/MS +monism/MS +monist/SM +monition/SM +monitor/GSMD +monitored/U +monitory/S +monk/MS +monkey/SMDG +monkeyshine/S +monkish +monkshood/SM +mono/MS +monochromatic +monochromator +monochrome/MS +monocle/SDM +monoclinic +monoclonal/S +monocotyledon/SM +monocotyledonous +monocular/SY +monodic +monodist/S +monody/MS +monogamist/MS +monogamous/PY +monogamy/MS +monogram/MS +monogrammed +monogramming +monograph/GMDS +monographs +monolingual/S +monolingualism +monolith/M +monolithic +monolithically +monoliths +monologist/S +monologue/GMSD +monomania/MS +monomaniac/MS +monomaniacal +monomer/SM +monomeric +monomial/SM +mononuclear +mononucleoses +mononucleosis/M +monophonic +monoplane/MS +monopole/S +monopolist/MS +monopolistic +monopolization/MS +monopolize/GZDSR +monopolized/U +monopolizes/U +monopoly/MS +monorail/SM +monostable +monosyllabic +monosyllable/MS +monotheism/SM +monotheist/S +monotheistic +monotone/SDMG +monotonic +monotonically +monotonicity +monotonous/YP +monotonousness/MS +monotony/MS +monovalent +monoxide/SM +monseigneur +monsieur/M +monsignor/S +monsoon/MS +monsoonal +monster/SM +monstrance/ASM +monstrosity/SM +monstrous/YP +monstrousness/M +montage/SDMG +month/MY +monthly/S +months +monument/DMSG +monumental/Y +monumentality/M +moo/GSD +mooch/ZSRDG +mood/MS +moodily +moodiness/MS +moody/PTR +moon/GDMS +moonbeam/SM +moonless +moonlight/GZDRMS +moonlighting/M +moonlit +moonscape/MS +moonshine/SRZM +moonshiner/M +moonshot/MS +moonstone/SM +moonstruck +moonwalk/SDG +moor/GDMJS +mooring/M +moorland/MS +moose/M +moot/RDGS +mop/SZGMDR +mope/S +moped/MS +moper/M +mopey +mopier +mopiest +mopish +mopped +moppet/MS +mopping +moraine/MS +moral/SMY +morale/MS +moralist/MS +moralistic +moralistically +morality/UMS +moralization/CS +moralize/CGDRSZ +moralled +moraller +moralling +morass/SM +moratorium/SM +moray/SM +morbid/YP +morbidity/SM +morbidness/S +mordancy/MS +mordant/GDYS +more/DSN +morel/SM +moreover +morgen/M +morgue/SM +moribund/Y +moribundity/M +morion/M +morn/SGJDM +morning/MY +morocco/SM +moron/SM +moronic +moronically +morose/YP +moroseness/MS +morph/GDJ +morpheme/DSMG +morphemic/S +morphia/S +morphine/MS +morphism/MS +morphologic +morphological/Y +morphology/MS +morphophonemic/S +morphophonemics/M +morphs +morris +morrow/MS +morsel/GMDS +mortal/SY +mortality/SM +mortar/GSDM +mortarboard/SM +mortgage/MGDS +mortgageable +mortgagee/SM +mortgagor/SM +mortice's +mortician/SM +mortification/M +mortified/Y +mortifier/M +mortify/DRSXGN +mortise/MGSD +mortuary/MS +mos/S +mosaic/MS +mosaicked +mosaicking +mosey/SGD +mosque/SM +mosquito/M +mosquitoes +moss/SDMG +mossback/MS +mossy/SRT +most/SY +mot/MSV +mote's +mote/ASCNK +motel/MS +motet/SM +moth/ZMR +mothball/DMGS +mother/RDYMZG +motherboard/MS +motherfucker/MS! +motherfucking/! +motherhood/SM +mothering/M +motherland/SM +motherless +motherliness/MS +motherly/P +moths +motif/MS +motile/S +motility/MS +motion's/ACK +motion/GRDMS +motional/K +motioner/M +motionless/YP +motionlessness/S +motions/K +motivate/XDSNGV +motivated/U +motivation/M +motivational/Y +motivator/S +motive/MGSD +motiveless +motley/S +motlier +motliest +motocross/SM +motor/DMSG +motorbike/SDGM +motorboat/MS +motorcade/MSDG +motorcar/MS +motorcycle/GMDS +motorcyclist/SM +motoring/M +motorist/SM +motorization/SM +motorize/DSG +motorized/U +motorman/M +motormen +motormouth +motormouths +motorway/SM +mottle/GSRD +mottler/M +motto/M +mottoes +moue/DSMG +moulder/DSG +moult/GSD +mound/GMDS +mount/EGACD +mountable +mountain/SM +mountaineer/JMDSG +mountaineering/M +mountainous/PY +mountainousness/M +mountainside/MS +mountaintop/SM +mountebank/SGMD +mounted/U +mounter/SM +mounties +mounting/MS +mounts/AE +mourn/ZGSJRD +mourner/M +mournful/YP +mournfuller +mournfullest +mournfulness/S +mourning/M +mouse/SRDGMZ +mouser/M +mousetrap/SM +mousetrapped +mousetrapping +mousiness/MS +mousing/M +mousse/MGSD +mousy/PRT +mouth/MSRDG +mouthful/MS +mouthiness/SM +mouthorgan +mouthpiece/SM +mouths +mouthwash/SM +mouthwatering +mouthy/PTR +mouton/SM +movable/ASP +movableness/AM +move/ARSDGZB +moved/U +movement/SM +mover/AM +movie/SM +moviegoer/S +moving/YS +mow/SDRZG +mower/M +mowing/M +moxie/MS +mozzarella/MS +mp +mpg +mph +ms +mt +mtg +mtge +mu/M +much/SP +muchness/M +mucilage/MS +mucilaginous +muck/GRDMS +mucker/M +muckrake/ZMDRSG +muckraker/M +mucky/RT +mucosa/M +mucous +mucus/SM +mud/MS +mudded +muddily +muddiness/SM +mudding +muddle/GRSDZ +muddlehead/SMD +muddleheaded/P +muddler/M +muddy/TPGRSD +mudflat/S +mudguard/SM +mudlarks +mudroom/S +mudslide/S +mudsling/JRGZ +mudslinger/M +mudslinging/M +muenster/MS +muesli/M +muezzin/MS +muff/GDMS +muffin/SM +muffle/ZRSDG +muffler/M +mufti/MS +mug/SM +mugged +mugger/SM +mugginess/S +mugging/S +muggy/RPT +mugshot/S +mugwump/MS +mukluk/SM +mulatto/M +mulattoes +mulberry/MS +mulch/GMSD +mulct/SDG +mule/MGDS +muleskinner/S +muleteer/MS +mulish/YP +mulishness/MS +mull/RDSG +mullah/M +mullahs +mullein/MS +muller/M +mullet/MS +mulligan/SM +mulligatawny/SM +mullion/MDSG +multi +multicellular +multichannel/M +multicollinearity/M +multicolor/SDM +multicolumn +multicomponent +multicomputer/MS +multicultural +multiculturalism/S +multidimensional +multidimensionality +multidisciplinary +multifaceted +multifamily +multifarious/YP +multifariousness/SM +multifigure +multiform +multifunction/D +multilateral/Y +multilayer +multilevel/D +multilingual +multilingualism/S +multimedia/S +multimegaton/M +multimeter/M +multimillionaire/SM +multinational/S +multinomial/M +multiphase +multiple/SM +multiplet/SM +multiplex/GZMSRD +multiplexor's +multipliable +multiplicand/SM +multiplication/M +multiplicative/YS +multiplicity/MS +multiplier/M +multiply/ZNSRDXG +multiprocess/G +multiprocessor/MS +multiprogram +multiprogrammed +multiprogramming/MS +multipurpose +multiracial +multistage +multistory/S +multisyllabic +multitasking/S +multitude/MS +multitudinous/YP +multitudinousness/M +multiuser +multivalent +multivalued +multivariate +multiversity/M +multivitamin/S +mum/MS +mumble/ZJGRSD +mumbler/M +mumbletypeg/S +mummed +mummer/SM +mummery/MS +mummification/M +mummify/XSDGN +mumming +mummy/GSDM +mumps/M +mun/S +munch/ZRSDG +muncher/M +munchies +mundane/YSP +munge/JGZSRD +municipal/YS +municipality/SM +munificence/MS +munificent/Y +munition/SDG +muon/M +mural/SM +muralist/SM +murder/GZRDMS +murderer/M +murderess/S +murderous/YP +murderousness/M +muriatic +murk/TRMS +murkily +murkiness/S +murky/RPT +murmur/RDMGZSJ +murmurer/M +murmuring/U +murmurous +murrain/SM +mus/GJDSR +muscat/SM +muscatel/MS +muscle/SDMG +musclebound +muscovite/MS +muscular/Y +muscularity/SM +musculature/SM +muse +muser/M +musette/SM +museum/MS +mush/MSRDG +musher/M +mushiness/MS +mushroom/DMSG +mushy/PTR +music/SM +musical/YU +musicale/SM +musicality/SM +musicals +musician/MYS +musicianship/MS +musicked +musicking +musicological +musicologist/MS +musicology/MS +musing/Y +musk/GDMS +muskeg/SM +muskellunge/SM +musket/SM +musketeer/MS +musketry/MS +muskie/M +muskiness/MS +muskmelon/MS +muskox/N +muskrat/MS +musky/RSPT +muslin/MS +muss/SDG +mussel/MS +mussy/RT +must've +must/RDGZS +mustache/DSM +mustachio/MDS +mustang/MS +mustard/MS +muster/GD +mustily +mustiness/MS +mustn't +musty/RPT +mutability/SM +mutable/P +mutableness/M +mutably +mutagen/SM +mutant/MS +mutate/XVNGSD +mutation/M +mutational/Y +mutator/S +mute/PDSRBYTG +muted/Y +muteness/S +mutilate/XDSNG +mutilation/M +mutilator/MS +mutineer/SMDG +mutinous/Y +mutiny/MGSD +mutt/ZSMR +mutter/GZRDJ +mutterer/M +mutton/SM +muttonchops +mutual/SY +mutuality/S +muumuu/MS +muzak +muzzle/MGRSD +muzzled/U +muzzler/M +my/S +mycologist/MS +mycology/MS +myelitides +myelitis/M +myers +mylar +myna/SM +myocardial +myocardium/M +myopia/MS +myopic/S +myopically +myriad/S +myrmidon/S +myrrh/M +myrrhs +myrtle/SM +mys +myself +mysterious/YP +mysteriousness/MS +mystery/MDSG +mystic/SM +mystical/Y +mysticism/MS +mystification/M +mystifier/M +mystify/CSDGNX +mystifying/Y +mystique/MS +myth/MS +mythic +mythical/Y +mythographer/SM +mythography/M +mythological/Y +mythologist/MS +mythologize/CSDG +mythology/SM +myths +m�tier/S +m�l�e/MS +n's/CI +n/T +nab/S +nabbed +nabbing +nabob/SM +nacelle/SM +nacho/S +nacre/MS +nacreous +nadir/SM +nae/VM +nag/MS +nagged +nagger/S +nagging/Y +naiad/SM +naifs +nail/SGMRD +nailbrush/SM +nailer/M +naive/SRTYP +naivety/MS +naivet�/SM +naked/TYRP +nakedness/MS +name's +name/ADSG +nameable/U +named's +named/U +namedrop +namedropping +nameless/PY +namely +nameplate/MS +namer/SM +namesake/SM +naming/M +nanny/SDMG +nanometer/MS +nanosecond/SM +nap/SM +napalm/MDGS +nape/SM +naphtha/SM +naphthalene/MS +napkin/SM +napless +napoleon/MS +napped +napper/MS +napping +nappy/TRSM +narc/DGS +narcissism/MS +narcissist/MS +narcissistic +narcissus/M +narcoleptic +narcoses +narcosis/M +narcotic/SM +narcotization/S +narcotize/GSD +nark's +narrate/VGNSDX +narration/M +narrative/MYS +narratology +narrator/SM +narrow/RDYTGPS +narrowing/P +narrowness/SM +narwhal/MS +nary +nasal/YS +nasality/MS +nasalization/MS +nasalize/GDS +nascence/ASM +nascent/A +nastily +nastiness/MS +nasturtium/SM +nasty/TRSP +natal +natalist +natality/M +natch/S +nation/MS +national/YS +nationalism/SM +nationalist/MS +nationalistic +nationalistically +nationality/MS +nationalization/MS +nationalize/CSDG +nationalized/AU +nationalizer/SM +nationhood/SM +nationwide +native/PYS +nativeness/M +nativity/MS +natl +natter/SGD +nattily +nattiness/SM +natty/TRP +natural/PUY +naturalism/MS +naturalist/MS +naturalistic +naturalization/SM +naturalize/GSD +naturalized/U +naturalness/US +naturals +nature's +nature/ASDCG +naturist +naught/MS +naughtily +naughtiness/SM +naughty/TPRS +nausea/SM +nauseate/DSG +nauseating/Y +nauseous/P +nauseousness/SM +nautical/Y +nautilus/MS +naval/Y +nave/SM +navel/MS +navigability/SM +navigable/P +navigableness/M +navigate/DSXNG +navigation/M +navigational +navigator/MS +navvy/M +navy/SM +nay/MS +naysayer/S +ne'er +neap/DGS +near/TYRDPSG +nearby +nearly/RT +nearness/MS +nearside/M +nearsighted/YP +nearsightedness/S +neat/YRNTXPS +neaten/DG +neath +neatness/MS +nebula/M +nebulae +nebular +nebulous/PY +nebulousness/SM +necessaries +necessarily/U +necessary/U +necessitate/DSNGX +necessitation/M +necessitous +necessity/SM +neck/GRDMJS +neckband/M +neckerchief/MS +necking/M +necklace/DSMG +neckline/MS +necktie/MS +necrology/SM +necromancer/MS +necromancy/MS +necromantic +necrophilia/M +necrophiliac/S +necropolis/SM +necropsy/M +necroses +necrosis/M +necrotic +nectar/SM +nectarine/SM +nectarous +nectary/MS +need/YRDGS +needed/U +needer/M +needful/YSP +neediness/MS +needle/GMZRSD +needlecraft/M +needlepoint/SM +needless/YP +needlessness/S +needlewoman/M +needlewomen +needlework/RMS +needn't +needy/TPR +nefarious/YP +nefariousness/MS +neg/S +negate/XRSDVNG +negated/U +negater/M +negation/M +negative/PDSYG +negativeness/SM +negativism/MS +negativity/MS +negator/MS +neglect/SDRG +neglecter/M +neglectful/YP +neglectfulness/SM +negligee/SM +negligence/MS +negligent/Y +negligibility/M +negligible +negligibly +negotiability/MS +negotiable/A +negotiant/M +negotiate/ASDXGN +negotiation/MA +negotiator/MS +negritude/MS +negroid +neigh/MDG +neighbor/SMRDYZGJ +neighbored/U +neighborer/M +neighborhood/SM +neighborliness/UM +neighborlinesses +neighborly/UP +neighs +neither +nelson/MS +nematic +nematode/SM +nemeses +nemesis +neoclassic/M +neoclassical +neoclassicism/MS +neocolonialism/MS +neocortex/M +neodymium/MS +neolithic +neologism/SM +neomycin/M +neon/DMS +neonatal/Y +neonate/MS +neophyte/MS +neoplasm/SM +neoplastic +neoprene/SM +nepenthe/MS +nephew/MS +nephrite/SM +nephritic +nephritides +nephritis/M +nepotism/MS +nepotist/S +neptunium/MS +nerd/S +nerdy/RT +nerve's +nerve/UGSD +nerveless/YP +nervelessness/SM +nerviness/SM +nerving/M +nervous/PY +nervousness/SM +nervy/TPR +nest/RDGSBM +nester/M +nestle/RSDG +nestler/M +nestling/M +net/SM +netball/M +nether +nethermost +netherworld/S +nett/JGRDS +netting/M +nettle/MSDG +nettlesome +network/SJMDG +neural/Y +neuralgia/MS +neuralgic +neurasthenia/MS +neurasthenic/S +neuritic/S +neuritides +neuritis/M +neuroanatomy +neurobiology/M +neurological/Y +neurologist/MS +neurology/SM +neuromuscular +neuron/MS +neuronal +neurone/S +neuropathology/M +neurophysiology/M +neuropsychiatric +neuroses +neurosis/M +neurosurgeon/MS +neurosurgery/SM +neurotic/S +neurotically +neurotransmitter/S +neut/ZR +neuter/JZGRD +neutral/PYS +neutralise's +neutralism/MS +neutralist/S +neutrality/MS +neutralization/MS +neutralize/GZSRD +neutralized/U +neutrino/MS +neutron/MS +never +nevermore +nevertheless +nevi +nevus/M +new/SPTGDRY +newbie/S +newborn/S +newcomer/MS +newed/A +newel/MS +newer/A +newfangled +newfound +newfoundland +newish +newline/SM +newlywed/MS +newness/MS +news's +news/A +newsagent/MS +newsboy/SM +newscast/SRMGZ +newscaster/M +newscasting/M +newsdealer/MS +newsed +newses +newsflash/S +newsgirl/S +newsgroup/SM +newsing +newsletter/SM +newsman/M +newsmen +newspaper/SMGD +newspaperman/M +newspapermen +newspaperwoman/M +newspaperwomen +newsprint/MS +newsreader/MS +newsreel/SM +newsroom/S +newsstand/MS +newsweekly/S +newswire +newswoman/M +newswomen +newsworthiness/SM +newsworthy/RPT +newsy/TRS +newt/MS +newton/SM +next +nexus/SM +niacin/SM +nib/SM +nibbed +nibbing +nibble/RSDGZ +nibbler/M +nice/YTPR +niceness/MS +nicety/MS +niche/SDGM +nichrome +nick/GZRDMS +nickel/SGMD +nickelodeon/SM +nicker/GD +nicknack's +nickname/MGDRS +nicknamer/M +nicotine/MS +niece/MS +nifty/TRS +niggard/SGMDY +niggardliness/SM +niggardly/P +nigger/SGDM! +niggle/RSDGZJ +niggler/M +niggling/Y +nigh/RDGT +nighs +night/SMYDZ +nightcap/SM +nightclothes +nightclub/MS +nightclubbed +nightclubbing +nightdress/MS +nightfall/SM +nightgown/MS +nighthawk/MS +nightie/MS +nightingale/SM +nightlife/MS +nightlong +nightmare/MS +nightmarish/Y +nightshade/SM +nightshirt/MS +nightspot/MS +nightstand/SM +nightstick/S +nighttime/S +nightwear/M +nighty's +nihilism/MS +nihilist/MS +nihilistic +nil/MYS +nilled +nilling +nilpotent +nimbi +nimble/TRP +nimbleness/SM +nimbly +nimbus/DM +nincompoop/MS +nine/MS +ninefold +ninepence/M +ninepin/S +ninepins/M +nineteen/SMH +nineteenths +ninetieths +ninety/MHS +ninja/S +ninny/SM +ninth +ninths +niobium/MS +nip/S +nipped +nipper/DMGS +nippiness/S +nipping/Y +nipple/GMSD +nippy/TPR +nirvana/MS +nisei +nit/ZSMR +niter/M +nitpick/DRSJZG +nitrate/MGNXSD +nitration/M +nitric +nitride/MGS +nitriding/M +nitrification/SM +nitrite/MS +nitrocellulose/MS +nitrogen/SM +nitrogenous +nitroglycerin/MS +nitrous +nitwit/MS +nix/GDSR +nixer/M +nm +no/A +nob/MY +nobelium/MS +nobility/MS +noble/TPSR +nobleman/M +noblemen +nobleness/SM +noblesse/M +noblewoman +noblewomen +nobody/MS +nocturnal/SY +nocturne/SM +nod/SM +nodal/Y +nodded +nodding +noddle/MSDG +noddy/M +node/MS +nodular +nodule/SM +noel/S +noes/S +noggin/SM +nohow +noise/GMSD +noiseless/YP +noiselessness/SM +noisemake/ZGR +noisemaker/M +noisily +noisiness/MS +noisome +noisy/TPR +nomad/SM +nomadic +nomenclature/MS +nominal/K +nominalized +nominally +nominals +nominate/CDSAXNG +nomination/MAC +nominative/SY +nominator/CSM +nominee/MS +non +nonabrasive +nonabsorbent/S +nonacademic/S +nonacceptance/MS +nonacid/MS +nonactive +nonadaptive +nonaddictive +nonadhesive +nonadjacent +nonadjustable +nonadministrative +nonage/MS +nonagenarian/MS +nonaggression/SM +nonagricultural +nonalcoholic/S +nonaligned +nonalignment/SM +nonallergic +nonappearance/MS +nonassignable +nonathletic +nonattendance/SM +nonautomotive +nonavailability/SM +nonbasic +nonbeliever/SM +nonbelligerent/S +nonblocking +nonbreakable +nonburnable +nonbusiness +noncaloric +noncancerous +noncarbohydrate/M +nonce/MS +nonchalance/SM +nonchalant/YP +nonchargeable +nonclerical/S +nonclinical +noncollectable +noncom/MS +noncombatant/MS +noncombustible/S +noncommercial/S +noncommissioned +noncommittal/Y +noncommunicable +noncompeting +noncompetitive +noncompliance/MS +noncomplying/S +noncomprehending +nonconducting +nonconductor/MS +nonconforming +nonconformist/SM +nonconformity/SM +nonconsecutive +nonconservative +nonconstructive +noncontagious +noncontiguous +noncontinuous +noncontributing +noncontributory +noncontroversial +nonconvertible +noncooperation/SM +noncorroding/S +noncorrosive +noncredit +noncriminal/S +noncritical +noncrystalline +noncumulative +noncustodial +noncyclic +nondairy +nondecreasing +nondeductible +nondelivery/MS +nondemocratic +nondenominational +nondepartmental +nondepreciating +nondescript/YS +nondestructive/Y +nondetachable +nondeterminacy +nondeterminate/Y +nondeterminism +nondeterministic +nondeterministically +nondisciplinary +nondisclosure/SM +nondiscrimination/SM +nondiscriminatory +nondramatic +nondrinker/SM +nondrying +nondurable +none/S +noneconomic +noneducational +noneffective/S +nonelastic +nonelectric/S +nonelectrical +nonemergency +nonempty +nonenforceable +nonentity/MS +nonequivalence/M +nonequivalent/S +nones/M +nonessential/S +nonesuch/SM +nonetheless +nonevent/MS +nonexchangeable +nonexclusive +nonexempt +nonexistence/MS +nonexistent +nonexplosive/S +nonextensible +nonfactual +nonfading +nonfat +nonfatal +nonfattening +nonferrous +nonfiction/SM +nonfictional +nonflammable +nonflowering +nonfluctuating +nonflying +nonfood/M +nonfreezing +nonfunctional +nongovernmental +nongranular +nonhazardous +nonhereditary +nonhuman +nonidentical +noninclusive +nonindependent +nonindustrial +noninfectious +noninflammatory +noninflationary +noninflected +nonintellectual/S +noninteracting +noninterchangeable +noninterference/MS +nonintervention/SM +nonintoxicating +nonintuitive +noninvasive +nonionic +nonirritating +nonjudgmental +nonjudicial +nonlegal +nonlethal +nonlinear/Y +nonlinearity/MS +nonlinguistic +nonliterary +nonliving +nonlocal +nonmagical +nonmagnetic +nonmalignant +nonmember/SM +nonmetal/MS +nonmetallic +nonmigratory +nonmilitant/S +nonmilitary +nonnarcotic/S +nonnative/S +nonnegative +nonnegotiable +nonnuclear +nonnumerical/S +nonobjective +nonobligatory +nonobservance/MS +nonobservant +nonoccupational +nonoccurence +nonofficial +nonogenarian +nonoperational +nonoperative +nonorthogonal +nonorthogonality +nonparallel/S +nonparametric +nonpareil/SM +nonparticipant/SM +nonparticipating +nonpartisan/S +nonpaying +nonpayment/SM +nonperformance/SM +nonperforming +nonperishable/S +nonperson/S +nonperturbing +nonphysical/Y +nonplus/S +nonplussed +nonplussing +nonpoisonous +nonpolitical +nonpolluting +nonporous +nonpracticing +nonprejudicial +nonprescription +nonprocedural/Y +nonproductive +nonprofessional/S +nonprofit/SB +nonprogrammable +nonprogrammer +nonproliferation/SM +nonpublic +nonpunishable +nonracial +nonradioactive +nonrandom +nonreactive +nonreciprocal/S +nonreciprocating +nonrecognition/SM +nonrecoverable +nonrecurring +nonredeemable +nonreducing +nonrefillable +nonrefundable +nonreligious +nonrenewable +nonrepresentational +nonresident/SM +nonresidential +nonresidual +nonresistance/SM +nonresistant/S +nonrespondent/S +nonresponse +nonrestrictive +nonreturnable/S +nonrhythmic +nonrigid +nonsalaried +nonscheduled +nonscientific +nonscoring +nonseasonal +nonsectarian +nonsecular +nonsegregated +nonsense/MS +nonsensical/PY +nonsensicalness/M +nonsensitive +nonsexist +nonsexual +nonsingular +nonskid +nonslip +nonsmoker/SM +nonsmoking +nonsocial +nonspeaking +nonspecialist/MS +nonspecializing +nonspecific +nonspiritual/S +nonstaining +nonstandard +nonstarter/SM +nonstick +nonstop +nonstrategic +nonstriking +nonstructural +nonsuccessive +nonsupervisory +nonsupport/GS +nonsurgical +nonsustaining +nonsympathizer/M +nontarnishable +nontaxable/S +nontechnical/Y +nontenured +nonterminal/MS +nonterminating +nontermination/M +nontheatrical +nonthinking/S +nonthreatening +nontoxic +nontraditional +nontransferable +nontransparent +nontrivial +nontropical +nonuniform +nonunion/S +nonuser/SM +nonvenomous +nonverbal/Y +nonveteran/MS +nonviable +nonviolence/SM +nonviolent/Y +nonvirulent +nonvocal +nonvocational +nonvolatile +nonvolunteer/S +nonvoter/MS +nonvoting +nonwhite/SM +nonworking +nonyielding +nonzero +noodle/GMSD +nook/MS +noon/GDMS +noonday/MS +nooning/M +noontide/MS +noontime/MS +noose/SDGM +nope/S +nor/H +noradrenalin +noradrenaline/M +norm/SMGD +normal/SY +normalcy/MS +normality/SM +normalization's +normalization/A +normalizations +normalize/SRDZGB +normalized/AU +normalizes/AU +normative/YP +normativeness/M +north/MRGZ +northbound +northeast/ZSMR +northeaster/YM +northeastern +northeastward/S +norther/MY +northerly/S +northern/RYZS +northernmost +northing/M +northland +northmen +norths +northward/S +northwest/MRZS +northwester/YM +northwestern +northwestward/S +nos/GDS +nose/M +nosebag/M +nosebleed/SM +nosecone/S +nosed/V +nosedive/DSG +nosegay/MS +nosh/MSDG +nosily +nosiness/MS +nosing/M +nostalgia/SM +nostalgic/S +nostalgically +nostril/SM +nostrum/SM +nosy/SRPMT +not/DRGB +notability/SM +notable/PS +notableness/M +notably +notarial +notarization/S +notarize/DSG +notary/MS +notate/VGNXSD +notation/CMSF +notational/CY +notative/CF +notch/MSDG +note's +note/CSDFG +notebook/MS +noted/YP +notedness/M +notepad/S +notepaper/MS +noteworthiness/SM +noteworthy/P +nothing/PS +nothingness/SM +notice/MSDG +noticeable/U +noticeably +noticeboard/S +noticed/U +notifiable +notification/M +notifier/M +notify/NGXSRDZ +notion/MS +notional/Y +notoriety/S +notorious/YP +notoriousness/M +notwithstanding +nougat/MS +noun/SMK +nourish/DRSGL +nourished/U +nourisher/M +nourishment/SM +nous/M +nouveau +nouvelle +nova/MS +novae +novel/SM +novelette/SM +novelist/SM +novelization/S +novelize/GDS +novella/SM +novelty/MS +novena/SM +novene +novice/MS +novitiate/MS +now/S +nowadays +noway/S +nowhere/S +nowise +noxious/PY +noxiousness/M +nozzle/MS +nroff/M +nth +nu/M +nuance/SDM +nub/MS +nubbin/SM +nubby/RT +nubile +nuclear/K +nuclease/M +nucleate/DSXNG +nucleated/A +nucleation/M +nuclei/M +nucleic +nucleoli +nucleolus/M +nucleon/MS +nucleotide/MS +nucleus/M +nuclide/M +nude/CRS +nudely +nudeness/M +nudest +nudge/GSRD +nudger/M +nudism/MS +nudist/MS +nudity/MS +nugatory +nugget/SM +nuisance/MS +nuke/DSMG +null/DSG +nullification/M +nullifier/M +nullify/RSDXGNZ +nullity/SM +numb/SGZTYRDP +number/RDMGJ +numbered/UA +numberer/M +numberless +numberplate/M +numbers/A +numbing/Y +numbness/MS +numbskull's +numerable/IC +numeracy/SI +numeral/YMS +numerate/SDNGX +numerates/I +numeration/M +numerator/MS +numeric/S +numerical/Y +numerological +numerologist/S +numerology/MS +numerous/YP +numerousness/M +numinous/S +numismatic/S +numismatics/M +numismatist/MS +numskull/SM +nun/MS +nuncio/SM +nunnery/MS +nuptial/S +nurse/SRDJGMZ +nursemaid/MS +nurser/M +nursery/MS +nurseryman/M +nurserymen +nursling/M +nurture/SRDGZM +nurturer/M +nus +nut/MS +nutate/NGSD +nutation/M +nutcrack/RZ +nutcracker/M +nuthatch/SM +nutmeat/SM +nutmeg/MS +nutmegged +nutmegging +nutpick/MS +nutria/SM +nutrient/MS +nutriment/MS +nutrition/SM +nutritional/Y +nutritionist/MS +nutritious/PY +nutritiousness/MS +nutritive/Y +nutshell/MS +nutted +nuttiness/SM +nutting +nutty/TRP +nuzzle/GZRSD +nylon/SM +nymph/M +nymphet/MS +nympholepsy/M +nymphomania/MS +nymphomaniac/S +nymphs +n�e +o +o'clock +o'er +o's +oaf/MS +oafish/PY +oafishness/S +oak/SMN +oakum/MS +oakwood +oar/GSMD +oarlock/MS +oarsman/M +oarsmen +oarswoman +oarswomen +oases +oasis/M +oat/SMNR +oatcake/MS +oater/M +oath/M +oaths +oatmeal/SM +ob +obbligato/S +obduracy/S +obdurate/PDSYG +obdurateness/S +obedience/EMS +obedient/EY +obeisance/MS +obeisant/Y +obelisk/SM +obese +obesity/MS +obey/EDRGS +obeyer/EM +obfuscate/SRDXGN +obfuscation/M +obfuscatory +obi/MDGS +obit/SMR +obituary/SM +obj +object/SGVMD +objectify/GSDXN +objection/SMB +objectionable/U +objectionableness/M +objectionably +objective/PYS +objectiveness/MS +objectivity/MS +objector/SM +objurgate/GNSDX +objurgation/M +oblate/NYPSX +oblation/M +obligate/NGSDXY +obligation/M +obligational +obligatorily +obligatory +oblige/SRDG +obliged/E +obliger/M +obliges/E +obliging/PY +obligingness/M +oblique/DSYGP +obliqueness/S +obliquity/MS +obliterate/VNGSDX +obliteration/M +obliterative/Y +oblivion/MS +oblivious/YP +obliviousness/MS +oblong/SYP +oblongness/M +obloquies +obloquy/M +obnoxious/YP +obnoxiousness/MS +oboe/SM +oboist/S +obos +obs +obscene/RYT +obscenity/MS +obscurantism/MS +obscurantist/MS +obscuration +obscure/YTPDSRGL +obscureness/M +obscurity/MS +obsequies +obsequious/YP +obsequiousness/S +obsequy +observability/M +observable/SU +observably +observance/MS +observant/U +observantly +observants +observation/MS +observational/Y +observatory/MS +observe/ZGDSRB +observed/U +observer/M +observing/Y +obsess/GVDS +obsession/MS +obsessional +obsessive/PYS +obsessiveness/S +obsidian/SM +obsolesce/GSD +obsolescence/S +obsolescent/Y +obsolete/GPDSY +obsoleteness/M +obstacle/SM +obstetric/S +obstetrical +obstetrician/SM +obstetrics/M +obstinacy/SM +obstinate/PY +obstinateness/M +obstreperous/PY +obstreperousness/SM +obstruct/RDVGS +obstructed/U +obstructer/M +obstruction/SM +obstructionism/SM +obstructionist/MS +obstructive/PSY +obstructiveness/MS +obtain/LSGDRB +obtainable/U +obtainably +obtainment/S +obtrude/DSRG +obtruder/M +obtrusion/S +obtrusive/UPY +obtrusiveness/MSU +obtuse/PRTY +obtuseness/S +obverse/YS +obviate/XGNDS +obvious/YP +obviousness/SM +ocarina/MS +occasion/MDSJG +occasional/Y +occident/M +occidental/SY +occipital/Y +occlude/GSD +occlusion/MS +occlusive/S +occult/SRDYG +occulter/M +occultism/SM +occupancy/SM +occupant/MS +occupation/SAM +occupational/Y +occupied/AU +occupier/M +occupies/A +occupy/RSDZG +occur/AS +occurred/A +occurrence/SM +occurring/A +ocean/MS +oceanfront/MS +oceangoing +oceanic +oceanographer/SM +oceanographic +oceanography/SM +oceanology/MS +oceanside +ocelot/SM +ocher/DMGS +octagon/SM +octagonal/Y +octahedral +octahedron/M +octal/S +octane/MS +octant/M +octave/MS +octavo/MS +octennial +octet/SM +octile +octillion/M +octogenarian/MS +octopi +octopus/SM +octoroon/M +ocular/S +oculist/SM +odalisque/SM +odd/TRYSPL +oddball/SM +oddity/MS +oddment/MS +oddness/MS +ode/MDRS +odious/PY +odiousness/MS +odium/MS +odometer/SM +odor/DMS +odoriferous +odorless +odorous/YP +odyssey/S +oedipal +oenology/MS +oenophile/S +oesophagi +oeuvre/SM +of/K +off/SZGDRJ +offal/MS +offbeat/MS +offcuts +offend/SZGDR +offender/M +offense/MSV +offensive/YSP +offensively/I +offensiveness/MSI +offer/RDJGZ +offerer/M +offering/M +offertory/SM +offhand/D +offhanded/YP +offhandedness/S +office/SRMZ +officeholder/SM +officemate/S +officer/GMD +officership/S +official/PSYM +officialdom/SM +officialism/SM +officially/U +officiant/SM +officiate/XSDNG +officiation/M +officiator/MS +officio +officious/YP +officiousness/MS +offing/M +offish +offload/GDS +offprint/GSDM +offramp +offset/SM +offsetting +offshoot/MS +offshore +offside/RS +offspring/M +offstage/S +offtrack +oft/NRT +often/RT +oftentimes +ofttimes +ogive/M +ogle/ZGDSR +ogre/MS +ogreish +ogress/S +oh +ohm/SM +ohmic +ohmmeter/MS +oho/S +ohs +oil/MDRSZG +oilcloth/M +oilcloths +oiler/M +oilfield/MS +oiliness/SM +oilman/M +oilmen +oilseed/SM +oilskin/MS +oily/TPR +oink/GDS +ointment/SM +okapi/SM +okay/M +okra/MS +old/XTNRPS +olden/DG +oldie/MS +oldish +oldness/S +oldster/SM +oleaginous +oleander/SM +olefin/M +oleo/S +oleomargarine/SM +oles +olfactory +oligarch/M +oligarchic +oligarchical +oligarchs +oligarchy/SM +oligopolistic +oligopoly/MS +olive/MSR +ol� +om/XN +ombudsman/M +ombudsmen +omega/MS +omelet/SM +omelette's +omen/DMG +omicron/MS +ominous/YP +ominousness/SM +omission/MS +omit/S +omitted +omitting +omni/M +omnibus/MS +omnipotence/SM +omnipotent/SY +omnipresence/MS +omnipresent/Y +omniscience/SM +omniscient/YS +omnivore/MS +omnivorous/PY +omnivorousness/MS +oms +on/RY +onanism/M +once/SR +oncer/M +oncogene/S +oncologist/S +oncology/SM +oncoming/S +one/NPMSX +oneiric +oneiric's +oneness/MS +oner/M +onerous/YP +onerousness/SM +oneself +onetime +oneupmanship +ongoing/S +onion/GDM +onionskin/MS +onlooker/MS +onlooking +only/TP +onomatopoeia/SM +onomatopoeic +onomatopoetic +onrush/GMS +ons +onset/SM +onsetting +onshore +onside +onslaught/MS +onto +ontogeny/SM +ontological/Y +ontology/SM +onus/SM +onward/S +onyx/MS +oodles +ooh/GD +oohs +oolitic +oops/S +ooze/GDS +oozy/RT +op/XGDN +opacity/SM +opal/SM +opalescence/S +opalescent/Y +opaque/GTPYRSD +opaqueness/SM +opcode/MS +ope/S +open/YRDJGZTP +opencast +opened/AU +opener/M +openhanded/P +openhandedness/SM +openhearted +opening/M +openness/S +opens/A +openwork/MS +opera/SM +operable/I +operand/SM +operandi +operant/YS +operate/XNGVDS +operatic/S +operatically +operation/M +operational/Y +operationalization/S +operationalize/D +operative/IP +operatively +operativeness/MI +operatives +operator/SM +operetta/MS +ophthalmic/S +ophthalmologist/SM +ophthalmology/MS +opiate/GMSD +opine/XGNSD +opinion/M +opinionated/PY +opinionatedness/M +opioid +opium/MS +opossum/SM +opp +opponent/MS +opportune/IY +opportunism/SM +opportunist/SM +opportunistic +opportunistically +opportunity/MS +oppose/BRSDG +opposed/U +opposer/M +opposite/SXYNP +oppositeness/M +opposition/M +oppositional +oppress/DSGV +oppression/MS +oppressive/YP +oppressiveness/MS +oppressor/MS +opprobrious/Y +opprobrium/SM +ops +opt/DSG +opthalmic +opthalmologic +opthalmology +optic/S +optical/Y +optician/SM +optics/M +optima +optimal/Y +optimality +optimise's +optimism/SM +optimist/SM +optimistic +optimistically +optimization/SM +optimize/DRSZG +optimized/U +optimizer/M +optimizes/U +optimum/SM +option/GDMS +optional/YS +optionality/M +optoelectronic +optometric +optometrist/MS +optometry/SM +opulence/SM +opulent/Y +opus/SM +or/MY +oracle/GMSD +oracular +oral/YS +orange/MS +orangeade/MS +orangery/SM +orangutan/MS +orate/SDGNX +oration/M +orator/MS +oratorical/Y +oratorio/MS +oratory/MS +orb/SMDG +orbicular +orbiculares +orbit/MRDGZS +orbital/MYS +orchard/SM +orchestra/MS +orchestral/Y +orchestrate/GNSDX +orchestrater's +orchestration/M +orchestrator/M +orchid/SM +ordain/SGLDR +ordainer/M +ordainment/MS +ordeal/SM +order's/E +order/AESGD +ordered/U +orderer +ordering/S +orderless +orderliness/SE +orderly/PS +ordinal/S +ordinance/MS +ordinarily +ordinariness/S +ordinary/RSPT +ordinate's +ordinate/I +ordinated +ordinates +ordinating +ordination/SM +ordnance/SM +ordure/MS +ore/NSM +oregano/SM +organ/MS +organdie's +organdy/MS +organelle/MS +organic/S +organically/I +organism/MS +organismic +organist/MS +organizable/UMS +organization/MEAS +organizational/MYS +organize/AGZDRS +organized/UE +organizer/MA +organizes/E +organizing/E +organometallic +organza/SM +orgasm/GSMD +orgasmic +orgiastic +orgy/SM +oriel/MS +orient's +orient/GADES +orientable +oriental/SY +orientate/ESDXGN +orientated/A +orientates/A +orientation/AMES +orienteering/M +orienter +orifice/MS +orig +origami/MS +origin/MS +original/US +originality/SM +originally +originate/VGNXSD +origination/M +originative/Y +originator/SM +oriole/SM +orison/SM +ormolu/SM +ornament/GSDM +ornamental/SY +ornamentation/SM +ornate/YP +ornateness/SM +orneriness/SM +ornery/PRT +ornithological +ornithologist/SM +ornithology/MS +orographic/M +orography/M +orotund +orotundity/MS +orphan/SGDM +orphanage/MS +orphanhood/M +orris/SM +ors +orthodontia/S +orthodontic/S +orthodontics/M +orthodontist/MS +orthodox/YS +orthodoxies +orthodoxly/U +orthodoxy's +orthodoxy/U +orthogonal/Y +orthogonality/M +orthogonalization/M +orthogonalized +orthographic +orthographically +orthography/MS +orthonormal +orthopedic/S +orthopedics/M +orthopedist/SM +orthophosphate/MS +orthorhombic +oscillate/SDXNG +oscillation/M +oscillator/SM +oscillatory +oscilloscope/SM +osculate/XDSNG +osculation/M +osier/MS +osmium/MS +osmoses +osmosis/M +osmotic +osprey/SM +osseous/Y +ossification/M +ossify/NGSDX +ostensible +ostensibly +ostentation/MS +ostentatious/PY +ostentatiousness/M +osteoarthritides +osteoarthritis/M +osteology/M +osteopath/M +osteopathic +osteopaths +osteopathy/MS +osteoporoses +osteoporosis/M +ostracise's +ostracism/MS +ostracize/GSD +ostrich/MS +other/SMP +otherness/M +otherwise +otherworld/Y +otherworldly/P +otiose +otter/DMGS +ottoman/MS +oubliette/SM +ouch/SDG +ought/SGD +oughtn't +ounce/MS +our/S +ourself +ourselves +oust/RDGZS +ouster/M +out/PJZGSDR +outage/MS +outargue/GDS +outback/MRS +outbalance/GDS +outbid/S +outbidding +outboard/S +outboast/GSD +outbound/S +outbreak/SMG +outbroke +outbroken +outbuilding/SM +outburst/MGS +outcast/GSM +outclass/SDG +outcome/SM +outcrop/SM +outcropped +outcropping/S +outcry/MSDG +outdated/P +outdid +outdistance/GSD +outdo/G +outdoes +outdone +outdoor/S +outdoorsy +outdraw/GS +outdrawn +outdrew +outermost +outerwear/M +outface/SDG +outfall/MS +outfield/RMSZ +outfielder/M +outfight/SG +outfit/MS +outfitted +outfitter/MS +outfitting +outflank/SGD +outflow/SMDG +outfought +outfox/GSD +outgeneraled +outgo/GJ +outgoes +outgoing/P +outgrew +outgrip +outgrow/GSH +outgrown +outgrowth/M +outgrowths +outguess/SDG +outhit/S +outhitting +outhouse/SM +outing/M +outlaid +outland/ZR +outlander/M +outlandish/PY +outlandishness/MS +outlast/GSD +outlaw/SDMG +outlawry/M +outlay/GSM +outlet/SM +outliers +outline/SDGM +outlive/GSD +outlook/MDGS +outlying +outmaneuver/GSD +outmatch/SDG +outmigration +outmoded +outness/M +outnumber/GDS +outpaced +outpatient/SM +outperform/DGS +outplacement/S +outplay/GDS +outpoint/GDS +outpost/SM +outpour/MJG +outpouring/M +outproduce/GSD +output/SM +outputted +outputting +outrace/GSD +outrage/GSDM +outrageous/YP +outrageousness/M +outran +outrank/GSD +outreach/SDG +outrider/MS +outrigger/SM +outright/Y +outrun/S +outrunning +outr� +outscore/GDS +outsell/GS +outset/MS +outsetting +outshine/SG +outshone +outshout/GDS +outside/ZSR +outsider/PM +outsize/S +outskirt/SM +outsmart/SDG +outsold +outsource/SDJG +outspend/SG +outspent +outspoke +outspoken/YP +outspokenness/SM +outspread/SG +outstanding/Y +outstate/NX +outstation/M +outstay/SDG +outstretch/GSD +outstrip/S +outstripped +outstripping +outtake/S +outvote/GSD +outward/SYP +outwardness/M +outwear/SG +outweigh/GD +outweighs +outwit/S +outwitted +outwitting +outwore +outwork/SMDG +outworn +ouzo/SM +ova/M +oval/MYPS +ovalness/M +ovarian +ovary/SM +ovate/SDGNX +ovation/GMD +oven/MS +ovenbird/SM +over/YGS +overabundance/MS +overabundant +overachieve/SRDGZ +overact/DGVS +overage/S +overaggressive +overall/SM +overallocation +overambitious +overanxious +overarching +overarm/GSD +overate +overattentive +overawe/GDS +overbalance/DSG +overbear/GS +overbearing/YP +overbearingness/M +overbid/S +overbidding +overbite/MS +overblown +overboard +overbold +overbook/SDG +overbore +overborne +overbought +overbuild/GS +overbuilt +overburden/SDG +overburdening/Y +overbuy/GS +overcame +overcapacity/M +overcapitalize/DSG +overcareful +overcast/GS +overcasting/M +overcautious +overcerebral +overcharge/DSG +overcloud/DSG +overcoat/SMG +overcoating/M +overcome/RSG +overcomer/M +overcommitment/S +overcompensate/XGNDS +overcompensation/M +overcomplexity/M +overcomplicated +overconfidence/MS +overconfident/Y +overconscientious +overconsumption/M +overcook/SDG +overcooled +overcorrection +overcritical +overcrowd/DGS +overcurious +overdecorate/SDG +overdependent +overdetermined +overdevelop/SDG +overdid +overdo/G +overdoes +overdone +overdose/DSMG +overdraft/SM +overdraw/GS +overdrawn +overdress/GDS +overdrew +overdrive/GSM +overdriven +overdrove +overdub/S +overdubbed +overdubbing +overdue +overeager/PY +overeagerness/M +overeat/GNRS +overeater/M +overeducated +overemotional +overemphases +overemphasis/M +overemphasize/GZDSR +overenthusiastic +overestimate/DSXGN +overestimation/M +overexcite/DSG +overexercise/SDG +overexert/GDS +overexertion/SM +overexploitation +overexploited +overexpose/GDS +overexposure/SM +overextend/DSG +overextension +overfall/M +overfed +overfeed/GS +overfill/GDS +overfishing +overflew +overflight/SM +overflow/DGS +overflown +overfly/GS +overfond +overfull +overgeneralize/GDS +overgenerous +overgraze/SDG +overgrew +overground +overgrow/GSH +overgrown +overgrowth/M +overgrowths +overhand/DGS +overhang/GS +overhasty +overhaul/GRDJS +overhead/S +overhear/SRG +overheard +overhearer/M +overheat/SGD +overhung +overincredulous +overindulge/SDG +overindulgence/SM +overindulgent +overinflated +overjoy/SGD +overkill/SDMG +overladed +overladen +overlaid +overlain +overland/S +overlap/MS +overlapped +overlapping +overlarge +overlay/GS +overleaf +overlie +overload/SDG +overlong +overlook/DSG +overlord/DMSG +overloud +overly/GRS +overmanning +overmaster/GSD +overmatching +overmodest +overmuch/S +overnice +overnight/SDRGZ +overoptimism/SM +overoptimistic +overpaid +overparticular +overpass/GMSD +overpay/LSG +overpayment/M +overplay/SGD +overpopulate/DSNGX +overpopulation/M +overpopulous +overpower/GSD +overpowering/Y +overpraise/DSG +overprecise +overpressure +overprice/SDG +overprint/DGS +overproduce/SDG +overproduction/S +overprotect/GVDS +overprotection/M +overqualified +overran +overrate/DSG +overreach/DSRG +overreact/SGD +overreaction/SM +overred +overrefined +overrepresented +overridden +override/RSG +overrider/M +overripe +overrode +overrule/GDS +overrun/S +overrunning +oversample/DG +oversaturate +oversaw +oversea/S +oversee/ZRS +overseeing +overseen +overseer/M +oversell/SG +oversensitive/P +oversensitiveness/S +oversensitivity +oversexed +overshadow/GSD +overshoe/SM +overshoot/SG +overshot/S +oversight/SM +oversimple +oversimplification/M +oversimplify/GXNDS +oversize/GS +oversleep/GS +overslept +oversoft/P +oversoftness/M +oversold +overspecialization/MS +overspecialize/GSD +overspend/SG +overspent +overspill/DMSG +overspread/SG +overstaffed +overstate/SDLG +overstatement/SM +overstay/GSD +overstep/S +overstepped +overstepping +overstimulate/DSG +overstock/SGD +overstraining +overstressed +overstretch/D +overstrict +overstrike/GS +overstrung +overstuffed +oversubscribe/SDG +oversubtle +oversupply/MDSG +oversuspicious +overt/PY +overtake/RSZG +overtaken +overtax/DSG +overthrew +overthrow/GS +overthrown +overtightened +overtime/MGDS +overtire/DSG +overtone/MS +overtook +overture/DSMG +overturn/SDG +overuse/DSG +overvalue/GSD +overview/MS +overweening +overweight/GSD +overwhelm/GDS +overwhelming/Y +overwinter/SDG +overwork/GSD +overwrap +overwrite/SG +overwritten +overwrote +overwrought +overzealous/P +overzealousness/M +oviduct/SM +oviform +oviparous +ovoid/S +ovular +ovulate/GNXDS +ovulatory +ovule/MS +ovum/MS +ow/DYG +owe/S +owl/GSMDR +owlet/SM +owlish/PY +owlishness/M +own/EGDS +owned/U +owner/SM +ownership/MS +ox/MNS +oxalate/M +oxalic +oxaloacetic +oxblood/S +oxbow/SM +oxcart/MS +oxen/M +oxford/MS +oxidant/SM +oxidate/NVX +oxidation/M +oxidative/Y +oxide/SM +oxidization/MS +oxidize/JDRSGZ +oxidized/U +oxidizer/M +oxidizes/A +oxtail/M +oxyacetylene/MS +oxygen/MS +oxygenate/XSDMGN +oxygenation/M +oxyhydroxides +oxymora +oxymoron/M +oyster/GSDM +oystering/M +oz +ozone/SM +p's/A +p/XTGJ +pH/M +pa/MH +pablum/S +pabulum/SM +pace/DRSMZG +pacemaker/SM +pacer/M +pacesetter/MS +pacesetting +pachyderm/MS +pachysandra/MS +pacific +pacifically +pacification/M +pacifier/M +pacifism/MS +pacifist/MS +pacifistic +pacify/NRSDGXZ +pack/GZSJDRMB +package's +package/ARSDG +packaged/U +packager/S +packages/U +packaging/SM +packed/AU +packer/MUS +packet/MSDG +packhorse/M +packing/M +packinghouse/S +packs/UA +packsaddle/SM +pact/SM +pad/MS +padded/U +padding/SM +paddle/MZGRSD +paddler/M +paddock/SDMG +paddy/SM +padlock/SGDM +padre/MS +paean/MS +paediatrician/MS +paediatrics/M +paedophilia's +paella/SM +paeony/M +pagan/SM +paganism/MS +page/MZGDRS +pageant/SM +pageantry/SM +pageboy/SM +paged/U +pageful +pager/M +paginate/DSNGX +pagoda/MS +paid/AU +pail/SM +pailful/SM +pain/GSDM +painful/YP +painfuller +painfullest +painfulness/MS +painkiller/MS +painkilling +painless/YP +painlessness/S +painstaking/SY +paint's +paint/ADRZGS +paintbox/M +paintbrush/SM +painted/U +painter/YM +painterly/P +painting/SM +paintwork +pair/JSDMG +paired/UA +pairs/A +pairwise +paisley/MS +pajama/MDS +pal/SJMDRYTG +palace/MS +paladin/MS +palaeolithic +palaeontologists +palaeontology/M +palanquin/MS +palatability/M +palatable/P +palatableness/M +palatal/YS +palatalization/MS +palatalize/SDG +palate/BMS +palatial/Y +palatinate/SM +palatine/S +palaver/GSDM +pale/SPY +paleface/SM +paleness/S +paleographer/SM +paleography/SM +paleolithic +paleontologist/S +paleontology/MS +palette/MS +palfrey/MS +palimony/S +palimpsest/MS +palindrome/MS +palindromic +paling/M +palisade/MGSD +palish +pall/GSMD +palladium/SM +pallbearer/SM +pallet/SMGD +palletized +palliate/SDVNGX +palliation/M +palliative/SY +pallid/PY +pallidness/MS +pallor/MS +palm/GSMDR +palmate +palmer/M +palmetto/MS +palmist/MS +palmistry/MS +palmtop/S +palmy/RT +palomino/MS +palpable +palpably +palpate/SDNGX +palpation/M +palpitate/NGXSD +palpitation/M +palsy/GSDM +paltriness/SM +paltry/TRP +paludal +pampas/M +pamper/RDSG +pamperer/M +pamphlet/SM +pamphleteer/DMSG +pan/SMD +panacea/MS +panache/MS +panama/S +pancake/MGSD +panchromatic +pancreas/MS +pancreatic +panda/SM +pandemic/S +pandemonium/SM +pander/ZGRDS +pane/KMS +panegyric/SM +panel/JSGDM +paneling/M +panelist/MS +panelization +panelized +pang/GDMS +pangolin/M +panhandle/RSDGMZ +panic/SM +panicked +panicking +panicky/RT +panier's +panjandrum/M +panned +pannier/SM +panning +panoply/MSD +panorama/MS +panoramic +panpipes +pansy/SM +pant/GDS +pantaloons +pantheism/MS +pantheist/S +pantheistic +pantheon/MS +panther/SM +pantie/SM +pantiled +pantograph/M +pantomime/SDGM +pantomimic +pantomimist/SM +pantry/SM +pantsuit/SM +pantyhose +pantyliner +pantywaist/SM +pap/SZMNR +papa/MS +papacy/SM +papal/Y +paparazzi +papaw/SM +papaya/MS +paper/GJMRDZ +paperback/GDMS +paperboard/MS +paperboy/SM +paperer/M +papergirl/SM +paperhanger/SM +paperhanging/SM +paperiness/M +paperless +paperweight/MS +paperwork/SM +papery/P +papilla/M +papillae +papillary +papist/MS +papoose/SM +papped +papping +pappy/RST +paprika/MS +papyri +papyrus/M +par/ZGSJBMDR +para/MS +parable/MGSD +parabola/MS +parabolic +paraboloid/MS +paraboloidal/M +paracetamol/M +parachute/RSDMG +parachuter/M +parachutist/MS +parade/RSDMZG +parader/M +paradigm/SM +paradigmatic +paradisaic +paradisaical +paradise/MS +paradox/MS +paradoxic +paradoxical/YP +paradoxicalness/M +paraffin/GSMD +paragon/SGDM +paragraph/MRDG +paragrapher/M +paragraphs +parakeet/MS +paralegal/S +paralinguistic +parallax/SM +parallel/DSG +paralleled/U +parallelepiped/MS +parallelism/SM +parallelization/MS +parallelize/ZGDSR +parallelogram/MS +paralysis/M +paralytic/S +paralytically +paralyze/ZGDRS +paralyzed/Y +paralyzedly/S +paralyzer/M +paralyzing/Y +paralyzingly/S +paramagnet/M +paramagnetic +paramecia +paramecium/M +paramedic/MS +paramedical/S +parameter/SM +parameterization/SM +parameterize/BSDG +parameterized/U +parameterless +parametric +parametrically +parametrization +parametrize/DS +paramilitary/S +paramount/S +paramour/MS +paranoia/SM +paranoiac/S +paranoid/S +paranormal/SY +parapet/SMD +paraphernalia +paraphrase/GMSRD +paraphraser/M +paraplegia/MS +paraplegic/S +paraprofessional/SM +parapsychologist/S +parapsychology/MS +paraquat/S +parasite/SM +parasitic/S +parasitically +parasitism/SM +parasitologist/M +parasitology/M +parasol/SM +parasympathetic/S +parathion/SM +parathyroid/S +paratroop/RSZ +paratrooper/M +paratyphoid/S +parboil/DSG +parcel/SGMD +parceled/U +parceling/M +parch/GSDL +parchment/SM +pardon/ZBGRDS +pardonable/U +pardonableness/M +pardonably/U +pardoner/M +pare/S +paregoric/SM +parent/MDGJS +parentage/MS +parental/Y +parenteral +parentheses +parenthesis/M +parenthesize/GSD +parenthetic +parenthetical/Y +parenthood/MS +pares/S +paresis/M +parfait/SM +pariah/M +pariahs +parietal/S +parimutuel/S +paring/M +parish/MS +parishioner/SM +parity/ESM +park/GJZDRMS +parka/MS +parking/M +parkish +parkland/M +parklike +parkway/MS +parlance/SM +parlay/DGS +parley/MDSG +parliament/MS +parliamentarian/SM +parliamentary/U +parlor/SM +parlous +parmigiana +parochial/Y +parochialism/SM +parochiality +parodied/U +parodist/SM +parody/SDGM +parole/MSDG +parolee/MS +paroxysm/MS +paroxysmal +parquet/SMDG +parquetry/SM +parrakeet's +parred +parricidal +parricide/MS +parring +parrot/GMDS +parrotlike +parry/GSD +pars/JDSRGZ +parse +parsec/SM +parsed/U +parser/M +parsimonious/Y +parsimony/SM +parsley/MS +parsnip/MS +parson/MS +parsonage/MS +part's +part/CDGS +partake/ZGSR +partaken +partaker/M +parter/S +parterre/MS +parthenogeneses +parthenogenesis/M +partial/SY +partiality/MS +participant/MS +participate/NGVDSX +participation/M +participator/S +participatory +participial/Y +participle/MS +particle/MS +particleboard/S +particolored +particular/SY +particularistic +particularity/SM +particularization/MS +particularize/GSD +particulate/S +parting/MS +partisan/SM +partisanship/SM +partition/AMRDGS +partitioned/U +partitioner/M +partitive/S +partizan's +partly +partner/DMGS +partnership/SM +partook +partridge/MS +parturition/SM +partway +party/RSDMG +parvenu/SM +pas/S +pascal/SM +paschal/S +pasha/MS +pass/JGVBZDSR +passably +passage/MGSD +passageway/MS +passband +passbook/MS +passel/MS +passenger/MYS +passer/M +passerby +passersby +passim +passing/Y +passion/SEM +passionate/EYP +passionated +passionateness/EM +passionates +passionating +passioned +passionflower/MS +passioning +passionless +passivated +passive/SYP +passiveness/S +passivity/S +passkey/SM +passmark +passover +passport/SM +password/SDM +pass�/M +past's/A +past/PGMDRS +pasta/MS +paste/MS +pasteboard/SM +pasted/UA +pastel/MS +pastern/SM +pasteup +pasteurization/MS +pasteurize/RSDGZ +pasteurized/U +pasteurizer/M +pastiche/MS +pastille/SM +pastime/SM +pastiness/SM +pastor/GSDM +pastoral/SPY +pastoralization/M +pastorate/MS +pastrami/MS +pastry/SM +pasts/A +pasturage/SM +pasture/MGSRD +pasturer/M +pasty/PTRS +pat/MNDRS +patch's +patch/EGRSD +patcher/EM +patchily +patchiness/S +patchwork/RMSZ +patchy/PRT +pate/SM +patella/MS +patellae +paten/M +patent/ZGMRDYSB +patentee/SM +pater/M +paterfamilias/SM +paternal/Y +paternalism/MS +paternalist +paternalistic +paternity/SM +paternoster/SM +path/M +pathetic +pathetically +pathfinder/MS +pathless/P +pathname/SM +pathogen/SM +pathogenesis/M +pathogenic +pathologic +pathological/Y +pathologist/MS +pathology/SM +pathos/SM +paths +pathway/MS +patience/SM +patient's/I +patient/MRYTS +patients/I +patina/SM +patine +patio/MS +patois/M +patresfamilias +patriarch/M +patriarchal +patriarchate/MS +patriarchs +patriarchy/MS +patrician/MS +patricide/MS +patrimonial +patrimony/SM +patriot/SM +patriotic/U +patriotically +patriotism/SM +patristic/S +patrol/MS +patrolled +patrolling +patrolman/M +patrolmen +patrolwoman +patrolwomen +patron/YMS +patronage/MS +patroness/S +patronization +patronize/GZRSDJ +patronized/U +patronizer/M +patronizes/A +patronizing's/U +patronizing/YM +patronymic/S +patronymically +patroon/MS +patsy/SM +patted +patten/MS +patter/RDSGJ +patterer/M +pattern/GSDM +patternless +patting +patty/SM +paucity/SM +paunch/GMSD +paunchiness/M +paunchy/RTP +pauper/SGDM +pauperism/SM +pauperize/SDG +pause/DSG +pave/GDRSJL +paved/UA +pavement/SGDM +paver/M +paves/A +pavilion/SMDG +paving's +paving/A +paw/MDSG +pawl/SM +pawn/GSDRM +pawnbroker/SM +pawnbroking/S +pawner/M +pawnshop/MS +pawpaw's +paxes +pay/AGSLB +payable/S +payback/S +paycheck/SM +payday/MS +payed +payee/SM +payer/SM +payload/SM +paymaster/SM +payment/ASM +payoff/MS +payola/MS +payout/S +payroll/MS +payslip/S +pct +pd +pea/MS +peace/GMDS +peaceable/P +peaceableness/M +peaceably +peaceful/PY +peacefuller +peacefullest +peacefulness/S +peacekeeping/S +peacemaker/MS +peacemaking/MS +peacetime/MS +peach/GSDM +peachy/RT +peacock/SGMD +peafowl/SM +peahen/MS +peak/SGDM +peaked/P +peakiness/M +peaky/P +peal/MDSG +pealed/A +peals/A +peanut/SM +pear/SYM +pearl/SGRDM +pearler/M +pearly/TRS +peartrees +peasant/SM +peasanthood +peasantry/SM +peashooter/MS +peat/SM +peats/A +peaty/TR +pebble/MGSD +pebbling/M +pebbly/TR +pecan/SM +peccadillo/M +peccadilloes +peccary/MS +peck/GZSDRM +pecker/M +pectic +pectin/SM +pectoral/S +peculate/NGDSX +peculator/S +peculiar/SY +peculiarity/MS +pecuniary +pedagogic/S +pedagogical/Y +pedagogics/M +pedagogue/SDGM +pedagogy/MS +pedal/SGRDM +pedant/SM +pedantic +pedantically +pedantry/MS +peddle/ZGRSD +peddler/M +pederast/SM +pederasty/SM +pedestal/GDMS +pedestrian/MS +pedestrianization +pedestrianize/GSD +pediatric/S +pediatrician/SM +pedicab/SM +pedicure/DSMG +pedicurist/SM +pedigree/DSM +pediment/DMS +pedlar's +pedometer/MS +pedophile/S +pedophilia +peduncle/MS +pee/ZDRS +peeing +peek/GSD +peekaboo/SM +peel/SJGZDR +peeler/M +peeling/M +peen/GSDM +peep/SGZDR +peeper/M +peephole/SM +peepshow/MS +peepy +peer/DMG +peerage/MS +peeress/MS +peerless/PY +peerlessness/M +peeve/GZMDS +peevers/M +peevish/YP +peevishness/SM +peewee/S +peg/MS +pegboard/SM +pegged +pegging +peignoir/SM +pejoration/SM +pejorative/SY +peke/MS +pekingese +pekoe/SM +pelagic +pelf/SM +pelican/SM +pellagra/SM +pellet/SGMD +pellucid +pelt/GSDR +pelter/M +pelvic/S +pelvis/SM +pemmican/SM +pen/M +penal/Y +penalization/SM +penalize/SDG +penalized/U +penalty/MS +penance/SDMG +pence/M +penchant/MS +pencil/SGJMD +pend/DCGS +pendant/SM +pendent/CS +pendulous +pendulum/MS +penetrability/SM +penetrable +penetrate/SDVGNX +penetrating/Y +penetration/M +penetrative/PY +penetrativeness/M +penetrator/MS +penguin/MS +penicillin/SM +penile +peninsula/SM +peninsular +penis/MS +penitence/MS +penitent/SY +penitential/YS +penitentiary/MS +penknife/M +penknives +penlight/MS +penman/M +penmanship/MS +penmen +pennant/SM +penned +penniless +penning +pennis +pennon/SM +penny/SM +pennyweight/SM +pennyworth/M +penologist/MS +penology/MS +pens/V +pension/ZGMRDBS +pensioner/M +pensive/PY +pensiveness/S +pent/AS +pentacle/MS +pentagon/SM +pentagonal/SY +pentagram/MS +pentameter/SM +pentathlete/S +pentathlon/MS +pentatonic +pentecostal +penthouse/SDGM +penuche/SM +penultimate/SY +penumbra/MS +penumbrae +penurious/YP +penuriousness/MS +penury/SM +peon/MS +peonage/MS +peony/SM +people/SDMG +pep/SM +pepped +pepper/SGRDM +peppercorn/MS +pepperer/M +peppergrass/M +peppermint/MS +pepperoni/S +peppery +peppiness/SM +pepping +peppy/PRT +pepsin/SM +peptic/S +peptidase/SM +peptide/SM +peptizing +per/K +peradventure/S +perambulate/DSNGX +perambulation/M +perambulator/MS +percale/MS +perceivably +perceive/DRSZGB +perceived/U +perceiver/M +percent/MS +percentage/MS +percentile/SM +percept/VMS +perceptible +perceptibly +perception/MS +perceptional +perceptive/YP +perceptiveness/MS +perceptual/Y +perch/GSDM +perchance +perchlorate/M +perchlorination +percipience/MS +percipient/S +percolate/NGSDX +percolation/M +percolator/MS +percuss/DSGV +percussion/SAM +percussionist/MS +percussive/PY +percussiveness/M +percutaneous/Y +perdition/MS +perdurable +peregrinate/XSDNG +peregrination/M +peregrine/S +peremptorily +peremptory/P +perennial/SY +perestroika/S +perfect/DRYSTGVP +perfecta/S +perfecter/M +perfectibility/MS +perfectible +perfection/MS +perfectionism/MS +perfectionist/MS +perfective/PY +perfectiveness/M +perfectness/MS +perfidious/YP +perfidiousness/M +perfidy/MS +perforate/XSDGN +perforated/U +perforation/M +perforce +perform/SDRZGB +performance/MS +performed/U +performer/M +perfume/ZMGSRD +perfumer/M +perfumery/SM +perfunctorily +perfunctoriness/M +perfunctory/P +perfused +perfusion/M +pergola/SM +perhaps/S +pericardia +pericardium/M +perigee/SM +perihelia +perihelion/M +peril/GSDM +perilous/PY +perilousness/M +perimeter/MS +perinatal +perinea +perineum/M +period/MS +periodic +periodical/YMS +periodicity/MS +periodontal/Y +periodontics/M +periodontist/S +peripatetic/S +peripheral/SY +periphery/SM +periphrases +periphrasis/M +periphrastic +periscope/SDMG +perish/BZGSRD +perishable/SM +perishing/Y +peristalses +peristalsis/M +peristaltic +peristyle/MS +peritoneal +peritoneum/SM +peritonitis/MS +periwig/MS +periwigged +periwigging +periwinkle/SM +perjure/SRDZG +perjurer/M +perjury/MS +perk/GDS +perkily +perkiness/S +perky/TRP +perm/MDGS +permafrost/MS +permalloy/M +permanence/SM +permanency/MS +permanent/YSP +permanentness/M +permeability/SM +permeable/P +permeableness/M +permeate/NGVDSX +permissibility/M +permissible/P +permissibleness/M +permissibly +permission/SM +permissive/YP +permissiveness/MS +permit/SM +permitted +permitting +permutation/MS +permute/SDG +pernicious/PY +perniciousness/MS +peroration/SM +peroxidase/M +peroxide/MGDS +perpend/DG +perpendicular/SY +perpendicularity/SM +perpetrate/NGXSD +perpetration/M +perpetrator/SM +perpetual/SY +perpetuate/NGSDX +perpetuation/M +perpetuity/MS +perplex/DSG +perplexed/Y +perplexity/MS +perquisite/SM +persecute/XVNGSD +persecution/M +persecutor/MS +persecutory +perseverance/MS +persevere/GSD +persevering/Y +persiflage/MS +persimmon/SM +persist/DRSG +persistence/SM +persistent/Y +persnickety +person's/U +person/BMS +persona/M +personable/P +personableness/M +personae +personage/SM +personal/YS +personality/SM +personalization/CMS +personalize/CSDG +personalized/U +personalty/MS +personification/M +personifier/M +personify/XNGDRS +personnel/SM +persons/U +perspective/YMS +perspex +perspicacious/PY +perspicaciousness/M +perspicacity/S +perspicuity/SM +perspicuous/YP +perspicuousness/M +perspiration/MS +perspire/DSG +persuade/ZGDRSB +persuaded/U +persuader/M +persuasion/SM +persuasive/U +persuasively +persuasiveness/MS +pert/YRTSP +pertain/GSD +pertinacious/YP +pertinaciousness/M +pertinacity/MS +pertinence/S +pertinent/YS +pertness/MS +perturb/GDS +perturbation/MS +perturbed/U +pertussis/SM +peruke/SM +perusal/SM +peruse/RSDZG +peruser/M +pervade/SDG +pervasion/M +pervasive/PY +pervasiveness/MS +perverse/PXYNV +perverseness/SM +perversion/M +perversity/MS +pervert/DRSG +perverted/YP +perverter/M +perviousness +peseta/SM +peskily +peskiness/S +pesky/RTP +peso/MS +pessimal/Y +pessimism/SM +pessimist/SM +pessimistic +pessimistically +pest/RZSM +pester/DG +pesticide/MS +pestiferous +pestilence/SM +pestilent/Y +pestilential/Y +pestle/SDMG +pesto/S +pet/SMRZ +petal/SDM +petard/MS +petcock/SM +peter/GD +pethidine/M +petiole/SM +petite/XNPS +petiteness/M +petition's/A +petition/GZMRD +petitioner/M +petitions/A +petits +petrel/SM +petri +petrifaction/SM +petrify/NDSG +petrochemical/SM +petrodollar/MS +petroglyph/M +petrol/MS +petrolatum/MS +petroleum/MS +petrolled +petrolling +petrologist/MS +petrology/MS +petted +petter/MS +petticoat/SMD +pettifog/S +pettifogged +pettifogger/SM +pettifogging +pettily +pettiness/S +petting +pettis +pettish/YP +pettishness/M +petty/PRST +petulance/MS +petulant/Y +petunia/SM +pew/SM +pewee/MS +pewit/MS +pewter/SRM +peyote/SM +pf +pfennig/SM +pg +phaeton/MS +phage/M +phagocyte/SM +phalanger/MS +phalanges +phalanx/SM +phalli +phallic +phallus/M +phantasm/SM +phantasmagoria/SM +phantasmal +phantasy's +phantom/MS +pharaoh +pharaohs +pharisaic +pharisee/S +pharmaceutic/S +pharmaceutical/SY +pharmaceutics/M +pharmacist/SM +pharmacological/Y +pharmacologist/SM +pharmacology/SM +pharmacopoeia/SM +pharmacy/SM +pharyngeal/S +pharynges +pharyngitides +pharyngitis/M +pharynx/M +phase/DSRGZM +phaseout/S +pheasant/SM +phenacetin/MS +phenobarbital/SM +phenol/MS +phenolic +phenolphthalein/M +phenomena/SM +phenomenal/Y +phenomenological/Y +phenomenology/MS +phenomenon/SM +phenotype/MS +phenyl/M +phenylalanine/M +pheromone/MS +phew/S +phi/SM +phial/MS +phialled +phialling +philander/SRDGZ +philanderer/M +philanthropic +philanthropically +philanthropist/MS +philanthropy/SM +philatelic +philatelist/MS +philately/SM +philharmonic/S +philippic/SM +philistine/S +philistinism/S +philodendron/MS +philological/Y +philologist/MS +philology/MS +philosopher/MS +philosophic +philosophical/Y +philosophize/ZDRSG +philosophized/U +philosophizer/M +philosophizes/U +philosophy/MS +philter/SGDM +philtre/DSMG +phlebitides +phlebitis/M +phlegm/SM +phlegmatic +phlegmatically +phloem/MS +phlox/M +phobia/SM +phobic/S +phoebe/SM +phoenix/MS +phone/DSGM +phoneme/SM +phonemic/S +phonemically +phonemics/M +phonetic/S +phonetically +phonetician/SM +phonetics/M +phonic/S +phonically +phonics/M +phoniness/MS +phonograph/RM +phonographer/M +phonographic +phonographs +phonologic +phonological/Y +phonologist/MS +phonology/MS +phonon/M +phony/PTRSDG +phooey/S +phosphatase/M +phosphate/MS +phosphide/M +phosphine/MS +phosphor/MS +phosphoresce +phosphorescence/SM +phosphorescent/Y +phosphoric +phosphorous +phosphorus/SM +photo/SGMD +photocell/MS +photochemical/Y +photochemistry/M +photocopier/M +photocopy/MRSDZG +photoelectric +photoelectrically +photoelectronic +photoelectrons +photoengrave/RSDJZG +photoengraver/M +photoengraving/M +photofinishing/MS +photogenic +photogenically +photograph's +photograph/AGD +photographer/SM +photographic +photographically +photographs/A +photography/MS +photojournalism/SM +photojournalist/SM +photoluminescence/M +photolysis/M +photolytic +photometer/SM +photometric +photometrically +photometry/M +photomicrograph/M +photomicrography/M +photomultiplier/M +photon/MS +photorealism +photosensitive +photosphere/M +photostatic +photosyntheses +photosynthesis/M +photosynthesize/DSG +photosynthetic +phototypesetter +phototypesetting/M +phrasal +phrase's +phrase/AGDS +phrasebook +phrasemaking +phraseology/MS +phrasing/SM +phrenological/Y +phrenologist/MS +phrenology/MS +phyla/M +phylactery/MS +phylae +phylogeny/MS +phylum/M +phys +physic/SM +physical/PYS +physicality/M +physician/SM +physicist/MS +physicked +physicking +physiochemical +physiognomy/SM +physiography/MS +physiologic +physiological/Y +physiologist/SM +physiology/MS +physiotherapist/MS +physiotherapy/SM +physique/MSD +phytoplankton/M +pi/ZGDRH +pianism/M +pianissimo/S +pianist/SM +pianistic +piano/SM +pianoforte/MS +pianola +piaster/MS +piazza/SM +pibroch/M +pibrochs +pica/SM +picador/MS +picaresque/S +picayune/S +piccalilli/MS +piccolo/MS +pick/GZSJDR +pickaback's +pickax/GMSD +pickaxe's +picker/MG +pickerel/MS +picket/MSRDZG +picketer/M +pickle/SDMG +pickoff/S +pickpocket/GSM +pickup/SM +picky/RT +picnic/SM +picnicked +picnicker/MS +picnicking +picofarad/MS +picojoule +picoseconds +picot/DMGS +pictograph/M +pictographs +pictorial/PYS +pictorialness/M +picture/MGSD +picturesque/PY +picturesqueness/SM +piddle/GSD +piddly +pidgin/SM +pie/MS +piebald/S +piece/GMDSR +piecemeal +piecer/M +piecewise +piecework/ZSMR +pieceworker/M +piedmont +pieing +pier/M +pierce/RSDZGJ +piercer/M +piercing/Y +piety/SM +piezoelectric +piezoelectricity/M +piffle/MGSD +pig/MLS +pigeon/DMGS +pigeonhole/SDGM +pigged +piggery/M +pigging +piggish/YP +piggishness/SM +piggy/RSMT +piggyback/MSDG +pigheaded/YP +pigheadedness/S +piglet/MS +pigment/MDSG +pigmentation/MS +pigpen/SM +pigroot +pigskin/MS +pigsty/SM +pigswill/M +pigtail/SMD +pike/MZGDRS +piker/M +pikestaff/MS +pilaf/MS +pilaster/SM +pilau's +pilchard/SM +pile/JDSMZG +pileup/MS +pilfer/ZGSRD +pilferage/SM +pilferer/M +pilgrim/MS +pilgrimage/DSGM +piling/M +pill/GSMD +pillage/RSDZG +pillar/DMSG +pillbox/MS +pillion/DMGS +pillory/MSDG +pillow/GDMS +pillowcase/SM +pillowslip/S +pilot/DMGS +pilothouse/SM +piloting/M +pimento/MS +pimiento/SM +pimp/GSMYD +pimpernel/SM +pimple/SDM +pimplike +pimply/TRM +pin's +pin/US +pinafore/MS +pinball/MS +pincer/GSD +pinch/GRSD +pincher/M +pincushion/SM +pine/MNGXDS +pineapple/MS +pined/A +pines/A +pinfeather/SM +ping/GDRM +pinhead/SMD +pinheaded/P +pinhole/SM +pining/A +pinion/DMG +pink/GTYDRMPS +pinkeye/MS +pinkie/SM +pinkish/P +pinkness/S +pinko/MS +pinky's +pinnacle/MGSD +pinnate +pinned/U +pinning/S +pinochle/SM +pinpoint/SDG +pinprick/MDSG +pinsetter/SM +pinstripe/SDM +pint/MRS +pintail/SM +pinto/S +pinup/MS +pinwheel/DMGS +piny/RT +pinyin +pion/M +pioneer/SDMG +pious/YP +piousness/MS +pip/JSZMGDR +pipe/MS +pipeline/DSMG +piper/M +pipet's +pipette/MGSD +pipework +piping/YM +pipit/MS +pipped +pippin/SM +pipping +pipsqueak/SM +piquancy/MS +piquant/PY +piquantness/M +pique/GMDS +piracy/MS +piranha/SM +pirate/MGSD +piratical/Y +pirogi +pirogies +pirouette/MGSD +pis +piscatorial +pismire/SM +piss/DSRG! +pistachio/MS +piste/SM +pistil/MS +pistillate +pistol/SMGD +pistole/M +pistoleers +piston/SM +pit/MS +pita/SM +pitapat/S +pitapatted +pitapatting +pitch/RSDZG +pitchblende/SM +pitcher/M +pitchfork/GDMS +pitching/M +pitchman/M +pitchmen +pitchstone/M +piteous/YP +piteousness/SM +pitfall/SM +pith/MGDS +pithily +pithiness/SM +piths +pithy/RTP +pitiable/P +pitiableness/M +pitiably +pitier/M +pitiful/PY +pitifuller +pitifullest +pitifulness/M +pitiless/PY +pitilessness/SM +pitman/M +piton/SM +pittance/SM +pitted +pitting +pituitary/SM +pity/ZDSRMG +pitying/Y +pivot/DMSG +pivotal/Y +pivoting/M +pix/DSG +pixel/SM +pixie/MS +pixiness +pixmap/SM +pizazz/S +pizza/SM +pizzeria/SM +pizzicati +pizzicato +pi�ata/S +pi�on/S +pj's +pk +pkg +pkt +pkwy +pl +placard/DSMG +placate/NGVXDRS +placatory +place/DSRJLGZM +placeable/A +placebo/SM +placed/EAU +placeholder/S +placekick/DGS +placeless/Y +placement/AMES +placenta/SM +placental/S +placer/EM +places/EA +placid/PY +placidity/SM +placidness/M +placing/AE +placket/SM +plagiarism/MS +plagiarist/MS +plagiarize/GZDSR +plagiary/SM +plague/MGRSD +plagued/U +plaguer/M +plaice/M +plaid/DMSG +plain/SPTGRDY +plainclothes +plainclothesman +plainclothesmen +plainness/MS +plainsman/M +plainsmen +plainsong/SM +plainspoken +plaint/VMS +plaintiff/MS +plaintive/YP +plaintiveness/M +plait/SRDMG +plaiting/M +plan/DRMSGZ +planar +planarity +plane's +plane/SCGD +planeload +planer/M +planet/MS +planetarium/MS +planetary +planetesimal/M +planetoid/SM +plangency/S +plangent +plank/SJMDG +planking/M +plankton/MS +planned/U +planner/SM +planning +planoconcave +planoconvex +plant's +plant/SADG +plantain/MS +plantar +plantation/MS +planter/MS +planting/S +plantlike +plaque/MS +plash/GSDM +plasm/M +plasma/MS +plasmid/S +plaster/MDRSZG +plasterboard/MS +plasterer/M +plastering/M +plasterwork/M +plastic/MYS +plastically +plasticine +plasticity/SM +plasticize/GDS +plat/JDNRSGXZ +plate/SM +plateau/GDMS +plateful/S +platelet/SM +platen/M +plater/M +platform/SGDM +plating/M +platinize/GSD +platinum/MS +platitude/SM +platitudinous/Y +platonic +platoon/MDSG +platted +platter/MS +platting +platy/TR +platypus/MS +platys +plaudit/MS +plausibility/S +plausible/P +plausibly +play/DRSEBG +playability/U +playable/U +playact/SJDG +playacting/M +playback/MS +playbill/SM +playboy/SM +played/A +player's/E +player/SM +playfellow/S +playful/PY +playfulness/MS +playgirl/SM +playgoer/MS +playground/MS +playgroup/S +playhouse/SM +playing/S +playmate/MS +playoff/S +playpen/SM +playroom/SM +plays/A +plaything/MS +playtime/SM +playwright/SM +playwriting/M +plaza/SM +plea/SM +plead/ZGJRDS +pleader/MA +pleading/MY +pleas/RSDJG +pleasant/UYP +pleasanter +pleasantest +pleasantness/SMU +pleasantry/MS +please/Y +pleased/EU +pleaser/M +pleases/E +pleasing/YP +pleasingness/M +pleasurable/P +pleasurableness/M +pleasurably +pleasure's/E +pleasure/MGBDS +pleasureful +pleasures/E +pleat/RDMGS +pleater/M +plebe/MS +plebeian/SY +plebiscite/SM +plectra +plectrum/SM +pledge/RSDMG +pledger/M +plenary/S +plenipotentiary/S +plenitude/MS +plenteous/PY +plenteousness/M +plentiful/YP +plentifulness/M +plenty/SM +plenum/M +pleonasm/MS +plethora/SM +pleura/M +pleurae +pleural +pleurisy/SM +plexus/SM +pliability/MS +pliable/P +pliableness/M +pliancy/MS +pliant/YP +pliantness/M +plication/MA +plier/MA +plight/GMDRS +plimsolls +plink/GRDS +plinker/M +plinth/M +plinths +plod/S +plodded +plodder/SM +plodding/SY +plop/SM +plopped +plopping +plosive +plot/SM +plotted/A +plotter/MDSG +plotting +plover/MS +plow/SGZDRM +plowed/U +plower/M +plowman/M +plowmen +plowshare/MS +ploy's +ploy/SCDG +pluck/SGRD +plucker/M +pluckily +pluckiness/SM +plucky/TPR +plug's +plug/US +pluggable +plugged/UA +plugging/AU +plughole +plum/SMDG +plumage/DSM +plumb/JSZGMRD +plumbago/M +plumbed/U +plumber/M +plumbing/M +plume/SM +plummer +plummest +plummet/DSG +plummy +plump/RDNYSTGP +plumper/M +plumpness/S +plumy/TR +plunder/GDRSZ +plunge/RSDZG +plunger/M +plunk/ZGSRD +plunker/M +pluperfect/S +plural/SY +pluralism/MS +pluralist/S +pluralistic +plurality/SM +pluralization/MS +pluralize/GZRSD +pluralizer/M +plus/S +plush/RSYMTP +plushness/MS +plushy/RPT +plussed +plussing +plutocracy/MS +plutocrat/SM +plutocratic +plutonium/SM +pluvial/S +ply/AZNGRSD +plywood/MS +pm +pneumatic/S +pneumatically +pneumatics/M +pneumonia/MS +poach/ZGSRD +poacher/M +pock/GDMS +pocket/MSRDG +pocketbook/SM +pocketful/SM +pocketing/M +pocketknife/M +pocketknives +pockmark/MDSG +pod/SM +podded +podding +podge/ZR +podiatrist/MS +podiatry/MS +podium/MS +poem/MS +poesy/GSDM +poet/MS +poetaster/MS +poetess/MS +poetic/S +poetical/U +poetically +poeticalness +poetics/M +poetry/SM +pogo +pogrom/GMDS +poi/SM +poignancy/MS +poignant/Y +poinciana/SM +poinsettia/SM +point/RDMZGS +pointblank +pointed/PY +pointedness/M +pointer/M +pointillism/SM +pointillist/SM +pointing/M +pointless/YP +pointlessness/SM +pointy/TR +pois/GDS +poise/M +poison/RDMZGSJ +poisoner/M +poisoning/M +poisonous/PY +poke/DRSZG +poker/M +pokerface/D +poky/SRT +pol/GMDRS +polar/S +polarimeter/SM +polarimetry +polariscope/M +polarity/MS +polarization/CMS +polarize/RSDZG +polarized/UC +polarizes/C +polarizing/C +polarogram/SM +polarograph +polarography/M +pole/MS +polecat/SM +polemic/S +polemical/Y +polemicist/S +polemics/M +poler/M +polestar/S +poleward/S +police/MSDG +policeman/M +policemen/M +policewoman/M +policewomen +policy/SM +policyholder/MS +policymaker/S +policymaking +polio/SM +poliomyelitides +poliomyelitis/M +polis/M +polish/RSDZGJ +polished/U +polisher/M +politburo/S +polite/PRTY +politeness/MS +politesse/SM +politic/S +political/U +politically +politician/MS +politicization/S +politicize/CSDG +politicked +politicking/SM +politico/SM +politics/M +polity/MS +polka/SDMG +poll/MDNRSGX +pollack/SM +polled/U +pollen/GDM +pollinate/XSDGN +pollination/M +pollinator/MS +polliwog/SM +pollock's +pollster/MS +pollutant/MS +pollute/RSDXZVNG +polluted/U +polluter/M +pollution/M +pollywog's +polo/MS +polonaise/MS +polonium/MS +poltergeist/SM +poltroon/MS +polyandrous +polyandry/MS +polyatomic +polybutene/MS +polycarbonate +polychemicals +polychrome +polyclinic/MS +polycrystalline +polyelectrolytes +polyester/SM +polyether/S +polyethylene/SM +polygamist/MS +polygamous/Y +polygamy/MS +polyglot/S +polygon/MS +polygonal/Y +polygraph/MDG +polygraphs +polygynous +polyhedral +polyhedron/MS +polyisobutylene +polyisocyanates +polymath/M +polymaths +polymer/MS +polymerase/S +polymeric +polymerization/SM +polymerize/SDG +polymorph/M +polymorphic +polymorphism/MS +polymyositis +polynomial/YMS +polyp/MS +polyphonic +polyphony/MS +polyphosphate/S +polypropylene/MS +polystyrene/SM +polysyllabic +polysyllable/SM +polytechnic/MS +polytheism/SM +polytheist/SM +polytheistic +polythene/M +polytonal/Y +polytopes +polyunsaturated +polyurethane/SM +polyvinyl/MS +pomade/MGSD +pomander/MS +pomegranate/SM +pommel/GSMD +pomp/SM +pompadour/MDS +pompano/SM +pompom/SM +pompon's +pomposity/MS +pompous/YP +pompousness/S +ponce/M +poncho/MS +pond/SMDRGZ +ponder/ZGRD +ponderer/M +ponderous/PY +ponderousness/MS +pone/SM +pongee/MS +poniard/GSDM +pons/M +pontiff/MS +pontifical/YS +pontificate/XGNDS +pontoon/SMDG +pony/DSMG +ponytail/SM +pooch/GSDM +poodle/MS +poof/MS +pooh/DG +poohs +pool/MDSG +poolroom/MS +poolside +poop/MDSG +poor/TYRP +poorboy +poorhouse/MS +poorness/MS +pop/SM +popcorn/MS +pope/SM +popgun/SM +popinjay/MS +poplar/SM +poplin/MS +popover/SM +poppa/MS +popped +popper/SM +poppet/M +popping +poppy/SDM +poppycock/MS +poppyseed +populace/MS +popular/YS +popularism +popularity/UMS +popularization/SM +popularize/A +popularized +popularizer/MS +popularizes/U +popularizing +populate/CXNGDS +populated/UA +populates/A +populating/A +population/MC +populism/S +populist/SM +populous/YP +populousness/MS +porcelain/SM +porch/SM +porcine +porcupine/MS +pore/ZGDRS +porgy/SM +poring/Y +pork/ZRMS +porker/M +porky/TSR +porn/S +porno/S +pornographer/SM +pornographic +pornographically +pornography/SM +porosity/SM +porous/PY +porousness/MS +porphyritic +porphyry/MS +porpoise/DSGM +porridge/MS +porringer/MS +port/ABSGZMRD +portability/S +portable/U +portables +portably +portage/ASM +portaged +portaging +portal/SM +portamento/M +portcullis/MS +ported/CE +portend/SDG +portent/SM +portentous/PY +portentousness/M +porter's/A +porter/DMG +porterage/M +porterhouse/SM +portfolio/MS +porthole/SM +portico/M +porticoes +porting/E +portion/KGSMD +porti�re/SM +portliness/SM +portly/PTR +portmanteau/SM +portrait/MS +portraitist/SM +portraiture/MS +portray/GDRS +portrayal/SM +portrayer/M +ports/CE +portulaca/MS +pose/ZGKDRSE +posed/CA +poser/KME +poses/CA +poseur/MS +posh/DSRGT +posing/CA +posit/SCGD +positifs +position's/EC +position/KGASMD +positionable +positional/KY +positions/EC +positive/RSPYT +positiveness/S +positivism/M +positivist/S +positivity +positron/SM +poss/S +posse/M +possess/AGEDS +possessed/PY +possession/AEMS +possessional +possessive/PSMY +possessiveness/MS +possessor/MS +possibility/SM +possible/TRS +possibly +possum/MS +post's +post/ASDRJG +postage/MS +postal/S +postbag/M +postbox/SM +postcard/SM +postcode/SM +postcondition/S +postconsonantal +postdate/DSG +postdoctoral +poster/MS +posterior/SY +posteriori +posterity/SM +postfix/GDS +postgraduate/SM +posthaste/S +posthumous/YP +posthumousness/M +posthypnotic +postilion/MS +postindustrial +posting/M +postlude/MS +postman/M +postmarital +postmark/GSMD +postmaster/SM +postmen +postmeridian +postmistress/MS +postmodern +postmodernist +postmortem/S +postnasal +postnatal +postoperative/Y +postorder +postpaid +postpartum +postpone/GLDRS +postponement/S +postpositions +postprandial +postscript/SM +postsecondary +postulate/XGNSD +postulation/M +postural +posture/MGSRD +posturer/M +postvocalic +postwar +posy/SM +pot/CMS +potability/SM +potable/SP +potableness/M +potage/M +potash/MS +potassium/MS +potato/M +potatoes +potbelly/MSD +potboil/ZR +potboiler/M +potency/MS +potent/YS +potentate/SM +potential/SY +potentiality/MS +potentiating +potentiometer/SM +potful/SM +pothead/MS +pother/GDMS +potherb/MS +potholder/MS +pothole/SDMG +potholing/M +pothook/SM +potion/SM +potlatch/SM +potluck/MS +potpie/SM +potpourri/SM +potsherd/MS +potshot/S +pottage/SM +potted +potter/RDMSG +pottery/MS +potting +potty/SRT +pouch/SDMG +poulterer/MS +poultice/DSMG +poultry/MS +pounce/SDG +pound/KRDGS +poundage/MS +pounder/MS +pour/DSG +pourer's +pout/GZDRS +pouter/M +poverty/MS +pow/RZ +powder/RDGMS +powderpuff +powdery +power/GMD +powerboat/MS +powerful/YP +powerfulness/M +powerhouse/MS +powerless/YP +powerlessness/SM +powwow/GDMS +pox/GMDS +pp +ppm +ppr +pr +practicability/S +practicable/P +practicably +practical/YPS +practicality/SM +practicalness/M +practice/BDRSMG +practiced/U +practicer/M +practicum/SM +practitioner/SM +praetor/MS +praetorian/S +pragmatic/S +pragmatical/Y +pragmatics/M +pragmatism/MS +pragmatist/MS +prairie/MS +praise's +praise/ESDG +praiser/S +praiseworthiness/MS +praiseworthy/P +praising/Y +praline/MS +pram/MS +prance/ZGSRD +prancer/M +prancing/Y +prank/SMDG +prankster/SM +praseodymium/SM +prate/DSRGZ +prater/M +pratfall/MS +prating/Y +prattle/DRSGZ +prattler/M +prattling/Y +prawn/MDSG +praxes +praxis/M +pray/DRGZS +prayer/M +prayerbook +prayerful/YP +prayerfulness/M +preach/DRSGLZJ +preacher/M +preaching/Y +preachment/MS +preachy/RT +preadolescence/S +preallocate/XGNDS +preallocation/M +preallocator/S +preamble/MGDS +preamp +preamplifier/M +prearrange/LSDG +prearrangement/SM +preassign/SDG +preauthorize +prebendary/M +precancel/DGS +precancerous +precarious/PY +precariousness/MS +precaution/SGDM +precautionary +precede/DSG +precedence/SM +precedent/SDM +precedented/U +precept/SMV +preceptive/Y +preceptor/MS +precess/DSG +precession/M +precinct/MS +preciosity/MS +precious/PYS +preciousness/S +precipice/MS +precipitable +precipitant/S +precipitate/YNGVPDSX +precipitateness/M +precipitation/M +precipitous/YP +precipitousness/M +precise/XYTRSPN +preciseness/SM +precision/M +preclude/GDS +preclusion/S +precocious/YP +precociousness/MS +precocity/SM +precode/D +precognition/SM +precognitive +precollege/M +precolonial +precomputed +preconceive/GSD +preconception/SM +precondition/GMDS +preconscious +precook/GDS +precursor/SM +precursory +precut +predate/NGDSX +predation/CMS +predator/SM +predatory +predecease/SDG +predecessor/MS +predeclared +predecline +predefine/GSD +predefinition/SM +predesignate/GDS +predestination/SM +predestine/SDG +predetermination/MS +predetermine/ZGSRD +predeterminer/M +predicable/S +predicament/SM +predicate/VGNXSD +predication/M +predicator +predict/BSDGV +predictability/UMS +predictable/U +predictably/U +predicted/U +prediction/MS +predictive/Y +predictor/MS +predigest/GDS +predilect +predilection/SM +predispose/SDG +predisposition/MS +predoctoral +predominance/SM +predominant/Y +predominate/YSDGN +predomination/M +preemie/MS +preeminence/SM +preeminent/Y +preemployment/M +preempt/GVSD +preemption/SM +preemptive/Y +preemptor/M +preen/SRDG +preener/M +preexist/DSG +preexistence/SM +preexistent +pref/RZ +prefab/MS +prefabbed +prefabbing +prefabricate/XNGDS +prefabrication/M +preface/DRSGM +prefacer/M +prefatory +prefect/MS +prefecture/MS +prefer/BL +preferable/P +preferableness/M +preferably +preference/MS +preferential/Y +preferment/SM +preferred +preferring +prefiguration/M +prefigure/SDG +prefix/MDSG +preflight/SGDM +preform/DSG +pregnancy/SM +pregnant/Y +preheat/GDS +prehensile +prehistoric +prehistorical/Y +prehistory/SM +preindustrial +preinitialize/SDG +preinterview/M +preisolated +prejudge/DRSG +prejudger/M +prejudgment/SM +prejudice/MSDG +prejudiced/U +prejudicial/PY +prekindergarten/MS +prelacy/MS +prelate/SM +preliminarily +preliminary/S +preliterate/S +preloaded +prelude/GMDRS +preluder/M +premarital/Y +premarket +premature/SPY +prematureness/M +prematurity/M +premed/S +premedical +premeditate/XDSGNV +premeditated/Y +premeditation/M +premenstrual +premier/GSDM +premiere/MS +premiership/SM +premise/GMDS +premiss's +premium/MS +premix/GDS +premolar/S +premonition/SM +premonitory +prenatal/Y +prenuptial +preoccupation/MS +preoccupy/DSG +preoperative +preordain/DSLG +prep/SM +prepackage/GSD +prepaid +preparation/SM +preparative/SYM +preparatory +prepare/ZDRSG +prepared/UP +preparedly +preparedness/USM +prepay/GLS +prepayment/SM +prepender/S +prepends +preplanned +preponderance/SM +preponderant/Y +preponderate/DSYGN +preposition/SDMG +prepositional/Y +prepossess/GSD +prepossessing/U +prepossession/MS +preposterous/PY +preposterousness/M +prepped +prepping +preppy/RST +preprepared +preprint/SGDM +preprocessed +preprocessing +preprocessor/S +preproduction +preprogrammed +prepubescence/S +prepubescent/S +prepublication/M +prepuce/SM +prequel/S +preradiation +prerecord/DGS +preregister/DSG +preregistration/MS +prerequisite/SM +prerogative/SDM +pres/S +presage/GMDRS +presager/M +presbyopia/MS +presbyter/MS +presbyterian +presbytery/MS +preschool/RSZ +prescience/SM +prescient/Y +prescribe/RSDG +prescribed/U +prescriber/M +prescript/SVM +prescription/SM +prescriptive/Y +preselect/SGD +presence/SM +present/SLBDRYZGP +presentable/P +presentableness/M +presentably/A +presentation/AMS +presentational/A +presented/A +presenter/A +presentiment/MS +presentment/SM +presents/A +preservation/SM +preservationist/S +preservative/SM +preserve/DRSBZG +preserved/U +preserver/M +preset/S +presetting +preshrank +preshrink/SG +preshrunk +preside/DRSG +presidency/MS +president/SM +presidential/Y +presider/M +presidia +presidium/M +presoaks +presort/GDS +press/ACDSG +pressed/U +presser/MS +pressing/YS +pressingly/C +pressman/M +pressmen +pressure/DSMG +pressurization/MS +pressurize/DSRGZ +pressurized/U +prestidigitate/NX +prestidigitation/M +prestidigitator/M +prestidigitatorial +prestige/MS +prestigious/PY +presto/S +presumably +presume/BGDRS +presumer/M +presuming/Y +presumption/MS +presumptive/Y +presumptuous/YP +presumptuousness/SM +presuppose/GDS +presupposition/S +pretax +preteen/S +pretend/SDRZG +pretended/Y +pretender/M +pretending/U +pretense/MNVSX +pretension/GDM +pretentious/UYP +pretentiousness/S +preterit/SM +preterite's +preternatural/Y +pretest/SDG +pretext/SMDG +pretreated +pretreatment/S +pretrial +prettify/SDG +prettily +prettiness/SM +pretty/TGPDRS +pretzel/SM +prevail/SGD +prevailing/Y +prevalence/MS +prevalent/SY +prevaricate/DSXNG +prevaricator/MS +prevent/BSDRGV +preventable/U +preventably +preventative/S +preventer/M +prevention/MS +preventive/SPY +preventiveness/M +preview/ZGSDRM +previous/Y +prevision/SGMD +prewar +prexes +prey/SMDG +preyer's +priapic +price's +price/AGSD +priced/U +priceless +pricer/MS +pricey +pricier +priciest +prick/RDSYZG +pricker/M +pricking/M +prickle/GMDS +prickliness/S +prickly/RTP +pride/GMDS +prideful/Y +prier/M +priest/SMYDG +priestess/MS +priesthood/SM +priestliness/SM +priestly/PTR +prig/SM +prigged +prigging +priggish/PYM +priggishness/S +prim/SPJGZYDR +primacy/MS +primal +primarily +primary/MS +primate/MS +prime/PYS +primed/U +primely/M +primeness/M +primer/M +primeval/Y +priming/M +primitive/YPS +primitiveness/SM +primitivism/M +primmed +primmer +primmest +primming +primness/MS +primogenitor/MS +primogeniture/MS +primordial/YS +primp/DGS +primrose/MGSD +prince/SMY +princedom/MS +princeliness/SM +princely/PRT +princess/MS +principal/SY +principality/MS +principle/SDMG +principled/U +print/AGDRS +printable/U +printably +printed/U +printer/AM +printers +printing/SM +printmake/ZGR +printmaker/M +printmaking/M +printout/S +prior/YS +prioress/MS +priori +prioritize/DSRGZJ +priority/MS +priory/SM +prise/GMAS +prised +prism/MS +prismatic +prison/DRMSGZ +prisoner/M +prissily +prissiness/SM +prissy/RSPT +pristine/Y +prithee/S +privacy/MS +private/NVYTRSXP +privateer/SMDG +privateness/M +privation/MCS +privative/Y +privatization/S +privatize/GSD +privet/SM +privilege/SDMG +privileged/U +privily +privy/SRMT +prize/DSRGZM +prized/A +prizefight/SRMGJZ +prizefighter/M +prizefighting/M +prizewinner/S +prizewinning +pro/MS +proactive +prob/RBJ +probabilist +probabilistic +probabilistically +probability/SM +probable/S +probably +probate/NVMX +probated/A +probates/A +probating/A +probation's/A +probation/MRZ +probational +probationary/S +probationer/M +probative/A +prober/M +probity/SM +problem/SM +problematic/S +problematical/UY +proboscis/MS +procaine/MS +procedural/SY +procedure/MS +proceed/JRDSG +proceeder/M +proceeding/M +process/BSDMG +processed/UA +processes/A +procession/GD +processional/YS +processor/MS +proclamation/MS +proclivity/MS +proconsular +procrastinate/XNGDS +procrastination/M +procrastinator/MS +procreational +procreatory +procrustean +proctor/GSDM +proctorial +procurable/U +procure/L +procurement/MS +prod/S +prodded +prodding +prodigal/SY +prodigality/S +prodigious/PY +prodigiousness/M +prodigy/MS +produce/AZGDRS +producer/AM +producible/A +product/V +production/ASM +productive/PY +productively/UA +productiveness/MS +productivities +productivity's +productivity/A +productize/GZRSD +prof/S +profanation/S +profane/YPDRSG +profaneness/MS +profanity/MS +professed/Y +profession/SM +professional/USY +professionalism/SM +professionalize/GSD +professor/SM +professorial/Y +professorship/SM +proffer/GSD +proficiency/SM +proficient/YS +profit/GZDRB +profitability/MS +profitable/UP +profitableness/MU +profitably/U +profiteer/GSMD +profiterole/MS +profitless +profligacy/S +profligate/YS +proforma/S +profound/PTYR +profoundity +profoundness/SM +profundity/MS +profuse/YP +profuseness/MS +progenitor/SM +progeny/M +progesterone/SM +prognathous +prognoses +prognosis/M +prognostic/S +prognosticate/NGVXDS +prognostication/M +prognosticator/S +program/CSA +programed +programing +programmability +programmable/S +programmed/CA +programmer/ASM +programming/CA +programmings +progress/MSDVG +progression/SM +progressive/SPY +progressiveness/SM +progressivism +prohibit/VGSRD +prohibiter/M +prohibition/MS +prohibitionist/MS +prohibitive/PY +prohibitiveness/M +prohibitory +project/MDVGS +projected/AU +projectile/MS +projection/MS +projectionist/MS +projective/Y +projector/SM +prolegomena +proletarian/S +proletarianization/M +proletarianized +proletariat/SM +proliferate/GNVDSX +proliferation/M +prolific/P +prolifically +prolix/Y +prolixity/MS +prologize +prologue/MGSD +prologuize +prolong/G +prolongate/NGSDX +prolongation/M +prolonger/M +promenade/GZMSRD +promenader/M +promethium/SM +prominence/MS +prominent/Y +promiscuity/MS +promiscuous/PY +promiscuousness/M +promise/GD +promising/UY +promissory +promontory/MS +promote/GVZBDR +promoter/M +promotive/P +promotiveness/M +prompt/SGJTZPYDR +prompted/U +prompter/M +promptitude/SM +promptness/MS +promulgate/NGSDX +promulgation/M +promulgator/MS +pron +prone/PY +proneness/MS +prong/SGMD +pronghorn/SM +pronominalization +pronominalize +pronounce/GLSRD +pronounceable/U +pronounced/U +pronouncedly +pronouncement/SM +pronouncer/M +pronto +pronunciation/SM +proof/SEAM +proofed/A +proofer +proofing/M +proofread/GZSR +proofreader/M +prop/SZ +propaganda/SM +propagandist/SM +propagandistic +propagandize/DSG +propagate/SDVNGX +propagated/U +propagation/M +propagator/MS +propel/S +propellant/MS +propelled +propeller/MS +propelling +propensity/MS +proper/PYRT +properness/M +propertied/U +property/SDM +prophecy/SM +prophesier/M +prophesy/GRSDZ +prophet/SM +prophetess/S +prophetic +prophetical/Y +prophylactic/S +prophylaxes +prophylaxis/M +propinquity/MS +propionate/M +propitiate/GNXSD +propitiatory +propitious/YP +propitiousness/M +proponent/MS +proportion/ESGDM +proportional/SY +proportionality/M +proportionate/YGESD +proportioner/M +proportionment/M +proposal/SM +propped +propping +proprietary/S +proprietor/SM +proprietorial +proprietorship/SM +proprietress/MS +propriety/MS +proprioception +proprioceptive +propulsion/MS +propulsive +propylene/M +prorogation/SM +prorogue +pros/DSRG +prosaic +prosaically +proscenium/MS +prosciutti +prosciutto/SM +proscription/SM +proscriptive +prose/M +prosecute/SDBXNG +prosecution/M +prosecutor/MS +proselyte/SDGM +proselytism/MS +proselytize/ZGDSR +proser/M +prosodic/S +prosody/MS +prospect/DMSVG +prospection/SM +prospective/SYP +prospectiveness/M +prospector/MS +prospectus/SM +prosper/GSD +prosperity/MS +prosperous/PY +prosperousness/M +prostate +prostheses +prosthesis/M +prosthetic/S +prosthetics/M +prostitute/DSXNGM +prostitution/M +prostrate/SDXNG +prostration/M +prosy/RT +protactinium/MS +protagonist/SM +protean/S +protease/M +protect/DVGS +protected/UY +protection/MS +protectionism/MS +protectionist/MS +protective/YPS +protectiveness/S +protector/MS +protectorate/SM +protein/MS +proteolysis/M +proteolytic +protest/G +protestant/S +protestantism +protestation/MS +protesting/Y +protocol/DMGS +protoplasm/MS +protoplasmic +prototype/SDGM +prototypic +prototypical/Y +protozoa +protozoan/MS +protozoic +protozoon's +protract/DG +protrude/SDG +protrusile +protrusion/MS +protrusive/PY +protuberance/S +protuberant +prot�g�/SM +prot�g�es +proud/TRY +prov/DRGZB +provabilities +provability's +provability/U +provable/P +provableness/M +provably +prove/ESDAG +proved/U +proven/U +provenance/SM +provender/SDG +provenience/SM +provenly +prover/M +proverb/DG +proverbial/Y +provide/DRSBGZ +provided/U +providence/SM +provident/Y +providential/Y +provider/M +province/SM +provincial/SY +provincialism/SM +provision/R +provisional/YS +provisioner/M +proviso/MS +provocateur/S +provocative/P +provocativeness/SM +provoke/GZDRS +provoked/U +provoking/Y +provolone/SM +provost/MS +prow/TRMS +prowess/SM +prowl/RDSZG +prowler/M +proximal/Y +proximate/PY +proximateness/M +proximity/MS +proxy/SM +prude/MS +prudence/SM +prudent/Y +prudential/SY +prudery/MS +prudish/YP +prudishness/SM +prune/DSRGZM +pruner/M +prurience/MS +prurient/Y +prussic +pry/DRSGTZ +pryer's +prying/Y +pr�cis/MDG +psalm/SGDM +psalmist/SM +psalter +psaltery/MS +psephologist/M +pseudo/S +pseudonym/SM +pseudonymous +pseudopod +pseudoscience/S +pshaw/SDG +psi/S +psittacoses +psittacosis/M +psoriases +psoriasis/M +psst/S +psych/SDG +psyche/M +psychedelic/S +psychedelically +psychiatric +psychiatrist/SM +psychiatry/MS +psychic/MS +psychical/Y +psycho/SM +psychoacoustic/S +psychoacoustics/M +psychoactive +psychoanalysis/M +psychoanalyst/S +psychoanalytic +psychoanalytical +psychoanalyze/SDG +psychobabble/S +psychobiology/M +psychocultural +psychodrama/MS +psychogenic +psychokinesis/M +psycholinguistic/S +psycholinguistics/M +psycholinguists +psychological/Y +psychologist/MS +psychology/MS +psychometric/S +psychometrics/M +psychometry/M +psychoneuroses +psychoneurosis/M +psychopath/M +psychopathic/S +psychopathology/M +psychopaths +psychopathy/SM +psychophysic/S +psychophysical/Y +psychophysics/M +psychophysiology/M +psychos/S +psychosis/M +psychosocial/Y +psychosomatic/S +psychosomatics/M +psychotherapeutic/S +psychotherapist/MS +psychotherapy/SM +psychotic/S +psychotically +psychotropic/S +psychs +pt/C +ptarmigan/MS +pterodactyl/SM +ptomaine/MS +pub/MS +pubbed +pubbing +pubertal +puberty/MS +pubes +pubescence/S +pubescent +pubic +pubis/M +public/YSP +publican/AMS +publication/AMS +publicist/SM +publicity/SM +publicize/SDG +publicized/U +publicness/M +publics/A +publish/JDRSBZG +publishable/U +published/UA +publisher/ASM +publishes/A +publishing/M +puce/SM +puck/GZSDRM +pucker/DG +puckish/YP +puckishness/S +pudding/MS +puddle/JMGRSD +puddler/M +puddling/M +puddly +pudenda +pudendum/M +pudginess/SM +pudgy/PRT +pueblo/SM +puerile/Y +puerility/SM +puerperal +puers +puff/SGZDRM +puffball/SM +puffer/M +puffery/M +puffin/SM +puffiness/S +puffy/PRT +pug/MS +pugged +pugging +pugilism/SM +pugilist/S +pugilistic +pugnacious/YP +pugnaciousness/MS +pugnacity/SM +puissant/Y +puke/GDS +pukka +pulchritude/SM +pulchritudinous/M +pule/GDS +pull/DRGZSJ +pullback/S +pullet/SM +pulley/SM +pullout/S +pullover/SM +pulmonary +pulp/MDRGS +pulpiness/S +pulpit/MS +pulpwood/MS +pulpy/PTR +pulsar/MS +pulsate/NGSDX +pulsation/M +pulse's +pulse/ADSG +pulser +pulverable +pulverization/MS +pulverize/GZSRD +pulverized/U +pulverizer/M +pulverizes/UA +puma/SM +pumice/SDMG +pummel/SDG +pump/GZSMDR +pumpernickel/SM +pumping/M +pumpkin/MS +pun/MS +punch/GRSDJBZ +punchbowl/M +punched/U +puncheon/MS +puncher/M +punchline/S +punchy/RT +punctilio/SM +punctilious/PY +punctiliousness/SM +punctual/PY +punctualities +punctuality/UM +punctualness/M +punctuate/SDXNG +punctuation/M +punctuational +puncture/SDMG +pundit/SM +punditry/S +pungency/MS +pungent/Y +puniness/MS +punish/RSDGBL +punished/U +punisher/M +punishment/MS +punitive/YP +punitiveness/M +punk/TRMS +punky/PRS +punned +punning +punster/SM +punt/GZMDRS +punter/M +puny/PTR +pup/MS +pupa/M +pupae +pupal +pupate/NGSD +pupil/SM +pupillage/M +pupped +puppet/SM +puppeteer/SM +puppetry/MS +pupping +puppy/GSDM +puppyish +purblind +purchasable +purchase/GASD +purchaser/MS +purdah/M +purdahs +pure/PYTGDR +purebred/S +puree/DSM +pureeing +pureness/MS +purgation/M +purgative/MS +purgatorial +purgatory/SM +purge/GZDSR +purger/M +purify/GSRDNXZ +purine/SM +purism/MS +purist/MS +puristic +puritan/SM +puritanic +puritanical/Y +puritanism/S +purity/SM +purl/MDGS +purlieu/SM +purloin/DRGS +purloiner/M +purple/MTGRSD +purplish +purport/DRSZG +purported/Y +purpose/SDVGYM +purposeful/YP +purposefulness/S +purposeless/PY +purposelessness/M +purposive/YP +purposiveness/M +purr/DSG +purring/Y +purse/DSRGZM +purser/M +pursuance/MS +pursuant +pursue/ZGRSD +pursuer/M +pursuit/MS +purulence/MS +purulent +purvey/DGS +purveyance/MS +purveyor/MS +purview/SM +pus/SM +push/DSRBGZ +pushbutton/S +pushcart/SM +pushchair/SM +pushdown +pusher/M +pushily +pushiness/MS +pushover/SM +pushy/PRT +pusillanimity/MS +pusillanimous/Y +puss/S +pussy/TRSM +pussycat/S +pussyfoot/DSG +pustular +pustule/MS +put/IS +putative/Y +putout/S +putrefaction/SM +putrefactive +putrefy/DSG +putrescence/MS +putrescent +putrid/YP +putridity/M +putridness/M +putsch/S +putt/SGZMDR +putted/I +puttee/MS +putter/RDMGZ +putting/I +putty/SDMG +puttying/M +puzzle/JRSDZLG +puzzlement/MS +puzzler/M +pvt +pygmy/SM +pyknotic +pylon/SM +pylori +pyloric +pylorus/M +pyorrhea/SM +pyramid/GMDS +pyramidal/Y +pyre/MS +pyridine/M +pyrimidine/SM +pyrite/MS +pyroelectric +pyroelectricity/SM +pyrolysis/M +pyrolyze/RSM +pyromania/MS +pyromaniac/SM +pyrometer/MS +pyrometry/M +pyrophosphate/M +pyrotechnic/S +pyrotechnical +pyrotechnics/M +pyroxene/M +pyroxenite/M +python/MS +pyx/MDSG +p�res +q +q's +qr +qt +qty +qua +quack/SDG +quackery/MS +quackish +quad/SM +quadded +quadding +quadrangle/MS +quadrangular/M +quadrant/MS +quadraphonic/S +quadrapole +quadratic/SM +quadratical/Y +quadrature/MS +quadrennial/SY +quadrennium/MS +quadric +quadriceps/SM +quadrilateral/S +quadrille/XMGNSD +quadrillion/MH +quadripartite/NY +quadriplegia/SM +quadriplegic/SM +quadrivia +quadrivium/M +quadruped/MS +quadrupedal +quadruple/GSD +quadruplet/SM +quadruplicate/GDS +quadruply/NX +quadrupole +quadword/MS +quaff/SRDG +quaffer/M +quagmire/DSMG +quahog/MS +quail/GSDM +quaint/PTYR +quaintness/MS +quake/GZDSR +quaky/RT +qualification/ME +qualified/UY +qualifier/SM +qualify/EGXSDN +qualitative/Y +quality/MS +qualm/SM +qualmish +quandary/MS +quangos +quanta/M +quantifiable/U +quantified/U +quantifier/M +quantify/GNSRDZX +quantile/S +quantitative/PY +quantitativeness/M +quantity/MS +quantization/MS +quantize/ZGDRS +quantizer/M +quantum/M +quarantine/DSGM +quark/SM +quarrel/SZDRMG +quarreler/M +quarrellings +quarrelsome/PY +quarrelsomeness/MS +quarrier/M +quarry/RSDGM +quarryman/M +quarrymen +quart/RMSZ +quarter/MDRYG +quarterback/SGMD +quarterdeck/MS +quarterer/M +quarterfinal/MS +quartering/M +quarterly/S +quartermaster/MS +quarterstaff/M +quarterstaves +quartet/SM +quartic/S +quartile/SM +quarto/SM +quartz/SM +quartzite/M +quasar/SM +quash/GSD +quasi +quasilinear +quaternary/S +quaternion/SM +quatrain/SM +quaver/GDS +quavering/Y +quavery +quay/SM +quayside/M +queasily +queasiness/SM +queasy/TRP +queen/SGMDY +queenly/RT +queer/STGRDYP +queerness/S +quell/SRDG +queller/M +quench/GZRSDB +quenchable/U +quenched/U +quencher/M +quenchless +quern/M +querulous/YP +querulousness/S +query/MGRSD +quest/FSIM +quested/A +quester's +quester/AS +questing +question/SMRDGBZJ +questionable/P +questionableness/M +questionably/U +questioned/UA +questioner/M +questioning/UY +questionnaire/MS +quests/A +queue/GZMDSR +queued/C +queuer/M +queues/C +queuing/C +quibble/GZRSD +quibbler/M +quiche/SM +quick/RNYTXPS +quicken/RDG +quickie/MS +quicklime/SM +quickness/MS +quicksand/MS +quicksilver/GDMS +quickstep/SM +quid/SM +quiesce/D +quiescence/MS +quiescent/YP +quiet/UTGPSDRY +quieted/E +quieten/SGD +quieter's +quieter/E +quieting/E +quietly/E +quietness/MS +quiets/E +quietude/IEMS +quietus/MS +quill/GSDM +quilt/SZJGRDM +quilter/M +quilting/M +quince/SM +quincentenary/M +quincy/M +quinine/MS +quinquennial/Y +quinsy/SM +quint/MS +quintessence/SM +quintessential/Y +quintet/SM +quintic +quintile/SM +quintillion/MH +quintillionth/M +quintuple/SDG +quintuplet/MS +quip/MS +quipped +quipper +quipping +quipster/SM +quire/MDSG +quired/AI +quires/AI +quiring/IA +quirk/SGMD +quirkiness/SM +quirky/PTR +quirt/SDMG +quisling/SM +quit/DGS +quitclaim/GDMS +quite/SADG +quittance/SM +quitter/SM +quitting +quiver/GDS +quivering/Y +quivery +quixotic +quixotically +quiz/M +quizzed +quizzer/SM +quizzes +quizzical/Y +quizzing +quo/H +quoin/SGMD +quoit/GSDM +quondam +quonset +quorate/I +quorum/MS +quot/GDRB +quota/MS +quotability/S +quotation/SM +quote/UGSD +quoter/M +quotidian/S +quotient/SM +qwerty +qwertys +r's +r/TGVJ +rabbet/GSMD +rabbi/MS +rabbinate/MS +rabbinic +rabbinical/Y +rabbit/MRDSG +rabbiter/M +rabble/GMRSD +rabbler/M +rabid/YP +rabidness/SM +rabies +rabis +raccoon/SM +race/MZGDRSJ +racecourse/MS +racegoers +racehorse/SM +raceme/MS +racer/M +racetrack/SMR +raceway/SM +racial/Y +racialism/MS +racialist/MS +racily +raciness/MS +racism/S +racist/MS +rack/GDRMS +racket/SMDG +racketeer/MDSJG +rackety +raconteur/SM +racoon's +racquet's +racquetball/S +racy/RTP +rad/S +radar/SM +radarscope/MS +radded +radder +raddest +radding +radial/SY +radian/SM +radiance/SM +radiant/YS +radiate/XSDYVNG +radiation/M +radiative/Y +radiator/MS +radical/SPY +radicalism/MS +radicalization/S +radicalize/GSD +radicalness/M +radices's +radii/M +radio/SMDG +radioactive/Y +radioactivity/MS +radioastronomical +radioastronomy +radiocarbon/MS +radiochemical/Y +radiochemistry/M +radiogalaxy/S +radiogram/SM +radiographer/MS +radiographic +radiography/MS +radioisotope/SM +radiologic +radiological/Y +radiologist/MS +radiology/MS +radioman/M +radiomen +radiometer/SM +radiometric +radiometry/MS +radionics +radionuclide/M +radiopasteurization +radiophone/MS +radiophysics +radioscopy/SM +radiosonde/SM +radiosterilization +radiosterilized +radiotelegraph +radiotelegraphs +radiotelegraphy/MS +radiotelephone/SM +radiotherapist/SM +radiotherapy/SM +radish/MS +radium/MS +radius/M +radix/SM +radon/SM +raffia/SM +raffish/PY +raffishness/SM +raffle/MSDG +raft/GZSMDR +rafter/DM +rag/GSMD +raga/MS +ragamuffin/MS +ragbag/SM +rage/MS +ragged/PRYT +raggedness/SM +raggedy/TR +ragging +raging/Y +raglan/MS +ragout/SMDG +ragtag/MS +ragtime/MS +ragweed/MS +ragwort/M +rah/DG +rahs +raid/MDRSGZ +raider/M +rail's +rail/CDGS +railbird/S +railer/SM +railhead/SM +railing/MS +raillery/MS +railroad/SZRDMGJ +railroader/M +railroading/M +railway/MS +railwaymen +raiment/SM +rain/GSDM +rainbow/MS +raincloud/S +raincoat/SM +raindrop/SM +rainfall/SM +rainforest's +rainless +rainmaker/SM +rainmaking/MS +rainproof/GSD +rainstorm/SM +rainwater/MS +rainy/RT +raise/DSRGZ +raiser/M +raisin/MS +raising/M +raj/M +rajah/M +rajahs +rake/MGDRS +raker/M +rakish/PY +rakishness/MS +rally/GSD +ram/SM +ramble/JRSDGZ +rambler/M +rambling/Y +rambunctious/PY +rambunctiousness/S +ramekin/SM +ramie/MS +ramification/M +ramify/XNGSD +ramjet/SM +rammed +ramming +ramp/GMDS +rampage/SDG +rampancy/S +rampant/Y +rampart/SGMD +ramrod/MS +ramrodded +ramrodding +rams/S +ramshackle +ran/A +ranch/ZRSDMJG +rancher/M +rancho/SM +rancid/P +rancidity/MS +rancidness/SM +rancor/SM +rancorous/Y +rand/MDGS +randiness/S +random/PYS +randomization/SM +randomize/SRDG +randomness/SM +randy/PRST +ranee/SM +rang/GZDR +range/SM +ranged/C +rangeland/S +ranger/M +ranges/C +ranginess/S +ranging/C +rangy/RPT +rani's +rank/GZTYDRMPJS +ranked/U +ranker/M +ranking/M +rankle/SDG +rankness/MS +ransack/GRDS +ransacker/M +ransom/ZGMRDS +ransomer/M +rant/GZDRJS +ranter/M +ranting/Y +rap/MDRSZG +rapacious/YP +rapaciousness/MS +rapacity/MS +rape/SM +rapeseed/M +rapid/YRPST +rapidity/MS +rapidness/S +rapier/SM +rapine/SM +rapist/MS +rapped +rappel/S +rappelled +rappelling +rapper/SM +rapping/M +rapport/SM +rapporteur/SM +rapprochement/SM +rapscallion/MS +rapt/YP +raptness/S +rapture/MGSD +rapturous/YP +rapturousness/M +rare/YTPGDRS +rarebit/MS +rarefaction/MS +rarefy/GSD +rareness/MS +rarity/SM +rascal/SMY +rash/PZTYSR +rasher/M +rashness/S +rasp/SGJMDR +raspberry/SM +rasper/M +rasping/Y +raspy/RT +raster/MS +rat/MDRSJZGB +ratchet/MDSG +rate's +rate/KNGSD +rateable +rated/U +ratepayer/SM +rater/M +rather +rathskeller/SM +ratifier/M +ratify/ZSRDGXN +rating/M +ratio/MS +ratiocinate/VNGSDX +ratiocination/M +ration/DSMG +rational/YPS +rationale/SM +rationalism/SM +rationalist/S +rationalistic +rationality/MS +rationalization/SM +rationalize/ZGSRD +rationalizer/M +rationalness/M +ratlike +ratline/SM +rattail +rattan/MS +ratted +ratter/MS +ratting +rattle/RSDJGZ +rattlebrain/DMS +rattlesnake/MS +rattletrap/MS +rattling/Y +rattly/TR +rattrap/SM +ratty/RT +raucous/YP +raucousness/SM +raunchily +raunchiness/S +raunchy/RTP +ravage/GZRSD +ravager/M +rave/ZGDRSJ +ravel/UGDS +raveling/S +raven/JGMRDS +ravenous/YP +raver/M +ravine/SDGM +ravioli/SM +ravish/LSRDZG +ravisher/M +ravishing/Y +ravishment/SM +raw/PSRYT +rawboned +rawhide/SDMG +rawness/SM +ray/GSMD +rayon/SM +raze/DRSG +razer/M +razor/MDGS +razorback/SM +razorblades +razz/GDS +razzmatazz/S +rcpt +rd +re/YM +reabbreviate +reach/GRB +reachability +reachable/U +reachably +reached/U +reacher/M +reacquisition +reactant/SM +reacted/U +reaction +reactionary/SM +reactivity +read/JGZBR +readability/MS +readable/P +readably +readdress/G +reader/M +readership/MS +readied +readies +readily +readiness/UM +readinesses +reading/M +readopt/G +readout/MS +reads/A +ready/TUPR +readying +real/RSTP +realism's +realism/U +realisms +realist/SM +realistic/U +realistically/U +reality/USM +realizability/MS +realizable/SMP +realizableness/M +realizably/S +realization/MS +realize/JRSDBZG +realized/U +realizer/M +realizes/U +realizing/MY +realm/M +realness/S +realpolitik/SM +realtor's +realty/SM +ream/MDRGZ +reamer/M +reanimate +reap/SGZ +reaper/M +reappraise/G +rear/DRMSG +rearguard/MS +rearmost +rearrange/L +rearward/S +reason/UBDMG +reasonable/UP +reasonableness/SMU +reasonably/U +reasoner/SM +reasoning/MS +reasonless +reasons +reassess/GL +reassuringly/U +reattach/GSL +reawakening/M +rebate/M +rebel/MS +rebeller +rebellion/SM +rebellious/YP +rebelliousness/MS +rebid +rebidding +rebind/G +rebirth +reboil/G +rebook +reboot/ZR +rebound/G +rebroadcast/MG +rebuke/RSDG +rebuking/Y +rebus +rebuttal/SM +rebutting +rec +rec'd +recalcitrance/SM +recalcitrant/S +recalibrate/N +recant/G +recantation/S +recap +recappable +recapping +recast/G +recd +recede +receipt/SGDM +receivable/S +receive/ZGRSDB +received/U +receiver/M +receivership/SM +recency/M +recension/M +recent/YPT +recentness/SM +receptacle/SM +reception/MS +receptionist/MS +receptive/YP +receptiveness/S +receptivity/S +receptor/MS +recess/SDMVG +recessional/S +recessionary +recessive/YPS +recessiveness/M +rechargeable +recheck/G +recherches +recherch� +recidivism/MS +recidivist/MS +recipe/MS +recipiency +recipient/MS +reciprocal/SY +reciprocate/NGXVDS +reciprocation/M +reciprocity/MS +recital/MS +recitalist/S +recitative/MS +recite/ZR +reciter/M +recked +recking +reckless/PY +recklessness/S +reckon/SGRDJ +reckoner/M +reckoning/M +reclaim/B +reclamation/SM +recline/RSDZG +recliner/M +recluse/MVNS +reclusion/M +recode/G +recognizability +recognizable/U +recognizably +recognize/BZGSRD +recognized/U +recognizedly/S +recognizer/M +recognizing/UY +recognizingly/S +recoilless +recoinage +recolor/GD +recombinant +recombine +recommended/U +recompense/GDS +recompute/B +reconcile/SRDGB +reconciled/U +reconciler/M +recondite/YP +reconditeness/M +reconfigurability +reconfigure/R +reconnaissance/MS +reconnect/R +reconnoiter/GSD +reconquer/G +reconsecrate +reconstitute +reconstructed/U +reconsult/G +recontact/G +recontaminate/N +recontribute +recook/G +recopy/G +record/ZGJ +recorded/AU +records/A +recourse +recover/B +recoverability +recoverable/U +recovery/MS +recreant/S +recreational +recriminate/GNVXDS +recrimination/M +recriminatory +recross/G +recrudesce/GDS +recrudescence/MS +recrudescent +recruit/ZSGDRML +recruiter/M +recruitment/MS +recrystallize +recta's +rectal/Y +rectangle/SM +rectangular/Y +rectifiable +rectification/M +rectifier/M +rectify/DRSGXZN +rectilinear/Y +rectitude/MS +recto/MS +rector/SM +rectory/MS +rectum/SM +recumbent/Y +recuperate/VGNSDX +recuperation/M +recur +recurrence/MS +recurrent +recurse/NX +recursion/M +recusant/M +recuse +recyclable/S +recycle/BZ +red/PYS +redact/DGS +redaction/SM +redactor/MS +redbird/SM +redbreast/SM +redbrick/M +redbud/M +redcap/MS +redcoat/SM +redcurrant/M +redden/DGS +redder +reddest +redding +reddish/P +redeclaration +redecorate +redeem/BRZ +redeemable/U +redeemed/U +redeemer/M +redemption/RMS +redemptioner/M +redemptive +redeposit/M +redetermination +redhead/DRMS +redial/G +redirect/G +redirection +redlining/S +redneck/SMD +redness/MS +redo/G +redolence/MS +redolent +redouble/S +redoubtably +redound/GDS +redshift/S +redskin/SM +reduce/RSDGZ +reduced/U +reducer/M +reducibility/M +reducible +reducibly +reduct/V +reduction/SM +reductionism/M +reductionist/S +redundancy/SM +redundant/Y +redwood/SM +redye +redyeing +reecho/G +reed/GMDR +reediness/SM +reeding/M +reedy/PTR +reef/GZSDRM +reefer/M +reek/GSR +reeker/M +reel's +reel/USDG +reeler/M +reenforcement +reentrant +reestimate/M +reeve/G +reexamine +ref/ZS +refection/SM +refectory/SM +refer/B +referee/MSD +refereed/U +refereeing +reference's +reference/CGSRD +referenced/U +referencing/U +referendum/MS +referent/SM +referential/YM +referentiality +referral/SM +referred +referrer/S +referring +reffed +reffing +refile +refinance +refine/LZ +refined/U +refinement/MS +refinish/G +refit +reflect/SDGV +reflectance/M +reflected/U +reflection/SM +reflectional +reflective/YP +reflectiveness/M +reflectivity/M +reflector/MS +reflex/YV +reflexion/MS +reflexive/PSY +reflexiveness/M +reflexivity/M +reflooring +refluent +reflux/G +refocus/G +refold/G +reforestation +reforge/G +reform/B +reformatory/SM +reformed/U +reformer/M +reformism/M +reformist/S +refract/DGVS +refractive/PY +refractiveness/M +refractometer/MS +refractoriness/M +refractory/PS +refrain/DGS +refresh/LB +refreshed/U +refreshing/Y +refreshment/MS +refrigerant/MS +refrigerate/XDSGN +refrigerated/U +refrigeration/M +refrigerator/MS +refrozen +refry/GS +refuge/SDGM +refugee/MS +refulgence/SM +refulgent +refund/B +refunder/M +refurbish/L +refurbishment/S +refusal/SM +refuse/R +refuser/M +refutation/MS +refute/GZRSDB +refuter/M +reg +regal/GYRD +regale/L +regalement/S +regalia/M +regard/EGDS +regardless/PY +regather/G +regatta/MS +regency/MS +regeneracy/MS +regenerate/U +regenerately +regenerateness/M +reggae/SM +regicide/SM +regime/MS +regimen/MS +regiment/SDMG +regimental/S +regimentation/MS +region/SM +regional/SY +regionalism/MS +register's +register/UDSG +registrable +registrant/SM +registrar/SM +registration/AM +registrations +registry/MS +regnant +regress/DSGV +regression/MS +regressive/PY +regressiveness/M +regressors +regret/S +regretful/PY +regretfulness/M +regrettable +regrettably +regretted +regretting +reground +regroup/G +regrow/G +regular/YS +regularity/MS +regularization/MS +regularize/SDG +regulate/CSDXNG +regulated/U +regulation/M +regulative +regulator/SM +regulatory +regurgitate/XGNSD +regurgitation/M +rehab/S +rehabbed +rehabbing +rehabilitate/SDXVGN +rehabilitation/M +rehang/G +rehear/GJ +rehears/R +rehearsal/SM +rehearse +rehearsed/U +rehearser/M +reheat/G +reheating/M +rehydrate +reign/MDSG +reimburse/GSDBL +reimbursement/MS +rein/GDM +reindeer/M +reinforce/GSRDL +reinforced/U +reinforcement/MS +reinforcer/M +reinstate/L +reinstatement/MS +reinsurance +reissue +reiterative/SP +reject/RDVGS +rejecter/M +rejecting/Y +rejection/SM +rejector/MS +rejigger +rejoice/RSDJG +rejoicing/Y +rejoinder/SM +rejuvenate/NGSDX +rejuvenatory +rel/V +relapse +relate/XVNGSZ +related/U +relatedly +relatedness/MS +relater/M +relation/M +relational/Y +relationship/MS +relative/SPY +relativeness/M +relativism/M +relativist/MS +relativistic +relativistically +relativity/MS +relator's +relax/GZD +relaxant/SM +relaxation/MS +relaxed/YP +relaxedness/M +relaxing/Y +relay/GDM +relearn/G +releasable/U +release/B +released/U +relent/SDG +relenting/U +relentless/PY +relentlessness/SM +relevance/SM +relevancy/MS +relevant/Y +reliability/UMS +reliable/U +reliables +reliably/U +reliance/MS +reliant/Y +relic/MS +relicense/R +relict's +relict/C +relief/M +relieve/RSDZG +relieved/U +relievedly +reliever/M +religion/SM +religionists +religiosity/M +religious/PY +religiousness/MS +relink/G +relinquish/GSDL +relinquishment/SM +reliquary/MS +relish/GSD +relive/GB +reload/GR +relocate/B +reluctance/MS +reluctant/Y +rely/DG +rem +remade/S +remain/GD +remainder/SGMD +remake/M +remand/DGS +remap +remapping +remark/BG +remarkable/U +remarkableness/S +remarkably +remarked/U +rematch/G +remeasure/D +remediable/P +remediableness/M +remedy/SDMG +remember/GR +remembered/U +rememberer/M +remembrance/MRS +remembrancer/M +reminisce/GSD +reminiscence/SM +reminiscent/Y +remiss/YP +remissness/MS +remit/S +remittance/MS +remitted +remitting/U +remnant/MS +remodel/G +remolding +remonstrant/MS +remonstrate/SDXVNG +remonstration/M +remonstrative/Y +remorse/SM +remorseful/PY +remorsefulness/M +remorseless/YP +remorselessness/MS +remote/RPTY +remoteness/MS +remoulds +removal/MS +remunerate/VNGXSD +remunerated/U +remuneration/M +remunerative/YP +remunerativeness/M +renaissance/S +renal +renaturation +rend +rend/RGZS +render/GJRD +renderer/M +rendering/M +rendezvous/DSMG +rendition/GSDM +renegade/SDMG +renege/GZRSD +reneger/M +renew/BG +renewal/MS +renewer/M +rennet/MS +rennin/SM +renounce/LGRSD +renouncement/MS +renouncer/M +renovate/NGXSD +renovation/M +renovator/SM +renown/SGDM +rent/GZMDRS +rental/SM +rentaller +renter/M +renumber/G +renumeration +renunciate/VNX +renunciation/M +reoccupy/G +reopen/G +reorganized/U +rep/S +repack/G +repair/BZGR +repairable/U +repairer/M +repairman/M +repairmen +repairs/E +repaper +reparable +reparation/SM +repartee/MDS +reparteeing +repartition/Z +repast/G +repatriate/SDXNG +repave +repeal/GR +repealer/M +repeat/RDJBZG +repeatability/M +repeatable/U +repeatably +repeated/Y +repeater/M +repel/S +repelled +repellent/SY +repelling/Y +repent/RDG +repentance/SM +repentant/SY +repertoire/SM +repertory/SM +repetition +repetitious/YP +repetitiousness/S +repetitive/PY +repetitiveness/MS +repine/R +repiner/M +replace/RL +replay/GM +replenish/LRSDG +replenishment/S +replete/SDPXGN +repleteness/MS +repletion/M +replica/SM +replicate/SDVG +replicator/S +replug +reply/X +repopulate +reported/Y +reportorial/Y +repose/M +reposeful +repository/MS +reprehend/GDS +reprehensibility/MS +reprehensible/P +reprehensibleness/M +reprehensibly +reprehension/MS +represent/GB +representable/U +representational/Y +representative/SYMP +representativeness/M +representativity +represented/U +repress/V +repression/SM +repressive/YP +repressiveness/M +reprieve/GDS +reprimand/SGMD +reprint/M +reprisal/MS +reproach/GRSDB +reproacher/M +reproachful/YP +reproachfulness/M +reproaching/Y +reprobate/N +reprocess/G +reproducibility/MS +reproducible/S +reproducibly +reproductive/S +reproof/G +reprove/R +reproving/Y +reptile/SM +reptilian/S +republic/M +republicanism/SM +republish/G +repudiate/XGNSD +repudiation/M +repudiator/S +repugnance/MS +repugnant/Y +repulse/VNX +repulsion/M +repulsive/PY +repulsiveness/MS +reputability/SM +reputably/E +reputation/SM +repute/ESB +reputed/Y +reputing +request/G +requested/U +requiem/SM +require/LR +requirement/MS +requisite/PNXS +requisiteness/M +requisition/GDRM +requisitioner/M +requital/MS +requite/RZ +requited/U +requiter/M +reread/G +rerecord/G +rerouteing +rerunning +res/C +rescale +rescind/SDRG +rescission/SM +rescue/GZRSD +reseal/BG +research/MB +reselect/G +resemblant +resemble/DSG +resend/G +resent/DSLG +resentful/PY +resentfulness/SM +resentment/MS +reserpine/MS +reservation/MS +reserved/UYP +reservedness/UM +reservednesses +reservist/SM +reservoir/MS +reset/RDG +resettle/L +reshipping +reshow/G +reshuffle/M +reside/G +residence/MS +residency/SM +resident/SM +residential/Y +resider/M +residua +residual/YS +residuary +residue/SM +residuum/M +resignation/MS +resigned/YP +resilience/MS +resiliency/S +resilient/Y +resin/D +resinlike +resinous +resiny +resist/RDZVGS +resistance/SM +resistant/U +resistantly +resistants +resisted/U +resistible +resistibly +resisting/U +resistive/PY +resistiveness/M +resistivity/M +resistless +resistor/MS +resize/G +resold +resole/G +resoluble +resolute/PYTRV +resoluteness/MS +resolvability/M +resolvable/U +resolved/U +resolvent +resonance/SM +resonant/YS +resonate/DSG +resonator/MS +resorption/MS +resort/R +resound/G +resourceful/PY +resourcefulness/SM +resp +respect's/E +respect/BSDRMZGV +respectability/SM +respectable/SP +respectably +respected/E +respectful/EY +respectfulness/SM +respecting/E +respective/PY +respectiveness/M +respects/E +respell/G +respiration/MS +respirator/SM +respiratory/M +resplendence/MS +resplendent/Y +respond/SDRZG +respondent/MS +response/RSXMV +responser/M +responsibility/MS +responsible/P +responsibleness/M +responsibly +responsive/YPU +responsiveness/MSU +respray/G +rest's/U +rest/DRSGVM +restart/B +restate/L +restaurant/SM +restaurateur/SM +rested/U +rester/M +restful/YP +restfuller +restfullest +restfulness/MS +restitution/SM +restive/PY +restiveness/SM +restless/YP +restlessness/MS +restorability +restoration/MS +restorative/PYS +restore/Z +restorer/M +restrained/UY +restraint/MS +restrict/DVGS +restricted/YU +restriction/SM +restrictive/U +restrictively +restrictiveness/MS +restrictives +restroom/SM +restructurability +restructure +rests/U +restudy/M +restyle +resubstitute +result/SGMD +resultant/YS +resume/SDBG +resumption/MS +resurface +resurgence/MS +resurgent +resurrect/GSD +resurrection/SM +resurvey/G +resuscitate/XSDVNG +resuscitation/M +resuscitator/MS +retail/Z +retain/LZGSRD +retainer/M +retake +retaliate/VNGXSD +retaliation/M +retaliatory +retard/ZGRDS +retardant/SM +retardation/SM +retarder/M +retch/SDG +retention/SM +retentive/YP +retentiveness/S +retentivity/M +retest/G +rethought +reticence/S +reticent/Y +reticle/SM +reticular +reticulate/GNYXSD +reticulation/M +reticule/MS +reticulum/M +retina/SM +retinal/S +retinue/MS +retire/L +retiredness/M +retiree/MS +retirement/SM +retiring/YP +retort/GD +retract/DG +retractile +retrench/L +retrenchment/MS +retributed +retribution/MS +retributive +retrieval/SM +retrieve/ZGDRSB +retriever/M +retro/SM +retroactive/Y +retrofire/GMSD +retrofit/S +retrofitted +retrofitting +retroflection +retroflex/D +retroflexion/M +retrogradations +retrograde/GYDS +retrogress/SDVG +retrogression/MS +retrogressive/Y +retrorocket/MS +retrospect/SVGMD +retrospection/MS +retrospective/SY +retrovirus/S +retrovision +retry/G +retsina/SM +returnable/S +returned/U +returnee/SM +retype +reuse/B +reutilization +rev/ZM +revanchist +reveal/JBG +revealed/U +revealing/U +revealingly +reveille/MS +revel/SJRDGZ +revelation/MS +revelatory +revelry/MS +revenge/MGSRD +revenger/M +revenue/ZR +revenuer/M +reverberant +reverberate/XVNGSD +reverberation/M +revere/GSD +reverence/SRDGM +reverencer/M +reverend/SM +reverent/Y +reverential/Y +reverie/SM +revers/M +reversal/MS +reverse/Y +reverser/M +reversibility/M +reversible/S +reversibly +reversion/R +reversioner/M +revert/RDVGS +reverter/M +revertible +revet/L +revetment/SM +review/G +revile/GZSDL +revilement/MS +reviler/M +revise/BRZ +revised/U +revisionary +revisionism/SM +revisionist/SM +revitalize/ZR +revival/SM +revivalism/MS +revivalist/MS +revive/RSDG +reviver/M +revivification/M +revivify/X +revocable +revoke/GZRSD +revolt/GRD +revolter/M +revolting/Y +revolution/SM +revolutionariness/M +revolutionary/MSP +revolutionist/MS +revolutionize/GDSRZ +revolutionizer/M +revolve/BSRDZJG +revolver/M +revue/MS +revulsion/MS +revved +revving +rewarded/U +rewarding/Y +rewarm/G +reweave +rewedding +reweigh/G +rewind/BGR +rewire/G +rework/G +rexes +rezone +rhapsodic +rhapsodical +rhapsodize/GSD +rhapsody/SM +rhea/SM +rhenium/MS +rheology/M +rheostat/MS +rhesus/S +rhetoric/MS +rhetorical/YP +rhetorician/MS +rheum/MS +rheumatic/S +rheumatically +rheumatics/M +rheumatism/SM +rheumatoid +rheumy/RT +rhinestone/SM +rhinitides +rhinitis/M +rhino/MS +rhinoceros/MS +rhinotracheitis +rhizome/MS +rho/MS +rhodium/MS +rhododendron/SM +rhodolite/M +rhodonite/M +rhombic +rhomboid/SM +rhomboidal +rhombus/SM +rhubarb/MS +rhyme/DSRGZM +rhymester/MS +rhythm/MS +rhythmic/S +rhythmical/Y +rhythmics/M +rial/MS +rib/MS +ribald/S +ribaldry/MS +ribbed +ribber/S +ribbing/M +ribbon/DMSG +ribcage +riboflavin/MS +ribonucleic +ribosomal +ribosome/MS +rice/DRSMZG +ricer/M +rich/YNSRPT +richen/DG +richness/MS +rick/GSDM +rickets/M +rickety/RT +rickrack/MS +rickshaw/SM +ricochet/GSD +ricotta/MS +rid/ZGRJSB +riddance/SM +ridden +ridding +riddle/GMRSD +ride/CZSGR +rider/CM +riderless +ridership/S +ridge/DSGM +ridgepole/SM +ridgy/RT +ridicule/MGDRS +ridiculer/M +ridiculous/PY +ridiculousness/MS +riding/M +rife/RT +riff/GSDM +riffle/SDG +riffraff/SM +rifle/GZMDSR +rifled/U +rifleman/M +riflemen +rifler/M +rifling/M +rift/GSMD +rig/MS +rigamarole's +rigatoni/M +rigged +rigger/SM +rigging/MS +right/SGTPYRDN +righteous/PYU +righteousness/MS +righteousnesses/U +rightful/PY +rightfulness/MS +rightism/SM +rightist/S +rightmost +rightness/MS +rights/M +rightsize/SDG +rightward/S +rigid/YP +rigidify/S +rigidity/S +rigidness/S +rigmarole/MS +rigor/MS +rigorous/YP +rigorousness/S +rile/DSG +rill/GSMD +rim/GSMDR +rime/MS +rimer/M +rimless +rimmed +rimming +rind/MDGS +ring/GZJDRM +ringer/M +ringing/Y +ringleader/MS +ringlet/SM +ringlike +ringmaster/MS +ringside/ZMRS +ringworm/SM +rink/GDRMS +rinse/DSRG +riot/SMDRGZJ +rioter/M +riotous/PY +riotousness/M +rip/NDRSXTG +riparian/S +ripcord/SM +ripe/PSY +ripen/RDG +ripened/U +ripeness/UM +ripenesses +riper/U +ripest/U +ripoff/S +riposte/SDMG +ripped +ripper/SM +ripping +ripple/RSDGM +rippler/M +ripply/TR +ripsaw/GDMS +riptide/SM +rise/RSJZG +risen +riser/M +risibility/SM +risible/S +rising/M +risk/GSDRM +risker/M +riskily +riskiness/MS +risky/RTP +risotto/SM +risqu� +rissole/M +rite/DSM +ritual/MSY +ritualism/SM +ritualistic +ritualistically +ritualized +ritzy/TR +riv/ZGNDR +rival/SGDM +rivaled/U +rivalry/MS +rive/CSGRD +river/CM +riverbank/SM +riverbed/S +riverboat/S +riverfront +riverine +riverside/S +rivet/GZSRDM +riveter/M +riveting/Y +rivulet/SM +riyal/SM +rm +roach/GSDM +road/MIS +roadbed/MS +roadblock/SMDG +roadhouse/SM +roadie/S +roadkill/S +roadrunner/MS +roadshow/S +roadside/S +roadsigns +roadster/SM +roadsweepers +roadway/SM +roadwork/SM +roadworthy +roam/DRGZS +roan/S +roar/DRSJGZ +roarer/M +roaring/T +roast/SGJZRD +roaster/M +rob/SDG +robbed +robber/SM +robbery/SM +robbing +robe's +robe/ESDG +robin/MS +robot/MS +robotic/S +robotism +robotize/GDS +robust/RYPT +robustness/SM +rock/GZDRMS +rockabilly/MS +rockabye +rockbound +rocker/M +rocket/SMDG +rocketry/MS +rockfall/S +rockiness/MS +rocky/SRTP +rococo/MS +rod/SGMD +rodded +rodder +rodding +rode/S +rodent/MS +rodeo/SMDG +roe/SM +roebuck/SM +roentgen/SM +roger/GSD +rogue/GMDS +rogued/K +roguery/MS +rogues/K +roguing/K +roguish/PY +roguishness/SM +roil/SGD +roister/SZGRD +roisterer/M +role/MS +roll/UDSG +rollback/SM +rolled/A +roller/SM +rollerskating +rollick/DGS +rollicking/Y +rolling/S +rollover/S +romaine/MS +roman/S +romance/RSDZMG +romancer/M +romantic/MS +romantically/U +romanticism/MS +romanticist/S +romanticize/SDG +romeo/S +romp/GSZDR +romper/M +rondo/SM +rood/MS +roof/DRMJGZS +roofer/M +roofgarden +roofing/M +roofless +rooftop/S +rook/GDMS +rookery/MS +rookie/SRMT +room/MDRGZS +roomer/M +roomette/SM +roomful/MS +roominess/MS +roommate/SM +roomy/TPSR +roost/SGZRDM +rooster/M +root/MGDRZS +rooted/P +rooter/M +rootless/P +rootlessness/M +rootlet/SM +rootstock/M +rope/DRSMZG +roper/M +roping/M +rosary/SM +rose/MGDS +roseate/Y +rosebud/MS +rosebush/SM +rosemary/MS +rosette/SDMG +rosewater +rosewood/SM +rosily +rosin/SMDG +rosiness/MS +roster/DMGS +rostra's +rostrum/SM +rosy/RTP +rot/SDG +rota/MS +rotary/S +rotate/VGNXSD +rotated/U +rotation/M +rotational/Y +rotative/Y +rotator/SM +rotatory +rote/MS +rotgut/MS +rotisserie/MS +rotogravure/SM +rotor/MS +rototill/RZ +rotted +rotten/RYSTP +rottenness/S +rotter/M +rotting +rotund/SDYPG +rotunda/SM +rotundity/S +rotundness/S +rouge/GMDS +rough/XPYRDNGT +roughage/SM +roughen/DG +rougher/M +roughhouse/GDSM +roughish +roughneck/MDSG +roughness/MS +roughs +roughshod +roulette/MGDS +round/YRDSGPZT +roundabout/PSM +rounded/P +roundedness/M +roundelay/SM +roundels +rounder/M +roundhead/D +roundheaded/P +roundheadedness/M +roundhouse/SM +roundish +roundness/MS +roundoff +roundup/MS +roundworm/MS +rouse/DSRG +rouser/M +roust/SGD +roustabout/SM +rout/GZJMDRS +route's +route/ASRDZGJ +router/M +routine/SYM +routing/M +routinize/GSD +rou�/MS +rove/ZGJDRS +rover/M +roving/M +row/SJZMGNDR +rowboat/SM +rowdily +rowdiness/MS +rowdy/PTSR +rowdyism/MS +rowel/DMSG +rowen/M +rower/M +royal/SY +royalist/SM +royalty/MS +rpm +rps +rs +rt +rte +rub/S +rubato/MS +rubbed +rubber/SDMG +rubberize/GSD +rubberneck/DRMGSZ +rubbery/TR +rubbing/M +rubbish/DSMG +rubbishy +rubble/GMSD +rubdown/MS +rube/SM +rubella/MS +rubicund +rubidium/SM +ruble/MS +rubout +rubric/MS +ruby/MTGDSR +ruck/M +rucksack/SM +ruckus/SM +ruction/SM +rudder/MS +rudderless +ruddiness/MS +ruddy/PTGRSD +rude/PYTR +rudeness/MS +rudiment/SM +rudimentariness/M +rudimentary/P +rue/GDS +rueful/PY +ruefulness/S +ruff/GSYDM +ruffian/GSMDY +ruffle/RSDG +ruffled/U +ruffler/M +ruffly/TR +rug/MS +rugby/SM +rugged/PYRT +ruggedness/S +rugging +ruin/MGSDR +ruination/MS +ruiner/M +ruinous/YP +ruinousness/M +rule/MZGJDRS +rulebook/S +ruled/U +ruler/GMD +ruling/M +rum/XSMN +rumba/GDMS +rumble/JRSDG +rumbler/M +rumbustious +rumen/M +ruminant/YMS +ruminate/VNGXSD +ruminative/Y +rummage/GRSD +rummager/M +rummer +rummest +rummy/TRSM +rumor/ZMRDSG +rumored/U +rumorer/M +rumormonger/SGMD +rump/GMYDS +rumple/SDG +rumply/TR +rumpus/SM +run/AS +runabout/SM +runaround/S +runaway/S +rundown/SM +rune/MS +rung/MS +runic +runlet/SM +runnable +runnel/SM +runner/MS +running/S +runny/RT +runoff/MS +runt/MS +runtime +runtiness/M +runty/RPT +runway/MS +rupee/MS +rupiah/M +rupiahs +rupture/GMSD +rural/Y +rurality/M +ruse/MS +rush/DSRGZ +rusher/M +rushes/I +rushing/M +rushy/RT +rusk/MS +russet/MDS +russetting +rust/MSDG +rustic/S +rustically +rusticate/GSD +rustication/M +rusticity/S +rustiness/MS +rustle/RSDGZ +rustler/M +rustproof/DGS +rusty/XNRTP +rut/MS +rutabaga/SM +ruthenium/MS +rutherfordium/SM +ruthless/YP +ruthlessness/MS +rutted +rutting +rutty/RT +rye/MS +s's/KI +s/XJBG +sabbath +sabbatical/S +saber/GSMD +sabered/U +sable/GMDS +sabot/MS +sabotage/DSMG +saboteur/SM +sabra/MS +sac/SM +saccharides +saccharin/MS +saccharine +sacerdotal +sachem/MS +sachet/SM +sack/GJDRMS +sackcloth/M +sackcloths +sacker/M +sackful/MS +sacking/M +sacra/L +sacral +sacrament/DMGS +sacramental/S +sacred/PY +sacredness/S +sacrifice/RSDZMG +sacrificer/M +sacrificial/Y +sacrilege/MS +sacrilegious/Y +sacristan/SM +sacristy/MS +sacroiliac/S +sacrosanct/P +sacrosanctness/MS +sacrum/M +sad/PY +sadden/DSG +sadder +saddest +saddle's +saddle/UGDS +saddlebag/SM +saddler/M +sades +sadism/MS +sadist/MS +sadistic +sadistically +sadness/SM +sadomasochism/MS +sadomasochist/S +sadomasochistic +safari/GMDS +safe/URPTY +safeguard/MDSG +safekeeping/MS +safeness's/U +safeness/MS +safes +safety/SDMG +safflower/SM +saffron/MS +sag/TSR +saga/MS +sagacious/YP +sagaciousness/M +sagacity/MS +sage/MYPS +sagebrush/SM +sagged +sagger +sagging +saggy/RT +sago/MS +saguaro/SM +sahib/MS +said/U +saids +sail/GJMDRS +sailboard/DGS +sailboat/SRMZG +sailcloth/M +sailcloths +sailer/M +sailfish/SM +sailing/M +sailor/YMS +sailplane/SDMG +saint/YDMGS +sainthood/MS +saintlike +saintliness/MS +saintly/RTP +saith +saiths +sake/MRS +saker/M +saki's +salaam/GMDS +salable/U +salacious/YP +salaciousness/MS +salacity/MS +salad/SM +salamander/MS +salami/MS +salary/SDMG +sale/ABMS +saleability/M +salesclerk/SM +salesgirl/SM +saleslady/S +salesman/M +salesmanship/SM +salesmen +salespeople/M +salesperson/MS +salesroom/M +saleswoman +saleswomen +salience/MS +saliency +salient/SY +saline/S +salinger +salinity/MS +saliva/MS +salivary +salivate/XNGSD +salivation/M +sallow/TGRDSP +sallowness/MS +sally/GSDM +salmon/SM +salmonella/M +salmonellae +salon/SM +saloon/MS +saloonkeeper +salsa/MS +salsify/M +salt/GZTPMDRS +saltcellar/SM +salted/UC +salter/M +saltine/MS +saltiness/SM +saltness/M +saltpeter/SM +salts/C +saltshaker/S +saltwater +salty/RSPT +salubrious/YP +salubriousness/M +salubrity/M +salutariness/M +salutary/P +salutation/SM +salutatory/S +salute/RSDG +saluter/M +salvage/MGRSD +salvageable +salvager/M +salvation/MS +salve/GZMDSR +salver/M +salvo/GMDS +samarium/MS +samba/GSDM +same/SP +sameness/MS +samovar/SM +sampan/MS +sample/RSDJGMZ +sampler/M +sampling/M +samurai/M +sanatorium/MS +sanctification/M +sanctifier/M +sanctify/RSDGNX +sanctimonious/PY +sanctimoniousness/MS +sanctimony/MS +sanction/SMDG +sanctioned/U +sanctity/SM +sanctuary/MS +sanctum/SM +sand/SMDRGZ +sandal/MDGS +sandalwood/SM +sandbag/MS +sandbagged +sandbagging +sandbank/SM +sandbar/S +sandblast/GZSMRD +sandblaster/M +sandbox/MS +sandcastle/S +sander/M +sandhill +sandhog/SM +sandiness/S +sandlot/SM +sandlotter/S +sandman/M +sandmen +sandpaper/DMGS +sandpile +sandpiper/MS +sandpit/M +sandstone/MS +sandstorm/SM +sandwich/SDMG +sandy/PRT +sane/IRYTP +saned +saneness's/I +saneness/MS +sanes +sang/S +sangfroid/S +sangria/SM +sanguinary +sanguine/F +sanguined +sanguinely +sanguineness/M +sanguineous/F +sanguines +sanguining +saning +sanitarian/S +sanitarium/SM +sanitary/S +sanitate/NX +sanitation/M +sanitize/RSDZG +sanitizer/M +sanity/SIM +sank +sans +sanserif +sap/MS +sapience/MS +sapient +sapless +sapling/SM +sapped +sapper/SM +sapphire/MS +sappiness/SM +sapping +sappy/RPT +saprophyte/MS +saprophytic +sapsucker/SM +sapwood/SM +saran/SM +sarape's +sarcasm/MS +sarcastic +sarcastically +sarcoma/MS +sarcophagi +sarcophagus/M +sardine/SDMG +sardonic +sardonically +sarge/SM +sari/MS +sarong/MS +sarsaparilla/MS +sartorial/Y +sartorius/M +sash/GMDS +sashay/GDS +sass/GDSM +sassafras/MS +sassy/TRS +sat/DG +satanic +satanical/Y +satanism/S +satanist/S +satchel/SM +sate/S +sateen/MS +satellite/GMSD +satiable/I +satiate/GNXSD +satiation/M +satiety/MS +satin/MDSG +satinwood/MS +satiny +satire/SM +satiric +satirical/Y +satirist/SM +satirize/DSG +satirizes/U +satisfaction/ESM +satisfactorily/U +satisfactoriness/MU +satisfactory/UP +satisfiability/U +satisfiable/U +satisfied/UE +satisfier/M +satisfies/E +satisfy/GZDRS +satisfying/EU +satisfyingly +satori/SM +satrap/SM +saturate/XDRSNG +saturated/CUA +saturater/M +saturates/A +saturation/M +saturnalia +saturnine/Y +satyr/MS +satyriases +satyriasis/M +satyric +sauce/DSRGZM +saucepan/SM +saucer/M +saucily +sauciness/S +saucy/TRP +sauerkraut/SM +sauna/DMSG +saunter/DRSG +saurian/S +sauropod/SM +sausage/MS +saut�/DGS +savage/GTZYPRSD +savageness/SM +savagery/MS +savanna/MS +savant/SM +save/ZGJDRSB +saved/U +saveloy/M +saver/M +savior/SM +savor/SMRDGZ +savored/U +savorer/M +savorier +savoriest +savoriness/S +savoring/Y +savoringly/S +savory/UMPS +savoy/SM +savvy/GTRSD +saw/SMDRG +sawbones/M +sawbuck/SM +sawdust/MDSG +sawer/M +sawfly/SM +sawhorse/MS +sawmill/SM +sawtooth +sawyer/MS +sax/MS +saxifrage/SM +saxophone/MS +saxophonist/SM +say/USG +sayer/SM +sayest +saying/MS +says/M +scab/SM +scabbard/SGDM +scabbed +scabbiness/SM +scabbing +scabby/RTP +scabies/M +scabrous/YP +scabrousness/M +scad/SM +scaffold/JGDMS +scaffolding/M +scalability +scalar/SM +scalawag/SM +scald/GJRDS +scale/JGZMBDSR +scaled/AU +scaleless +scalene +scaler/M +scales/A +scaliness/MS +scaling/A +scallion/MS +scallop/GSMDR +scalloper/M +scalloping/M +scalp/GZRDMS +scalpel/SM +scalper/M +scalping/M +scaly/TPR +scam/SM +scammed +scamming +scamp/RDMGZS +scamper/GD +scampi/M +scan/AS +scandal/GMDS +scandalize/GDS +scandalized/U +scandalmonger/SM +scandalous/YP +scandalousness/M +scandium/MS +scanned/A +scanner/SM +scanning/A +scansion/SM +scant/CDRSG +scantest +scantily +scantiness/MS +scantly +scantness/MS +scanty/TPRS +scape/M +scapegoat/SGDM +scapegrace/MS +scapula/M +scapulae +scapular/S +scar/DRMSG +scarab/SM +scarce/RTYP +scarceness/SM +scarcity/MS +scare/S +scarecrow/MS +scaremonger/SGM +scaremongering/M +scarer/M +scarf/SDGM +scarface +scarification/M +scarify/DRSNGX +scarily +scariness/S +scarlatina/MS +scarlet/MDSG +scarp/SDMG +scarred +scarring +scarves/M +scary/PTR +scat/S +scathe/DG +scathed/U +scathing/Y +scatological +scatology/SM +scatted +scatter/DRJZSG +scatterbrain/MDS +scatterer/M +scattergun +scattering/YM +scatting +scavenge/GDRSZ +scavenger/M +scenario/SM +scenarist/MS +scene/GMDS +scenery/SM +scenic/S +scenically +scent's/C +scent/GDMS +scented/U +scentless +scents/C +scepter/DMSG +scepters/U +sceptically +sch +schedule's +schedule/ADSRG +scheduled/U +scheduler/MS +schema/M +schemata +schematic/S +schematically +scheme/JSRDGMZ +schemer/M +schemta +scherzo/MS +schilling/SM +schism/SM +schismatic/S +schist/SM +schizo/S +schizoid/S +schizomycetes +schizophrenia/SM +schizophrenic/S +schizophrenically +schlemiel/MS +schlep/S +schlepped +schlepping +schlock/SM +schlocky/TR +schmaltz/MS +schmaltzy/TR +schmo/M +schmoes +schmooze/GSD +schmuck/MS +schnapps/M +schnauzer/MS +schnitzel/MS +schnook/SM +schnoz/S +schnozzle/MS +scholar/SYM +scholarship/MS +scholastic/S +scholastically +school/ZGMRDJS +schoolbag/SM +schoolbook/SM +schoolboy/MS +schoolchild/M +schoolchildren +schooldays +schooled/U +schoolfellow/S +schoolfriend +schoolgirl/MS +schoolgirlish +schoolhouse/MS +schooling/M +schoolmarm/MS +schoolmarmish +schoolmaster/SGDM +schoolmate/MS +schoolmistress/MS +schoolroom/SM +schoolteacher/MS +schoolwork/SM +schoolyard/SM +schooner/SM +schuss/SDMG +schussboomer/S +schwa/SM +sci +sciatic/S +sciatica/SM +science/FMS +scientific/U +scientifically/U +scientist/SM +scimitar/SM +scintilla/MS +scintillate/GNDSX +scintillation/M +scintillator/SM +scion/SM +scissor/SGD +scleroses +sclerosis/M +sclerotic/S +scoff/RDGZS +scoffer/M +scofflaw/MS +scold/GSJRD +scolder/M +scolioses +scoliosis/M +scollop's +sconce/SDGM +scone/SM +scoop/SRDMG +scooper/M +scoot/SRDGZ +scooter/M +scope/DSGM +scops +scorbutic +scorch/ZGRSD +scorcher/M +scorching/Y +score/ZMDSRJG +scoreboard/MS +scorecard/MS +scored/M +scorekeeper/SM +scoreless +scoreline +scorn/SGZMRD +scorner/M +scornful/PY +scornfulness/M +scorpion/SM +scotch/MSDG +scotchs +scoundrel/YMS +scour/SRDGZ +scourer/M +scourge/MGRSD +scourger/M +scouring/M +scout/SRDMJG +scouter/M +scouting/M +scoutmaster/SM +scow/DMGS +scowl/SRDG +scowler/M +scrabble/DRSZG +scrabbler/M +scrag/SM +scragged +scragging +scraggly/TR +scraggy/TR +scram/S +scramble/UDSRG +scrambler's/U +scrambler/MS +scrammed +scramming +scrap/SGZJRDM +scrapbook/SM +scrape/S +scraper/M +scrapheap/SM +scrapped +scrapper/SM +scrapping +scrappy/RT +scrapyard/S +scratch/JDRSZG +scratched/U +scratcher/M +scratches/M +scratchily +scratchiness/S +scratchy/TRP +scrawl/GRDS +scrawler/M +scrawly/RT +scrawniness/MS +scrawny/TRP +scream/ZGSRD +screamer/M +screaming/Y +scree/DSM +screech/GMDRS +screecher/M +screechy/TR +screed/MS +screen/RDMJSG +screened/U +screening/M +screenplay/MS +screenwriter/MS +screw's +screw/GUSD +screwball/SM +screwdriver/SM +screwer/M +screwiness/S +screwup +screwworm/MS +screwy/RTP +scribal +scribble/JZDRSG +scribbler/M +scribe's +scribe/CDRSGIK +scriber/MKIC +scrim/SM +scrimmage/RSDMG +scrimmager/M +scrimp/DGS +scrimshaw/GSDM +scrip/SM +script/FGMDS +scripted/U +scriptural/Y +scripture/MS +scriptwriter/SM +scriptwriting/M +scriven/ZR +scrivener/M +scrod/M +scrofula/MS +scrofulous +scroll/GMDSB +scrollbar/SM +scrooge/SDMG +scrota +scrotal +scrotum/M +scrounge/ZGDRS +scroungy/TR +scrub/S +scrubbed +scrubber/MS +scrubbing +scrubby/TR +scruff/SM +scruffily +scruffiness/S +scruffy/PRT +scrum/MS +scrummage/MG +scrumptious/Y +scrunch/DSG +scrunchy/S +scruple/SDMG +scrupulosity/SM +scrupulous/UPY +scrupulousness's +scrupulousness/US +scrutable/I +scrutinize/RSDGZ +scrutinized/U +scrutinizer/M +scrutinizing/UY +scrutinizingly/S +scrutiny/MS +scuba/SDMG +scud/S +scudded +scudding +scuff/GSD +scuffle/SDG +scull/SRDMGZ +sculler/M +scullery/MS +scullion/MS +sculpt/SDG +sculptor/MS +sculptress/MS +sculptural/Y +sculpture/SDGM +scum/MS +scumbag/S +scummed +scumming +scummy/TR +scupper/SDMG +scurf/MS +scurfy/TR +scurrility/MS +scurrilous/PY +scurrilousness/MS +scurry/GJSD +scurvily +scurviness/M +scurvy/SRTP +scutcheon/SM +scuttle/MGSD +scuttlebutt/MS +scuzzy/RT +scythe/SDGM +sea/MYS +seabed/S +seabird/S +seaboard/MS +seaborne +seacoast/MS +seafare/JRZG +seafarer/M +seafood/MS +seafront/MS +seagoing +seagull/S +seahorse/S +seal/MDRSGZ +sealant/MS +sealed/AU +sealer/M +seals/UA +sealskin/SM +seam/MNDRGS +seamail +seaman/YM +seamanship/SM +seamer/M +seaminess/M +seamless/PY +seamlessness/M +seams/I +seamstress/MS +seamy/TRP +seaplane/SM +seaport/SM +seaquake/M +sear/DRSJGT +search/RSDAGZ +searcher/AM +searching/YS +searchlight/SM +searing/Y +seascape/SM +seashell/MS +seashore/SM +seasick/P +seasickness/SM +seaside/SM +season/JRDYMBZSG +seasonable/UP +seasonableness/M +seasonably/U +seasonal/Y +seasonality +seasoned/U +seasoner/M +seasoning/M +seat's +seat/UDSG +seatbelt +seated/A +seater/M +seating/SM +seawall/S +seaward/S +seawater/S +seaway/MS +seaweed/SM +seaworthiness/MU +seaworthinesses +seaworthy/TRP +sebaceous +seborrhea/SM +sec'y +sec/S +secant/SM +secede/GRSD +secession/MS +secessionist/MS +seclude/GSD +secluded/YP +secludedness/M +seclusion/SM +seclusive +second/RDYZGSL +secondarily +secondary/PS +seconder/M +secondhand +secrecy/MS +secret/TVGRDYS +secretarial +secretariat/MS +secretary/SM +secretaryship/MS +secrete/XNS +secretion/M +secretive/PY +secretiveness/S +secretory +sect/ISM +sectarian/S +sectarianism/MS +sectary/MS +section/ASEM +sectional/SY +sectionalism/MS +sectionalized +sectioned +sectioning +sector/EMS +sectoral +sectored +sectoring +sects/E +secular/SY +secularism/MS +secularist/MS +secularity/M +secularization/MS +secularize/GSD +secularized/U +secure/PGTYRSDJ +secured/U +securely/I +security/MSI +secy +sedan/SM +sedate/PXVNGTYRSD +sedateness/SM +sedation/M +sedative/S +sedentary +sedge/SM +sedgy/RT +sediment/SGDM +sedimentary +sedimentation/SM +sedition/SM +seditious/PY +seditiousness/M +seduce/RSDGZ +seducer/M +seduction/MS +seductive/YP +seductiveness/MS +seductress/SM +sedulous/Y +see/U +seed's +seed/ADSG +seedbed/MS +seedcase/SM +seeded/U +seeder/MS +seediness/MS +seeding/S +seedless +seedling/SM +seedpod/S +seedy/TPR +seeing's +seeing/U +seeings +seek/GZSR +seeker/M +seeking/Y +seem/GJSYD +seeming/Y +seemliness's +seemliness/US +seemly/UTPR +seen/U +seep/GSD +seepage/MS +seer/SM +seersucker/MS +sees +seesaw/DMSG +seethe/SDGJ +segment/SGDM +segmental/Y +segmentation/SM +segmented/U +segregant +segregate/XCNGSD +segregated/U +segregation/CM +segregationist/SM +segregative +segue/DS +segueing +seigneur/MS +seignior/SM +seine/GZMDSR +seiner/M +seismic +seismically +seismograph/ZMR +seismographer/M +seismographic +seismographs +seismography/SM +seismologic +seismological +seismologist/MS +seismology/SM +seismometer/S +seize/BJGZDSR +seizer/M +seizin/MS +seizing/M +seizor/MS +seizure/MS +seldom +select/PDSVGB +selected/UAC +selection/MS +selectional +selective/YP +selectiveness/M +selectivity/MS +selectman/M +selectmen +selectness/SM +selector/SM +selects/A +selenate/M +selenite/M +selenium/MS +selenographer/SM +selenography/MS +self/GPDMS +selfish/PUY +selfishness/SU +selfless/YP +selflessness/MS +selfness/M +selfsame/P +selfsameness/M +sell/AZGSR +seller/AM +sellout/MS +seltzer/S +selvage/MGSD +selves/M +semantic/S +semantical/Y +semanticist/SM +semantics/M +semaphore/GMSD +semblance/ASME +semen/SM +semester/SM +semi/SM +semiannual/Y +semiarid +semiautomated +semiautomatic/S +semicircle/SM +semicircular +semicolon/MS +semiconductor/SM +semiconscious +semidefinite +semidetached +semidrying/M +semifinal/MS +semifinalist/MS +semilogarithmic +semimonthly/S +seminal/Y +seminar/SM +seminarian/MS +seminary/MS +semiofficial +semiotic/S +semioticians +semiotics/M +semipermanent/Y +semipermeable +semiprecious +semiprivate +semiprofessional/YS +semipublic +semiquantitative/Y +semiretired +semisecret +semiskilled +semisolid/S +semistructured +semisweet +semitic/S +semitone/SM +semitrailer/SM +semitrance +semitransparent +semitropical +semivowel/MS +semiweekly/S +semiyearly +semolina/SM +sempiternal +sempstress/SM +sen +senate/MS +senator/MS +senatorial +send/SRGZ +sender/M +sends/A +senescence/SM +senescent +senile/SY +senility/MS +senior/MS +seniority/SM +senna/MS +senor/MS +senora/S +senorita/S +sens/DSG +sensate/YNX +sensately/I +sensation/M +sensational/Y +sensationalism/MS +sensationalist/S +sensationalize/GSD +sense/M +senseless/PY +senselessness/SM +sensibility/ISM +sensible/PRST +sensibleness/MS +sensibly/I +sensitive/YIP +sensitiveness's/I +sensitiveness/MS +sensitives +sensitivity/ISM +sensitization/CSM +sensitize/SDCG +sensitized/U +sensitizers +sensor/MS +sensory +sensual/YF +sensualist/MS +sensuality/MS +sensuous/PY +sensuousness/S +sent/UFEA +sentence/SDMG +sentential/Y +sententious/Y +sentience/ISM +sentient/YS +sentiment/MS +sentimental/Y +sentimentalism/SM +sentimentalist/SM +sentimentality/SM +sentimentalization/SM +sentimentalize/RSDZG +sentimentalizes/U +sentinel/GDMS +sentry/SM +sepal/SM +separability/MSI +separable/PI +separableness/MI +separably/I +separate/YNGVDSXP +separateness/MS +separates/M +separation/M +separatism/SM +separatist/SM +separator/SM +sepia/MS +sepses +sepsis/M +sept/M +septa/M +septate/N +septennial/Y +septet/MS +septic/S +septicemia/SM +septicemic +septillion/M +septuagenarian/MS +septum/M +sepulcher/MGSD +sepulchers/UA +sepulchral/Y +seq +sequel/MS +sequence's/F +sequence/DRSJZMG +sequenced/A +sequencer/M +sequences/F +sequent/F +sequential/YF +sequentiality/FM +sequentialize/DSG +sequester/SDG +sequestrate/XGNDS +sequestration/M +sequin/SDMG +sequitur +sequoia/MS +sera's +seraglio/SM +serape/S +seraph/M +seraphic +seraphically +seraphim's +seraphs +sere/TGDRS +serenade/MGDRS +serenader/M +serendipitous/Y +serendipity/MS +serene/GTYRSDP +sereneness/SM +serenity/MS +serf/MS +serfdom/MS +serge/DSGM +sergeant/SM +serial/MYS +serialization/MS +serialize/GSD +series/M +serif/SMD +serigraph/M +serigraphs +serious/PY +seriousness/SM +sermon/SGDM +sermonize/GSD +serological/Y +serology/MS +serons +serous +serpent/GSDM +serpentine/GYS +serrate/GNXSD +serration/M +serried +serum/MS +servant/SDMG +serve/AGCFDSR +served/U +server/MCF +servers +service's/E +service/MGSRD +serviceability/SM +serviceable/P +serviceableness/M +serviced/U +serviceman/M +servicemen +services/E +servicewoman +servicewomen +serviette/MS +servile/U +servilely +servileness/M +serviles +servility/SM +serving/SM +servitor/SM +servitude/MS +servo/S +servomechanism/MS +servomotor/MS +sesame/MS +sesquicentennial/S +sessile +session/SM +set's +set/SIA +setback/S +setscrew/SM +sett/BJGZSMR +settable/A +settee/MS +setter/M +setting's +setting/AS +settle/AUDSG +settlement/ASM +settler/MS +settling/S +setup/MS +seven/SMH +sevenfold +sevenpence +seventeen/HMS +seventeenths +sevenths +seventieths +seventy/MSH +sever/SGTRD +several/YS +severalfold +severalty/M +severance/SM +severe/PY +severed/E +severeness/SM +severing/E +severity/MS +severs/E +sew/SAGD +sewage/MS +sewer/GSMD +sewerage/SM +sewing/SM +sewn +sex/GMDS +sexagenarian/MS +sexily +sexiness/MS +sexism/SM +sexist/SM +sexless +sexologist/SM +sexology/MS +sexpot/SM +sextant/SM +sextet/SM +sextillion/M +sexton/MS +sextuple/MDG +sextuplet/MS +sexual/Y +sexuality/MS +sexualized +sexy/RTP +sf +sh/DRS +shabbily +shabbiness/SM +shabby/RTP +shack/GMDS +shackle's +shackle/UGDS +shackler/M +shad/DRJGSM +shade/SM +shaded/U +shadeless +shadily +shadiness/MS +shading/M +shadow/GSDRM +shadowbox/SDG +shadower/M +shadowiness/M +shadowy/TRP +shady/TRP +shaft/SDMG +shafting/M +shag/MS +shagged +shagginess/SM +shagging +shaggy/TPR +shah/M +shahs +shakable/U +shakably/U +shake/SRGZB +shakeable +shakedown/S +shaken/U +shakeout/SM +shaker/M +shakeup/S +shakily +shakiness/S +shaking/M +shaky/TPR +shale/SM +shall +shallot/SM +shallow/STPGDRY +shallowness/SM +shalom +shalt +sham/MDSG +shaman/SM +shamanic +shamble/DSG +shambles/M +shame/SM +shamefaced/Y +shameful/YP +shamefulness/S +shameless/PY +shamelessness/SM +shammed +shammer +shamming +shammy's +shampoo/DRSMZG +shampooer/M +shamrock/SM +shan't +shandy/M +shanghai/SDG +shank/SMDG +shantis +shantung/MS +shanty/SM +shantytown/SM +shape's +shape/AGDSR +shaped/U +shapeless/PY +shapelessness/SM +shapeliness/S +shapely/RPT +shaper/S +sharable/U +shard/SM +share/DSRGZMB +shareable +sharecrop/S +sharecropped +sharecropper/MS +sharecropping +shared/U +shareholder/MS +shareholding/S +sharer/M +shareware/S +sharia/SM +shark/SGMD +sharkskin/SM +sharp/SGTZXPYRDN +sharpen/ASGD +sharpened/U +sharpener/S +sharper/M +sharpie/SM +sharpness/MS +sharpshoot/JRGZ +sharpshooter/M +sharpshooting/M +sharpy's +shat +shatter/DSG +shattering/Y +shatterproof +shave/DSRJGZ +shaved/U +shaver/M +shaving/M +shaw/M +shawl/SDMG +shay/MS +she'd +she'll +she/M +sheaf/MDGS +shear/RDGZS +shearer/M +sheath/GJMDRS +sheathe/UGSD +sheather/M +sheathing/M +sheaths +sheave/SDG +sheaves/M +shebang/MS +shed's +shed/U +shedding +sheds +sheen/MDGS +sheeny/TRSM +sheep/M +sheepdog/SM +sheepfold/MS +sheepherder/MS +sheepish/YP +sheepishness/SM +sheepskin/SM +sheer/PGTYRDS +sheerness/S +sheet/RDMJSG +sheeting/M +sheetlike +sheik/SM +sheikdom/SM +sheikh's +shekel/MS +shelf/MDGS +shell/RDMGS +shellac/S +shellacked +shellacking/MS +shelled/U +shellfire/SM +shellfish/SM +shelter/DRMGS +sheltered/U +shelterer/M +shelve/JRSDG +shelver/M +shelves/M +shelving/M +shenanigan/SM +shepherd/DMSG +shepherdess/S +sherbet/MS +sherd's +sheriff/SM +sherlock/M +sherry/MS +shew/GSD +shewn +shh +shiatsu/S +shibboleth/M +shibboleths +shield/MDRSG +shielded/U +shielder/M +shift/RDGZS +shiftily +shiftiness/SM +shiftless/PY +shiftlessness/S +shifty/TRP +shill/DJSG +shillelagh/M +shillelaghs +shilling/M +shim/SM +shimmed +shimmer/DGS +shimmery +shimming +shimmy/DSMG +shin/SGZDRM +shinbone/SM +shindig/MS +shine/S +shiner/M +shingle/MDRSG +shingler/M +shinguard +shininess/MS +shining/Y +shinned +shinning +shinny/GDSM +shinsplints +shiny/PRT +ship's +ship/SLA +shipboard/MS +shipborne +shipbuild/RGZJ +shipbuilder/M +shipload/SM +shipman/M +shipmate/SM +shipmen +shipment/AMS +shipowner/MS +shippable +shipped/A +shipper/SM +shipping/MS +shipshape +shipwreck/GSMD +shipwright/MS +shipyard/MS +shire/MS +shirk/RDGZS +shirker/M +shirr/GJDS +shirt/JDMSG +shirtfront/S +shirting/M +shirtless +shirtmake/R +shirtmaker/M +shirtsleeve/MS +shirttail/S +shirtwaist/SM +shit/S! +shitting/! +shitty/RT! +shiv/SZRM +shiver/GDR +shiverer/M +shivery +shivved +shivving +shlemiel's +shoal/SRDMGT +shoat/SM +shock/SGZRD +shocker/M +shocking/Y +shockproof +shod/U +shoddily +shoddiness/SM +shoddy/RSTP +shoe/MS +shoehorn/GSMD +shoeing +shoelace/MS +shoemake/RZ +shoemaker/M +shoer's +shoeshine/MS +shoestring/MS +shoetree/MS +shogun/MS +shogunate/SM +shone +shoo/DSG +shoofly +shook/SM +shoot/SJRGZ +shooter/M +shootout/MS +shop/MS +shopkeep/RGZ +shopkeeper/M +shoplift/SRDGZ +shoplifter/M +shoplifting/M +shoppe/RSDGZJ +shopped/M +shopper/M +shopping/M +shoptalk/SM +shopworn +shore/DSRGMJ +shorebird/S +shoreline/SM +shoring/M +short/SGTXYRDNP +shortage/MS +shortbread/MS +shortcake/SM +shortchange/DSG +shortcoming/MS +shortcrust +shortcut/MS +shortcutting +shorten/RDGJ +shortener/M +shortening/M +shortfall/SM +shorthand/DMS +shorthorn/MS +shortie's +shortish +shortlist/GD +shortness/MS +shortsighted/YP +shortsightedness/S +shortstop/MS +shortwave/SM +shorty/SM +shot/MS +shotgun/SM +shotgunned +shotgunner +shotgunning +shotted +shotting +should/TZR +shoulder/GMD +shouldn't +shout/SGZRDM +shove/DSRG +shovel/MDRSZG +shoveler/M +shovelful/MS +shover/M +show/GDRZJS +showbiz +showbizzes +showboat/SGDM +showcase/MGSD +showdown/MS +shower/GDM +showery/TR +showgirl/SM +showily +showiness/MS +showing/M +showman/M +showmanship/SM +showmen +shown +showoff/S +showpiece/SM +showplace/SM +showroom/MS +showy/RTP +shpt +shrank +shrapnel/SM +shred/MS +shredded +shredder/MS +shredding +shrew/GSMD +shrewd/RYTP +shrewdness/SM +shrewish/PY +shrewishness/M +shriek/SGDRMZ +shrieker/M +shrift/SM +shrike/SM +shrill/DRTGPS +shrillness/MS +shrilly +shrimp/MDGS +shrine/SDGM +shrink/SRBG +shrinkage/SM +shrinker/M +shrinking/U +shrive/RSDG +shrivel/GSD +shriven +shroud/GSMD +shrub/SM +shrubbed +shrubbery/SM +shrubbing +shrubby/TR +shrug/S +shrugged +shrugging +shrunk/N +shtick/S +shuck/SGMRD +shucker/M +shucks/S +shudder/DSG +shuddery +shuffle/GDSRZ +shuffleboard/MS +shuffled/A +shuffles/A +shuffling/A +shun/S +shunned +shunning +shunt/GSRD +shunter/M +shush/SDG +shut/S +shutdown/MS +shuteye/SM +shutoff/M +shutout/SM +shutter/DMGS +shutterbug/S +shuttering/M +shutting +shuttle/MGDS +shuttlecock/MDSG +shy/DRSGTZY +shyer +shyest +shyness/SM +shyster/SM +sibilance/M +sibilancy/M +sibilant/SY +sibling/SM +sibyl/SM +sibylline +sic/S +sick/GXTYNDRSP +sickbay/M +sickbed/S +sicken/JRDG +sickener/M +sickening/Y +sicker/Y +sickie/SM +sickish/PY +sickle/SDGM +sickliness/M +sickly/TRSDPG +sickness/MS +sicko/S +sickout/S +sickroom/SM +side/ISRM +sidearm/S +sideband/MS +sidebar/MS +sideboard/SM +sideburns +sidecar/MS +sided/A +sidedness +sidekick/MS +sidelight/SM +sideline/MGDRS +sidelong +sideman/M +sidemen +sidepiece/S +sider/FA +sidereal +sides/A +sidesaddle/MS +sideshow/MS +sidesplitting +sidestep/S +sidestepped +sidestepping +sidestroke/GMSD +sideswipe/GSDM +sidetrack/SDG +sidewalk/MS +sidewall/MS +sidewards +sideway/SM +sidewinder/SM +siding/SM +sidle/DSG +siege/GMDS +sienna/SM +sierra/SM +siesta/MS +sieve/GZMDS +sift/GZJSDR +sifted/UA +sifter/M +sigh/DRG +sigher/M +sighs +sight/ISM +sighted/P +sighter/M +sighting/S +sightless/Y +sightliness/UM +sightly/TURP +sightread +sightsee/RZ +sightseeing/S +sigma/SM +sigmoid +sign's +sign/GARDCS +signal's +signal/A +signaled +signaler/S +signaling +signalization/S +signalize/GSD +signally +signalman/M +signalmen +signals +signatory/SM +signature/MS +signboard/MS +signed/FU +signer/SC +signet/SGMD +significance/IMS +significant/YS +significantly/I +signification/M +signify/DRSGNX +signing/S +signor/SFM +signora/SM +signore/M +signori +signories +signorina/SM +signorine +signpost/DMSG +signs/F +silage/GMSD +siled +silence/MZGRSD +silencer/M +silent/TSPRY +silentness/M +silhouette/GMSD +silica/SM +silicate/SM +siliceous +silicide/M +silicon/MS +silicone/SM +silicoses +silicosis/M +silk/GXNDMS +silken/DG +silkily +silkiness/SM +silkscreen/SM +silkworm/MS +silky/RSPT +sill/MS +silliness/SM +silly/PRST +silo/GSM +silt/MDGS +siltation/M +siltstone/M +silty/RT +silver/RDYMGS +silverer/M +silverfish/MS +silversmith/M +silversmiths +silverware/SM +silvery/RTP +simian/S +similar/EY +similarity/EMS +simile/SM +similitude/SME +simmer/GSD +simonize/SDG +simony/MS +simpatico +simper/GDS +simple/RSDGTP +simpleminded/YP +simpleness/S +simpleton/SM +simplex/S +simplicity/MS +simplified/U +simplify/ZXRSDNG +simplistic +simplistically +simply +simulacrum/M +simulate/XENGSD +simulation/ME +simulative +simulator/SEM +simulcast/GSD +simultaneity/SM +simultaneous/YP +simultaneousness/M +sin/MAGS +since +sincere/IY +sincereness/M +sincerer +sincerest +sincerity/MIS +sine/SM +sinecure/MS +sinecurist/M +sinew/SGMD +sinewy +sinful/YP +sinfulness/SM +sing/BGJZYDR +singe/S +singeing +singer/M +singing/Y +single/PSDG +singlehanded/Y +singleness/SM +singlet/SM +singleton/SM +singletree/SM +singsong/GSMD +singular/SY +singularity/SM +singularization/M +sinister/YP +sinisterness/M +sinistral/Y +sink/GZSDRB +sinkable/U +sinker/M +sinkhole/SM +sinking/M +sinless/YP +sinlessness/M +sinned +sinner/MS +sinning +sinter/DM +sinuosity/MS +sinuous/PY +sinuousities +sinuousness/M +sinus/MS +sinusitis/SM +sinusoid/MS +sinusoidal/Y +sip/S +siphon/DMSG +siphons/U +sipped +sipper/SM +sipping +sir/XGMNDS +sire/MS +sired/C +siren/M +sires/C +siring/C +sirloin/MS +sirocco/MS +sirred +sirring +sirup's +sis/S +sisal/MS +sissified +sissy/TRSM +sister's/A +sister/GDYMS +sisterhood/MS +sisterliness/MS +sisterly/P +sit/AG +sitar/SM +sitarist/SM +sitcom/SM +site/DSJM +sits +sitter/MS +sitting/SM +situ/S +situate/GNSDX +situation/M +situational/Y +situationist +situs/M +six/MRSH +sixfold +sixgun +sixpence/MS +sixpenny +sixshooter +sixteen/HRSM +sixteenths +sixth/Y +sixths +sixtieths +sixty/SMH +sizable/P +sizableness/M +size/GJDRSBMZ +sized/UA +sizer/M +sizes/A +sizing/M +sizzle/RSDG +sizzler/M +ska/S +skat/JMDRGZ +skate/SM +skateboard/SJGZMDR +skater/M +skedaddle/GSD +skeet/RMS +skein/MDGS +skeletal/Y +skeleton/MS +skeptic/SM +skeptical/Y +skepticism/MS +sketch/MRSDZG +sketchbook/SM +sketcher/M +sketchily +sketchiness/MS +sketchpad +sketchy/PRT +skew/DRSPGZ +skewer/GDM +skewing/M +skewness/M +ski/MNJSG +skid/S +skidded +skidding +skiff/GMDS +skiing/M +skilfully +skill/DMSG +skilled/U +skillet/MS +skillful/YUP +skillfulness/MU +skillfulnesses +skilling/M +skim/SM +skimmed +skimmer/MS +skimming/SM +skimp/GDS +skimpily +skimpiness/MS +skimpy/PRT +skin/SM +skincare +skindive/G +skinflint/MS +skinhead/SM +skinless +skinned +skinner/SM +skinniness/MS +skinning +skinny/TRSP +skintight +skip/S +skipped +skipper/SGDM +skipping +skirmish/RSDMZG +skirmisher/M +skirt/RDMGS +skirter/M +skirting/M +skit/GSMD +skitter/SDG +skittish/YP +skittishness/SM +skittle/SM +skivvy/GSDM +skoal/SDG +skulduggery/MS +skulk/SRDGZ +skulker/M +skull/SDM +skullcap/MS +skullduggery's +skunk/GMDS +sky/MDRSGZ +skycap/MS +skydiver/SM +skydiving/MS +skyhook +skyjack/ZSGRDJ +skyjacker/M +skylark/SRDMG +skylarker/M +skylight/MS +skyline/MS +skyrocket/GDMS +skyscrape/RZ +skyscraper/M +skyward/S +skywave +skyway/M +skywriter/MS +skywriting/MS +slab/MS +slabbed +slabbing +slack/SPGTZXYRDN +slacken/DG +slacker/M +slackness/MS +slag/MS +slagged +slagging +slain +slake/DSG +slaked/U +slalom/SGMD +slam/S +slammed +slammer/S +slamming +slander/MDRZSG +slanderous/PY +slanderousness/M +slang/SMGD +slangy/TR +slant/SDG +slanting/Y +slantwise +slap/MS +slapdash/S +slaphappy/TR +slapped +slapper +slapping +slapstick/MS +slash/GZRSD +slashing/Y +slat/MDRSGZ +slate/SM +slater/M +slather/SMDG +slating/M +slatted +slattern/MYS +slatting +slaughter/SJMRDGZ +slaughterer/M +slaughterhouse/SM +slave/DSRGZM +slaveholder/SM +slaver/GDM +slavery/SM +slavish/YP +slavishness/SM +slaw/MS +slay/RGZS +sleaze/S +sleazily +sleaziness/SM +sleazy/RTP +sled/SM +sledded +sledder/S +sledding +sledge/SDGM +sledgehammer/MDGS +sleek/PYRDGTS +sleekness/S +sleep/RMGZS +sleeper/M +sleepily +sleepiness/SM +sleeping/M +sleepless/YP +sleeplessness/SM +sleepover/S +sleepwalk/JGRDZS +sleepwalker/M +sleepwear/M +sleepy/PTR +sleepyhead/MS +sleet/DMSG +sleety/TR +sleeve/SDGM +sleeveless +sleeving/M +sleigh/GMD +sleighs +sleight/SM +sleken/DG +slender/RYTP +slenderize/DSG +slenderness/MS +slept +sleuth/GMD +sleuths +slew/DGS +slice/DSRGZM +sliced/U +slicer/M +slick/PSYRDGTZ +slicker/M +slickness/MS +slid/GZDR +slide/S +slider/M +slight/DRYPSTG +slighter/M +slighting/Y +slightness/S +slim/SPGYD +slime/SM +sliminess/S +slimline +slimmed +slimmer/S +slimmest +slimming/S +slimness/S +slimy/PTR +sling/GMRS +slings/U +slingshot/MS +slink/GS +slinky/RT +slip/SM +slipcase/MS +slipcover/GMDS +slipknot/SM +slippage/SM +slipped +slipper/GSMD +slipperiness/S +slippery/PRT +slipping +slipshod +slipstream/MDGS +slipway/SM +slit/SM +slither/DSG +slithery +slitted +slitter/S +slitting +sliver/GSDM +slivery +slob/MS +slobber/SDG +slobbery +sloe/MS +slog/S +slogan/MS +sloganeer/MG +slogged +slogging +sloop/SM +slop/DRSGZ +slope/S +sloped/U +slopped +sloppily +sloppiness/SM +slopping +sloppy/RTP +slosh/GSDM +slot/MS +sloth/GDM +slothful/PY +slothfulness/MS +sloths +slotted +slotting +slouch/DRSZG +sloucher/M +slouchy/RT +slough/GMD +sloughs +sloven/YMS +slovenliness/SM +slovenly/TRP +slow/PGTYDRS +slowcoaches +slowdown/MS +slowish +slowness/MS +slowpoke/MS +sludge/SDGM +sludgy/TR +slue/MGDS +slug/MS +sluggard/MS +slugged +slugger/SM +slugging +sluggish/YP +sluggishness/SM +sluice/SDGM +slum/MS +slumber/MDRGS +slumberer/M +slumberous +slumlord/MS +slummed +slummer +slumming +slummy/TR +slump/DSG +slung/U +slunk +slur/MS +slurp/GSD +slurred +slurried/M +slurring +slurry/MGDS +slurrying/M +slush/SDMG +slushiness/SM +slushy/RTP +slut/MS +sluttish +slutty/TR +sly/RTY +slyness/MS +smack/SMRDGZ +smacker/M +small/SGTRDP +smallholders +smallholding/MS +smallish +smallness/S +smallpox/SM +smalltalk +smalltime +smarmy/RT +smart/YRDNSGTXP +smarten/GD +smartness/S +smartypants +smash/GZRSD +smasher/M +smashing/Y +smashup/S +smattering/SM +smear/GRDS +smearer/M +smeary/TR +smell/SBRDG +smeller/M +smelliness/MS +smelly/TRP +smelt/SRDGZ +smelter/M +smidgen/MS +smilax/MS +smile/GMDSR +smiley/M +smilies +smiling/UY +smirch/SDG +smirk/GSMD +smite/GSR +smiter/M +smith/DMG +smithereens +smiths +smithy/SM +smitten +smock/SGMDJ +smocking/M +smog/SM +smoggy/TR +smoke/GZMDSRBJ +smokehouse/MS +smokeless +smoker/M +smokescreen/S +smokestack/MS +smokiness/S +smoking/M +smoky/RSPT +smolder/SGD +smoldering/Y +smooch/SDG +smooth/TZGPRDNY +smoothen/DG +smoother/M +smoothie/SM +smoothness/MS +smooths +smote +smother/GSD +smudge/GSD +smudginess/M +smudgy/TRP +smug/YSP +smugged +smugger +smuggest +smugging +smuggle/JZGSRD +smuggler/M +smugness/MS +smut/SM +smutted +smuttiness/SM +smutting +smutty/TRP +sm�rg�sbord/SM +snack/SGMD +snaffle/GDSM +snafu/DMSG +snag/MS +snagged +snagging +snail/GSDM +snake/DSGM +snakebird/M +snakebite/MS +snakelike +snakeroot/M +snaky/TR +snap/US +snapback/M +snapdragon/MS +snapped/U +snapper/SM +snappily +snappiness/SM +snapping/U +snappish/PY +snappishness/SM +snappy/PTR +snapshot/MS +snapshotted +snapshotting +snare/DSRGM +snarer/M +snarf/JSGD +snarl/UGSD +snarler/M +snarling/Y +snarly/RT +snatch/DRSZG +snatcher/M +snazzily +snazzy/TR +sneak/RDGZS +sneaker/MD +sneakily +sneakiness/SM +sneaking/Y +sneaky/PRT +sneer/GMRDJS +sneerer/M +sneering/Y +sneeze/SRDG +snick/MRZ +snicker/GMRD +snide/YTSRP +snideness/M +sniff/GZSRD +sniffer/M +sniffle/GDRS +sniffler/M +sniffles/M +snifter/MDSG +snigger's +snip/SGDRZ +snipe/SM +sniper/M +snipped +snipper/SM +snippet/SM +snipping +snippy/RT +snit/SM +snitch/GDS +snivel/JSZGDR +sniveler/M +snob/MS +snobbery/SM +snobbish/YP +snobbishness/S +snobby/RT +snood/SGDM +snook/SMRZ +snooker/GMD +snoop/SRDGZ +snooper/M +snoopy/RT +snoot/SDMG +snootily +snootiness/MS +snooty/TRP +snooze/GSD +snore/DSRGZ +snorkel/ZGSRDM +snort/GSZRD +snorter/M +snot/MS +snotted +snottily +snottiness/SM +snotting +snotty/TRP +snout/SGDM +snow/GDMS +snowball/SDMG +snowbank/SM +snowbird/SM +snowblower/S +snowboard/GZDRJS +snowbound +snowcapped +snowdrift/MS +snowdrop/MS +snowfall/MS +snowfield/MS +snowflake/MS +snowily +snowiness/MS +snowman/M +snowmen +snowmobile/GMDRS +snowplough/M +snowploughs +snowplow/SMGD +snowshed +snowshoe/MRS +snowshoeing +snowshoer/M +snowstorm/MS +snowsuit/S +snowy/RTP +snub/SP +snubbed +snubber +snubbing +snuff/GZSYRD +snuffbox/SM +snuffer/M +snuffle/GDSR +snuffler/M +snuffly/RT +snug/SYP +snugged +snugger +snuggest +snugging +snuggle/GDS +snuggly +snugness/MS +so +soak/GDRSJ +soaker/M +soap/MDRGS +soapbox/DSMG +soapiness/S +soapstone/MS +soapsud/S +soapy/RPT +soar/DRJSG +soarer/M +soaring/Y +sob/SZR +sobbed +sobbing/Y +sober/PGTYRD +soberer/M +soberness/SM +sobriety/SIM +sobriquet/MS +soc/S +soccer/MS +sociabilities +sociability/IM +sociable/S +sociably/IU +social/SY +socialism/SM +socialist/SM +socialistic +socialite/SM +sociality/M +socialization/SM +socialize/RSDG +socialized/U +socializer/M +socially/U +societal/Y +society/MS +socio +sociobiology/M +sociocultural/Y +sociodemographic +socioeconomic/S +socioeconomically +sociolinguistics/M +sociological/MY +sociologist/SM +sociology/SM +sociometric +sociometry/M +sociopath/M +sociopaths +sock/GDMS +socket/SMDG +sod/MS +soda/SM +sodded +sodden/DYPSG +soddenness/M +sodding +sodium/MS +sodomite/MS +sodomize/GDS +sodomy/SM +soever +sofa/SM +soft/SPXTYNR +softball/MS +softbound +soften/ZGRD +softener/M +softhearted +softie's +softness/MS +software/MS +softwood/SM +softy/SM +soggily +sogginess/S +soggy/RPT +soign� +soil/SGMD +soiled/U +soir�e/SM +sojourn/RDZGSM +sol/GSMDR +solace/GMSRD +solacer/M +solar/S +solaria +solarium/M +sold/RU +solder/RDMSZG +soldier/MDYSG +soldiery/MS +sole/YSP +solecism/MS +soled/FA +solemn/PTRY +solemness +solemnify/GSD +solemnity/MS +solemnization/SM +solemnize/GSD +solemnness/SM +solenoid/MS +soler/F +soles/IFA +solicit/SDG +solicitation/S +solicited/U +solicitor/MS +solicitous/YP +solicitousness/S +solicitude/MS +solid/STYRP +solidarity/MS +solidi +solidification/M +solidify/NXSDG +solidity/S +solidness/SM +solidus/M +soliloquies +soliloquize/DSG +soliloquy/M +soling/NM +solipsism/MS +solipsist/S +solitaire/SM +solitary/SP +solitude/SM +solo/DMSG +soloist/SM +solstice/SM +solubility/IMS +soluble/SI +solute's +solute/ENAXS +solution/AME +solvable/UI +solvating +solve/ABSRDZG +solved/EU +solvency/IMS +solvent's +solvent/IS +solvently +solver/MEA +solves/E +solving/E +soma/M +somatic +somber/PY +somberness/SM +sombre +sombrero/SM +some/Z +somebody'll +somebody/SM +someday +somehow +someone'll +someone/SM +someplace/M +somersault/DSGM +somerset/S +somersetted +somersetting +something/S +sometime/S +someway/S +somewhat/S +somewhere/S +sommelier/SM +somnambulism/SM +somnambulist/SM +somnolence/MS +somnolent/Y +son/SMY +sonar/SM +sonata/MS +sonatina/SM +song/MS +songbag +songbird/SM +songbook/S +songfest/MS +songful/YP +songfulness/M +songster/MS +songstress/SM +songwriter/SM +songwriting +sonic/S +sonnet/MDSG +sonny/SM +sonority/S +sonorous/PY +sonorousness/SM +sonuvabitch +soon/TR +soonish +soot/MGDS +sooth/GZTYSRDMJ +soothe +soother/M +soothing/YP +soothingness/M +sooths +soothsay/JGZR +soothsayer/M +sooty/RT +sop/SM +sophism/SM +sophist/RMS +sophister/M +sophistic/S +sophistical +sophisticate/XNGDS +sophisticated/U +sophisticatedly +sophistication/MU +sophistry/SM +sophomore/SM +sophomoric +soporific/SM +soporifically +sopped +sopping/S +soppy/RT +soprano/SM +sorbet/SM +sorcerer/MS +sorceress/S +sorcery/MS +sordid/PY +sordidness/SM +sore/PYTGDRS +sorehead/SM +soreness/S +sorghum/MS +sorority/MS +sorrel/SM +sorrily +sorriness/SM +sorrow/GRDMS +sorrower/M +sorrowful/YP +sorrowfulness/SM +sorry/PTSR +sort's +sort/FSAGD +sorta +sortable +sorted/U +sorter/MS +sortie/MSD +sortieing +sos +sot/SM +sottish +sou'wester +sou/SMH +soubriquet's +souffl�/MS +sough/DG +soughs +sought/U +soul/MDS +soulful/YP +soulfulness/MS +soulless/Y +sound's +sound/AUD +soundboard/MS +sounder's +sounder/U +sounders +soundest +sounding's +sounding/AY +soundings +soundless/Y +soundly/U +soundness/UMS +soundproof/GSD +soundproofing/M +sounds/A +soundtrack/MS +soup/GMDS +soupy/RT +soup�on/SM +sour/TYDRPSG +source/ASDMG +sourceless +sourdough +sourdoughs +sourish +sourness/MS +sourpuss/MS +sous/DSG +sousaphone/SM +souse +south/RDMG +southbound +southeast/RZMS +southeaster/YM +southeastern +southeastward/S +souther/MY +southerly/S +southern/PZSYR +southerner/M +southernisms +southernmost +southing/M +southland/M +southpaw/MS +souths +southward/S +southwest/RMSZ +southwester/YM +southwestern +southwestward/S +souvenir/SM +sovereign/YMS +sovereignty/MS +soviet/MS +sow/ADGS +sowbelly/M +sowens/M +sower/DS +sown/A +sox's +soy/MS +soybean/MS +spa/MS +space/DSRGZMJ +spacecraft/MS +spaceflight/S +spaceman/M +spacemen +spaceport/SM +spacer/M +spaceship/MS +spacesuit/MS +spacewalk/GSMD +spacewoman +spacewomen +spacey +spacial +spacier +spaciest +spaciness +spacing/M +spacious/PY +spaciousness/SM +spade/DSRGM +spadeful/SM +spader/M +spadework/SM +spadices +spadix/M +spaghetti/SM +spake +span/MS +spandex/MS +spandrels +spangle/GMDS +spaniel/SM +spanielled +spanielling +spank/SRDJG +spanker/M +spanking/M +spanned/U +spanner/SM +spanning +spar/DRMGTS +spare/PSY +spareness/MS +sparer/M +spareribs +sparing/UY +spark/SGMRD +sparker/M +sparkle/DRSGZ +sparkler/M +sparky/RT +sparling/SM +sparred +sparrer +sparring/U +sparrow/MS +spars/TR +sparse/YP +sparseness/S +sparsity/S +spartan +spasm/GSDM +spasmodic +spasmodically +spastic/S +spat/MS +spate/SM +spathe/MS +spatial/Y +spatiality/M +spatted +spatter/DGS +spatterdock/M +spatting +spatula/SM +spavin/DMS +spawn/MRDSG +spawner/M +spay/DGS +speak/RBGZJS +speakable/U +speakeasy/SM +speaker/M +speakership/M +speaking/U +spear/MRDGS +spearer/M +spearfish/SDMG +spearhead/GSDM +spearmint/MS +spec'd +spec'ing +spec/SM +special/SRYP +specialism/MS +specialist/MS +specialization/SM +specialize/GZDSR +specialized/U +specializing/U +specialty/MS +specie/MS +specif +specifiability +specifiable +specifiably +specific/SP +specifically +specification/SM +specificity/S +specified/U +specifier/SM +specifies +specify/AD +specifying +specimen/SM +specious/YP +speciousness/SM +speck/GMDS +speckle/GMDS +spectacle/MSD +spectacular/SY +spectator/SM +specter's/A +specter/DMS +spectra/M +spectral/YP +spectralness/M +spectrogram/MS +spectrograph/M +spectrographically +spectrography/M +spectrometer/MS +spectrometric +spectrometry/M +spectrophotometer/SM +spectrophotometric +spectrophotometry/M +spectroscope/SM +spectroscopic +spectroscopically +spectroscopy/SM +spectrum/M +specular/Y +specularity +speculate/VNGSDX +speculation/M +speculative/Y +speculator/SM +sped +speech/GMDS +speechless/YP +speechlessness/SM +speed/RMJGZS +speedboat/GSRM +speedboating/M +speeder/M +speedily +speediness/SM +speedometer/MS +speedster/SM +speedup/MS +speedway/SM +speedwell/MS +speedy/PTR +speer/M +speleological +speleologist/S +speleology/MS +spell/RDSJGZ +spellbind/SRGZ +spellbinder/M +spellbound +spelldown/MS +spelled/A +speller/M +spelling/M +spells/A +spelunker/MS +spelunking/S +spend/SBJRGZ +spender/M +spendthrift/MS +spent/U +sperm/SM +spermatophyte/M +spermatozoa +spermatozoon/M +spermicidal +spermicide/MS +spew/DRGZJS +spewer/M +sphagnum/SM +sphere/SDGM +spheric/S +spherical/Y +spherics/M +spheroid/SM +spheroidal/Y +spherule/MS +sphincter/SM +sphinx/MS +spic/DGM +spice/SM +spicebush/M +spicily +spiciness/SM +spicule/MS +spicy/PTR +spider/SM +spiderweb/S +spiderwort/M +spidery/TR +spiel/GDMS +spier/M +spiffy/TDRSG +spigot/MS +spike/GMDSR +spiker/M +spikiness/SM +spiky/PTR +spill/RDSG +spillage/SM +spillover/SM +spillway/SM +spin/S +spinach/MS +spinal/YS +spindle/JGMDRS +spindly/RT +spine/MS +spineless/YP +spinelessness/M +spinet/SM +spininess/M +spinnability/M +spinnaker/SM +spinner/SM +spinneret/MS +spinning/SM +spinster/MS +spinsterhood/SM +spinsterish +spiny/PRT +spiracle/SM +spiraea's +spiral/YDSG +spire's +spire/AIDSGF +spirea/MS +spirit/GMDS +spirited/PY +spiritedness/M +spiritless +spirits/I +spiritual/SYP +spiritualism/SM +spiritualist/SM +spiritualistic +spirituality/SM +spirituous +spirochete/SM +spiry/TR +spit/SGD +spitball/SM +spite's/A +spite/CSDAG +spiteful/PY +spitefuller +spitefullest +spitefulness/MS +spitfire/SM +spitted +spitting +spittle/SM +spittoon/SM +splash/GZDRS +splashdown/MS +splasher/M +splashily +splashiness/MS +splashy/RTP +splat/SM +splatted +splatter/DSG +splatting +splay/SDG +splayfeet +splayfoot/MD +spleen/SM +splendid/YRPT +splendidness/M +splendor/SM +splendorous +splenetic/S +splice/RSDGZJ +splicer/M +spline/MSD +splint/SGZMDR +splinter/GMD +splintery +split/SM +splits/M +splittable +splitter/MS +splitting/S +splodge/SM +splotch/MSDG +splotchy/RT +splurge/GMDS +splutter/RDSG +splutterer/M +spoil/CSZGDR +spoilables +spoilage/SM +spoiled/U +spoiler/MC +spoilsport/SM +spoke/DSG +spoken/U +spokeshave/MS +spokesman/M +spokesmen +spokespeople +spokesperson/S +spokeswoman/M +spokeswomen +spoliation/MCS +sponge/GMZRSD +spongecake +sponger/M +sponginess/S +spongy/TRP +sponsor/DGMS +sponsorship/S +spontaneity/SM +spontaneous/PY +spontaneousness/M +spoof/SMDG +spook/SMDG +spookiness/MS +spooky/PRT +spool/SRDMGZ +spoon/GSMD +spoonbill/SM +spoonerism/SM +spoonful/MS +spoor/GSMD +sporadic/Y +sporadically +spore/DSGM +sporran/MS +sport/VGSRDM +sportiness/SM +sporting/Y +sportive/PY +sportiveness/M +sportscast/RSGZM +sportsman/MY +sportsmanlike/U +sportsmanship/MS +sportsmen +sportswear/M +sportswoman/M +sportswomen +sportswriter/S +sporty/PRT +spot/MSC +spotless/YP +spotlessness/MS +spotlight/GDMS +spotlit +spotted/U +spotter/MS +spottily +spottiness/SM +spotting/M +spotty/RTP +spousal/MS +spouse/GMSD +spout/SGRD +spouter/M +sprain/SGD +sprang/S +sprat/SM +sprawl/GSD +spray/GZSRDM +sprayed/UA +sprayer/M +sprays/A +spread/RSJGZB +spreadeagled +spreader/M +spreadsheet/S +spree/MDS +spreeing +sprig/MS +sprigged +sprigging +sprightliness/MS +sprightly/PRT +spring/SGZR +springboard/MS +springbok/MS +springeing +springer/M +springily +springiness/SM +springing/M +springlike +springtime/MS +springy/TRP +sprinkle/DRSJZG +sprinkler/DM +sprinkling/M +sprint/SGZMDR +sprite/SM +spritz/GZDSR +sprocket/DMGS +sprocketed/U +sprout/GSD +spruce/GMTYRSDP +spruceness/SM +sprue/M +sprung/U +spry/TRY +spryness/S +spud/MS +spudded +spudding +spume/DSGM +spumone's +spumoni/S +spumy/TR +spun +spunk/GSMD +spunky/SRT +spur/MS +spurge/MS +spurious/PY +spuriousness/SM +spurn/RDSG +spurred +spurring +spurt/SGD +sputa +sputnik/MS +sputter/DRGS +sputum/M +spy/DRSGM +spyglass/MS +sq +sqq +sqrt +squab/SM +squabbed +squabber +squabbest +squabbing +squabble/ZGDRS +squabbler/M +squad/SM +squadded +squadding +squadron/MDGS +squalid/PRYT +squalidness/SM +squall/GMRDS +squaller/M +squally/RT +squalor/SM +squamous/Y +squander/GSRD +square/GMTYRSDP +squareness/SM +squarer/M +squarish +squash/GSRD +squashiness/M +squashy/RTP +squat/SPY +squatness/MS +squatted +squatter/SMDG +squattest +squatting +squaw/SM +squawk/GRDMZS +squawker/M +squeak/RDMGZS +squeaker/M +squeakily +squeakiness/S +squeaky/RPT +squeal/MRDSGZ +squealer/M +squeamish/YP +squeamishness/SM +squeegee/DSM +squeegeeing +squeeze/GZSRDB +squeezer/M +squelch/GDRS +squelcher/M +squelchy/RT +squib/SM +squibbed +squibbing +squid/SM +squidded +squidding +squiggle/MGDS +squiggly/RT +squint/GTSRD +squinter/M +squinting/Y +squire/SDGM +squirehood +squirm/SGD +squirmy/TR +squirrel/SGYDM +squirt/GSRD +squirter/M +squish/GSD +squishy/RTP +ssh +st/GBJ +stab/YS +stabbed +stabber/S +stabbing/S +stability/ISM +stabilizability +stabilization's +stabilization/CS +stabilize/CGSD +stabilizer/MS +stable's/F +stable/RSDGMTP +stableman/M +stablemate +stablemen +stableness/UM +stabler/U +stables/F +stablest/U +stabling/M +stably/U +staccato/S +stack's +stack/USDG +stackable +stacker/M +stadia's +stadias +stadium/MS +staff's +staff/ADSG +staffer/MS +staffroom +stag/DRMJSGZ +stage/SM +stagecoach/MS +stagecraft/MS +stagehand/MS +stager/M +stagestruck +stagflation/SM +stagged +stagger/GSJDR +staggerer/M +staggering/Y +staggers/M +stagging +staginess/M +staging/M +stagnancy/SM +stagnant/Y +stagnate/NGDSX +stagnation/M +stagy/PTR +staid/YRTP +staidness/MS +stain/SGRD +stained/U +stainer/M +stainless/YS +stair/MS +staircase/SM +stairway/SM +stairwell/MS +stake/DSGM +stakeholder/S +stakeout/SM +stalactite/SM +stalag/M +stalagmite/SM +stale/PGYTDSR +stalemate/SDMG +staleness/MS +stalk/MRDSGZJ +stalker/M +stall/DMSJG +stalled/I +stallholders +stallion/SM +stalls/I +stalwart/PYS +stalwartness/M +stamen/MS +stamina/SM +staminate +stammer/DRSZG +stammerer/M +stammering/Y +stamp/RDSGZJ +stamped/U +stampede/MGDRS +stampeder/M +stamper/M +stance/MIS +stanch/GDRST +stancher/M +stanchion/SGMD +stand/SJGZR +standalone +standard/YMS +standardization/AMS +standardize/GZDSR +standardized/U +standardizer/M +standardizes/A +standby +standbys +standee/MS +standing/M +standoff/SM +standoffish +standout/MS +standpipe/MS +standpoint/SM +standstill/SM +stank/S +stannic +stannous +stanza/MS +staph/M +staphs +staphylococcal +staphylococci +staphylococcus/M +staple/ZRSDGM +stapled/U +stapler/M +star/DRMGZS +starboard/SDMG +starch/MDSG +starchily +starchiness/MS +starchy/TRP +stardom/MS +stardust/MS +stare/S +starfish/SM +stargaze/ZGDRS +staring/U +stark/SPGTYRD +starkness/MS +starless +starlet/MS +starlight/MS +starling/MS +starlit +starred +starring +starry/TR +starship +starstruck +start/ASGDR +starter/MS +startle/GDS +startling/PY +startup/SM +starvation/MS +starve/RSDG +starveling/M +starver/M +stash/GSD +stasis/M +stat/DRSGV +state's/K +state/IGASD +statecraft/MS +stated/U +statehood/MS +statehouse/S +stateless/P +statelessness/MS +stateliness/MS +stately/PRT +statement/MSA +stater/M +stateroom/SM +states/K +stateside +statesman/MY +statesmanlike +statesmanship/SM +statesmen +stateswoman +stateswomen +statewide +static/S +statical/Y +statics/M +station/SZGMDR +stationarity +stationary/S +stationer/M +stationery/MS +stationmaster/M +statistic/MS +statistical/Y +statistician/MS +stator/SM +statuary/SM +statue/MSD +statuesque/YP +statuette/MS +stature/MS +status/SM +statute/SM +statutorily +statutory/P +staunch/PDRSYTG +staunchness/S +stave/DGM +stay/DRGZS +stayer/M +std +stdio +stead/SGDM +steadfast/PY +steadfastness/MS +steadily/U +steadiness's +steadiness/US +steading/M +steady/DRSUTGP +steak/SM +steakhouse/SM +steal/SRHG +stealer/M +stealing/M +stealth/M +stealthily +stealthiness/MS +stealths +stealthy/PTR +steam/SGZRDMJ +steamboat/MS +steamer/MDG +steamfitter/S +steamfitting/S +steamily +steaminess/SM +steamroll/GZRDS +steamroller/DMG +steamship/SM +steamy/RSTP +steed/SM +steel/SDMGZ +steeliness/SM +steelmaker/M +steelwork/ZSMR +steelworker/M +steely/TPRS +steelyard/MS +steep/SYRNDPGTX +steepen/GD +steeper/M +steeple/MS +steeplebush/M +steeplechase/GMSD +steeplejack/MS +steepness/S +steer/SGBRDJ +steerage/MS +steerer/M +steersman/M +steersmen +steeves +stegosauri +stegosaurus/S +stein/SGZMRD +stellar +stellated +stem/MS +stemless +stemmed/U +stemming +stemware/MS +stench/GMDS +stencil/GDRMSZ +stenciler/M +stencillings +steno/SM +stenographer/SM +stenographic +stenography/SM +stenotype/M +stentorian +step/MIS +stepbrother/MS +stepchild/M +stepchildren +stepdaughter/MS +stepfather/SM +stepladder/SM +stepmother/SM +stepparent/SM +steppe/RSDGMZ +stepper/M +steppingstone/S +stepsister/SM +stepson/SM +stepwise +stereo/GSDM +stereographic +stereography/M +stereophonic +stereoscope/MS +stereoscopic +stereoscopically +stereoscopy/M +stereotype/GMZDRS +stereotypic +stereotypical/Y +sterile +sterility/SM +sterilization/SM +sterilize/RSDGZ +sterilized/U +sterilizes/A +sterling/MPYS +sterlingness/M +stern/SYRDPGT +sternal +sternness/S +sternum/SM +steroid/MS +steroidal +stertorous +stet/MS +stethoscope/SM +stetson/MS +stetted +stetting +stevedore/GMSD +stew/GDMS +steward/DMSG +stewardess/SM +stewardship/MS +stick/MRDSGZ +sticker/M +stickily +stickiness/SM +stickle/GZDR +stickleback/MS +stickler/M +stickpin/SM +stickup/SM +sticky/GPTDRS +stiff/GTXPSYRND +stiffen/JZRDG +stiffness/MS +stifle/GJRSD +stifler/M +stifling/Y +stigma/MS +stigmata +stigmatic/S +stigmatization's +stigmatization/C +stigmatizations +stigmatize/DSG +stigmatized/U +stile/GMDS +stiletto/MDSG +still/RDIGS +stillbirth/M +stillbirths +stillborn/S +stiller/MI +stillest +stillness/MS +stilt/GDMS +stilted/PY +stimulant/MS +stimulate/SDVGNX +stimulated/U +stimulation/M +stimulative/S +stimulator/M +stimulatory +stimuli/M +stimulus/MS +sting/GZR +stinger/M +stingily +stinginess/MS +stinging/Y +stingray/MS +stingy/RTP +stink/GZRJS +stinkbug/S +stinker/M +stinking/Y +stinkpot/M +stinky/RT +stint/JGRDMS +stinter/M +stinting/U +stipend/MS +stipendiary +stipple/JDRSG +stippler/M +stipulate/XNGSD +stipulation/M +stir/S +stirred/U +stirrer/SM +stirring/YS +stirrup/SM +stitch's +stitch/ASDG +stitcher/M +stitchery/S +stitching/MS +stoat/SM +stochastic +stochastically +stochasticity +stock's +stock/SGAD +stockade/SDMG +stockbreeder/SM +stockbroker/MS +stockbroking/S +stocker/SM +stockholder/SM +stockily +stockiness/SM +stockinet's +stockinette/S +stocking/MDS +stockist/MS +stockpile/GRSD +stockpiler/M +stockpot/MS +stockroom/MS +stocktaking/MS +stocky/PRT +stockyard/SM +stodge/M +stodgily +stodginess/S +stodgy/TRP +stogy/SM +stoic/MS +stoical/Y +stoichiometric +stoichiometry/M +stoicism/SM +stoke/DSRGZ +stoker/M +stokes/M +stole/MDS +stolen +stolid/PTYR +stolidity/S +stolidness/S +stolon/SM +stomach/RSDMZG +stomachache/MS +stomacher/M +stomachs +stomp/DSG +stone/DSRGM +stonecutter/SM +stoneless +stonemason/MS +stoner/M +stonewall/GDS +stoneware/MS +stonewashed +stonework/SM +stonewort/M +stonily +stoniness/MS +stony/TPR +stood +stooge/SDGM +stool/SDMG +stoop/SDG +stop's +stop/US +stopcock/MS +stopgap/SM +stoplight/SM +stopover/MS +stoppable/U +stoppage/MS +stopped/U +stopper/GMDS +stopping/M +stopple/GDSM +stops/M +stopwatch/SM +storage/SM +store's +store/ADSRG +storefront/SM +storehouse/MS +storekeep/ZR +storekeeper/M +storeroom/SM +stork/SM +storm/SRDMGZ +stormbound +stormer/M +stormily +storminess/S +stormtroopers +stormy/PTR +story/GSDM +storyboard/MDSG +storybook/MS +storyline +storyteller/SM +storytelling/MS +stoup/SM +stout/STYRNP +stouten/DG +stouthearted +stoutness/MS +stove/DSRGM +stovepipe/SM +stover/M +stow/GDS +stowage/SM +stowaway/MS +straddle/ZDRSG +straddler/M +strafe/GRSD +strafer/M +straggle/GDRSZ +straggly/RT +straight/RNDYSTXGP +straightaway/S +straightedge/MS +straighten/ZGDR +straightener/M +straightforward/SYP +straightforwardness/MS +straightjacket's +straightness/MS +straightway/S +strain/ASGZDR +strained/UF +strainer/MA +straining/F +strains/F +strait/XTPSMGYDNR +straiten/DG +straitjacket/GDMS +straitlaced +straitness/M +strand/SDRG +stranded/P +strange/PYZTR +strangeness/SM +stranger/GMD +strangle/JDRSZG +stranglehold/MS +strangles/M +strangulate/NGSDX +strangulation/M +strap's +strap/US +strapless/S +strapped/U +strapping/S +strata/MS +stratagem/SM +strategic/S +strategical/Y +strategics/M +strategist/SM +strategy/SM +strati +stratification/M +stratified/U +stratify/NSDGX +stratigraphic +stratigraphical +stratigraphy/M +stratosphere/SM +stratospheric +stratospherically +stratum/M +stratus/M +straw/SMDG +strawberry/SM +strawflower/SM +stray/GSRDM +strayer/M +streak/DRMSGZ +streaker/M +streaky/TR +stream/GZSMDR +streamed/U +streamer/M +streaming/M +streamline/SRDGM +street/SMZ +streetcar/MS +streetlight/SM +streetwalker/MS +streetwise +strength/NMX +strengthen/AGDS +strengthener/MS +strengths +strenuous/PY +strenuousness/SM +strep/MS +streptococcal +streptococci +streptococcus/M +streptomycin/SM +stress/DSMG +stressed/U +stressful/YP +stretch/BDRSZG +stretchability/M +stretchable/U +stretcher/DMG +stretchy/TRP +strew/GDHS +strewn +stria/M +striae +striate/DSXGN +striated/U +striation/M +stricken +strict/AF +stricter +strictest +strictly +strictness/S +stricture/SM +stridden +stride/RSGM +stridency/S +strident/Y +strider/M +strife/SM +strike/RSGZJ +strikebreak/ZGR +strikebreaker/M +strikebreaking/M +strikeout/S +striker/M +striking/Y +string's +string/SAG +stringed +stringency/S +stringent/Y +stringer/MS +stringiness/SM +stringing/M +stringy/RTP +strip/GRDMS +stripe/SM +striper/M +stripling/M +stripped/U +stripper/MS +stripping +striptease/SRDGZM +stripteaser/M +stripy/RT +strive/JRSG +striven +striver/M +strobe/SDGM +stroboscope/SM +stroboscopic +strode +stroke/ZRSDGM +stroking/M +stroll/GZSDR +stroller/M +strong/YRT +strongbow +strongbox/MS +stronghold/SM +strongish +strongman/M +strongmen +strongroom/MS +strontium/SM +strop/SM +strophe/MS +strophic +stropped +stropping +strove +struck +structural/Y +structuralism/M +structuralist/SM +structure/SRDMG +structured/AU +structureless +structures/A +structuring/A +strudel/MS +struggle/GDRS +struggler/M +strum/S +strummed +strumming +strumpet/GSDM +strung/UA +strut/S +strutted +strutter/M +strutting +strychnine/MS +stub/MS +stubbed/M +stubbing +stubble/SM +stubbly/RT +stubborn/SGTYRDP +stubbornness/SM +stubby/SRT +stucco/GDM +stuccoes +stuck/U +stud/MS +studbook/SM +studded +studding/SM +student/SM +studentship/MS +studied/PY +studiedness/M +studier/SM +studio/MS +studious/PY +studiousness/SM +study/AGDS +stuff/JGSRD +stuffily +stuffiness/SM +stuffing/M +stuffy/TRP +stultify/NXGSD +stumble/GZDSR +stumbling/Y +stump/RDMSG +stumpage/M +stumper/M +stumpy/RT +stun/S +stung +stunk +stunned +stunner/M +stunning/Y +stunt/GSDM +stunted/P +stupefaction/SM +stupefy/DSG +stupendous/PY +stupendousness/M +stupid/PTYRS +stupidity/SM +stupidness/M +stupor/MS +sturdily +sturdiness/SM +sturdy/SRPT +sturgeon/SM +stutter/DRSZG +sty/DSGM +style/GZMDSR +styled/A +styles/A +styli +styling/A +stylish/PY +stylishness/S +stylist/MS +stylistic/S +stylistically +stylites +stylization/MS +stylize/DSG +stylos +stylus/SM +stymie/SD +stymieing +stymy's +styptic/S +styrene/MS +suable +suasion/EMS +suave/PRYT +suaveness/S +suavity/SM +sub/MS +subaltern/SM +subarctic/S +subareas +subassembly/M +subatomic/S +subbasement/SM +subbed +subbing +subbranch/S +subcaste/M +subcategorizing +subcategory/SM +subchain +subclass/MS +subclassifications +subclauses +subcommand/S +subcommittee/SM +subcompact/S +subcomponent/MS +subcomputation/MS +subconcept +subconscious/PSY +subconsciousness/SM +subconstituent +subcontinent/MS +subcontinental +subcontract/SMDG +subcontractor/SM +subcultural +subculture/GMDS +subcutaneous/Y +subdirectory/S +subdistrict/M +subdivide/SRDG +subdivision/SM +subdue/GRSD +subdued/Y +subduer/M +subexpression/MS +subfamily/SM +subfield/MS +subfile/SM +subfreezing +subgoal/SM +subgraph +subgraphs +subgroup/SGM +subharmonic/S +subhead/MGJS +subheading/M +subhuman/S +subindex/M +subinterval/MS +subj +subject/GVDMS +subjection/SM +subjective/PSY +subjectiveness/M +subjectivist/S +subjectivity/SM +subjoin/DSG +subjugate/NGXSD +subjugation/M +subjunctive/S +sublayer +sublease/DSMG +sublet/S +subletting +sublimate/GNSDX +sublimation/M +sublime/GRSDTYP +sublimeness/M +sublimer/M +subliminal/Y +sublimity/SM +sublist/SM +subliterary +sublunary +submachine +submarginal +submarine/MZGSRD +submariner/M +submerge/DSG +submergence/SM +submerse/XNGDS +submersible/S +submersion/M +submicroscopic +submission/SAM +submissive/PY +submissiveness/MS +submit/SA +submittable +submittal +submitted/A +submitter/S +submitting/A +submode/S +submodule/MS +subnational +subnet/SM +subnetwork/SM +subnormal/SY +suboptimal +suborbital +suborder/MS +subordinate/YVNGXPSD +subordinately/I +subordinates/I +subordination/IMS +subordinator +suborn/GSD +subornation/SM +subpage +subparagraph/M +subpart/MS +subplot/MS +subpoena/GSDM +subpopulation/MS +subproblem/SM +subprocess/SM +subprofessional/S +subprogram/SM +subproject +subproof/SM +subquestion/MS +subrange/SM +subregion/MS +subregional/Y +subrogation/M +subroutine/SM +subsample/MS +subschema/MS +subscribe/ASDG +subscriber/SM +subscript/SGD +subscripted/U +subscription/MS +subsection/SM +subsegment/SM +subsentence +subsequence/MS +subsequent/SYP +subservience/SM +subservient/SY +subset/MS +subside/SDG +subsidence/MS +subsidiarity +subsidiary/MS +subsidization/MS +subsidize/ZRSDG +subsidized/U +subsidizer/M +subsidy/MS +subsist/SGD +subsistence/MS +subsistent +subsocietal +subsoil/DRMSG +subsonic +subspace/MS +subspecies/M +substance/MS +substandard +substantial/PYS +substantially/IU +substantialness/M +substantiate/VGNSDX +substantiated/U +substantiation/MFS +substantive/PSYM +substantiveness/M +substantivity +substation/MS +substerilization +substitutability +substitute/NGVBXDRS +substituted/U +substitution/M +substitutionary +substitutive/Y +substrata +substrate/MS +substratum/M +substring/S +substructure/SM +subsume/SDG +subsurface/S +subsystem/MS +subtable/S +subtask/SM +subteen/SM +subtenancy/MS +subtenant/SM +subtend/DS +subterfuge/SM +subterranean/SY +subtest +subtext/SM +subtitle/DSMG +subtle/RPT +subtleness/M +subtlety/MS +subtly/U +subtopic/SM +subtotal/GSDM +subtract/SRDZVG +subtracter/M +subtraction/MS +subtrahend/SM +subtree/SM +subtropic/S +subtropical +subtype/MS +subunit/SM +suburb/MS +suburban/S +suburbanite/MS +suburbanization/MS +suburbanized +suburbanizing +suburbia/SM +subvention/MS +subversion/SM +subversive/SPY +subversiveness/MS +subvert/SGDR +subverter/M +subway/MDGS +subzero +succeed/GDRS +succeeder/M +success/MSV +successful/UY +successfulness/M +succession/SM +successive/YP +successiveness/M +successor/MS +successorship +succinct/RYPT +succinctness/SM +succor/SGZRDM +succored/U +succorer/M +succotash/SM +succubus/M +succulence/SM +succulency/MS +succulent/S +succumb/SDG +such +suchlike +suck/GZSDRB +sucker/DMG +suckle/SDJG +suckling/M +sucrose/MS +suction/SMGD +sud/S +sudden/YPS +suddenness/SM +suds/DSRG +sudsy/TR +sue/ZGDRS +sued/DG +suede/SM +suer/M +suet/MS +suety +suffer/SJRDGZ +sufferance/SM +sufferer/M +suffering/M +suffice/GRSD +sufficiency/SIM +sufficient/IY +suffix/GMRSD +suffixation/S +suffixed/U +suffocate/XSDVGN +suffocating/Y +suffragan/S +suffrage/MS +suffragette/MS +suffragist/SM +suffuse/VNGSDX +suffusion/M +sugar/SJGMD +sugarcane/S +sugarcoat/GDS +sugarless +sugarplum/MS +sugary/TR +suggest/DRZGVS +suggester/M +suggestibility/SM +suggestible +suggestion/MS +suggestive/PY +suggestiveness/MS +sugillate +suicidal/Y +suicide/GSDM +suit/MDGZBJS +suitability/SU +suitable/P +suitableness/S +suitably/U +suitcase/MS +suite/SM +suited/U +suiting/M +suitor/SM +sukiyaki/SM +sulfa/S +sulfaquinoxaline +sulfate/MSDG +sulfide/S +sulfite/M +sulfonamide/SM +sulfur/DMSG +sulfuric +sulfurous/YP +sulfurousness/M +sulk/GDS +sulkily +sulkiness/S +sulky/RSPT +sullen/TYRP +sullenness/MS +sullied/U +sully/GSD +sulphate/SM +sulphide/MS +sulphuric +sultan/SM +sultana/SM +sultanate/MS +sultrily +sultriness/SM +sultry/PRT +sum/MRS +sumac/SM +sumach's +sumer/F +summability/M +summable +summand/MS +summarily +summarization/MS +summarize/GSRDZ +summarized/U +summarizer/M +summary/MS +summation/FMS +summed +summer/SGDM +summerhouse/MS +summertime/MS +summery/TR +summing +summit/GMDS +summitry/MS +summon/JSRDGZ +summoner/M +summons/MSDG +sumo/SM +sump/SM +sumptuous/PY +sumptuousness/SM +sun/MS +sunbaked +sunbath/ZRSDG +sunbathe +sunbather/M +sunbathing/M +sunbaths +sunbeam/MS +sunblock/S +sunbonnet/MS +sunburn/GSMD +sunburst/MS +suncream +sundae/MS +sunder/SDG +sundial/MS +sundown/MRDSZG +sundowner/M +sundris +sundry/S +sunfish/SM +sunflower/MS +sung/U +sunglass/MS +sunk/SN +sunlamp/S +sunless +sunlight/MS +sunlit +sunned +sunniness/SM +sunning +sunny/RSTP +sunrise/GMS +sunroof/S +sunscreen/S +sunset/MS +sunsetting +sunshade/MS +sunshine/MS +sunshiny +sunspot/SM +sunstroke/MS +suntan/SM +suntanned +suntanning +sunup/MS +sup/RSZ +super/DG +superabundance/MS +superabundant +superannuate/GNXSD +superannuation/M +superb/YRPT +superbness/M +supercargo/M +supercargoes +supercharge/SRDZG +supercharger/M +supercilious/PY +superciliousness/SM +supercity/S +superclass/M +supercomputer/MS +supercomputing +superconcept +superconducting +superconductivity/SM +superconductor/SM +supercooled +supercooling +supercritical +superdense +superego/SM +supererogation/MS +supererogatory +superficial/SPY +superficiality/S +superfine +superfix/M +superfluity/MS +superfluous/YP +superfluousness/S +superheat/D +superhero/SM +superheroes +superhighway/MS +superhuman/YP +superhumanness/M +superimpose/SDG +superimposition/MS +superintend/GSD +superintendence/S +superintendency/SM +superintendent/SM +superior/SMY +superiority/MS +superlative/PYS +superlativeness/M +superlunary +supermachine +superman/M +supermarket/SM +supermen +supermodel +supermom/S +supernal +supernatant +supernatural/SPY +supernaturalism/M +supernaturalness/M +supernormal/Y +supernova/MS +supernovae +supernumerary/S +superordinate +superpose/BSDG +superposition/MS +superpower/MS +superpredicate +supersaturate/XNGDS +supersaturation/M +superscribe/GSD +superscript/DGS +superscription/SM +supersede/SRDG +superseder/M +supersensitive/P +supersensitiveness/M +superset/MS +supersonic/S +supersonically +supersonics/M +superstar/SM +superstition/SM +superstitious/YP +superstore/S +superstructural +superstructure/SM +supertanker/SM +supertitle/MSDG +superuser/MS +supervene/GSD +supervention/S +supervise/SDGNX +supervised/U +supervision/M +supervisor/SM +supervisory +superwoman/M +superwomen +supine/PSY +supineness/M +supp/YDRGZ +supper/DMG +suppl/RDGT +supplant/SGRD +supplanter/M +supple/SPLY +supplement/SMDRG +supplemental/S +supplementary/S +supplementation/S +supplementer/M +suppleness/SM +suppliant/S +supplicant/MS +supplicate/NGXSD +supplication/M +supplier/AM +supply/MAZGSRD +support/ZGVSBDR +supportability/M +supportable/UI +supported/U +supporter/M +supporting/Y +supportive/Y +suppose/SRDBJG +supposed/Y +supposition/MS +suppository/MS +suppress/VGSD +suppressant/S +suppressed/U +suppressible/I +suppression/SM +suppressive/P +suppressor/S +suppurate/NGXSD +suppuration/M +supra +supranational +supranationalism/M +suprasegmental +supremacist/SM +supremacy/SM +supremal +supreme/PSRTY +supremeness/M +supremo/M +supt +surcease/DSMG +surcharge/MGSD +surcingle/MGSD +surd/M +sure/PU +sured/I +surefire +surefooted +surely +sureness's/U +sureness/MS +surer/I +surest +surety/SM +surf/SJDRGMZ +surface/GSRDPZM +surfaced/UA +surfacer/AMS +surfaces/A +surfacing/A +surfactant/SM +surfboard/MDSG +surfeit/SDRMG +surfer/M +surfing/M +surge/GYMDS +surged/A +surgeon/MS +surgery/MS +surges/A +surgical/Y +surliness/SM +surly/TPR +surmise/SRDG +surmiser/M +surmount/DBSG +surmountable/IU +surname/GSDM +surpass/GDS +surpassed/U +surpassing/Y +surplice/SM +surplus/MS +surplussed +surplussing +surprise/MGDRSJ +surprised/U +surpriser/M +surprising/YU +surreal/S +surrealism/MS +surrealist/S +surrealistic +surrealistically +surreality +surrender/DRSG +surrenderer/M +surreptitious/PY +surreptitiousness/S +surrey/SM +surrogacy/S +surrogate/SDMNG +surrogation/M +surround/JGSD +surrounding/M +surtax/SDGM +surveillance/SM +surveillant +survey/JDSG +surveyed/A +surveying/M +surveyor/MS +surveys/A +survivability/M +survivable/U +survival/MS +survivalist/S +survive/SRDBG +survivor/MS +survivorship/M +susceptibilities +susceptibility/IM +susceptible/I +sushi/SM +suspect/GSDR +suspected/U +suspecter/M +suspecting/U +suspend/DRZGS +suspended/UA +suspender/M +suspense/MXNVS +suspenseful +suspension/AM +suspensive/Y +suspensor/M +suspicion/GSMD +suspicious/YP +suspiciousness/M +sustain/DRGLBS +sustainability +sustainable/U +sustainer/M +sustainment/M +sustenance/MS +sutler/MS +suture/GMSD +suzerain/SM +suzerainty/MS +svelte/RPTY +swab/MS +swabbed +swabbing +swabby/S +swaddle/SDG +swag/GMS +swagged +swagger/GSDR +swagging +swain/SM +swallow/GDRS +swallower/M +swallowtail/SM +swam +swami/SM +swamp/SRDMG +swamper/M +swampland/MS +swampy/RPT +swan/MS +swank/RDSGT +swankily +swankiness/MS +swanky/PTRS +swanlike +swanned +swanning +swap/S +swappable/U +swapped +swapper/SM +swapping +sward/MSGD +swarm/GSRDM +swarmer/M +swart/P +swarthiness/M +swarthy/RTP +swash/GSRD +swashbuckler/SM +swashbuckling/S +swastika/SM +swat/S +swatch/MS +swath/SRDMGJ +swathe +swather/M +swaths +swatted +swatter/MDSG +swatting +sway/DRGS +swayback/SD +swayer/M +swear/SGZR +swearer/M +swearword/SM +sweat/SGZRM +sweatband/MS +sweater/M +sweatily +sweatiness/M +sweatpants +sweatshirt/S +sweatshop/MS +sweaty/TRP +swede/SM +sweep/SBRJGZ +sweeper/M +sweeping/PY +sweepingness/M +sweeps/M +sweepstake's +sweepstakes +sweet/TXSYRNPG +sweetbread/SM +sweetbrier/SM +sweetcorn +sweeten/ZDRGJ +sweetened/U +sweetener/M +sweetening/M +sweetheart/MS +sweetie/MS +sweeting/M +sweetish/Y +sweetmeat/MS +sweetness/MS +sweetshop +swell/SJRDGT +swellhead/DS +swelling/M +swelter/DJGS +sweltering/Y +swept +sweptback +swerve/GSD +swerving/U +swift/GTYRDPS +swifter/M +swiftness/MS +swig/SM +swigged +swigging +swill/SDG +swim/S +swimmer/MS +swimming/MYS +swimsuit/MS +swindle/GZRSD +swindler/M +swine/SM +swineherd/MS +swing/SGRZJB +swingeing +swinger/M +swinging/Y +swingy/R +swinish/PY +swinishness/M +swipe/DSG +swirl/SGRD +swirling/Y +swirly/TR +swish/GSRD +swishy/R +swiss +switch/GBZMRSDJ +switchback/GDMS +switchblade/SM +switchboard/MS +switcher/M +switchgear +switchman/M +switchmen/M +switchover/M +swivel/GMDS +swizzle/RDGM +swob's +swollen +swoon/GSRD +swooning/Y +swoop/RDSG +swoosh/GSD +swop's +sword/DMSG +swordfish/SM +swordplay/RMS +swordplayer/M +swordsman/M +swordsmanship/SM +swordsmen +swordtail/M +swore +sworn +swot/S +swum +swung +sybarite/MS +sybaritic +sycamore/SM +sycophancy/S +sycophant/SYM +sycophantic +sycophantically +syllabi's +syllabic/S +syllabicate/GNDSX +syllabication/M +syllabicity +syllabification/M +syllabify/GSDXN +syllable/SDMG +syllabub/M +syllabus/MS +syllabusss +syllogism/MS +syllogistic +sylph/M +sylphic +sylphlike +sylphs +sylvan/S +symbiont/M +symbioses +symbiosis/M +symbiotic +symbol/GMDS +symbolic/SM +symbolical/Y +symbolics/M +symbolism/MS +symbolist/MS +symbolization/MAS +symbolize/GZRSD +symbolized/U +symbolizes/A +symmetric +symmetrical/PY +symmetrically/U +symmetricalness/M +symmetrization/M +symmetrizing +symmetry/MS +sympathetic/S +sympathetically/U +sympathize/SRDJGZ +sympathized/U +sympathizer/M +sympathizing/MYUS +sympathy/MS +symphonic +symphonists +symphony/MS +symposium/MS +symptom/MS +symptomatic +symptomatically +symptomatology/M +syn +synagogal +synagogue/SM +synapse/SDGM +synaptic +sync/SGD +synchronism/M +synchronization's +synchronization/SA +synchronize/AGCDS +synchronized/U +synchronizer/MS +synchronous/YP +synchronousness/M +synchrony +synchrotron/M +syncopate/VNGXSD +syncopation/M +syncope/MS +syndic/SM +syndicalist +syndicate/XSDGNM +syndrome/SM +synergism/SM +synergistic +synergy/MS +synfuel/S +synod/SM +synonym/SM +synonymic +synonymous/Y +synonymy/MS +synopses +synopsis/M +synopsized +synopsizes +synopsizing +synoptic/S +syntactic/SY +syntactical/Y +syntactics/M +syntax/MS +syntheses +synthesis/M +synthesize/GZSRD +synthesized/U +synthesizer/M +synthesizes/A +synthetic/S +synthetically +syphilis/MS +syphilitic/S +syphilized +syphilizing +syringe/GMSD +syrup/DMSG +syrupy +sys +system/MS +systematic/SP +systematical/Y +systematics/M +systematization/SM +systematize/ZDRSG +systematized/U +systematizer/M +systematizing/U +systemic/S +systemically +systemization/SM +systole/MS +systolic +s�ance/SM +t/XTJBG +tab/SM +tabbed +tabbing +tabbouleh +tabboulehs +tabby/GSD +tabernacle/SDGM +tabla/MS +table/GMSD +tableau/M +tableaux +tablecloth/M +tablecloths +tableland/SM +tablespoon/SM +tablespoonful/MS +tablet/MDGS +tabletop/MS +tableware/SM +tabling/M +tabloid/MS +taboo/GSMD +tabor/MDGS +tabula +tabular/Y +tabulate/XNGDS +tabulation/M +tabulator/MS +tachometer/SM +tachometry +tachycardia/MS +tachyon/SM +tacit/YP +tacitness/MS +taciturn/Y +taciturnity/MS +tack/GZRDMS +tacker/M +tackiness/MS +tackle/RSDMZG +tackler/M +tackling/M +tacky/RSTP +taco/MS +tact/FSM +tactful/YP +tactfulness/S +tactic/SM +tactical/Y +tactician/MS +tactile/Y +tactility/S +tactless/PY +tactlessness/SM +tactual/Y +tad/SM +tadpole/MS +taffeta/MS +taffrail/SM +taffy/SM +tag/SM +tagged/U +tagger/S +tagging +taiga/MS +tail/CMRDGAS +tailback/MS +tailcoat/S +tailer/AM +tailgate/MGRSD +tailgater/M +tailing/MS +tailless/P +taillessness/M +taillight/MS +tailor/DMJSGB +tailpipe/SM +tailspin/MS +tailwind/SM +taint/DGS +tainted/U +take/RSHZGJ +takeaway/S +taken/A +takeoff/SM +takeout/S +takeover/SM +taker/M +takes/IA +taking/IA +talc/SM +talcked +talcking +talcum/S +tale/RSMN +talebearer/SM +talent/SMD +talented/M +talentless +taler/M +tali +talion/M +talisman/SM +talismanic +talk/GZSRD +talkative/YP +talkativeness/MS +talker/M +talkie/M +talky/RST +tall/TPR +tallboy/MS +tallish +tallness/MS +tallow/DMSG +tallowy +tally/GRSDZ +tallyho/DMSG +talon/SMD +talus/MS +tam/MDRSTZGB +tamable/M +tamale/SM +tamarack/SM +tamarind/MS +tambourine/MS +tame/SYP +tamed/U +tameness/S +tamp/SGZRD +tamper/ZGRD +tampered/U +tamperer/M +tampon/DMSG +tan/MS +tanager/MS +tanbark/SM +tandem/SM +tandoori/S +tang/GSYDM +tangelo/SM +tangency/M +tangent/SM +tangential/Y +tangerine/MS +tangibility/MIS +tangible/IPS +tangibleness's/I +tangibleness/SM +tangibly/I +tangle's +tangle/UDSG +tango/MDSG +tangy/RST +tank/GZSRDM +tankard/MS +tanker/M +tankful/MS +tanned/U +tanner/SM +tannery/MS +tannest +tannin/SM +tanning/SM +tansy/SM +tantalization/SM +tantalize/GZSRD +tantalized/U +tantalizing/YP +tantalizingly/S +tantalizingness/S +tantalum/MS +tantamount +tantra/S +tantrum/SM +tao/S +taoism +taoist/S +tap/MSDRJZG +tape/SM +taped/U +tapeline/S +taper/GRD +taperer/M +tapestry/GMSD +tapeworm/MS +tapioca/MS +tapir/MS +tapped/U +tapper/MS +tappet/MS +tapping/M +taproom/MS +taproot/SM +taps/M +tar/GSMD +tarantella/MS +tarantula/MS +tardily +tardiness/S +tardy/TPRS +tare/MS +target/GSMD +tariff/DMSG +tarmac/S +tarmacked +tarmacking +tarn/MS +tarnish/GDS +tarnished/U +taro/MS +tarot/MS +tarp/MS +tarpapered +tarpaulin/MS +tarpon/MS +tarragon/SM +tarred/M +tarring/M +tarry/TGRSD +tarsal/S +tarsi +tarsus/M +tart/PMYRDGTS +tartan/MS +tartar/SM +tartaric +tartness/MS +task/GSDM +taskmaster/SM +taskmistress/MS +tassel/MDGS +tassellings +taste's/E +taste/GZMJSRD +tasted/EU +tasteful/PEY +tastefulness/SME +tasteless/YP +tastelessness/SM +taster/M +tastes/E +tastily +tastiness/MS +tasting/E +tasty/RTP +tat/SRZ +tatami/MS +tater/M +tatted +tatter/GDS +tatterdemalion/SM +tattered/M +tatting/SM +tattle/RSDZG +tattler/M +tattletale/SM +tattoo/ZRDMGS +tattooer/M +tattooist/MS +tatty/R +tau/SM +taught/AU +taunt/ZGRDS +taunter/M +taunting/Y +taupe/SM +taut/PGTXYRDNS +tauten/GD +tautness/S +tautological/Y +tautologous +tautology/SM +tavern/RMS +taverner/M +tawdrily +tawdriness/SM +tawdry/SRTP +tawny/RSMPT +tax/ZGJMDRSB +taxable/S +taxably +taxation/MS +taxed/U +taxi/MDGS +taxicab/MS +taxidermist/SM +taxidermy/MS +taximeter/SM +taxing/Y +taxiway/MS +taxonomic +taxonomically +taxonomist/SM +taxonomy/SM +taxpayer/MS +taxpaying/M +tbs +tbsp +tea/MDGS +teabag/S +teacake/MS +teacart/M +teach/AGS +teachable/P +teacher/MS +teaching/SM +teacloth +teacup/MS +teacupful/MS +teahouse/SM +teak/SM +teakettle/SM +teakwood/M +teal/MS +tealeaves +team/MRDGS +teammate/MS +teamster/MS +teamwork/SM +teapot/MS +tear/RDMSG +tearaway +teardrop/MS +tearer/M +tearful/YP +tearfulness/M +teargas/S +teargassed +teargassing +tearjerker/S +tearoom/MS +teary/RT +teas/SRDGZ +tease/KS +teasel/DGSM +teaser/M +teashop/SM +teasing/Y +teaspoon/MS +teaspoonful/MS +teat/MDS +teatime/MS +tech/D +technetium/SM +technical/YSP +technicality/MS +technicalness/M +technician/MS +technique/SM +technocracy/MS +technocrat/S +technocratic +technological/Y +technologist/MS +technology/MS +technophobia +technophobic +techs +tectonic/S +tectonically +tectonics/M +teddy/SM +tedious/YP +tediousness/SM +tedium/MS +tee/DRSMH +teeing +teem/GSD +teeming/PY +teemingness/M +teen/SR +teenage/RZ +teenager/M +teeny/RT +teenybopper/SM +teepee's +teeshirt/S +teeter/GDS +teeth/RSDJMG +teethe +teether/M +teething/M +teethmarks +teetotal/SRDGZ +teetotaler/M +teetotalism/MS +tektite/SM +tel/SY +telecast/SRGZ +telecommunicate/NX +telecommunication/M +telecommute/SRDZGJ +telecoms +teleconference/GMJSD +telegenic +telegram/MS +telegrammed +telegramming +telegraph/MRDGZ +telegraphic +telegraphically +telegraphist/MS +telegraphs +telegraphy/MS +telekineses +telekinesis/M +telekinetic +telemarketer/S +telemarketing/S +telemeter/DMSG +telemetric +telemetry/MS +teleological/Y +teleology/M +telepathic +telepathically +telepathy/SM +telephone/SRDGMZ +telephonic +telephonist/SM +telephony/MS +telephoto/S +telephotography/MS +teleprinter/MS +teleprocessing/S +teleprompter +telescope/GSDM +telescopic +telescopically +teletext/S +telethon/MS +teletype/SM +teletypewriter/SM +televangelism/S +televangelist/S +televise/SDXNG +television/M +televisor/MS +televisual +telex/GSDM +tell/AGS +teller/SDMG +telling/YS +telltale/MS +tellurium/SM +telly/SM +telnet/S +telomeric +temblor/SM +temerity/MS +temp/SGZTMRD +temper's/E +temper/GRDM +tempera/SLM +temperament/SM +temperamental/Y +temperance/IMS +temperate/SDGPY +temperately/I +temperateness's/I +temperateness/SM +temperature/MS +tempered/UE +tempering/E +tempers/E +tempest/DMSG +tempestuous/PY +tempestuousness/SM +template's +template/FS +temple/SDM +tempo/MS +tempoes +temporal/YS +temporarily +temporariness/FM +temporarinesses +temporary/SFP +temporize/GJZRSD +temporizer/M +temporizing/YM +temporizings/U +tempt/FS +temptation/MS +tempted +tempter/S +tempting/YS +temptress/MS +tempura/SM +ten/MHB +tenabilities +tenability/UM +tenable/P +tenableness/M +tenably +tenacious/YP +tenaciousness/S +tenacity/S +tenancy/MS +tenant/MDSG +tenanted/U +tenantry/MS +tench/M +tend/ISFRDG +tended/UE +tendency/MS +tendentious/PY +tendentiousness/SM +tender/FS +tendered +tenderer +tenderest +tenderfoot/MS +tenderhearted/YP +tenderheartedness/MS +tendering +tenderize/SRDGZ +tenderizer/M +tenderloin/SM +tenderly +tenderness/SM +tending/E +tendinitis/S +tendon/MS +tendril/SM +tends/E +tenebrous +tenement/MS +tenet/SM +tenfold/S +tenner +tennis/SM +tenon/GSMD +tenor/MS +tenpin/SM +tens/SRDVGT +tense/IPYTNVR +tenseness's/I +tenseness/SM +tensile +tension's/I +tension/GMRDS +tensional/I +tensionless +tensions/E +tensity/IMS +tensor/MS +tensorial +tenspot +tent/FSIM +tentacle/MSD +tentative/SPY +tentativeness/S +tented/UF +tenter/M +tenterhook/MS +tenth/SY +tenths +tenting/F +tenuity/S +tenuous/YP +tenuousness/SM +tenure/SDM +tepee/MS +tepid/YP +tepidity/S +tepidness/S +tequila/SM +teratogenic +teratology/MS +terbium/SM +tercel/M +tercentenary/S +tercentennial/S +term/MYRDGS +termagant/SM +termcap +termer/M +terminable/CPI +terminableness/IMC +terminal/SYM +terminate/CXNV +terminated/U +terminates +terminating +termination/MC +terminative/YC +terminator/SM +termini +terminological/Y +terminology/MS +terminus/M +termite/SM +tern's +tern/GIDS +ternary/S +terpsichorean +terr/S +terrace/MGSD +terracing/M +terracotta +terrain/MS +terramycin +terrapin/MS +terrarium/MS +terrazzo/SM +terrestrial/YMS +terrible/P +terribleness/SM +terribly +terrier/M +terrific/Y +terrifically +terrify/GDS +terrifying/Y +terrine/M +territorial/SY +territoriality/M +territory/SM +terror/MS +terrorism/MS +terrorist/MS +terroristic +terrorize/RSDZG +terrorized/U +terrorizer/M +terry/ZMRS +terrycloth +terse/RTYP +terseness/SM +tertian +tertiary/S +tessellate/XDSNG +tessellation/M +tesseral +test's/AKF +test/RDBFZGSC +testability/M +testable/U +testament/SM +testamentary +testate/IS +testator/MS +testatrices +testatrix +testbed/S +testcard +tested/AKU +tester/MFCKS +testes/M +testicle/SM +testicular +testifier/M +testify/GZDRS +testily +testimonial/SM +testimony/SM +testiness/S +testing/S +testis/M +testosterone/SM +tests/AK +testy/RTP +tetanus/MS +tetchy/TR +tether/DMSG +tethered/U +tetra/MS +tetrachloride/M +tetracycline/SM +tetrafluoride +tetragonal/Y +tetrahalides +tetrahedral/Y +tetrahedron/SM +tetrameron +tetrameter/SM +tetrasodium +tetravalent +text/FSM +textbook/SM +textile/SM +textual/FY +textural/Y +texture/MGSD +textured/U +th/GNJX +thalami +thalamus/M +thalidomide/MS +thallium/SM +thallophyte/M +than +thane/SM +thank/SRDG +thanker/M +thankful/YP +thankfuller +thankfullest +thankfulness/SM +thankless/PY +thanklessness/SM +thanksgiving/MS +that'd +that'll +that/MS +thatch/JMDRSZG +thatching/M +thaumaturge/M +thaw/DGS +the +theater/SM +theatergoer/MS +theatergoing/MS +theatric/S +theatrical/YS +theatricality/SM +theatrics/M +thee/DS +theeing +theft/MS +their/MS +theism/SM +theist/SM +theistic +them/GD +themas +thematic/U +thematically +thematics +theme/MS +themselves +thence +thenceforth +thenceforward/S +theocracy/SM +theocratic +theodolite/MS +theologian/SM +theological/Y +theologists +theology/MS +theorem/MS +theoretic/S +theoretical/Y +theoretician/MS +theoretics/M +theorist/SM +theorization/SM +theorize/ZGDRS +theory/MS +theosophic +theosophical +theosophist/MS +theosophy/SM +therapeutic/S +therapeutically +therapeutics/M +therapist/MS +therapy/MS +there'd +there'll +there/MS +thereabout/S +thereafter +thereat +thereby +therefor +therefore +therefrom +therein +thereof +thereon +thereto +theretofore +thereunder +thereunto +thereupon +therewith +therm/MS +thermal/YS +thermionic/S +thermionics/M +thermistor/MS +thermo/S +thermocouple/MS +thermodynamic/S +thermodynamical/Y +thermodynamics/M +thermoelastic +thermoelectric +thermoformed +thermoforming +thermogravimetric +thermoluminescence/M +thermometer/MS +thermometric +thermometry/M +thermonuclear +thermopile/M +thermoplastic/S +thermopower +thermos/S +thermosetting +thermostable +thermostat/SM +thermostatic/S +thermostatically +thermostatics/M +thermostatted +thermostatting +thesauri +thesaurus/MS +these/S +thesis/M +thespian/S +theta/MS +thew/SM +they +they'd +they'll +they're +they've +thiamine/MS +thick/TXPSRNY +thicken/RDJZG +thickener/M +thickening/M +thicket/SMD +thickheaded/M +thickish +thickness/MS +thickset/S +thief/M +thieve/SDJG +thievery/MS +thievish/P +thievishness/M +thigh/DM +thighbone/SM +thighs +thimble/DSMG +thimbleful/MS +thin/STPYR +thine +thing/MP +thingamabob/MS +thingamajig/SM +think/AGRS +thinkable/U +thinkableness/M +thinkably/U +thinker/MS +thinking/SMYP +thinkingly/U +thinned +thinner/MS +thinness/MS +thinnest +thinning +thinnish +thiocyanate/M +thiouracil/M +third/DYGS +thirst/GSMDR +thirster/M +thirstily +thirstiness/S +thirsty/TPR +thirteen/MHS +thirteenths +thirtieths +thirty/HMS +this +this'll +thistle/SM +thistledown/MS +thither +tho +thole/GMSD +thong/SMD +thoracic +thorax/MS +thoriate/D +thorium/MS +thorn/SMDG +thorniness/S +thorny/PTR +thorough/PTYR +thoroughbred/S +thoroughfare/MS +thoroughgoing +thoroughness/SM +those +thou/DSG +though +thought/MS +thoughtful/U +thoughtfully +thoughtfulness/S +thoughtless/YP +thoughtlessness/MS +thousand/SHM +thousandfold +thousandths +thrall/GSMD +thralldom/S +thrash/DSRZGJ +thrasher/M +thrashing/M +thread/MZDRGS +threadbare/P +threader/M +threading/A +threadlike +thready/RT +threat/MDNSXG +threaten/GJRD +threatener/M +threatening/Y +three/MS +threefold +threepence/M +threepenny +threescore/S +threesome/SM +threnody/SM +thresh/DSRZG +thresher/M +threshold/MDGS +threw +thrice +thrift/SM +thriftily +thriftiness/S +thriftless +thrifty/PTR +thrill/ZMGDRS +thriller/M +thrilling/Y +thrive/RSDJG +thriver/M +thriving/Y +throat/MDSG +throatily +throatiness/MS +throaty/PRT +throb/S +throbbed +throbbing +throe/SDM +throeing +thrombi +thromboses +thrombosis/M +thrombotic +thrombus/M +throne's +throne/CGSD +throng/GDSM +throttle/DRSZMG +throttler/M +through/Y +throughout +throughput/SM +throughway's +throw/SZGR +throwaway/SM +throwback/MS +thrower/M +thrown +throwout +thrum/S +thrummed +thrumming +thrush/MS +thrust/ZGSR +thruster/M +thruway/SM +thud/MS +thudded +thudding +thug/MS +thuggee/M +thuggery/SM +thuggish +thulium/SM +thumb/SMDG +thumbnail/MS +thumbscrew/SM +thumbtack/GMDS +thump/RDMSG +thunder/ZGJDRMS +thunderbolt/MS +thunderclap/SM +thundercloud/SM +thunderer/M +thunderhead/SM +thundering/Y +thunderous/Y +thundershower/MS +thunderstorm/MS +thunderstruck +thundery +thunk +thus/Y +thwack/DRSZG +thwacker/M +thwart/GSDRY +thwarter/M +thy +thyme/SM +thymine/MS +thymus/SM +thyratron/M +thyristor/MS +thyroglobulin +thyroid/S +thyroidal +thyronine +thyrotoxic +thyrotrophic +thyrotrophin +thyrotropic +thyrotropin/M +thyroxine/M +thyself +ti/MDRZ +tiara/MS +tibia/M +tibiae +tibial +tic/MS +tick/GZJRDMS +ticker/M +ticket/SGMD +ticking/M +tickle/RSDZG +tickler/M +ticklish/PY +ticklishness/MS +ticktacktoe/S +ticktock/SMDG +tidal/Y +tidbit/MS +tiddlywinks/M +tide/GJDS +tideland/MS +tidewater/SM +tideway/SM +tidily/U +tidiness/USM +tidy/UGDSRPT +tidying/M +tie/AUDS +tieback/MS +tiebreaker/SM +tier/DGM +tiff/GDMS +tiffany/M +tiger/SM +tigerish +tight/STXPRNY +tighten/JZGDR +tightener/M +tightfisted +tightness/MS +tightrope/SM +tightwad/MS +tigress/SM +tike's +tilde/MS +tile/DRSJMZG +tiled/UE +tiles/U +tiling/M +till/EGSZDR +tillable +tillage/SM +tiller's/E +tiller/GDM +tilt/RDSGZ +tilth/M +timber/DMSG +timbering/M +timberland/SM +timberline/S +timbre/MS +timbrel/SM +time/DRSJMYZG +timebase +timekeeper/MS +timekeeping/SM +timeless/PY +timelessness/S +timeliness/SMU +timely/UTRP +timeout/S +timepiece/MS +timer/M +timescale/S +timeserver/MS +timeserving/S +timeshare/SDG +timespan +timestamped +timestamps +timetable/GMSD +timeworn +timezone/S +timid/RYTP +timidity/SM +timidness/MS +timing/M +timorous/YP +timorousness/MS +timothy/MS +timpani +timpanist/S +tin/MDGS +tincture/SDMG +tinder/MS +tinderbox/MS +tine/SM +tinfoil/MS +ting/GYDM +tinge/S +tingeing +tingle/SDG +tingling/Y +tingly/TR +tinily +tininess/MS +tinker/SRDMZG +tinkle/SDG +tinkling/M +tinkly +tinned +tinner/M +tinnily +tinniness/SM +tinning/M +tinnitus/MS +tinny/RSTP +tinplate/S +tinsel/GMDYS +tinsmith/M +tinsmiths +tint/SGMRDB +tinter/M +tintinnabulation/MS +tintype/SM +tinware/MS +tiny/RPT +tip/MS +tipi's +tipoff +tipped +tipper/MS +tippet/MS +tipping +tipple/ZGRSD +tippler/M +tippy/R +tipsily +tipsiness/SM +tipster/SM +tipsy/TPR +tiptoe/SD +tiptoeing +tiptop/S +tirade/SM +tire/MGDSJ +tired/AYP +tireder +tiredest +tiredness/S +tireless/PY +tirelessness/SM +tires/A +tiresome/PY +tiresomeness/S +tiring/AU +tiro's +tis +tissue/MGSD +tit/MRZS +titan/SM +titanate/M +titanic +titanically +titanium/SM +titbit's +titer/M +tithe/SRDGZM +tither/M +tithing/M +titian/S +titillate/XSDVNG +titillating/Y +titillation/M +titivate/NGDSX +titivation/M +title/GMSRD +titled/AU +titleholder/SM +titling/A +titmice +titmouse/M +titrate/SDGN +titration/M +titted +titter/GDS +titting +tittle/SDMG +titular/SY +tizzy/SM +tn +tnpk +to/D +toad/SM +toadstool/SM +toady/GSDM +toadyism/M +toast/SZGRDM +toaster/M +toastmaster/MS +toastmistress/S +toasty/TRS +tobacco/SM +tobacconist/SM +tobaggon/SM +toboggan/MRDSZG +toccata/M +tocsin/MS +today'll +today/SM +toddle/ZGSRD +toddler/M +toddy/SM +toe/MS +toecap/SM +toeclip/S +toehold/MS +toeing +toenail/DMGS +toffee/SM +tofu/S +tog/SMG +toga/SMD +toge +together/P +togetherness/MS +togged +togging +toggle/SDMG +toil/SGZMRD +toilet/GMDS +toiletry/MS +toilette/SM +toilsome/PY +toilsomeness/M +tokamak +toke/GDS +token/SMDG +tokenism/SM +tokenized +told/AU +tole/MGDS +tolerability/IM +tolerable/I +tolerably/I +tolerance/SIM +tolerant/IY +tolerate/XVNGSD +toleration/M +toll/DGS +tollbooth/M +tollbooths +tollgate/MS +tollhouse/M +tollway/S +toluene/MS +tom/SM +tomahawk/SGMD +tomato/M +tomatoes +tomb/GSDM +tomblike +tombola/M +tomboy/MS +tomboyish +tombstone/MS +tomcat/SM +tomcatted +tomcatting +tome/SM +tomfool/M +tomfoolery/MS +tommed +tomming +tommy/M +tomographic +tomography/MS +tomorrow/MS +tomtit/SM +ton/SKM +tonal/Y +tonality/MS +tone's +tone/ISRDZG +tonearm/S +toneless/YP +tonelessness/M +toner/IM +tong/GRDS +tongue/SDMG +tongueless +tonguing/M +tonic/SM +tonight/MS +tonk/MS +tonnage/SM +tonne/MS +tonsil/SM +tonsillectomy/MS +tonsillitis/SM +tonsorial +tonsure/SDGM +tony/RT +too/H +toodle +took/A +tool's +tool/AGDS +toolbox/SM +tooler/SM +tooling/M +toolkit/SM +toolmake/ZRG +toolmaker/M +toolmaking/M +toolsmith +toot/GRDZS +tooter/M +tooth/DMG +toothache/SM +toothbrush/MSG +toothily +toothless +toothmarks +toothpaste/SM +toothpick/MS +tooths +toothsome +toothy/TR +tootle/SRDG +toots/M +tootsie +tootsy/MS +top/SMDRG +topaz/MS +topcoat/MS +topdressing/S +toper/M +topflight +topgallant/M +topiary/S +topic/MS +topical/Y +topicality/MS +topknot/MS +topless +topmast/MS +topmost +topnotch/R +topocentric +topographer/SM +topographic +topographical/Y +topography/MS +topological/Y +topologist/MS +topology/MS +topped +topper/MS +topping/MS +topple/GSD +topsail/MS +topside/SRM +topsoil/GDMS +topspin/MS +toque/MS +tor/SLM +torch/SDMG +torchbearer/SM +torchlight/S +tore/S +toreador/SM +tori/M +torment/GSD +tormenting/Y +tormentor/MS +torn +tornado/M +tornadoes +toroid/MS +toroidal/Y +torpedo/GMD +torpedoes +torpid/SY +torpidity/S +torpor/MS +torque/MZGSRD +torrence +torrent/MS +torrential +torrid/RYTP +torridity/SM +torridness/SM +tors/S +torsi's +torsion/IAM +torsional/Y +torsions +torso/SM +tort's +tort/ASFE +torte/MS +tortellini/MS +torten +tortilla/MS +tortoise/SM +tortoiseshell/SM +tortoni/MS +tortuous/PY +tortuousness/MS +torture/ZGSRD +torturous +torus/MS +toss/SRDGZ +tossup/MS +tot/MDRSG +total/ZGSRDYM +totaler/M +totalistic +totalitarian/S +totalitarianism/SM +totality/MS +totalizator/S +totalizing +tote/S +totem/MS +totemic +toter/M +toting/M +totted +totter/ZGRDS +totterer/M +tottering/Y +totting +toucan/MS +touch/ASDG +touchable/U +touchdown/SM +touched/U +toucher/M +touchily +touchiness/SM +touching/SY +touchline/M +touchscreen +touchstone/SM +touchy/TPR +touch� +tough/TXGRDNYP +toughen/DRZG +toughener/M +toughness/SM +toughs +toupee/SM +tour's/CF +tour/GZSRDM +toured/CF +tourer/M +touring/F +tourism/SM +tourist/SM +touristic +touristy +tourmaline/SM +tournament/MS +tourney/GDMS +tourniquet/MS +tours/CF +tousle/GSD +tout/SGRD +touter/M +tow/DRSZG +toward/YU +towardliness/M +towardly/P +towards +towboat/MS +towel/GJDMS +towelette/S +toweling/M +tower/GMD +towering/Y +towhead/MSD +towhee/SM +towline/MS +town/SRM +towner/M +townhouse/S +townie/S +townsfolk +township/MS +townsman/M +townsmen +townspeople/M +townswoman/M +townswomen +towpath/M +towpaths +towrope/MS +toxemia/MS +toxic/S +toxicity/MS +toxicological +toxicologist/SM +toxicology/MS +toxin/MS +toy/MDRSG +toyer/M +toymaker +toyshop +tr +trace's +trace/ASDG +traceability/M +traceable/P +traceableness/M +traceback/MS +traced/U +traceless/Y +tracepoint/SM +tracer/MS +tracery/MDS +trachea/M +tracheae +tracheal/M +tracheotomy/SM +tracing/SM +track/SZGMRD +trackage +trackball/S +trackbed +tracked/U +tracker/M +trackless +tracksuit/SM +tract's +tract/ABS +tractability/SI +tractable/I +tractably/I +traction/KSCEMAF +tractive/KFE +tractor/FKMASC +tracts/CEFK +trade/SRDGZM +trademark/GSMD +trader/M +tradesman/M +tradesmen +tradespeople +tradespersons +tradeswoman/M +tradeswomen +tradition/SM +traditional/U +traditionalism/MS +traditionalist/MS +traditionalistic +traditionalized +traditionally +traduce/DRSGZ +traffic/SM +trafficked +trafficker/MS +trafficking/S +tragedian/SM +tragedienne/MS +tragedy/MS +tragic/S +tragically +tragicomedy/SM +tragicomic +trail/SZGJRD +trailblazer/MS +trailblazing/S +trailer/GDM +trails/F +trailside +train/ASDG +trainable +trained/U +trainee/MS +traineeships +trainer/MS +training/SM +trainman/M +trainmen +trainspotter/S +traipse/DSG +trait/MS +traitor/SM +traitorous/Y +trajectory/MS +tram/MS +trammed +trammel/GSD +trammeled/U +tramming +tramp/RDSZG +trample/DGRSZ +trampler/M +trampoline/GMSD +tramway/M +trance/MGSD +tranche/SM +tranquil/PTRY +tranquility/S +tranquilize/JGZDSR +tranquilized/U +tranquilizer/M +tranquilizes/A +tranquilizing/YM +tranquillize/GRSDZ +tranquillizer/M +tranquilness/M +trans/I +transact/GSD +transaction/MS +transactional +transactor/SM +transalpine +transaminase +transatlantic +transceiver/SM +transcend/SDG +transcendence/MS +transcendent/Y +transcendental/YS +transcendentalism/SM +transcendentalist/SM +transconductance +transcontinental +transcribe/DSRGZ +transcriber/M +transcript/SM +transcription/SM +transcultural +transducer/SM +transduction/M +transect/DSG +transept/SM +transfer/BSMD +transferability/M +transferal/MS +transferee/M +transference/SM +transferor/MS +transferral/SM +transferred +transferrer/SM +transferring +transfiguration/SM +transfigure/SDG +transfinite/Y +transfix/SDG +transform/DRZBSG +transformation/MS +transformational +transformed/U +transformer/M +transfuse/XSDGNB +transfusion/M +transgress/VGSD +transgression/SM +transgressor/S +transience/SM +transiency/S +transient/YS +transistor/SM +transistorize/GDS +transit/SGVMD +transition/MDGS +transitional/Y +transitive/PIY +transitiveness/IM +transitivenesses +transitivity/MS +transitoriness/M +transitory/P +transl +translatability/M +translatable/U +translate/VGNXSDB +translated/AU +translation/M +translational +translator/SM +transliterate/XNGSD +translucence/SM +translucency/MS +translucent/Y +transmigrate/XNGSD +transmissible +transmission/MSA +transmissive +transmit/AS +transmittable +transmittal/SM +transmittance/MS +transmitted/A +transmitter/SM +transmitting/A +transmogrification/M +transmogrify/GXDSN +transmutation/SM +transmute/GBSD +transnational/S +transoceanic +transom/SM +transonic +transpacific +transparency/MS +transparent/YP +transparentness/M +transpiration/SM +transpire/GSD +transplant/GRDBS +transplantation/S +transpolar +transponder/MS +transport/BGZSDR +transportability +transportable/U +transportation/SM +transpose/BGSD +transposed/U +transposition/SM +transsexual/SM +transsexualism/MS +transship/LS +transshipment/SM +transshipped +transshipping +transubstantiation/MS +transversal/YM +transverse/GYDS +transvestism/SM +transvestite/SM +transvestitism +trap/MS +trapdoor/S +trapeze/DSGM +trapezium/MS +trapezoid/MS +trapezoidal +trappable/U +trapped +trapper/SM +trapping/S +trapshooting/SM +trash/SRDMG +trashcan/SM +trashiness/SM +trashy/TRP +trauma/MS +traumatic +traumatically +traumatize/SDG +travail/SMDG +travel/SDRGZJ +traveled/U +traveler/M +travelog's +travelogue/S +traversal/SM +traverse/GBDRS +traverser/M +travertine/M +travesty/SDGM +trawl/RDMSZG +trawler/M +tray/SM +treacherous/PY +treacherousness/SM +treachery/SM +treacle/DSGM +treacly +tread/SAGD +treader/M +treadle/GDSM +treadmill/MS +treas +treason/BMS +treasonous +treasure/DRSZMG +treasurer/M +treasurership +treasury/SM +treat's +treat/SAGDR +treatable +treated/U +treater/S +treatise/MS +treatment/MS +treaty/MS +treble/SDG +tree/MDS +treeing +treeless +treelike +treetop/SM +trefoil/SM +trek/MS +trekked +trekker/MS +trekking +trellis/GDSM +trematode/SM +tremble/JDRSG +trembler/M +trembles/M +trembly +tremendous/YP +tremendousness/M +tremolo/MS +tremor/MS +tremulous/YP +tremulousness/SM +trench's +trench/GASD +trenchancy/MS +trenchant/Y +trencher/SM +trencherman/M +trenchermen +trend/SDMG +trendily +trendiness/S +trendy/PTRS +trepanned +trepidation/MS +trespass/ZRSDG +trespasser/M +tress/MSDG +tressed/E +tresses/E +tressing/E +trestle/MS +trey/MS +triable/P +triableness/M +triad/MS +triadic +triage/SDMG +trial/ASM +trialization +trialled +trialling +triamcinolone +triangle/SM +triangulable +triangular/Y +triangularization/S +triangulate/YGNXSD +triangulation/M +triathlon/S +triatomic +tribal/Y +tribalism/MS +tribe/MS +tribesman/M +tribesmen +tribeswoman +tribeswomen +tribulate/NX +tribulation/M +tribunal/MS +tribune/SM +tributary/MS +tribute's +tribute/EGSF +trice/GSDM +tricentennial/S +triceps/SM +triceratops/M +trichina/M +trichinae +trichinoses +trichinosis/M +trichloroacetic +trichloroethane +trichotomy/M +trichromatic +trick/GMSRD +trickery/MS +trickily +trickiness/SM +trickle/DSG +trickster/MS +tricky/RPT +tricolor/SMD +tricycle/SDMG +trident/SM +tridiagonal +tried/UA +triennial/SY +trier's +trier/AS +tries/A +triffid/S +trifle/MZGJSRD +trifler/M +trifluoride/M +trifocals +trig/S +trigged +trigger/GSDM +triggest +trigging +triglyceride/MS +trigonal/Y +trigonometric +trigonometrical +trigonometry/MS +trigram/S +trihedral +trike/GMSD +trilateral/S +trilby/SM +trilingual +trill/RDMGS +trillion/SMH +trillionth/M +trillionths +trillium/SM +trilobite/MS +trilogy/MS +trim/PSYR +trimaran/MS +trimer/M +trimester/MS +trimmed/U +trimmer/MS +trimmest +trimming/MS +trimness/S +trimodal +trimonthly +trinitarian/S +trinitrotoluene/SM +trinity/MS +trinket/MRDSG +trinketer/M +trio/SM +triode/MS +trioxide/M +trip/SMY +tripartite/N +tripartition/M +tripe/MS +triphenylarsine +triphenylphosphine +triphenylstibine +triphosphopyridine +triple/GSD +triplet/SM +triplex/S +triplicate/SDG +triplication/M +triply/GDSN +tripod/MS +tripodal +tripoli/M +tripolyphosphate +tripos/SM +tripped +tripper/MS +tripping/Y +triptych/M +triptychs +tripwire/MS +trireme/SM +trisect/GSD +trisection/S +trisector +trisodium +tristate +trisyllable/M +trite/SRPTY +tritely/F +triteness/SF +tritium/MS +triton/M +triumph/GMD +triumphal +triumphalism +triumphant/Y +triumphs +triumvir/MS +triumvirate/MS +triune +trivalent +trivet/SM +trivia +trivial/Y +triviality/MS +trivialization/MS +trivialize/DSG +trivium/M +trochaic/S +trochee/SM +trod/AU +trodden/UA +trodes +troff/MR +troglodyte/MS +troika/SM +troll/DMSG +trolled/F +trolley/SGMD +trolleybus/S +trolling/F +trollish +trollop/GSMD +trolly's +trombone/MS +trombonist/SM +tromp/DSG +troop/SRDMZG +trooper/M +troopship/SM +trope/SM +trophic +trophy/MGDS +tropic/MS +tropical/SY +tropism/SM +tropocollagen +troposphere/MS +tropospheric +trot/S +troth/GDM +troths +trotted +trotter/SM +trotting +troubadour/SM +trouble/GDRSM +troubled/U +troublemaker/MS +troubler/M +troubleshoot/SRDZG +troubleshooter/M +troubleshot +troublesome/YP +troublesomeness/M +trough/M +troughs +trounce/GZDRS +trouncer/M +troupe/MZGSRD +trouper/M +trouser/DMGS +trousseau/M +trousseaux +trout/SM +trove/SM +trow/SGD +trowel/SMDRGZ +troweler/M +troy/S +truancy/MS +truant/SMDG +truce/SDGM +truck/SZGMRDJ +trucker/M +trucking/M +truckle/GDS +truckload/MS +truculence/SM +truculent/Y +trudge/SRDG +true/DRSPTG +truelove/MS +trueness/M +truer/U +truest/U +truffle/MS +truism/SM +truly/U +trump/DMSG +trumpery/SM +trumpet/MDRZGS +trumpeter/M +truncate/NGDSX +truncation/M +truncheon/MDSG +trundle/GZDSR +trundler/M +trunk/GSMD +trunnion/SM +truss/SRDG +trusser/M +trussing/M +trust/RDMSG +trusted/EU +trustee/MDS +trusteeing +trusteeship/SM +truster/M +trustful/EY +trustfulness/SM +trustiness/M +trusting/Y +trusts/E +trustworthier +trustworthiest +trustworthiness/MS +trustworthy/UP +trusty/PTMSR +truth/UM +truthful/UYP +truthfulness/US +truths/U +try/JGDRSZ +trying/Y +tryout/MS +trypsin/M +tryst/GDMS +ts +tsarevich +tsarina's +tsarism/M +tsarist +tsetse/S +tsp +tsunami/MS +tty/M +ttys +tub/JMDRSZG +tuba/SM +tubae +tubal +tubbed +tubbing +tubby/TR +tube/SM +tubeless +tuber/M +tubercle/MS +tubercular/S +tuberculin/MS +tuberculoses +tuberculosis/M +tuberculous +tuberose/SM +tuberous +tubing/M +tubular/Y +tubule/SM +tuck/GZSRD +tucker/GDM +tuft/GZSMRD +tufter/M +tufting/M +tug/S +tugboat/MS +tugged +tugging +tuition/ISM +tularemia/S +tulip/SM +tulle/SM +tum +tumble/ZGRSDJ +tumbledown +tumbler/M +tumbleweed/MS +tumbrel/SM +tumescence/S +tumescent +tumid/Y +tumidity/MS +tummy/SM +tumor/MDS +tumorous +tumult/SGMD +tumultuous/PY +tumultuousness/M +tumulus/M +tun/DRJZGBS +tuna/SM +tunable/P +tunableness/M +tundra/SM +tune's +tune/CSDG +tuneful/YP +tunefulness/MS +tuneless/Y +tuner/M +tuneup/S +tung +tungstate/M +tungsten/SM +tunic/MS +tuning's +tuning/A +tunned +tunnel/MRDSJGZ +tunneler/M +tunning +tunny/SM +tupelo/M +tuple/SM +tuppence/M +turban/SDM +turbid +turbidity/SM +turbinate/SD +turbine/SM +turbo/SM +turbocharged +turbocharger/SM +turbofan/MS +turbojet/MS +turboprop/MS +turbot/MS +turbulence/SM +turbulent/Y +turd/MS +tureen/MS +turf/DGSM +turfy/RT +turgid/PY +turgidity/SM +turgidness/M +turk/S +turkey/SM +turmeric/MS +turmoil/SDMG +turn/AZGRDBS +turnabout/SM +turnaround/MS +turnbuckle/SM +turncoat/SM +turned/U +turner/M +turning/MS +turnip/SMDG +turnkey/MS +turnoff/MS +turnout/MS +turnover/SM +turnpike/MS +turnround/MS +turnstile/SM +turnstone/M +turntable/SM +turpentine/GMSD +turpitude/SM +turquoise/SM +turret/SMD +turtle/SDMG +turtleback/MS +turtledove/MS +turtleneck/SDM +turves's +turvy +tush/SDG +tusk/GZRDMS +tusker/M +tussle/GSD +tussock/MS +tussocky +tut/S +tutelage/MS +tutelary/S +tutor/MDGS +tutored/U +tutorial/MS +tutorship/S +tutted +tutti/S +tutting +tutu/SM +tux/S +tuxedo/SDM +twaddle/GZMRSD +twaddler/M +twain/S +twang/MDSG +twangy/TR +twas +tweak/SGRD +twee/DP +tweed/SM +tweediness/M +tweedy/PTR +tween +tweet/ZSGRD +tweeter/M +tweeze/ZGRD +tweezer/M +twelfth +twelfths +twelve/MS +twelvemonth/M +twelvemonths +twentieths +twenty/MSH +twerp/MS +twice/R +twiddle/GRSD +twiddler/M +twiddly/RT +twig/SM +twigged +twigging +twiggy/RT +twilight/MS +twilit +twill/SGD +twin/RDMGZS +twine/SM +twiner/M +twinge/SDMG +twinkle/RSDG +twinkler/M +twinkling/M +twinkly +twinned +twinning +twirl/SZGRD +twirler/M +twirling/Y +twirly/TR +twist/SZGRD +twisted/U +twister/M +twists/U +twisty +twit/S +twitch/GRSD +twitchy/TR +twitted +twitter/SGRD +twitterer/M +twittery +twitting +twixt +two/MS +twofer/MS +twofold/S +twopence/SM +twopenny/S +twosome/MS +twp +tycoon/MS +tyeing +tying/UA +tyke/SM +tympani +tympanist/SM +tympanum/SM +type/MGDRSJ +typeahead +typecast/SG +typed/AU +typedef/S +typeface/MS +typeless +types/A +typescript/SM +typeset/S +typesetter/MS +typesetting/SM +typewrite/SRJZG +typewriter/M +typewriting/M +typewritten +typewrote +typhoid/SM +typhoon/SM +typhus/SM +typical/U +typicality/MS +typically +typicalness/M +typification/M +typify/SDNXG +typing/A +typist/MS +typo/MS +typographer/SM +typographic +typographical/Y +typography/MS +typological/Y +typology/MS +tyrannic +tyrannical/PY +tyrannicalness/M +tyrannicide/M +tyrannize/ZGJRSD +tyrannizer/M +tyrannizing/YM +tyrannosaur/MS +tyrannosaurus/S +tyrannous +tyranny/MS +tyrant/MS +tyreo +tyro/SM +tyrosine/M +tzar's +tzarina's +u +ubiquitous/YP +ubiquity/S +udder/SM +ufologist/S +ufology/MS +ugh +ughs +uglification +ugliness/MS +uglis +ugly/PTGSRD +uh +ukase/SM +ukulele/SM +ulcer/MDGS +ulcerate/NGVXDS +ulceration/M +ulcerous +ulna/M +ulnae +ulnar +ulster/MS +ult +ulterior/Y +ultimas +ultimate/DSYPG +ultimateness/M +ultimatum/MS +ultimo +ultra/S +ultracentrifugally +ultracentrifugation +ultracentrifuge/M +ultraconservative/S +ultrafast +ultrahigh +ultralight/S +ultramarine/SM +ultramodern +ultramontane +ultrashort +ultrasonic/S +ultrasonically +ultrasonics/M +ultrasound/SM +ultrastructure/M +ultraviolet/SM +ululate/DSXGN +ululation/M +um +umbel/MS +umber/GMDS +umbilical/S +umbilici +umbilicus/M +umbra/MS +umbrage/MGSD +umbrageous +umbrella/GDMS +umiak/MS +umlaut/GMDS +ump/MDSG +umpire/MGSD +umpteen/H +unabated/Y +unabridged/S +unacceptability +unacceptable +unaccepted +unaccommodating +unaccountability +unaccustomed/Y +unadapted +unadulterated/Y +unadventurous +unalienability +unalterable/P +unalterableness/M +unalterably +unambiguity +unambiguous +unambitious +unamused +unanimity/SM +unanimous/Y +unanticipated/Y +unapologetic +unapologizing/M +unappeasable +unappeasably +unappreciative +unary +unassailable/P +unassailableness/M +unassertive +unassuming/PY +unassumingness/M +unauthorized/PY +unavailing/PY +unaware/SPY +unbalanced/P +unbar +unbarring +unbecoming/P +unbeknown +unbelieving/Y +unbiased/P +unbid +unbind/G +unblessed +unblinking/Y +unbodied +unbolt/G +unbreakability +unbred +unbroken +unbuckle +unbudging/Y +unburnt +uncap +uncapping +uncatalogued +uncauterized/MS +unceasing/Y +uncelebrated +uncertain/P +unchallengeable +unchanging/PY +unchangingness/M +uncharacteristic +uncharismatic +unchastity +unchristian +uncial/S +uncivilized/Y +unclassified +uncle/MSD +unclouded/Y +uncodable +uncollected +uncolored/PY +uncoloredness/M +uncombable +uncommunicative +uncompetitive +uncomplicated +uncomprehending/Y +uncompromisable +unconcern/M +unconcerned/P +unconfirmed +unconfused +unconscionable/P +unconscionableness/M +unconscionably +unconstitutional +unconsumed +uncontentious +uncontrollability +unconvertible +uncool +uncooperative +uncork/G +uncouple/G +uncouth/YP +uncouthness/M +uncreate/V +uncritical +uncross/GB +uncrowded +unction/IM +unctions +unctuous/PY +unctuousness/MS +uncustomary +uncut +undated/I +undaunted/Y +undeceive +undecided/S +undedicated +undefinability +undefined/P +undefinedness/M +undelete +undeliverability +undeniable/P +undeniableness/M +undeniably +undependable +under/Y +underachieve/SRDGZ +underachiever/M +underact/GDS +underadjusting +underage/S +underarm/DGS +underbedding +underbelly/MS +underbid/S +underbidding +underbracing +underbrush/MSDG +undercarriage/MS +undercharge/GSD +underclass/S +underclassman +underclassmen +underclothes +underclothing/MS +undercoat/JMDGS +undercoating/M +underconsumption/M +undercooked +undercount/S +undercover +undercurrent/SM +undercut/S +undercutting +underdeveloped +underdevelopment/MS +underdog/MS +underdone +undereducated +underemphasis +underemployed +underemployment/SM +underenumerated +underenumeration +underestimate/NGXSD +underexploited +underexpose/SDG +underexposure/SM +underfed +underfeed/SG +underfloor +underflow/GDMS +underfoot +underfund/DG +underfur/MS +undergarment/SM +undergirding +undergo/G +undergoes +undergone +undergrad/MS +undergraduate/MS +underground/RMS +undergrowth/M +undergrowths +underhand/D +underhanded/YP +underhandedness/MS +underheat +underinvestment +underlaid +underlain/S +underlay/GS +underlie +underline/GSDJ +underling/MS +underlip/SM +underloaded +underly/GS +undermanned +undermentioned +undermine/SDG +undermost +underneath +underneaths +undernourished +undernourishment/SM +underpaid +underpants +underpart/MS +underpass/SM +underpay/GSL +underpayment/SM +underperformed +underpin/S +underpinned +underpinning/MS +underplay/SGD +underpopulated +underpopulation/M +underpowered +underpricing +underprivileged +underproduction/MS +underrate/GSD +underregistration/M +underreported +underreporting +underrepresentation/M +underrepresented +underscore/SDG +undersea/S +undersealed +undersecretary/SM +undersell/SG +undersexed +undershirt/SM +undershoot/SG +undershorts +undershot +underside/SM +undersign/SGD +undersigned/M +undersized +undersizes +undersizing +underskirt/MS +undersold +underspecification +underspecified +underspend/G +understaffed +understand/RGSJB +understandability/M +understandably +understanding/YM +understate/GSDL +understatement/MS +understocked +understood +understrength +understructure/SM +understudy/GMSD +undertake/SRGZJ +undertaken +undertaker/M +undertaking/M +underthings +undertone/SM +undertook +undertow/MS +underused +underusing +underutilization/M +underutilized +undervaluation/S +undervalue/SDG +underwater/S +underway +underwear/M +underweight/S +underwent +underwhelm/DGS +underwood/M +underworld/MS +underwrite/GZSR +underwriter/M +underwritten +underwrote +undeserving +undesigned +undeviating/Y +undialyzed/SM +undiplomatic +undiscerning +undiscriminating +undo/GJ +undoubted/Y +undramatic +undramatized/SM +undress/G +undrinkability +undrinkable +undroppable +undue +undulant +undulate/XDSNG +undulation/M +unearth/YG +unearthliness/S +unearthly/P +unease +uneconomic +uneducated +unemployed/S +unencroachable +unending/Y +unendurable/P +unenergized/MS +unenforced +unenterprising +unethical +uneulogized/SM +unexacting +unexceptionably +unexcited +unexpectedness/MS +unfading/Y +unfailing/P +unfailingness/M +unfamiliar +unfashionable +unfathomably +unfavored +unfeeling +unfeigned/Y +unfelt +unfeminine +unfertile +unfetchable +unflagging +unflappability/S +unflappable +unflappably +unflinching/Y +unfold/LG +unfoldment/M +unforced +unforgeable +unfossilized/MS +unfraternizing/SM +unfrozen +unfulfillable +unfunny +unfussy +ungainliness/MS +ungainly/PRT +ungenerous +ungentle +unglamorous +ungrammaticality +ungrudging +unguent/MS +ungulate/MS +unharmonious +unharness/G +unhistorical +unholy/TP +unhook/DG +unhydrolyzed/SM +unhygienic +unicameral +unicellular +unicorn/SM +unicycle/MGSD +unicyclist/MS +unideal +unidimensional +unidiomatic +unidirectional/Y +unidirectionality +unidolized/MS +unifiable +unification/MA +unifier/MS +unifilar +uniform/TGSRDYMP +uniformity/MS +uniformness/M +unify/AXDSNG +unilateral/Y +unilateralism/M +unilateralist +unimodal +unimpeachably +unimportance +unimportant +unimpressive +unindustrialized/MS +uninhibited/YP +uninominal +uninsured +unintellectual +unintended +uninteresting +uninterrupted/YP +uninterruptedness/M +unintuitive +uninviting +union/AEMS +unionism/SM +unionist/SM +unionize +unipolar +uniprocessor/SM +unique/TYSRP +uniqueness/S +unisex/S +unison/MS +unit/VGRD +unitarian/MS +unitarianism/M +unitary +unite/AEDSG +united/Y +uniter/M +unitize/GDS +unity/SEM +univ +univalent/S +univalve/MS +univariate +universal/YSP +universalism/M +universalistic +universality/SM +universalize/DSRZG +universalizer/M +universe/MS +university/MS +unjam +unkempt +unkind/TP +unkink +unknightly +unknowable/S +unknowing +unlabored +unlace/G +unlearn/G +unlikeable +unlikeliness/S +unlimber/G +unlimited +unlit +unliterary +unloose/G +unlucky/TP +unmagnetized/MS +unmanageably +unmannered/Y +unmask/G +unmeaning +unmeasured +unmeetable +unmelodious +unmemorable +unmemorialized/MS +unmentionable/S +unmerciful +unmeritorious +unmethodical +unmineralized/MS +unmissable +unmistakably +unmitigated/YP +unmnemonic +unmobilized/SM +unmoral +unmount/B +unmovable +unmoving +unnaturalness/M +unnavigable +unnerving/Y +unobliging +unoffensive +unofficial +unorganized/YP +unorthodox +unpack/G +unpaintable +unpalatability +unpalatable +unpartizan +unpatronizing +unpeople +unperceptive +unperson +unperturbed/Y +unphysical +unpick/G +unpicturesque +unpinning +unpleasing +unploughed +unpolarized/SM +unpopular +unpractical +unprecedented/Y +unpredictable/S +unpreemphasized +unpremeditated +unpretentiousness/M +unprincipled/P +unproblematic +unproductive +unpropitious +unprovable +unproven +unprovocative +unpunctual +unquestionable +unraisable +unravellings +unread/B +unreadability +unreal +unrealizable +unreasoning/Y +unreceptive +unrecordable +unreflective +unrelenting/Y +unremitting/Y +unrepeatability +unrepeated +unrepentant +unreported +unrepresentative +unreproducible +unrest/G +unrestrained/P +unrewarding +unriddle +unripe/P +unromantic +unruliness/SM +unruly/PTR +unsaleable +unsanitary +unsavored/YP +unsavoriness/M +unseal/GB +unsearchable +unseasonal +unseeing/Y +unseen/S +unselfconscious/P +unselfconsciousness/M +unselfishness/M +unsellable +unsentimental +unset +unsettled/P +unsettledness/M +unsettling/Y +unshapely +unshaven +unshorn +unsighted +unsightliness/S +unskilful +unsociability +unsociable/P +unsocial +unsound/PT +unspeakably +unspecific +unspectacular +unspoilt +unspoke +unsporting +unstable/P +unstigmatized/SM +unstilted +unstinting/Y +unstopping +unstrapping +unstudied +unstuffy +unsubdued +unsubstantial +unsubtle +unsuitable +unsuspecting/Y +unswerving/Y +unsymmetrical +unsympathetic +unsystematic +unsystematized/Y +untactful +untalented +untaxing +unteach/B +untellable +untenable +unthinking +until/G +untiring/Y +unto +untouchable/MS +untoward/P +untowardness/M +untraceable +untrue +untruthfulness/M +untwist/G +unusualness/M +unutterable +unutterably +unvocalized/MS +unvulcanized/SM +unwaivering +unwarrantable +unwarrantably +unwashed/PS +unwearable +unwearied/Y +unwed +unwedge +unwelcome +unwell/M +unwieldiness/MS +unwieldy/TPR +unwind/B +unwomanly +unworkable/S +unworried +unwrap +unwrapping +unyielding/Y +unyoke +unzip +up +uparrow +upbeat/SM +upbraid/GDRS +upbring/JG +upbringing/M +upchuck/SDG +upcome/G +upcountry/S +updatability +update/RSDG +updater/M +updraft/SM +upend/SDG +upfield +upfront +upgrade/DSJG +upgradeable +upheaval/MS +upheld +uphill/S +uphold/RSGZ +upholder/M +upholster/ADGS +upholsterer/SM +upholstery/MS +upkeep/SM +upland/MRS +uplander/M +uplift/SJDRG +uplifter/M +upload/GSD +upmarket +upon +upped +upper/S +uppercase/GSD +upperclassman/M +upperclassmen +uppercut/S +uppercutting +uppermost +upping +uppish +uppity +upraise/GDS +uprated +uprating +uprear/DSG +upright/DYGSP +uprightness/S +uprise/RGJ +uprising/M +upriver/S +uproar/MS +uproarious/PY +uproariousness/M +uproot/DRGS +uprooter/M +ups +upscale/GDS +upset/S +upsetting/MS +upshot/SM +upside/MS +upsilon/MS +upslope +upstage/DSRG +upstairs +upstanding/P +upstandingness/M +upstart/MDGS +upstate/SR +upstream/DSG +upstroke/MS +upsurge/DSG +upswing/GMS +upswung +uptake/SM +upthrust/GMS +uptight +uptime +uptown/RS +uptrend/M +upturn/GDS +upward/SYP +upwardness/M +upwelling +upwind/S +uracil/MS +uranium/MS +uranyl/M +urban/RT +urbane/Y +urbanism/M +urbanite/SM +urbanity/SM +urbanization/MS +urbanize/DSG +urbanologist/S +urbanology/S +urchin/SM +urea/SM +uremia/MS +uremic +ureter/MS +urethane/MS +urethra/M +urethrae +urethral +urethritis/M +urge/GDRSJ +urgency/SM +urgent/Y +urger/M +uric +urinal/MS +urinalyses +urinalysis/M +urinary/MS +urinate/XDSNG +urination/M +urine/MS +urn/MDGS +urning/M +urogenital +urological +urologist/S +urology/MS +ursine +urticaria/MS +us/DRSBZG +usability/S +usable/U +usably/U +usage/SM +use/ESDAG +used/U +useful/YP +usefulness/SM +useless/PY +uselessness/MS +user/M +usher/SGMD +usherette/SM +usu +usual/UPY +usuals +usurer/SM +usurious/PY +usuriousness/M +usurp/RDZSG +usurpation/MS +usurper/M +usury/SM +utensil/SM +uteri +uterine +uterus/M +utile/I +utilitarian/S +utilitarianism/MS +utility/MS +utilization's/A +utilization/MS +utilize/GZDRS +utilizer/M +utilizes/A +utmost/S +utopia/S +utopian's +utopianism/M +utter/TRDYGS +utterance/MS +uttered/U +utterer/M +uttermost/S +uucp/M +uvula/MS +uvular/S +uxorious +v/ASV +vacancy/MS +vacant/PY +vacantness/M +vacate/NGXSD +vacation/MRDZG +vacationist/SM +vacationland +vaccinate/NGSDX +vaccination/M +vaccine/SM +vaccinia/M +vaccinial +vacillate/XNGSD +vacillating/Y +vacillation/M +vacillator/SM +vacua's +vacuity/MS +vacuo +vacuolate/SDGN +vacuolated/U +vacuole/SM +vacuolization/SM +vacuous/PY +vacuousness/MS +vacuum/GSMD +vagabond/DMSG +vagabondage/MS +vagarious +vagary/MS +vagina/M +vaginae +vaginal/Y +vagrancy/MS +vagrant/SMY +vague/TYSRDP +vagueing +vagueness/MS +vain/TYRP +vainglorious/YP +vaingloriousness/M +vainglory/MS +val +valance/SDMG +vale/SM +valediction/MS +valedictorian/MS +valedictory/MS +valence/SM +valency/MS +valentine/SM +valet/GDMS +valetudinarian/MS +valetudinarianism/MS +valiance/S +valiant/SPY +valiantness/M +valid/PIY +validate/INGSDX +validated/AU +validates/A +validation/AMI +validity/IMS +validness/MI +validnesses +valise/MS +valley/SM +valor/MS +valorous/Y +valuable/IP +valuableness/IM +valuables +valuably/I +valuate/NGXSD +valuation/CSAM +valuator/SM +value's +value/CGASD +valued/U +valueless/P +valuelessness/M +valuer/SM +values/E +valve/GMSD +valveless +valvular +vamoose/GSD +vamp's +vamp/ADSG +vamper +vampire/MGSD +van/SMD +vanadium/MS +vandal/MS +vandalism/MS +vandalize/GSD +vane/MS +vanguard/MS +vanilla/MS +vanish/GRSDJ +vanisher/M +vanishing/Y +vanity/SM +vanned +vanning +vanquish/RSDGZ +vanquisher/M +vantage/MS +vapid/PY +vapidity/MS +vapidness/SM +vapor/MRDJGZS +vaporer/M +vaporing/MY +vaporisation +vaporise/DSG +vaporization/AMS +vaporize/DRSZG +vaporizer/M +vaporous +vapory +vaquero/SM +var/S +variability/IMS +variable/PMS +variableness/IM +variables/I +variably/I +variance's +variance/I +variances +variant/ISY +variate/MGNSDX +variation/M +variational +varicolored/MS +varicose/S +varied/U +variedly +variegate/NGXSD +variegation/M +varier/M +varietal/S +variety/MS +various/PY +varistor/M +varlet/MS +varmint/SM +varnish/ZGMDRS +varnished/U +varnisher/M +varsity/MS +vary/SRDJG +varying/UY +vascular +vase/SM +vasectomy/SM +vasomotor +vassal/GSMD +vassalage/MS +vast/PTSYR +vastness/MS +vat/SM +vatted +vatting +vaudeville/SM +vaudevillian/SM +vault/ZSRDMGJ +vaulter/M +vaulting/M +vaunt/GRDS +vaunter/M +vb +veal/MRDGS +vealed/A +vealer/MA +veals/A +vector's/F +vector/SGDM +vectorial +vectorization +vectorized +vectorizing +veejay/S +veep/S +veer/DSG +veering/Y +veg/M +vegan/SM +veges +vegetable/MS +vegetarian/SM +vegetarianism/MS +vegetate/DSNGVX +vegetation/M +vegetative/PY +vegged +veggie/S +vegging +vehemence/MS +vehemency/S +vehement/Y +vehicle/SM +vehicular +veil's +veil/UGSD +veiling/MU +vein/GSRDM +veining/M +vela/M +velar/S +velarize/SDG +veld/SM +veldt's +vellum/MS +velocipede/SM +velocity/SM +velor/S +velour's +velum/M +velvet/GSMD +velveteen/MS +velvety/RT +venal/Y +venality/MS +venation/SM +vend/DSG +vender's/K +vendetta/MS +vendible/S +vendor/MS +veneer/GSRDM +veneerer/M +veneering/M +venerability/S +venerable/P +venerate/XNGSD +veneration/M +venereal +venetian +vengeance/MS +vengeful/APY +vengefulness/AM +venial/YP +venialness/M +venireman/M +veniremen +venison/SM +venom/SGDM +venomous/YP +venomousness/M +venous/Y +vent's/F +vent/ISGFD +venter/M +ventilate/XSDVGN +ventilated/U +ventilation/M +ventilator/MS +ventral/YS +ventricle/MS +ventricular +ventriloquies +ventriloquism/MS +ventriloquist/MS +ventriloquy +venture/RSDJZG +venturesome/YP +venturesomeness/SM +venturi/S +venturous/YP +venturousness/MS +venue/MAS +veracious/YP +veraciousness/M +veracities +veracity/IM +veranda/SDM +verandahed +verb/KSM +verbal/SY +verbalization/MS +verbalize/ZGRSD +verbalized/U +verbalizer/M +verballed +verballing +verbatim +verbena/MS +verbiage/SM +verbose/YP +verbosity/SM +verboten +verdant/Y +verdict/SM +verdigris/GSDM +verdure/SDM +verge's +verge/FGSD +verger/SM +veridical/Y +verifiability/M +verifiable/U +verifiableness/M +verification/S +verified/U +verifier/MS +verify/GASD +verily +verisimilitude/SM +veritable/P +veritableness/M +veritably +verity/MS +vermicelli/MS +vermiculite/MS +vermiform +vermilion/MS +vermin/M +verminous +vermouth/M +vermouths +vernacular/YS +vernal/Y +vernier/SM +veronica/SM +verruca/MS +verrucae +versa +versatile/YP +versatileness/M +versatility/SM +verse's +verse/XSRDAGNF +versed/UI +verses/I +versicle/M +versification/M +versifier/M +versify/GDRSZXN +versing/I +version/MFISA +verso/SM +versus +vertebra/M +vertebrae +vertebral/Y +vertebrate/IMS +vertebration/M +vertex/SM +vertical/YPS +vertices's +vertiginous +vertigo/M +vertigoes +verve/SM +very/RT +vesicle/SM +vesicular/Y +vesiculate/GSD +vesper/SM +vessel/MS +vest's +vest/DIGSL +vestal/YS +vestibular +vestibule/SDM +vestige/SM +vestigial/Y +vesting/SM +vestment/ISM +vestry/MS +vestryman/M +vestrymen +vesture/SDMG +vet/SMR +vetch/SM +veter/M +veteran/SM +veterinarian/MS +veterinary/S +veto/DMG +vetoes +vetted +vetting/A +vex/GFSD +vexation/SM +vexatious/PY +vexatiousness/M +vexed/Y +vhf +vi/MDR +via +viability/SM +viable/I +viably +viaduct/MS +vial/MDGS +viand/SM +vibe/S +vibraharp/MS +vibrancy/MS +vibrant/YS +vibraphone/MS +vibraphonist/SM +vibrate/XNGSD +vibration/M +vibrational/Y +vibrato/MS +vibrator/SM +vibratory +vibrio/M +vibrionic +viburnum/SM +vicar/SM +vicarage/SM +vicarious/YP +vicariousness/MS +vice/CMS +viced +vicegerent/MS +vicennial +viceregal +viceroy/SM +vichyssoise/MS +vicing +vicinity/MS +vicious/YP +viciousness/S +vicissitude/MS +victim/SM +victimization/SM +victimize/SRDZG +victimized/U +victimizer/M +victor/SM +victorious/YP +victoriousness/M +victory/MS +victual/ZGSDR +victualer/M +vicu�a/S +videlicet +video/GSMD +videocassette/S +videoconferencing +videodisc/S +videodisk/SM +videophone/SM +videotape/SDGM +vie/S +vier/M +view/MBGZJSRD +viewed/A +viewer's +viewer/AS +viewfinder/MS +viewgraph/SM +viewing/M +viewless/Y +viewpoint/SM +views/A +vigesimal +vigil/SM +vigilance/MS +vigilant/Y +vigilante/SM +vigilantism/MS +vigilantist +vignette/MGDRS +vignetter/M +vignetting/M +vignettist/MS +vigor/MS +vigorous/YP +vigorousness/M +vii +viii +viking/S +vile/AR +vilely +vileness/MS +vilest +vilification/M +vilifier/M +vilify/GNXRSD +villa/MS +village/RSMZ +villager/M +villain/SM +villainous/YP +villainousness/M +villainy/MS +ville +villein/MS +villeinage/SM +villi +villus/M +vim/MS +vinaigrette/MS +vincible/I +vindicate/XSDVGN +vindication/M +vindicator/SM +vindictive/PY +vindictiveness/MS +vine/MGDS +vinegar/DMSG +vinegary +vineyard/SM +vino/MS +vinous +vintage/MRSDG +vintager/M +vintner/MS +vinyl/SM +viol/MSB +viola/SM +violable/I +violate/VNGXSD +violator/MS +violence/SM +violent/Y +violet/SM +violin/MS +violinist/SM +violist/MS +violoncellist/S +violoncello/MS +viper/MS +viperous +virago/M +viragoes +viral/Y +vireo/SM +virgin/SM +virginal/YS +virginity/SM +virgule/MS +virile +virility/MS +virologist/S +virology/SM +virtual/Y +virtue/SM +virtuosity/MS +virtuoso/MS +virtuosoes +virtuous/PY +virtuousness/SM +virulence/SM +virulent/Y +virus/MS +vis/MDSGV +visa/SGMD +visage/MSD +viscera +visceral/Y +viscid/Y +viscoelastic +viscoelasticity +viscometer/SM +viscose/MS +viscosity/MS +viscount/MS +viscountcy/MS +viscountess/SM +viscous/PY +viscousness/M +viscus/M +vise's +vise/CAXNGSD +viselike +visibility/ISM +visible/PI +visibly/I +vision's/A +vision/KMDGS +visionariness/M +visionary/PS +visit/GASD +visitable/U +visitant/SM +visitation/SM +visited/U +visitor/MS +visor/SMDG +vista/GSDM +visual/SY +visualization/AMS +visualize/SRDZG +visualized/U +visualizer/M +visualizes/A +vita/M +vitae +vital/SY +vitality/MS +vitalization/AMS +vitalize/ASDGC +vitamin/SM +vitiate/XGNSD +vitiation/M +viticulture/SM +viticulturist/S +vitreous/YSP +vitrifaction/S +vitrification/M +vitrify/XDSNG +vitrine/SM +vitriol/MDSG +vitriolic +vitro +vittles +vituperate/SDXVGN +vituperation/M +vituperative/Y +viva/DGS +vivace/S +vivacious/YP +vivaciousness/MS +vivacity/SM +vivaria +vivarium/MS +vivaxes +vive/Z +vivid/PTYR +vividness/SM +vivifier +vivify/NGASD +viviparous +vivisect/DGS +vivisection/MS +vivisectional +vivisectionist/SM +vivo +vixen/SM +vixenish/Y +viz +vizier/MS +vizor's +vocab/S +vocable/SM +vocabularian +vocabularianism +vocabulary/MS +vocal/SY +vocalic/S +vocalise's +vocalism/M +vocalist/MS +vocalization/SM +vocalize/ZGDRS +vocalized/U +vocalizer/M +vocation/AKMISF +vocational/Y +vocative/KYS +vociferate/NGXSD +vociferation/M +vociferous/YP +vociferousness/MS +vocoded +vocoder +vodka/MS +voe/S +vogue/GMSRD +vogueing +voguish +voice/IMGDS +voiceband +voiced/CU +voiceless/YP +voicelessness/SM +voicer/S +voices/C +voicing/C +void/C +voidable +voided +voider/M +voiding +voidness/M +voids +voile/MS +voil� +vol/GSD +volar +volatile/PS +volatileness/M +volatility/MS +volatilization/MS +volatilize/SDG +volcanic/S +volcanically +volcanism/M +volcano/M +volcanoes +vole/MS +volition/MS +volitional/Y +volitionality +volley/SMRDG +volleyball/MS +volleyer/M +volt/AMS +voltage/SM +voltaic +voltmeter/MS +volubility/S +voluble/P +volubly +volume/SDGM +volumetric +volumetrically +voluminous/PY +voluminousness/MS +voluntarily/I +voluntariness/MI +voluntarism/MS +voluntary/PS +volunteer/DMSG +voluptuary/SM +voluptuous/YP +voluptuousness/S +volute/S +vomit/GRDS +voodoo/GDMS +voodooism/S +voracious/YP +voraciousness/MS +voracity/MS +vortex/SM +vortices's +vorticity/M +votary/MS +vote's +vote/CSDG +voter/SM +votive/YP +vouch/SRDGZ +voucher/GMD +vouchsafe/SDG +vow/SMDRG +vowel/MS +vowelled +vowelling +vower/M +voyage/GMZJSRD +voyager/M +voyageur/SM +voyeur/MS +voyeurism/MS +voyeuristic +vs +vulcanization/SM +vulcanize/SDG +vulcanized/U +vulgar/TSYR +vulgarian/MS +vulgarism/MS +vulgarity/MS +vulgarization/S +vulgarize/GZSRD +vulnerability/SI +vulnerable/IP +vulnerably/I +vulpine +vulture/SM +vulturelike +vulturous +vulva/M +vulvae +vying +w/XTJGV +wackes +wackiness/MS +wacko/MS +wacky/RTP +wad/MDRZGS +wadded +wadding/SM +waddle/GRSD +wade/S +wader/M +wadi/SM +wafer/GSMD +waffle/GMZRSD +waft/SGRD +wafter/M +wag/DRZGS +wage/SM +waged/U +wager/GZMRD +wagged +waggery/MS +wagging +waggish/YP +waggishness/SM +waggle/SDG +waggly +wagon/SGZMRD +wagoner/M +wagtail/SM +waif/SGDM +wail/SGZRD +wailer/M +wain/GSDM +wainscot/SGJD +wainwright/SM +waist/GSRDM +waistband/MS +waistcoat/GDMS +waister/M +waistline/MS +wait/GSZJRD +waiter/DMG +waitpeople +waitperson/S +waitress/GMSD +waive/SRDGZ +waiver/MB +wake/MGDRSJ +wakeful/PY +wakefulness/MS +waken/SMRDG +waker/M +wakeup +wale/DRSMG +waling/M +walk/GZSBJRD +walkabout/M +walkaway/SM +walker/M +walkie +walkout/SM +walkover/SM +walkway/MS +wall/SGMRD +wallaby/MS +wallah/M +wallboard/MS +wallet/SM +walleye/MSD +wallflower/MS +wallop/RDSJG +walloper/M +walloping/M +wallow/RDSG +wallower/M +wallpaper/DMGS +wally/S +walnut/SM +walrus/SM +waltz/MRSDGZ +waltzer/M +wampum/SM +wan/PGSDY +wand/MRSZ +wander/JZGRD +wanderer/M +wanderlust/SM +wane/S +wangle/RSDGZ +wangler/M +wanna +wannabe/S +wanned +wanner +wanness/S +wannest +wanning +want/GRDSJ +wanted/U +wanter/M +wanton/PGSRDY +wantonness/S +wapiti/MS +war/GSMD +warble/GZRSD +warbler/M +warbonnet/S +ward/AGMRDS +warden/DMGS +warder/DMGS +wardrobe/MDSG +wardroom/MS +wards/I +wardship/M +ware/MS +warehouse/MGSRD +warehouseman/M +warfare/SM +warhead/MS +warhorse/SM +warily/U +wariness/MS +warinesses/U +warless +warlike +warlock/SM +warlord/MS +warm/YRDHPGZTS +warmblooded +warmed/A +warmer/M +warmhearted/PY +warmheartedness/SM +warmish +warmness/MS +warmonger/JGSM +warmongering/M +warms/A +warmth/M +warmths +warn/GRDJS +warned/U +warner/M +warning/YM +warp/MRDGS +warpaint +warpath/M +warpaths +warper/M +warplane/MS +warrant/GSMDR +warranted/U +warranter/M +warranty/SDGM +warred/M +warren/SZRM +warrener/M +warring/M +warrior/MS +wars/C +warship/MS +wart/MDS +warthog/S +wartime/SM +warty/RT +wary/URPT +was/S +wash/AGSD +washable/S +washbasin/SM +washboard/SM +washbowl/SM +washcloth/M +washcloths +washday/M +washed/U +washer/GDMS +washerwoman/M +washerwomen +washing/SM +washout/SM +washrag/SM +washroom/MS +washstand/SM +washtub/MS +washy/RT +wasn't +wasp/SM +waspish/PY +waspishness/SM +wassail/GMDS +wast/GZSRD +wastage/SM +waste/S +wastebasket/SM +wasteful/YP +wastefulness/S +wasteland/MS +wastepaper/MS +waster/DG +wastewater +wasting/Y +wastrel/MS +watch/JRSDGZB +watchable/U +watchband/SM +watchdog/SM +watchdogged +watchdogging +watched/U +watcher/M +watchful/PY +watchfulness/MS +watchmake/JRGZ +watchmaker/M +watchman/M +watchmen +watchpoints +watchtower/MS +watchword/MS +water/JGSMRD +waterbird/S +waterborne +watercolor/DMGS +watercolorist/SM +watercourse/SM +watercraft/M +watercress/SM +waterer/M +waterfall/SM +waterfowl/M +waterfront/SM +waterhole/S +wateriness/SM +watering/M +waterless +waterlily/S +waterline/S +waterlogged +waterloo +waterman/M +watermark/GSDM +watermelon/SM +watermill/S +waterproof/PGRDSJ +watershed/SM +waterside/MSR +watersider/M +waterspout/MS +watertight/P +watertightness/M +waterway/MS +waterwheel/S +waterworks/M +watery/PRT +watt/TMRS +wattage/SM +wattle/SDGM +wave/ZGDRS +waveband/MS +waveform/SM +wavefront/MS +waveguide/MS +wavelength/M +wavelengths +wavelet/SM +wavelike +wavenumber +waver/GZRD +wavering/YU +wavily +waviness/MS +wavy/SRTP +wax/MNDRSZG +waxer/M +waxiness/MS +waxwing/MS +waxwork/MS +waxy/PRT +way/MS +wayfarer/MS +wayfaring/S +waylaid +waylay/GRSZ +waylayer/M +wayleave/MS +waymarked +wayside/MS +wayward/YP +waywardness/S +we +we'd +we'll +we're +we've +weak/TXPYRN +weaken/ZGRD +weakener/M +weakfish/SM +weakish +weakliness/M +weakling/SM +weakly/RTP +weakness/MS +weal/MHS +wealth/M +wealthiness/MS +wealths +wealthy/PTR +wean/RDGS +weaner/M +weanling/M +weapon/GDMS +weaponless +weaponry/MS +wear/RBSJGZ +wearable/S +wearer/M +wearied/U +wearily +weariness/MS +wearing/Y +wearisome/YP +wearisomeness/M +weary/TGPRSD +wearying/Y +weasel/SGMDY +weather/MDRYJGS +weatherbeaten +weathercock/SDMG +weatherer/M +weathering/M +weatherize/GSD +weatherman/M +weathermen +weatherperson/S +weatherproof/SGPD +weatherstrip/S +weatherstripped +weatherstripping/S +weave/SRDGZ +weaver/M +weaves/A +weaving/A +web/SMR +webbed +webbing/MS +weber/M +webfeet +webfoot/M +website/S +wed/SA +wedded/A +wedder +wedding/SM +wedge/SDGM +wedgie/RST +wedlock/SM +wee/DRST +weed/SGMRDZ +weeder/M +weediness/M +weedkiller/M +weedless +weedy/TRP +weeing +week/SYM +weekday/MS +weekend/SDRMG +weekender/M +weekly/S +weeknight/SM +ween/SGD +weenie/M +weeny/RSMT +weep/SGZJRD +weeper/M +weepy/RST +weevil/MS +weft/SGMD +weigh/RDJG +weighed/UA +weigher/M +weighs/A +weight/JMSRDG +weighted/U +weighter/M +weightily +weightiness/SM +weighting/M +weightless/YP +weightlessness/SM +weightlifter/S +weightlifting/MS +weighty/TPR +weir/SDMG +weird/YRDPGTS +weirdie/SM +weirdness/MS +weirdo/SM +welcome/PRSDYG +welcomeness/M +welcoming/U +weld/SBJGZRD +welder/M +welfare/SM +welkin/SM +well/SGPD +wellbeing/M +wellhead/SM +wellington/S +wellness/MS +wellspring/SM +welsh/RSDGZ +welsher/M +welt/GZSMRD +welter/GD +welterweight/MS +wen/M +wench/GRSDM +wencher/M +wend/DSG +went +wept/U +were +weren't +werewolf/M +werewolves +werwolf's +west/RDGSM +westbound +wester/DYG +westerly/S +western/ZSR +westerner/M +westernization/MS +westernize/GSD +westernmost +westing/M +westward/S +wet/SPY +wetback/MS +wetland/S +wetness/MS +wettable +wetter/S +wettest +wetting +whack/GZRDS +whacker/M +whale/GSRDZM +whaleboat/MS +whalebone/SM +whaler/M +whaling/M +wham/MS +whammed +whamming/M +whammy/S +wharf/SGMD +wharves +what'd +what're +what/MS +whatchamacallit/MS +whatever +whatnot/MS +whatsoever +wheal/MS +wheat/NMXS +wheatgerm +whee/S +wheedle/ZDRSG +wheel/RDMJSGZ +wheelbarrow/GSDM +wheelbase/MS +wheelchair/MS +wheeler/M +wheelhouse/SM +wheelie/MS +wheeling/M +wheelwright/MS +wheeze/SDG +wheezily +wheeziness/SM +wheezy/PRT +whelk/MDS +whelm/DGS +whelp/DMGS +when/S +whence/S +whenever +whensoever +where'd +where're +where/MS +whereabout/S +whereas/S +whereat +whereby +wherefore/MS +wherein +whereof +whereon +wheresoever +whereto +whereupon +wherever +wherewith +wherewithal/SM +wherry/DSGM +whet/S +whether +whetstone/MS +whetted +whetting +whew/GSD +whey/MS +which +whichever +whiff/GSMD +whiffle/DRSG +whiffler/M +whiffletree/SM +whig/S +while/GSD +whilom +whilst +whim/SM +whimmed +whimming +whimper/DSG +whimsey's +whimsical/YP +whimsicality/MS +whimsy/TMDRS +whine/GZMSRD +whining/Y +whinny/GTDRS +whiny/RT +whip/SM +whipcord/SM +whiplash/SDMG +whipped +whipper/MS +whippersnapper/MS +whippet/MS +whipping/SM +whippletree/SM +whippoorwill/SM +whips/M +whipsaw/GDMS +whir/SY +whirl/RDGS +whirligig/MS +whirlpool/MS +whirlwind/MS +whirly/MS +whirlybird/MS +whirred +whirring +whisk/GZRDS +whisker/DM +whiskery +whiskey/SM +whisper/GRDJZS +whisperer/M +whispering/YM +whist/GDMS +whistle/DRSZG +whistleable +whistler/M +whistling/M +whit/SJGTXMRND +white/PYS +whitebait/M +whitecap/MS +whiteface/M +whitefish/SM +whitehead/S +whiten/JZDRG +whitener/M +whiteness/MS +whitening/M +whiteout/S +whitespace +whitetail/S +whitewall/SM +whitewash/GRSDM +whitewater +whitey/MS +whither/DGS +whitier +whitiest +whiting/M +whitish +whitter +whittle/JDRSZG +whittler/M +whiz +whizkid +whizzbang/S +whizzed +whizzes +whizzing +who'd +who'll +who're +who've +who/M +whoa/S +whodunit/SM +whoever +whole/SP +wholegrain +wholehearted/PY +wholeheartedness/MS +wholemeal +wholeness/S +wholesale/GZMSRD +wholesaler/M +wholesome/UYP +wholesomeness/USM +wholewheat +wholly +whom +whomever +whomsoever +whoop/SRDGZ +whoopee/S +whooper/M +whoosh/DSGM +whop +whopper/MS +whopping/S +whore/SDGM +whorehouse/SM +whoreish +whorish +whorl/SDM +whose +whoso +whosoever +why +whys +wick/GZRDMS +wicked/RYPT +wickedness/MS +wicker/M +wickerwork/MS +wicket/SM +wicketkeeper/SM +wicking/M +wide/RSYTP +widemouthed +widen/SGZRD +widener/M +wideness/S +widespread +widgeon's +widget/SM +widow/MRDSGZ +widower/M +widowhood/S +width/M +widths +widthwise +wield/GZRDS +wielder/M +wiener/SM +wienie/SM +wife/DSMYG +wifeless +wifely/RPT +wig/MS +wigeon/MS +wigged +wigging/M +wiggle/RSDGZ +wiggler/M +wiggly/RT +wight/SGDM +wiglet/S +wigmaker +wigwag/S +wigwagged +wigwagging +wigwam/MS +wild/SPGTYRD +wildcat/SM +wildcatted +wildcatter/MS +wildcatting +wildebeest/SM +wilder/P +wilderness/SM +wildfire/MS +wildflower/S +wildfowl/M +wilding/M +wildlife/M +wildness/MS +wile/DSMG +wilfulness's +wilily +wiliness/MS +will/SGJRD +willed/U +willer/M +willful/YP +willfulness/S +willies +willing/UYP +willinger +willingest +willingness's +willingness/US +williwaw/MS +willow/RDMSG +willower/M +willowy/TR +willpower/MS +wilt/DGS +wily/PTR +wimp/GSMD +wimpish +wimple/SDGM +wimpy/RT +win/ZGDRS +wince/SDG +winch/GRSDM +wincher/M +winchester/M +wind's +wind/USRZG +windbag/SM +windblown +windbreak/MZSR +windburn/GSMD +winded +winder/UM +windfall/SM +windflower/MS +windily +windiness/SM +winding/MS +windjammer/SM +windlass/GMSD +windless/YP +windmill/GDMS +window/DMGS +windowless +windowpane/SM +windowsill/SM +windpipe/SM +windproof +windrow/GDMS +winds/A +windscreen/MS +windshield/SM +windsock/MS +windstorm/MS +windsurf/GZJSRD +windswept +windup/MS +windward/SY +windy/TPR +wine/MS +wineglass/SM +winegrower/SM +winemake +winemaster +winery/MS +wineskin/M +wing/GZRDM +wingback/M +wingding/MS +wingeing +winger/M +wingless +winglike +wingman +wingmen +wingspan/SM +wingspread/MS +wingtip/S +wink/GZRDS +winker/M +winking/U +winkle/SDGM +winless +winnable +winner/MS +winning/SY +winnow/SZGRD +wino/MS +winsome/PRTY +winsomeness/SM +winter/SGRDYM +winterer/M +wintergreen/SM +winterize/GSD +wintertime/MS +wintriness/M +wintry/TPR +winy/RT +wipe/DRSZG +wiper/M +wire's +wire/UDA +wirehair/MS +wireless/MSDG +wireman/M +wiremen +wirer/M +wires/A +wiretap/MS +wiretapped +wiretapper/SM +wiretapping +wiriness/S +wiring/SM +wiry/RTP +wisdom/UM +wisdoms +wise/URTY +wiseacre/MS +wisecrack/GMRDS +wised +wisely/TR +wiseness +wisenheimer/M +wises +wish/GZSRD +wishbone/MS +wishful/PY +wishfulness/M +wishy +wising +wisp/MDGS +wispy/RT +wist/DGS +wisteria/SM +wistful/PY +wistfulness/MS +wit/PSM +witch/SDMG +witchcraft/SM +witchdoctor/S +witchery/MS +with/GSRDZ +withal +withdraw/RGS +withdrawal/MS +withdrawer/M +withdrawn/P +withdrawnness/M +withdrew +withe/M +wither/GDJ +withering/Y +withheld +withhold/SJGZR +withholder/M +within/S +without/S +withs +withstand/SG +withstood +witless/PY +witlessness/MS +witness/DSMG +witnessed/U +witted +witter/G +witticism/MS +wittily +wittiness/SM +witting/UY +wittings +witty/RTP +wive/GDS +wives/M +wiz's +wizard/MYS +wizardry/MS +wizen/D +wk/Y +woad/MS +wobble/GSRD +wobbler/M +wobbliness/S +wobbly/PRST +woe/PSM +woebegone/P +woeful/PY +woefuller +woefullest +woefulness/SM +wok/SMN +woke +wold/MS +wolf/RDMGS +wolfer/M +wolfhound/MS +wolfish/YP +wolfishness/M +wolfram/MS +wolverine/SM +wolves/M +woman/GSMYD +womanhood/MS +womanish +womanize/RSDZG +womanized/U +womanizer/M +womanizes/U +womankind/M +womanlike +womanliness/SM +womanly/PRT +womb/SDM +wombat/MS +women/MS +womenfolk/MS +won't +won/SG +wonder/GLRDMS +wonderer/M +wonderful/PY +wonderfulness/SM +wondering/Y +wonderland/SM +wonderment/SM +wondrous/YP +wondrousness/M +wonk/S +wonky/RT +wonned +wonning +wont/SGMD +wonted/PUY +wontedness/MU +woo/DRZGS +wood/SMNDG +woodbine/SM +woodblock/S +woodcarver/S +woodcarving/MS +woodchopper/SM +woodchuck/MS +woodcock/MS +woodcraft/MS +woodcut/SM +woodcutter/MS +woodcutting/MS +wooden/TPRY +woodenness/SM +woodgrain/G +woodhen +woodiness/MS +woodland/SRM +woodlice +woodlot/S +woodlouse/M +woodman/M +woodmen +woodpecker/SM +woodpile/SM +woodruff/M +woods/R +woodshed/SM +woodshedded +woodshedding +woodside +woodsman/M +woodsmen +woodsmoke +woodsy/TRP +woodwind/S +woodwork/SMRGZJ +woodworker/M +woodworking/M +woodworm/M +woody/TPSR +woodyard +woof/SRDMGZ +woofer/M +wool/SMYNDX +woolgather/RGJ +woolgatherer/M +woolgathering/M +woolliness/MS +woolly/RSPT +woozily +wooziness/MS +woozy/RTP +wop/MS! +word's +word/AGSJD +wordage/SM +wordbook/MS +wordily +wordiness/SM +wording/AM +wordless/Y +wordplay/SM +wordy/TPR +wore +work/GZJSRDMB +workability's +workability/U +workable/U +workableness/M +workably +workaday +workaholic/S +workaround/SM +workbench/MS +workbook/SM +workday/SM +worked/A +worker/M +workfare/S +workforce/S +workhorse/MS +workhouse/SM +working/M +workingman/M +workingmen +workingwoman/M +workingwomen +workload/SM +workman/MY +workmanlike +workmanship/MS +workmate/S +workmen/M +workout/SM +workpiece/SM +workplace/SM +workroom/MS +works/A +worksheet/S +workshop/MS +workspace/S +workstation/MS +worktable/SM +worktop/S +workup/S +workweek/SM +world/ZSYM +worldlier +worldliest +worldliness/USM +worldly/UP +worldwide +worm/SGMRD +wormer/M +wormhole/SM +wormwood/SM +wormy/RT +worn/U +worried/Y +worrier/M +worriment/MS +worrisome/YP +worry/ZGSRD +worrying/Y +worrywart/SM +worse/SR +worsen/GSD +worship/ZDRGS +worshiper/M +worshipful/YP +worshipfulness/M +worst/SGD +worsted/MS +wort/SM +worth/DG +worthily/U +worthiness/SM +worthinesses/U +worthless/PY +worthlessness/SM +worths +worthwhile/P +worthy/UTSRP +wost +wot +would've +would/S +wouldn't +wouldst +wound's +wound/AU +wounded/U +wounder +wounding +wounds +wove/A +woven/AU +wovens +wow/SDG +wpm +wrack/SGMD +wraith/M +wraiths +wrangle/GZDRS +wrangler/M +wrap/MS +wraparound/S +wrapped/U +wrapper/MS +wrapping/SM +wraps/U +wrasse/SM +wrath/GDM +wrathful/YP +wraths +wreak/SDG +wreath/GMDS +wreathe +wreaths +wreck/GZRDS +wreckage/MS +wrecker/M +wren/MS +wrench/MDSG +wrenching/Y +wrest/SRDG +wrester/M +wrestle/JGZDRS +wrestler/M +wrestling/M +wretch/MDS +wretched/TPYR +wretchedness/SM +wriggle/DRSGZ +wriggler/M +wriggly/RT +wright/MS +wring/GZRS +wringer/M +wrinkle/GMDS +wrinkled/U +wrinkly/RST +wrist/MS +wristband/SM +wristwatch/MS +writ/MRSBJGZ +writable/U +write/ASBRJG +writer/MA +writeup +writhe/SDG +writing/M +written/UA +wrong/PSGTYRD +wrongdoer/MS +wrongdoing/MS +wronger/M +wrongful/PY +wrongfulness/MS +wrongheaded/PY +wrongheadedness/MS +wrongness/MS +wrote/A +wroth +wrought/I +wrung +wry/DSGY +wryer +wryest +wryness/SM +wt +wurst/SM +wuss/S +wussy/TRS +x +xenon/SM +xenophobe/MS +xenophobia/SM +xenophobic +xerographic +xerography/MS +xerox/GSD +xi/M +xii +xiii +xis +xiv +xix +xterm/M +xv +xvi +xvii +xviii +xx +xylem/SM +xylene/M +xylophone/MS +xylophonist/S +y'all +y/F +ya +yacc/M +yacht/ZGJSDM +yachting/M +yachtsman +yachtsmen +yachtswoman/M +yachtswomen +yack's +yahoo/MS +yak/SM +yakked +yakking +yam/SM +yammer/RDZGS +yang/S +yank/GDS +yap/S +yapped +yapping +yard/SMDG +yardage/SM +yardarm/SM +yardman/M +yardmaster/S +yardmen +yardstick/SM +yarmulke/SM +yarn/SGDM +yarrow/MS +yaw/DSG +yawl/SGMD +yawn/GZSDR +yawner/M +yawning/Y +yd +ye/T +yea/S +yeah +yeahs +year/YMS +yearbook/SM +yearling/M +yearlong +yearly/S +yearn/JSGRD +yearner/M +yearning/MY +yeast/SGDM +yeastiness/M +yeasty/PTR +yecch +yegg/MS +yell/GSDR +yellow/TGPSRDM +yellowhammers +yellowish +yellowness/MS +yellowy +yelp/GSDR +yelper/M +yen/SM +yenned +yenning +yeoman/YM +yeomanry/MS +yeomen +yep/S +yes/S +yeshiva/SM +yessed +yessing +yesterday/MS +yesteryear/SM +yet +yeti/SM +yew/SM +yield/JGRDS +yielded/U +yielding/U +yikes +yin/S +yip/S +yipe/S +yipped +yippee/S +yipping +yo +yodel/SZRDG +yodeler/M +yoga/MS +yoghurt's +yogi/MS +yogurt/SM +yoke/DSMG +yoked/U +yokel/SM +yokes/U +yoking/U +yolk/DMS +yon +yonder +yore/MS +yorker/SM +you'd +you'll +you're +you've +you/SH +young/TRYP +youngish +youngster/MS +your/MS +yourself +yourselves +youth/SM +youthful/YP +youthfulness/SM +youths +yow +yowl/GSD +yr +yrs +ytterbium/MS +yttrium/SM +yuan/M +yucca/MS +yuck/GSD +yucky/RT +yuk/S +yukked +yukking +yule/MS +yuletide/MS +yum +yummy/TRS +yup/S +yuppie/SM +yurt/SM +z/TGJ +zag/S +zagging +zaniness/MS +zany/PDSRTG +zap/S +zapped +zapper/S +zapping +zeal/MS +zealot/MS +zealotry/MS +zealous/YP +zealousness/SM +zebra/MS +zebu/SM +zed/SM +zeitgeist/S +zenith/M +zeniths +zephyr/MS +zeppelin/SM +zero/SDHMG +zeroed/M +zeroing/M +zest/MDSG +zestful/YP +zestfulness/MS +zesty/RT +zeta/SM +zeugma/M +zig +zigged +zigging +zigzag/MS +zigzagged +zigzagger +zigzagging +zilch/S +zillion/MS +zinc/MS +zincked +zincking +zing/GZDRM +zingy/RT +zinnia/SM +zip/MS +zipped/U +zipper/GSDM +zipping/U +zippy/RT +zips/U +zircon/SM +zirconium/MS +zit/S +zither/SM +zloty/SM +zodiac/SM +zodiacal +zombi's +zombie/SM +zonal/Y +zone/MYDSRJG +zoned/A +zones/A +zoning/A +zonked +zoo/SM +zookeepers +zoological/Y +zoologist/SM +zoology/MS +zoom/DGS +zoophyte/SM +zoophytic +zounds/S +zucchini/SM +zwieback/MS +zydeco/S +zygote/SM +zygotic +zymurgy/S +�ngstr�m/M +�clair/MS +�clat/MS +�lan/M +�migr�/S +�p�e/S +�tude/MS diff --git a/scripts/hunspell/isocpp.dic b/scripts/hunspell/isocpp.dic new file mode 100644 index 000000000..4317579a8 --- /dev/null +++ b/scripts/hunspell/isocpp.dic @@ -0,0 +1,685 @@ +' +10'000 +0xFF0000 +0b0101'0101 +10x +'14 +20x +2D +2K +2ndEdition +2RDU00001 +3rdEdition +78e +86xWVb4XIyE +98's +à +a1 +A1 +a2 +A2 +aa +ABA +abi +ABI +ABIs +Abrahams +Abrahams01 +abstr +accessor +ack +ACCU +addressof +adl +ADL +Adve +Alexandrescu +Alexandrescu01 +algo +alloc +alloc0 +ap +API +APIs +archetypical +arg +argh +args +arithmeticcast +arr2 +arrayindex +ASIC +asio +AST +async +AUTOSAR +'B' +b2 +BDE +behaviorless +BigTrivial +BigObject +Bjarne +blog +Bloomberg +Boehm +bool +buf +bufmax +bY +C1 +C11 +C2 +callees +callers' +call's +camelCase +CamelCase +CaMelcAse +CaMeLcAsEvArIaBlE +Cargill +Cargill92 +cbegin +CComPtr +cend +cerr +chrono +cin +Clang's +class' +clib +Cline99 +ClosePort +cm3 +cnt +CommonMark +*compiletime +completers +componentization +composability +composable +ComputationCache +conceptsTS +cond +const +Const +constcast +constexpr +constness +constref +copy2 +coro +CORBA +cout +CP +cplusplus +Cplusplus +Cplusplus03 +CplusplusCS +cpp +cpp98 +CppCon +CppCoreCheck +cppcoreguidelines +cppreference +CRTP +cst +cstdarg +cstdio +cstring +cstylecast +ctor +ctors +cxx +cyclomatic +Cyclomatic +czstring +d1 +D1 +d1's +d2 +D2 +d2's +dag +DataRecord +dcl +dd +de +Dechev +default0 +default00 +defop +del +deref +derived1 +derived2 +destructors +Destructors +detach +Dewhurst +Dewhurst03 +disambiguator +draw2 +dtor +dtors +dyn +dynarray +ECBS +endl +enum +Enum +enums +EoP +eq +eqdefault +EqualityComparable +errno +expr +f1 +f2 +f3 +f4 +fac +Facebook +fallthrough +fallthroughs +faq +fclose +fct +fib10 +file1 +file2 +file3 +filesystem +flag1 +fmt +fn +fo +foo +Foo +foobar +Foobar +FOOBAR +fopen +fprintf's +fs +func +func1 +fx +g1 +g2 +GCC +Geosoft +getline +getx +GFM +Girou +github +GitHub +GOTW +gp +GPLv3 +grep +gsl +GSL +GSL's +gx +handcoded +Henricson +Henricson97 +Herlihy +hh +hier +hierclass +hnd +homebrew +HPL +href +HTTP +Hyslop +i2 +IDE +identitycast +IDEs +IEC +ifdef +iff +ifstream +impactful +impl +Impl +implicitpointercast +incform +incomplet +incorrekt +increment1 +Incrementable +indices +ing +init +inline +inlined +inlining +inout +InputIterator +int32 +int64 +ints +io +ios +iostream +Iostream +iostreams +iso +isocpp +ISORC +istream +Iter +Jiangang +jmp +join's +JSF +jthread +Juhl +knr +Koenig97 +l +Lakos +Lakos96 +Lavavej +LCSD05 +legacy_class +lifecycle +*life-time +linearization +llvm +lockfree +Lomow +longjmp +LSP +lst +Luchangco +lvalue +lvalues +m1 +m2 +m3 +m_owning; +m_observer; +macros2 +malloc +mallocfree +'many' +Mathematizing +maul2 +md +memberinit +members' +memcmp +memcpy +memmove +memoization +memoized +memoizes +memset +metameta +metaprogram +metaprograms +metaprogramming +Metaprogramming +Meyers01 +Meyers05 +Meyers15 +Meyers96 +Meyers97 +microbenchmarks +middleware +MISRA +mixin +mixins +mnemonizes +modify1 +modify2 +moredata +*multithreaded +msgsl +mtx +Murray93 +mutex +mutexes +mx +My_vector +MyCustomError +MyException +myMap +MyMap +myset +myX +n' +naïvely +namespace +namespaces +Namespaces +NaN +nargs +Naumann +ness +newdelete +nh +Nir +NL +nodiscard +noexcept +noname +nondependent +nonexported +nongeneric +nonlocally +nonprivate +nonreusable +nonvirtual +nonvirtually +nothrow +NR +nullness +nullptr +NVI +ofstream +ok +oo +OO +OOP +OOPSLA'09 +oper +optimizable +O'Reilly +org +ostream +ostringstream +overabstract +overconstrain +overconstrained +overridable +overriders +p1 +p2 +p3 +pµÃoorly +Pardoe +parens +passthrough +pb +pb1 +pb2 +pc +performant +pessimization +picture1 +pimpl +Pimpl +Pirkelbauer +PL4 +PLDI +Poco +PODs +poly +polymorphically +POPL +PortHandle +PostInitialize +pp216 +PPP +pragma +pre +Pre +precomputation +prefetcher +printf +printf's +Proc +productinfo +Productinfo +proto +ps +ptr +ptrdiff +Ptr +ptr2 +ptr's +q2 +qqq +qsort +R0 +r2 +raii +RAII +Rc +Rclib +rcon +Rcon +Rconc +Rconst +rcoro +Rcpl +*realtime +Rec2 +refactor +refactored +refcount +refcounted +regex +Regex +RegularFunction +reimplement +reinterpretcast +Reis +Reis's +Renum +reseat +reseating +reseats +resizable +rethrow +rethrowing +retryable +*re-use +*re-usable +*re-usability +*Re-usability +reusability +Reusability +rf +Ri +Rl +rnd +Rnr +Ro +Rouquette +Rp +Rper +Rr +rr +RRconc +Rsl +Rstr +RTTI +rvalue +rvalues +RVO +'s +s1 +s1's +s2 +s3 +Sarkar +scanf +Sd +SEI +semiregular +Semiregular +SemiRegular +Sergey +Sewell +SFINAE +Shavit +sharedFoo +sharedness +sharedptrparam +'sharedptrparam' +setjmp +SignedIntegral +signedness +simpleFunc +'size' +sizeof +sl +SL +smartptrconcepts +smartptrget +smartptrparam +smartptrs +SMS +Sommerlad +SomeLargeType +SomeOtherFunction +specialization2 +spinlock +splonk +splunk +SScp +stdarg +stdlib +Stepanov +stl +STL +stmt +str +strdup +stringification +stringlike +strlen +Str15 +Stroustrup +Stroustrup00 +Stroustrup05 +Stroustrup13 +Stroustrup14 +Stroustrup15 +Stroustrup94 +Stroustrup's +struct +structs +subobject +subobjects +suboperations +subsetting +sum1 +sum2 +supertype +Susmit +SuttAlex05 +Sutter +Sutter00 +Sutter02 +Sutter04 +Sutter's +SuttHysl04b +sz +T0 +t0 +Taligent94 +Taligent's +TBD +templated +Templating +templatize +templatized +thread1 +thread2 +Tjark +tmp +TMP +tock +TODO +tolower +toolchains +TotallyOrdered +TP +tradeoff +TSAN +TSs +tt +typeid +typename +typesafe +UB +u1 +u2 +UDLs +unaliased +uncompromised +uncopyable +underuse +undetached +unencapsulated +unenforceable +uninit +uniqueptrparam +unittest +unittests +unnamed2 +use1 +users' +UTF +util +v's +v1 +v17 +v2 +v22 +va +ValueType +vararg +varargs +variables' +variadic +Variadic +vbase +vd1 +vec +Vector0 +Vector1 +Vector2 +vid +virtuality +virtuals +VLAs +volatile2 +vptr +vr +vtable +vtbls +vv +w0 +wchar +webby +Webcolor +webcolors +WG21 +WidgetUser +WorkQueue +'widen' +x1 +x2 +x22 +xmax +xor +Xs +y1 +y2 +years' +yy +Zhuang +zstring +Zubkov +zz diff --git a/scripts/nodejs/package.json b/scripts/nodejs/package.json new file mode 100644 index 000000000..ff4453ab2 --- /dev/null +++ b/scripts/nodejs/package.json @@ -0,0 +1,12 @@ +{ + "name": "CppCoreGuidelinesCheck", + "version": "0.0.0", + "description": "CppCoreGuidelines Check", + "private": true, + "dependencies": { + "remark": "^4.2.2", + "remark-lint": "^4.0.2", + "remark-lint-sentence-newline": "^2.0.0", + "remark-validate-links": "^4.1.0" + } +} diff --git a/scripts/nodejs/remark/.remarkrc b/scripts/nodejs/remark/.remarkrc new file mode 100644 index 000000000..9b4ed377b --- /dev/null +++ b/scripts/nodejs/remark/.remarkrc @@ -0,0 +1,31 @@ +{ + "presets": ["lint-recommended", "lint-consistent"], + "plugins": { + "remark-lint": { + "unordered-list-marker-style": "consistent", + "list-item-bullet-indent": true, + "list-item-indent": false, + "list-item-spacing": false, + "no-html": false, + "maximum-line-length": false, + "no-file-name-mixed-case": false, + "heading-increment": false, + "no-multiple-toplevel-headings": true, + "no-consecutive-blank-lines": false, + "maximum-line-length": 9000, + "maximum-heading-length": 300, + "no-heading-punctuation": false, + "no-duplicate-headings": false, + "emphasis-marker": "*", + "no-tabs": true, + "blockquote-indentation": false, + "strong-marker": "*" + } + }, + "settings": { + "bullet": "*", + "listItemIndent": "1", + "strong": "*", + "emphasis": "*" + } +} diff --git a/scripts/python/Makefile.in b/scripts/python/Makefile.in new file mode 100644 index 000000000..4ecff78fa --- /dev/null +++ b/scripts/python/Makefile.in @@ -0,0 +1,16 @@ +.PHONY: default +default: all + +.PHONY: all +all: \ +cpplint-all + +CXX_SRCS := $(wildcard *.cpp) + +#### cpplint, check extracted sources using cpplint tool +CXX_LINT := ${CXX_SRCS:.cpp=.lint} + +.PHONY: cpplint-all +cpplint-all: + @python ../../python/cpplint_wrap.py *.cpp + diff --git a/scripts/python/cpplint.py b/scripts/python/cpplint.py new file mode 100755 index 000000000..825c87c2a --- /dev/null +++ b/scripts/python/cpplint.py @@ -0,0 +1,6476 @@ +#!/usr/bin/env python +# +# Copyright (c) 2009 Google Inc. All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions are +# met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above +# copyright notice, this list of conditions and the following disclaimer +# in the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Google Inc. nor the names of its +# contributors may be used to endorse or promote products derived from +# this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +"""Does google-lint on c++ files. + +The goal of this script is to identify places in the code that *may* +be in non-compliance with google style. It does not attempt to fix +up these problems -- the point is to educate. It does also not +attempt to find all problems, or to ensure that everything it does +find is legitimately a problem. + +In particular, we can get very confused by /* and // inside strings! +We do a small hack, which is to ignore //'s with "'s after them on the +same line, but it is far from perfect (in either direction). +""" + +import codecs +import copy +import getopt +import glob +import itertools +import math # for log +import os +import re +import sre_compile +import string +import sys +import unicodedata +import xml.etree.ElementTree + +# if empty, use defaults +_header_extensions = set([]) + +# if empty, use defaults +_valid_extensions = set([]) + + +# Files with any of these extensions are considered to be +# header files (and will undergo different style checks). +# This set can be extended by using the --headers +# option (also supported in CPPLINT.cfg) +def GetHeaderExtensions(): + if not _header_extensions: + return set(['h', 'hpp', 'hxx', 'h++', 'cuh']) + return _header_extensions + +# The allowed extensions for file names +# This is set by --extensions flag +def GetAllExtensions(): + if not _valid_extensions: + return GetHeaderExtensions().union(set(['c', 'cc', 'cpp', 'cxx', 'c++', 'cu'])) + return _valid_extensions + +def GetNonHeaderExtensions(): + return GetAllExtensions().difference(GetHeaderExtensions()) + + +_USAGE = """ +Syntax: cpplint.py [--verbose=#] [--output=emacs|eclipse|vs7|junit] + [--filter=-x,+y,...] + [--counting=total|toplevel|detailed] [--repository=path] + [--root=subdir] [--linelength=digits] [--recursive] + [--exclude=path] + [--headers=ext1,ext2] + [--extensions=hpp,cpp,...] + [file] ... + + The style guidelines this tries to follow are those in + https://google.github.io/styleguide/cppguide.html + + Every problem is given a confidence score from 1-5, with 5 meaning we are + certain of the problem, and 1 meaning it could be a legitimate construct. + This will miss some errors, and is not a substitute for a code review. + + To suppress false-positive errors of a certain category, add a + 'NOLINT(category)' comment to the line. NOLINT or NOLINT(*) + suppresses errors of all categories on that line. + + The files passed in will be linted; at least one file must be provided. + Default linted extensions are %s. + Other file types will be ignored. + Change the extensions with the --extensions flag. + + Flags: + + output=emacs|eclipse|vs7|junit + By default, the output is formatted to ease emacs parsing. Output + compatible with eclipse (eclipse), Visual Studio (vs7), and JUnit + XML parsers such as those used in Jenkins and Bamboo may also be + used. Other formats are unsupported. + + verbose=# + Specify a number 0-5 to restrict errors to certain verbosity levels. + Errors with lower verbosity levels have lower confidence and are more + likely to be false positives. + + quiet + Supress output other than linting errors, such as information about + which files have been processed and excluded. + + filter=-x,+y,... + Specify a comma-separated list of category-filters to apply: only + error messages whose category names pass the filters will be printed. + (Category names are printed with the message and look like + "[whitespace/indent]".) Filters are evaluated left to right. + "-FOO" and "FOO" means "do not print categories that start with FOO". + "+FOO" means "do print categories that start with FOO". + + Examples: --filter=-whitespace,+whitespace/braces + --filter=whitespace,runtime/printf,+runtime/printf_format + --filter=-,+build/include_what_you_use + + To see a list of all the categories used in cpplint, pass no arg: + --filter= + + counting=total|toplevel|detailed + The total number of errors found is always printed. If + 'toplevel' is provided, then the count of errors in each of + the top-level categories like 'build' and 'whitespace' will + also be printed. If 'detailed' is provided, then a count + is provided for each category like 'build/class'. + + repository=path + The top level directory of the repository, used to derive the header + guard CPP variable. By default, this is determined by searching for a + path that contains .git, .hg, or .svn. When this flag is specified, the + given path is used instead. This option allows the header guard CPP + variable to remain consistent even if members of a team have different + repository root directories (such as when checking out a subdirectory + with SVN). In addition, users of non-mainstream version control systems + can use this flag to ensure readable header guard CPP variables. + + Examples: + Assuming that Alice checks out ProjectName and Bob checks out + ProjectName/trunk and trunk contains src/chrome/ui/browser.h, then + with no --repository flag, the header guard CPP variable will be: + + Alice => TRUNK_SRC_CHROME_BROWSER_UI_BROWSER_H_ + Bob => SRC_CHROME_BROWSER_UI_BROWSER_H_ + + If Alice uses the --repository=trunk flag and Bob omits the flag or + uses --repository=. then the header guard CPP variable will be: + + Alice => SRC_CHROME_BROWSER_UI_BROWSER_H_ + Bob => SRC_CHROME_BROWSER_UI_BROWSER_H_ + + root=subdir + The root directory used for deriving header guard CPP variables. This + directory is relative to the top level directory of the repository which + by default is determined by searching for a directory that contains .git, + .hg, or .svn but can also be controlled with the --repository flag. If + the specified directory does not exist, this flag is ignored. + + Examples: + Assuming that src is the top level directory of the repository, the + header guard CPP variables for src/chrome/browser/ui/browser.h are: + + No flag => CHROME_BROWSER_UI_BROWSER_H_ + --root=chrome => BROWSER_UI_BROWSER_H_ + --root=chrome/browser => UI_BROWSER_H_ + + linelength=digits + This is the allowed line length for the project. The default value is + 80 characters. + + Examples: + --linelength=120 + + recursive + Search for files to lint recursively. Each directory given in the list + of files to be linted is replaced by all files that descend from that + directory. Files with extensions not in the valid extensions list are + excluded. + + exclude=path + Exclude the given path from the list of files to be linted. Relative + paths are evaluated relative to the current directory and shell globbing + is performed. This flag can be provided multiple times to exclude + multiple files. + + Examples: + --exclude=one.cc + --exclude=src/*.cc + --exclude=src/*.cc --exclude=test/*.cc + + extensions=extension,extension,... + The allowed file extensions that cpplint will check + + Examples: + --extensions=%s + + headers=extension,extension,... + The allowed header extensions that cpplint will consider to be header files + (by default, only files with extensions %s + will be assumed to be headers) + + Examples: + --headers=%s + + cpplint.py supports per-directory configurations specified in CPPLINT.cfg + files. CPPLINT.cfg file can contain a number of key=value pairs. + Currently the following options are supported: + + set noparent + filter=+filter1,-filter2,... + exclude_files=regex + linelength=80 + root=subdir + + "set noparent" option prevents cpplint from traversing directory tree + upwards looking for more .cfg files in parent directories. This option + is usually placed in the top-level project directory. + + The "filter" option is similar in function to --filter flag. It specifies + message filters in addition to the |_DEFAULT_FILTERS| and those specified + through --filter command-line flag. + + "exclude_files" allows to specify a regular expression to be matched against + a file name. If the expression matches, the file is skipped and not run + through the linter. + + "linelength" specifies the allowed line length for the project. + + The "root" option is similar in function to the --root flag (see example + above). + + CPPLINT.cfg has an effect on files in the same directory and all + subdirectories, unless overridden by a nested configuration file. + + Example file: + filter=-build/include_order,+build/include_alpha + exclude_files=.*\\.cc + + The above example disables build/include_order warning and enables + build/include_alpha as well as excludes all .cc from being + processed by linter, in the current directory (where the .cfg + file is located) and all subdirectories. +""" % (list(GetAllExtensions()), + ','.join(list(GetAllExtensions())), + GetHeaderExtensions(), + ','.join(GetHeaderExtensions())) + +# We categorize each error message we print. Here are the categories. +# We want an explicit list so we can list them all in cpplint --filter=. +# If you add a new error message with a new category, add it to the list +# here! cpplint_unittest.py should tell you if you forget to do this. +_ERROR_CATEGORIES = [ + 'build/class', + 'build/c++11', + 'build/c++14', + 'build/c++tr1', + 'build/deprecated', + 'build/endif_comment', + 'build/explicit_make_pair', + 'build/forward_decl', + 'build/header_guard', + 'build/include', + 'build/include_subdir', + 'build/include_alpha', + 'build/include_order', + 'build/include_what_you_use', + 'build/namespaces_literals', + 'build/namespaces', + 'build/printf_format', + 'build/storage_class', + 'legal/copyright', + 'readability/alt_tokens', + 'readability/braces', + 'readability/casting', + 'readability/check', + 'readability/constructors', + 'readability/fn_size', + 'readability/inheritance', + 'readability/multiline_comment', + 'readability/multiline_string', + 'readability/namespace', + 'readability/nolint', + 'readability/nul', + 'readability/strings', + 'readability/todo', + 'readability/utf8', + 'runtime/arrays', + 'runtime/casting', + 'runtime/explicit', + 'runtime/int', + 'runtime/init', + 'runtime/invalid_increment', + 'runtime/member_string_references', + 'runtime/memset', + 'runtime/indentation_namespace', + 'runtime/operator', + 'runtime/printf', + 'runtime/printf_format', + 'runtime/references', + 'runtime/string', + 'runtime/threadsafe_fn', + 'runtime/vlog', + 'whitespace/blank_line', + 'whitespace/braces', + 'whitespace/comma', + 'whitespace/comments', + 'whitespace/empty_conditional_body', + 'whitespace/empty_if_body', + 'whitespace/empty_loop_body', + 'whitespace/end_of_line', + 'whitespace/ending_newline', + 'whitespace/forcolon', + 'whitespace/indent', + 'whitespace/line_length', + 'whitespace/newline', + 'whitespace/operators', + 'whitespace/parens', + 'whitespace/semicolon', + 'whitespace/tab', + 'whitespace/todo', + ] + +# These error categories are no longer enforced by cpplint, but for backwards- +# compatibility they may still appear in NOLINT comments. +_LEGACY_ERROR_CATEGORIES = [ + 'readability/streams', + 'readability/function', + ] + +# The default state of the category filter. This is overridden by the --filter= +# flag. By default all errors are on, so only add here categories that should be +# off by default (i.e., categories that must be enabled by the --filter= flags). +# All entries here should start with a '-' or '+', as in the --filter= flag. +_DEFAULT_FILTERS = ['-build/include_alpha'] + +# The default list of categories suppressed for C (not C++) files. +_DEFAULT_C_SUPPRESSED_CATEGORIES = [ + 'readability/casting', + ] + +# The default list of categories suppressed for Linux Kernel files. +_DEFAULT_KERNEL_SUPPRESSED_CATEGORIES = [ + 'whitespace/tab', + ] + +# We used to check for high-bit characters, but after much discussion we +# decided those were OK, as long as they were in UTF-8 and didn't represent +# hard-coded international strings, which belong in a separate i18n file. + +# C++ headers +_CPP_HEADERS = frozenset([ + # Legacy + 'algobase.h', + 'algo.h', + 'alloc.h', + 'builtinbuf.h', + 'bvector.h', + 'complex.h', + 'defalloc.h', + 'deque.h', + 'editbuf.h', + 'fstream.h', + 'function.h', + 'hash_map', + 'hash_map.h', + 'hash_set', + 'hash_set.h', + 'hashtable.h', + 'heap.h', + 'indstream.h', + 'iomanip.h', + 'iostream.h', + 'istream.h', + 'iterator.h', + 'list.h', + 'map.h', + 'multimap.h', + 'multiset.h', + 'ostream.h', + 'pair.h', + 'parsestream.h', + 'pfstream.h', + 'procbuf.h', + 'pthread_alloc', + 'pthread_alloc.h', + 'rope', + 'rope.h', + 'ropeimpl.h', + 'set.h', + 'slist', + 'slist.h', + 'stack.h', + 'stdiostream.h', + 'stl_alloc.h', + 'stl_relops.h', + 'streambuf.h', + 'stream.h', + 'strfile.h', + 'strstream.h', + 'tempbuf.h', + 'tree.h', + 'type_traits.h', + 'vector.h', + # 17.6.1.2 C++ library headers + 'algorithm', + 'array', + 'atomic', + 'bitset', + 'chrono', + 'codecvt', + 'complex', + 'condition_variable', + 'deque', + 'exception', + 'forward_list', + 'fstream', + 'functional', + 'future', + 'initializer_list', + 'iomanip', + 'ios', + 'iosfwd', + 'iostream', + 'istream', + 'iterator', + 'limits', + 'list', + 'locale', + 'map', + 'memory', + 'mutex', + 'new', + 'numeric', + 'ostream', + 'queue', + 'random', + 'ratio', + 'regex', + 'scoped_allocator', + 'set', + 'sstream', + 'stack', + 'stdexcept', + 'streambuf', + 'string', + 'strstream', + 'system_error', + 'thread', + 'tuple', + 'typeindex', + 'typeinfo', + 'type_traits', + 'unordered_map', + 'unordered_set', + 'utility', + 'valarray', + 'vector', + # 17.6.1.2 C++ headers for C library facilities + 'cassert', + 'ccomplex', + 'cctype', + 'cerrno', + 'cfenv', + 'cfloat', + 'cinttypes', + 'ciso646', + 'climits', + 'clocale', + 'cmath', + 'csetjmp', + 'csignal', + 'cstdalign', + 'cstdarg', + 'cstdbool', + 'cstddef', + 'cstdint', + 'cstdio', + 'cstdlib', + 'cstring', + 'ctgmath', + 'ctime', + 'cuchar', + 'cwchar', + 'cwctype', + ]) + +# Type names +_TYPES = re.compile( + r'^(?:' + # [dcl.type.simple] + r'(char(16_t|32_t)?)|wchar_t|' + r'bool|short|int|long|signed|unsigned|float|double|' + # [support.types] + r'(ptrdiff_t|size_t|max_align_t|nullptr_t)|' + # [cstdint.syn] + r'(u?int(_fast|_least)?(8|16|32|64)_t)|' + r'(u?int(max|ptr)_t)|' + r')$') + + +# These headers are excluded from [build/include] and [build/include_order] +# checks: +# - Anything not following google file name conventions (containing an +# uppercase character, such as Python.h or nsStringAPI.h, for example). +# - Lua headers. +_THIRD_PARTY_HEADERS_PATTERN = re.compile( + r'^(?:[^/]*[A-Z][^/]*\.h|lua\.h|lauxlib\.h|lualib\.h)$') + +# Pattern for matching FileInfo.BaseName() against test file name +_test_suffixes = ['_test', '_regtest', '_unittest'] +_TEST_FILE_SUFFIX = '(' + '|'.join(_test_suffixes) + r')$' + +# Pattern that matches only complete whitespace, possibly across multiple lines. +_EMPTY_CONDITIONAL_BODY_PATTERN = re.compile(r'^\s*$', re.DOTALL) + +# Assertion macros. These are defined in base/logging.h and +# testing/base/public/gunit.h. +_CHECK_MACROS = [ + 'DCHECK', 'CHECK', + 'EXPECT_TRUE', 'ASSERT_TRUE', + 'EXPECT_FALSE', 'ASSERT_FALSE', + ] + +# Replacement macros for CHECK/DCHECK/EXPECT_TRUE/EXPECT_FALSE +_CHECK_REPLACEMENT = dict([(macro_var, {}) for macro_var in _CHECK_MACROS]) + +for op, replacement in [('==', 'EQ'), ('!=', 'NE'), + ('>=', 'GE'), ('>', 'GT'), + ('<=', 'LE'), ('<', 'LT')]: + _CHECK_REPLACEMENT['DCHECK'][op] = 'DCHECK_%s' % replacement + _CHECK_REPLACEMENT['CHECK'][op] = 'CHECK_%s' % replacement + _CHECK_REPLACEMENT['EXPECT_TRUE'][op] = 'EXPECT_%s' % replacement + _CHECK_REPLACEMENT['ASSERT_TRUE'][op] = 'ASSERT_%s' % replacement + +for op, inv_replacement in [('==', 'NE'), ('!=', 'EQ'), + ('>=', 'LT'), ('>', 'LE'), + ('<=', 'GT'), ('<', 'GE')]: + _CHECK_REPLACEMENT['EXPECT_FALSE'][op] = 'EXPECT_%s' % inv_replacement + _CHECK_REPLACEMENT['ASSERT_FALSE'][op] = 'ASSERT_%s' % inv_replacement + +# Alternative tokens and their replacements. For full list, see section 2.5 +# Alternative tokens [lex.digraph] in the C++ standard. +# +# Digraphs (such as '%:') are not included here since it's a mess to +# match those on a word boundary. +_ALT_TOKEN_REPLACEMENT = { + 'and': '&&', + 'bitor': '|', + 'or': '||', + 'xor': '^', + 'compl': '~', + 'bitand': '&', + 'and_eq': '&=', + 'or_eq': '|=', + 'xor_eq': '^=', + 'not': '!', + 'not_eq': '!=' + } + +# Compile regular expression that matches all the above keywords. The "[ =()]" +# bit is meant to avoid matching these keywords outside of boolean expressions. +# +# False positives include C-style multi-line comments and multi-line strings +# but those have always been troublesome for cpplint. +_ALT_TOKEN_REPLACEMENT_PATTERN = re.compile( + r'[ =()](' + ('|'.join(_ALT_TOKEN_REPLACEMENT.keys())) + r')(?=[ (]|$)') + + +# These constants define types of headers for use with +# _IncludeState.CheckNextIncludeOrder(). +_C_SYS_HEADER = 1 +_CPP_SYS_HEADER = 2 +_LIKELY_MY_HEADER = 3 +_POSSIBLE_MY_HEADER = 4 +_OTHER_HEADER = 5 + +# These constants define the current inline assembly state +_NO_ASM = 0 # Outside of inline assembly block +_INSIDE_ASM = 1 # Inside inline assembly block +_END_ASM = 2 # Last line of inline assembly block +_BLOCK_ASM = 3 # The whole block is an inline assembly block + +# Match start of assembly blocks +_MATCH_ASM = re.compile(r'^\s*(?:asm|_asm|__asm|__asm__)' + r'(?:\s+(volatile|__volatile__))?' + r'\s*[{(]') + +# Match strings that indicate we're working on a C (not C++) file. +_SEARCH_C_FILE = re.compile(r'\b(?:LINT_C_FILE|' + r'vim?:\s*.*(\s*|:)filetype=c(\s*|:|$))') + +# Match string that indicates we're working on a Linux Kernel file. +_SEARCH_KERNEL_FILE = re.compile(r'\b(?:LINT_KERNEL_FILE)') + +_regexp_compile_cache = {} + +# {str, set(int)}: a map from error categories to sets of linenumbers +# on which those errors are expected and should be suppressed. +_error_suppressions = {} + +# The root directory used for deriving header guard CPP variable. +# This is set by --root flag. +_root = None + +# The top level repository directory. If set, _root is calculated relative to +# this directory instead of the directory containing version control artifacts. +# This is set by the --repository flag. +_repository = None + +# Files to exclude from linting. This is set by the --exclude flag. +_excludes = None + +# Whether to supress PrintInfo messages +_quiet = False + +# The allowed line length of files. +# This is set by --linelength flag. +_line_length = 80 + +try: + xrange(1, 0) +except NameError: + # -- pylint: disable=redefined-builtin + xrange = range + +try: + unicode +except NameError: + # -- pylint: disable=redefined-builtin + basestring = unicode = str + +try: + long(2) +except NameError: + # -- pylint: disable=redefined-builtin + long = int + +if sys.version_info < (3,): + # -- pylint: disable=no-member + # BINARY_TYPE = str + itervalues = dict.itervalues + iteritems = dict.iteritems +else: + # BINARY_TYPE = bytes + itervalues = dict.values + iteritems = dict.items + +def unicode_escape_decode(x): + if sys.version_info < (3,): + return codecs.unicode_escape_decode(x)[0] + else: + return x + +# {str, bool}: a map from error categories to booleans which indicate if the +# category should be suppressed for every line. +_global_error_suppressions = {} + + + + +def ParseNolintSuppressions(filename, raw_line, linenum, error): + """Updates the global list of line error-suppressions. + + Parses any NOLINT comments on the current line, updating the global + error_suppressions store. Reports an error if the NOLINT comment + was malformed. + + Args: + filename: str, the name of the input file. + raw_line: str, the line of input text, with comments. + linenum: int, the number of the current line. + error: function, an error handler. + """ + matched = Search(r'\bNOLINT(NEXTLINE)?\b(\([^)]+\))?', raw_line) + if matched: + if matched.group(1): + suppressed_line = linenum + 1 + else: + suppressed_line = linenum + category = matched.group(2) + if category in (None, '(*)'): # => "suppress all" + _error_suppressions.setdefault(None, set()).add(suppressed_line) + else: + if category.startswith('(') and category.endswith(')'): + category = category[1:-1] + if category in _ERROR_CATEGORIES: + _error_suppressions.setdefault(category, set()).add(suppressed_line) + elif category not in _LEGACY_ERROR_CATEGORIES: + error(filename, linenum, 'readability/nolint', 5, + 'Unknown NOLINT error category: %s' % category) + + +def ProcessGlobalSuppresions(lines): + """Updates the list of global error suppressions. + + Parses any lint directives in the file that have global effect. + + Args: + lines: An array of strings, each representing a line of the file, with the + last element being empty if the file is terminated with a newline. + """ + for line in lines: + if _SEARCH_C_FILE.search(line): + for category in _DEFAULT_C_SUPPRESSED_CATEGORIES: + _global_error_suppressions[category] = True + if _SEARCH_KERNEL_FILE.search(line): + for category in _DEFAULT_KERNEL_SUPPRESSED_CATEGORIES: + _global_error_suppressions[category] = True + + +def ResetNolintSuppressions(): + """Resets the set of NOLINT suppressions to empty.""" + _error_suppressions.clear() + _global_error_suppressions.clear() + + +def IsErrorSuppressedByNolint(category, linenum): + """Returns true if the specified error category is suppressed on this line. + + Consults the global error_suppressions map populated by + ParseNolintSuppressions/ProcessGlobalSuppresions/ResetNolintSuppressions. + + Args: + category: str, the category of the error. + linenum: int, the current line number. + Returns: + bool, True iff the error should be suppressed due to a NOLINT comment or + global suppression. + """ + return (_global_error_suppressions.get(category, False) or + linenum in _error_suppressions.get(category, set()) or + linenum in _error_suppressions.get(None, set())) + + +def Match(pattern, s): + """Matches the string with the pattern, caching the compiled regexp.""" + # The regexp compilation caching is inlined in both Match and Search for + # performance reasons; factoring it out into a separate function turns out + # to be noticeably expensive. + if pattern not in _regexp_compile_cache: + _regexp_compile_cache[pattern] = sre_compile.compile(pattern) + return _regexp_compile_cache[pattern].match(s) + + +def ReplaceAll(pattern, rep, s): + """Replaces instances of pattern in a string with a replacement. + + The compiled regex is kept in a cache shared by Match and Search. + + Args: + pattern: regex pattern + rep: replacement text + s: search string + + Returns: + string with replacements made (or original string if no replacements) + """ + if pattern not in _regexp_compile_cache: + _regexp_compile_cache[pattern] = sre_compile.compile(pattern) + return _regexp_compile_cache[pattern].sub(rep, s) + + +def Search(pattern, s): + """Searches the string for the pattern, caching the compiled regexp.""" + if pattern not in _regexp_compile_cache: + _regexp_compile_cache[pattern] = sre_compile.compile(pattern) + return _regexp_compile_cache[pattern].search(s) + + +def _IsSourceExtension(s): + """File extension (excluding dot) matches a source file extension.""" + return s in GetNonHeaderExtensions() + + +class _IncludeState(object): + """Tracks line numbers for includes, and the order in which includes appear. + + include_list contains list of lists of (header, line number) pairs. + It's a lists of lists rather than just one flat list to make it + easier to update across preprocessor boundaries. + + Call CheckNextIncludeOrder() once for each header in the file, passing + in the type constants defined above. Calls in an illegal order will + raise an _IncludeError with an appropriate error message. + + """ + # self._section will move monotonically through this set. If it ever + # needs to move backwards, CheckNextIncludeOrder will raise an error. + _INITIAL_SECTION = 0 + _MY_H_SECTION = 1 + _C_SECTION = 2 + _CPP_SECTION = 3 + _OTHER_H_SECTION = 4 + + _TYPE_NAMES = { + _C_SYS_HEADER: 'C system header', + _CPP_SYS_HEADER: 'C++ system header', + _LIKELY_MY_HEADER: 'header this file implements', + _POSSIBLE_MY_HEADER: 'header this file may implement', + _OTHER_HEADER: 'other header', + } + _SECTION_NAMES = { + _INITIAL_SECTION: "... nothing. (This can't be an error.)", + _MY_H_SECTION: 'a header this file implements', + _C_SECTION: 'C system header', + _CPP_SECTION: 'C++ system header', + _OTHER_H_SECTION: 'other header', + } + + def __init__(self): + self.include_list = [[]] + self._section = None + self._last_header = None + self.ResetSection('') + + def FindHeader(self, header): + """Check if a header has already been included. + + Args: + header: header to check. + Returns: + Line number of previous occurrence, or -1 if the header has not + been seen before. + """ + for section_list in self.include_list: + for f in section_list: + if f[0] == header: + return f[1] + return -1 + + def ResetSection(self, directive): + """Reset section checking for preprocessor directive. + + Args: + directive: preprocessor directive (e.g. "if", "else"). + """ + # The name of the current section. + self._section = self._INITIAL_SECTION + # The path of last found header. + self._last_header = '' + + # Update list of includes. Note that we never pop from the + # include list. + if directive in ('if', 'ifdef', 'ifndef'): + self.include_list.append([]) + elif directive in ('else', 'elif'): + self.include_list[-1] = [] + + def SetLastHeader(self, header_path): + self._last_header = header_path + + def CanonicalizeAlphabeticalOrder(self, header_path): + """Returns a path canonicalized for alphabetical comparison. + + - replaces "-" with "_" so they both cmp the same. + - removes '-inl' since we don't require them to be after the main header. + - lowercase everything, just in case. + + Args: + header_path: Path to be canonicalized. + + Returns: + Canonicalized path. + """ + return header_path.replace('-inl.h', '.h').replace('-', '_').lower() + + def IsInAlphabeticalOrder(self, clean_lines, linenum, header_path): + """Check if a header is in alphabetical order with the previous header. + + Args: + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + header_path: Canonicalized header to be checked. + + Returns: + Returns true if the header is in alphabetical order. + """ + # If previous section is different from current section, _last_header will + # be reset to empty string, so it's always less than current header. + # + # If previous line was a blank line, assume that the headers are + # intentionally sorted the way they are. + if (self._last_header > header_path and + Match(r'^\s*#\s*include\b', clean_lines.elided[linenum - 1])): + return False + return True + + def CheckNextIncludeOrder(self, header_type): + """Returns a non-empty error message if the next header is out of order. + + This function also updates the internal state to be ready to check + the next include. + + Args: + header_type: One of the _XXX_HEADER constants defined above. + + Returns: + The empty string if the header is in the right order, or an + error message describing what's wrong. + + """ + error_message = ('Found %s after %s' % + (self._TYPE_NAMES[header_type], + self._SECTION_NAMES[self._section])) + + last_section = self._section + + if header_type == _C_SYS_HEADER: + if self._section <= self._C_SECTION: + self._section = self._C_SECTION + else: + self._last_header = '' + return error_message + elif header_type == _CPP_SYS_HEADER: + if self._section <= self._CPP_SECTION: + self._section = self._CPP_SECTION + else: + self._last_header = '' + return error_message + elif header_type == _LIKELY_MY_HEADER: + if self._section <= self._MY_H_SECTION: + self._section = self._MY_H_SECTION + else: + self._section = self._OTHER_H_SECTION + elif header_type == _POSSIBLE_MY_HEADER: + if self._section <= self._MY_H_SECTION: + self._section = self._MY_H_SECTION + else: + # This will always be the fallback because we're not sure + # enough that the header is associated with this file. + self._section = self._OTHER_H_SECTION + else: + assert header_type == _OTHER_HEADER + self._section = self._OTHER_H_SECTION + + if last_section != self._section: + self._last_header = '' + + return '' + + +class _CppLintState(object): + """Maintains module-wide state..""" + + def __init__(self): + self.verbose_level = 1 # global setting. + self.error_count = 0 # global count of reported errors + # filters to apply when emitting error messages + self.filters = _DEFAULT_FILTERS[:] + # backup of filter list. Used to restore the state after each file. + self._filters_backup = self.filters[:] + self.counting = 'total' # In what way are we counting errors? + self.errors_by_category = {} # string to int dict storing error counts + + # output format: + # "emacs" - format that emacs can parse (default) + # "eclipse" - format that eclipse can parse + # "vs7" - format that Microsoft Visual Studio 7 can parse + # "junit" - format that Jenkins, Bamboo, etc can parse + self.output_format = 'emacs' + + # For JUnit output, save errors and failures until the end so that they + # can be written into the XML + self._junit_errors = [] + self._junit_failures = [] + + def SetOutputFormat(self, output_format): + """Sets the output format for errors.""" + self.output_format = output_format + + def SetVerboseLevel(self, level): + """Sets the module's verbosity, and returns the previous setting.""" + last_verbose_level = self.verbose_level + self.verbose_level = level + return last_verbose_level + + def SetCountingStyle(self, counting_style): + """Sets the module's counting options.""" + self.counting = counting_style + + def SetFilters(self, filters): + """Sets the error-message filters. + + These filters are applied when deciding whether to emit a given + error message. + + Args: + filters: A string of comma-separated filters (eg "+whitespace/indent"). + Each filter should start with + or -; else we die. + + Raises: + ValueError: The comma-separated filters did not all start with '+' or '-'. + E.g. "-,+whitespace,-whitespace/indent,whitespace/badfilter" + """ + # Default filters always have less priority than the flag ones. + self.filters = _DEFAULT_FILTERS[:] + self.AddFilters(filters) + + def AddFilters(self, filters): + """ Adds more filters to the existing list of error-message filters. """ + for filt in filters.split(','): + clean_filt = filt.strip() + if clean_filt: + self.filters.append(clean_filt) + for filt in self.filters: + if not (filt.startswith('+') or filt.startswith('-')): + raise ValueError('Every filter in --filters must start with + or -' + ' (%s does not)' % filt) + + def BackupFilters(self): + """ Saves the current filter list to backup storage.""" + self._filters_backup = self.filters[:] + + def RestoreFilters(self): + """ Restores filters previously backed up.""" + self.filters = self._filters_backup[:] + + def ResetErrorCounts(self): + """Sets the module's error statistic back to zero.""" + self.error_count = 0 + self.errors_by_category = {} + + def IncrementErrorCount(self, category): + """Bumps the module's error statistic.""" + self.error_count += 1 + if self.counting in ('toplevel', 'detailed'): + if self.counting != 'detailed': + category = category.split('/')[0] + if category not in self.errors_by_category: + self.errors_by_category[category] = 0 + self.errors_by_category[category] += 1 + + def PrintErrorCounts(self): + """Print a summary of errors by category, and the total.""" + for category, count in sorted(iteritems(self.errors_by_category)): + self.PrintInfo('Category \'%s\' errors found: %d\n' % + (category, count)) + if self.error_count > 0: + self.PrintInfo('Total errors found: %d\n' % self.error_count) + + def PrintInfo(self, message): + if not _quiet and self.output_format != 'junit': + sys.stderr.write(message) + + def PrintError(self, message): + if self.output_format == 'junit': + self._junit_errors.append(message) + else: + sys.stderr.write(message) + + def AddJUnitFailure(self, filename, linenum, message, category, confidence): + self._junit_failures.append((filename, linenum, message, category, + confidence)) + + def FormatJUnitXML(self): + num_errors = len(self._junit_errors) + num_failures = len(self._junit_failures) + + testsuite = xml.etree.ElementTree.Element('testsuite') + testsuite.attrib['name'] = 'cpplint' + testsuite.attrib['errors'] = str(num_errors) + testsuite.attrib['failures'] = str(num_failures) + + if num_errors == 0 and num_failures == 0: + testsuite.attrib['tests'] = str(1) + xml.etree.ElementTree.SubElement(testsuite, 'testcase', name='passed') + + else: + testsuite.attrib['tests'] = str(num_errors + num_failures) + if num_errors > 0: + testcase = xml.etree.ElementTree.SubElement(testsuite, 'testcase') + testcase.attrib['name'] = 'errors' + error = xml.etree.ElementTree.SubElement(testcase, 'error') + error.text = '\n'.join(self._junit_errors) + if num_failures > 0: + # Group failures by file + failed_file_order = [] + failures_by_file = {} + for failure in self._junit_failures: + failed_file = failure[0] + if failed_file not in failed_file_order: + failed_file_order.append(failed_file) + failures_by_file[failed_file] = [] + failures_by_file[failed_file].append(failure) + # Create a testcase for each file + for failed_file in failed_file_order: + failures = failures_by_file[failed_file] + testcase = xml.etree.ElementTree.SubElement(testsuite, 'testcase') + testcase.attrib['name'] = failed_file + failure = xml.etree.ElementTree.SubElement(testcase, 'failure') + template = '{0}: {1} [{2}] [{3}]' + texts = [template.format(f[1], f[2], f[3], f[4]) for f in failures] + failure.text = '\n'.join(texts) + + xml_decl = '\n' + return xml_decl + xml.etree.ElementTree.tostring(testsuite, 'utf-8').decode('utf-8') + + +_cpplint_state = _CppLintState() + + +def _OutputFormat(): + """Gets the module's output format.""" + return _cpplint_state.output_format + + +def _SetOutputFormat(output_format): + """Sets the module's output format.""" + _cpplint_state.SetOutputFormat(output_format) + + +def _VerboseLevel(): + """Returns the module's verbosity setting.""" + return _cpplint_state.verbose_level + + +def _SetVerboseLevel(level): + """Sets the module's verbosity, and returns the previous setting.""" + return _cpplint_state.SetVerboseLevel(level) + + +def _SetCountingStyle(level): + """Sets the module's counting options.""" + _cpplint_state.SetCountingStyle(level) + + +def _Filters(): + """Returns the module's list of output filters, as a list.""" + return _cpplint_state.filters + + +def _SetFilters(filters): + """Sets the module's error-message filters. + + These filters are applied when deciding whether to emit a given + error message. + + Args: + filters: A string of comma-separated filters (eg "whitespace/indent"). + Each filter should start with + or -; else we die. + """ + _cpplint_state.SetFilters(filters) + +def _AddFilters(filters): + """Adds more filter overrides. + + Unlike _SetFilters, this function does not reset the current list of filters + available. + + Args: + filters: A string of comma-separated filters (eg "whitespace/indent"). + Each filter should start with + or -; else we die. + """ + _cpplint_state.AddFilters(filters) + +def _BackupFilters(): + """ Saves the current filter list to backup storage.""" + _cpplint_state.BackupFilters() + +def _RestoreFilters(): + """ Restores filters previously backed up.""" + _cpplint_state.RestoreFilters() + +class _FunctionState(object): + """Tracks current function name and the number of lines in its body.""" + + _NORMAL_TRIGGER = 250 # for --v=0, 500 for --v=1, etc. + _TEST_TRIGGER = 400 # about 50% more than _NORMAL_TRIGGER. + + def __init__(self): + self.in_a_function = False + self.lines_in_function = 0 + self.current_function = '' + + def Begin(self, function_name): + """Start analyzing function body. + + Args: + function_name: The name of the function being tracked. + """ + self.in_a_function = True + self.lines_in_function = 0 + self.current_function = function_name + + def Count(self): + """Count line in current function body.""" + if self.in_a_function: + self.lines_in_function += 1 + + def Check(self, error, filename, linenum): + """Report if too many lines in function body. + + Args: + error: The function to call with any errors found. + filename: The name of the current file. + linenum: The number of the line to check. + """ + if not self.in_a_function: + return + + if Match(r'T(EST|est)', self.current_function): + base_trigger = self._TEST_TRIGGER + else: + base_trigger = self._NORMAL_TRIGGER + trigger = base_trigger * 2**_VerboseLevel() + + if self.lines_in_function > trigger: + error_level = int(math.log(self.lines_in_function / base_trigger, 2)) + # 50 => 0, 100 => 1, 200 => 2, 400 => 3, 800 => 4, 1600 => 5, ... + if error_level > 5: + error_level = 5 + error(filename, linenum, 'readability/fn_size', error_level, + 'Small and focused functions are preferred:' + ' %s has %d non-comment lines' + ' (error triggered by exceeding %d lines).' % ( + self.current_function, self.lines_in_function, trigger)) + + def End(self): + """Stop analyzing function body.""" + self.in_a_function = False + + +class _IncludeError(Exception): + """Indicates a problem with the include order in a file.""" + pass + + +class FileInfo(object): + """Provides utility functions for filenames. + + FileInfo provides easy access to the components of a file's path + relative to the project root. + """ + + def __init__(self, filename): + self._filename = filename + + def FullName(self): + """Make Windows paths like Unix.""" + return os.path.abspath(self._filename).replace('\\', '/') + + def RepositoryName(self): + r"""FullName after removing the local path to the repository. + + If we have a real absolute path name here we can try to do something smart: + detecting the root of the checkout and truncating /path/to/checkout from + the name so that we get header guards that don't include things like + "C:\Documents and Settings\..." or "/home/username/..." in them and thus + people on different computers who have checked the source out to different + locations won't see bogus errors. + """ + fullname = self.FullName() + + if os.path.exists(fullname): + project_dir = os.path.dirname(fullname) + + # If the user specified a repository path, it exists, and the file is + # contained in it, use the specified repository path + if _repository: + repo = FileInfo(_repository).FullName() + root_dir = project_dir + while os.path.exists(root_dir): + # allow case insensitive compare on Windows + if os.path.normcase(root_dir) == os.path.normcase(repo): + return os.path.relpath(fullname, root_dir).replace('\\', '/') + one_up_dir = os.path.dirname(root_dir) + if one_up_dir == root_dir: + break + root_dir = one_up_dir + + if os.path.exists(os.path.join(project_dir, ".svn")): + # If there's a .svn file in the current directory, we recursively look + # up the directory tree for the top of the SVN checkout + root_dir = project_dir + one_up_dir = os.path.dirname(root_dir) + while os.path.exists(os.path.join(one_up_dir, ".svn")): + root_dir = os.path.dirname(root_dir) + one_up_dir = os.path.dirname(one_up_dir) + + prefix = os.path.commonprefix([root_dir, project_dir]) + return fullname[len(prefix) + 1:] + + # Not SVN <= 1.6? Try to find a git, hg, or svn top level directory by + # searching up from the current path. + root_dir = current_dir = os.path.dirname(fullname) + while current_dir != os.path.dirname(current_dir): + if (os.path.exists(os.path.join(current_dir, ".git")) or + os.path.exists(os.path.join(current_dir, ".hg")) or + os.path.exists(os.path.join(current_dir, ".svn"))): + root_dir = current_dir + current_dir = os.path.dirname(current_dir) + + if (os.path.exists(os.path.join(root_dir, ".git")) or + os.path.exists(os.path.join(root_dir, ".hg")) or + os.path.exists(os.path.join(root_dir, ".svn"))): + prefix = os.path.commonprefix([root_dir, project_dir]) + return fullname[len(prefix) + 1:] + + # Don't know what to do; header guard warnings may be wrong... + return fullname + + def Split(self): + """Splits the file into the directory, basename, and extension. + + For 'chrome/browser/browser.cc', Split() would + return ('chrome/browser', 'browser', '.cc') + + Returns: + A tuple of (directory, basename, extension). + """ + + googlename = self.RepositoryName() + project, rest = os.path.split(googlename) + return (project,) + os.path.splitext(rest) + + def BaseName(self): + """File base name - text after the final slash, before the final period.""" + return self.Split()[1] + + def Extension(self): + """File extension - text following the final period, includes that period.""" + return self.Split()[2] + + def NoExtension(self): + """File has no source file extension.""" + return '/'.join(self.Split()[0:2]) + + def IsSource(self): + """File has a source file extension.""" + return _IsSourceExtension(self.Extension()[1:]) + + +def _ShouldPrintError(category, confidence, linenum): + """If confidence >= verbose, category passes filter and is not suppressed.""" + + # There are three ways we might decide not to print an error message: + # a "NOLINT(category)" comment appears in the source, + # the verbosity level isn't high enough, or the filters filter it out. + if IsErrorSuppressedByNolint(category, linenum): + return False + + if confidence < _cpplint_state.verbose_level: + return False + + is_filtered = False + for one_filter in _Filters(): + if one_filter.startswith('-'): + if category.startswith(one_filter[1:]): + is_filtered = True + elif one_filter.startswith('+'): + if category.startswith(one_filter[1:]): + is_filtered = False + else: + assert False # should have been checked for in SetFilter. + if is_filtered: + return False + + return True + + +def Error(filename, linenum, category, confidence, message): + """Logs the fact we've found a lint error. + + We log where the error was found, and also our confidence in the error, + that is, how certain we are this is a legitimate style regression, and + not a misidentification or a use that's sometimes justified. + + False positives can be suppressed by the use of + "cpplint(category)" comments on the offending line. These are + parsed into _error_suppressions. + + Args: + filename: The name of the file containing the error. + linenum: The number of the line containing the error. + category: A string used to describe the "category" this bug + falls under: "whitespace", say, or "runtime". Categories + may have a hierarchy separated by slashes: "whitespace/indent". + confidence: A number from 1-5 representing a confidence score for + the error, with 5 meaning that we are certain of the problem, + and 1 meaning that it could be a legitimate construct. + message: The error message. + """ + if _ShouldPrintError(category, confidence, linenum): + _cpplint_state.IncrementErrorCount(category) + if _cpplint_state.output_format == 'vs7': + _cpplint_state.PrintError('%s(%s): warning: %s [%s] [%d]\n' % ( + filename, linenum, message, category, confidence)) + elif _cpplint_state.output_format == 'eclipse': + sys.stderr.write('%s:%s: warning: %s [%s] [%d]\n' % ( + filename, linenum, message, category, confidence)) + elif _cpplint_state.output_format == 'junit': + _cpplint_state.AddJUnitFailure(filename, linenum, message, category, + confidence) + else: + final_message = '%s:%s: %s [%s] [%d]\n' % ( + filename, linenum, message, category, confidence) + sys.stderr.write(final_message) + +# Matches standard C++ escape sequences per 2.13.2.3 of the C++ standard. +_RE_PATTERN_CLEANSE_LINE_ESCAPES = re.compile( + r'\\([abfnrtv?"\\\']|\d+|x[0-9a-fA-F]+)') +# Match a single C style comment on the same line. +_RE_PATTERN_C_COMMENTS = r'/\*(?:[^*]|\*(?!/))*\*/' +# Matches multi-line C style comments. +# This RE is a little bit more complicated than one might expect, because we +# have to take care of space removals tools so we can handle comments inside +# statements better. +# The current rule is: We only clear spaces from both sides when we're at the +# end of the line. Otherwise, we try to remove spaces from the right side, +# if this doesn't work we try on left side but only if there's a non-character +# on the right. +_RE_PATTERN_CLEANSE_LINE_C_COMMENTS = re.compile( + r'(\s*' + _RE_PATTERN_C_COMMENTS + r'\s*$|' + + _RE_PATTERN_C_COMMENTS + r'\s+|' + + r'\s+' + _RE_PATTERN_C_COMMENTS + r'(?=\W)|' + + _RE_PATTERN_C_COMMENTS + r')') + + +def IsCppString(line): + """Does line terminate so, that the next symbol is in string constant. + + This function does not consider single-line nor multi-line comments. + + Args: + line: is a partial line of code starting from the 0..n. + + Returns: + True, if next character appended to 'line' is inside a + string constant. + """ + + line = line.replace(r'\\', 'XX') # after this, \\" does not match to \" + return ((line.count('"') - line.count(r'\"') - line.count("'\"'")) & 1) == 1 + + +def CleanseRawStrings(raw_lines): + """Removes C++11 raw strings from lines. + + Before: + static const char kData[] = R"( + multi-line string + )"; + + After: + static const char kData[] = "" + (replaced by blank line) + ""; + + Args: + raw_lines: list of raw lines. + + Returns: + list of lines with C++11 raw strings replaced by empty strings. + """ + + delimiter = None + lines_without_raw_strings = [] + for line in raw_lines: + if delimiter: + # Inside a raw string, look for the end + end = line.find(delimiter) + if end >= 0: + # Found the end of the string, match leading space for this + # line and resume copying the original lines, and also insert + # a "" on the last line. + leading_space = Match(r'^(\s*)\S', line) + line = leading_space.group(1) + '""' + line[end + len(delimiter):] + delimiter = None + else: + # Haven't found the end yet, append a blank line. + line = '""' + + # Look for beginning of a raw string, and replace them with + # empty strings. This is done in a loop to handle multiple raw + # strings on the same line. + while delimiter is None: + # Look for beginning of a raw string. + # See 2.14.15 [lex.string] for syntax. + # + # Once we have matched a raw string, we check the prefix of the + # line to make sure that the line is not part of a single line + # comment. It's done this way because we remove raw strings + # before removing comments as opposed to removing comments + # before removing raw strings. This is because there are some + # cpplint checks that requires the comments to be preserved, but + # we don't want to check comments that are inside raw strings. + matched = Match(r'^(.*?)\b(?:R|u8R|uR|UR|LR)"([^\s\\()]*)\((.*)$', line) + if (matched and + not Match(r'^([^\'"]|\'(\\.|[^\'])*\'|"(\\.|[^"])*")*//', + matched.group(1))): + delimiter = ')' + matched.group(2) + '"' + + end = matched.group(3).find(delimiter) + if end >= 0: + # Raw string ended on same line + line = (matched.group(1) + '""' + + matched.group(3)[end + len(delimiter):]) + delimiter = None + else: + # Start of a multi-line raw string + line = matched.group(1) + '""' + else: + break + + lines_without_raw_strings.append(line) + + # TODO(unknown): if delimiter is not None here, we might want to + # emit a warning for unterminated string. + return lines_without_raw_strings + + +def FindNextMultiLineCommentStart(lines, lineix): + """Find the beginning marker for a multiline comment.""" + while lineix < len(lines): + if lines[lineix].strip().startswith('/*'): + # Only return this marker if the comment goes beyond this line + if lines[lineix].strip().find('*/', 2) < 0: + return lineix + lineix += 1 + return len(lines) + + +def FindNextMultiLineCommentEnd(lines, lineix): + """We are inside a comment, find the end marker.""" + while lineix < len(lines): + if lines[lineix].strip().endswith('*/'): + return lineix + lineix += 1 + return len(lines) + + +def RemoveMultiLineCommentsFromRange(lines, begin, end): + """Clears a range of lines for multi-line comments.""" + # Having // dummy comments makes the lines non-empty, so we will not get + # unnecessary blank line warnings later in the code. + for i in range(begin, end): + lines[i] = '/**/' + + +def RemoveMultiLineComments(filename, lines, error): + """Removes multiline (c-style) comments from lines.""" + lineix = 0 + while lineix < len(lines): + lineix_begin = FindNextMultiLineCommentStart(lines, lineix) + if lineix_begin >= len(lines): + return + lineix_end = FindNextMultiLineCommentEnd(lines, lineix_begin) + if lineix_end >= len(lines): + error(filename, lineix_begin + 1, 'readability/multiline_comment', 5, + 'Could not find end of multi-line comment') + return + RemoveMultiLineCommentsFromRange(lines, lineix_begin, lineix_end + 1) + lineix = lineix_end + 1 + + +def CleanseComments(line): + """Removes //-comments and single-line C-style /* */ comments. + + Args: + line: A line of C++ source. + + Returns: + The line with single-line comments removed. + """ + commentpos = line.find('//') + if commentpos != -1 and not IsCppString(line[:commentpos]): + line = line[:commentpos].rstrip() + # get rid of /* ... */ + return _RE_PATTERN_CLEANSE_LINE_C_COMMENTS.sub('', line) + + +class CleansedLines(object): + """Holds 4 copies of all lines with different preprocessing applied to them. + + 1) elided member contains lines without strings and comments. + 2) lines member contains lines without comments. + 3) raw_lines member contains all the lines without processing. + 4) lines_without_raw_strings member is same as raw_lines, but with C++11 raw + strings removed. + All these members are of , and of the same length. + """ + + def __init__(self, lines): + self.elided = [] + self.lines = [] + self.raw_lines = lines + self.num_lines = len(lines) + self.lines_without_raw_strings = CleanseRawStrings(lines) + for linenum in range(len(self.lines_without_raw_strings)): + self.lines.append(CleanseComments( + self.lines_without_raw_strings[linenum])) + elided = self._CollapseStrings(self.lines_without_raw_strings[linenum]) + self.elided.append(CleanseComments(elided)) + + def NumLines(self): + """Returns the number of lines represented.""" + return self.num_lines + + @staticmethod + def _CollapseStrings(elided): + """Collapses strings and chars on a line to simple "" or '' blocks. + + We nix strings first so we're not fooled by text like '"http://"' + + Args: + elided: The line being processed. + + Returns: + The line with collapsed strings. + """ + if _RE_PATTERN_INCLUDE.match(elided): + return elided + + # Remove escaped characters first to make quote/single quote collapsing + # basic. Things that look like escaped characters shouldn't occur + # outside of strings and chars. + elided = _RE_PATTERN_CLEANSE_LINE_ESCAPES.sub('', elided) + + # Replace quoted strings and digit separators. Both single quotes + # and double quotes are processed in the same loop, otherwise + # nested quotes wouldn't work. + collapsed = '' + while True: + # Find the first quote character + match = Match(r'^([^\'"]*)([\'"])(.*)$', elided) + if not match: + collapsed += elided + break + head, quote, tail = match.groups() + + if quote == '"': + # Collapse double quoted strings + second_quote = tail.find('"') + if second_quote >= 0: + collapsed += head + '""' + elided = tail[second_quote + 1:] + else: + # Unmatched double quote, don't bother processing the rest + # of the line since this is probably a multiline string. + collapsed += elided + break + else: + # Found single quote, check nearby text to eliminate digit separators. + # + # There is no special handling for floating point here, because + # the integer/fractional/exponent parts would all be parsed + # correctly as long as there are digits on both sides of the + # separator. So we are fine as long as we don't see something + # like "0.'3" (gcc 4.9.0 will not allow this literal). + if Search(r'\b(?:0[bBxX]?|[1-9])[0-9a-fA-F]*$', head): + match_literal = Match(r'^((?:\'?[0-9a-zA-Z_])*)(.*)$', "'" + tail) + collapsed += head + match_literal.group(1).replace("'", '') + elided = match_literal.group(2) + else: + second_quote = tail.find('\'') + if second_quote >= 0: + collapsed += head + "''" + elided = tail[second_quote + 1:] + else: + # Unmatched single quote + collapsed += elided + break + + return collapsed + + +def FindEndOfExpressionInLine(line, startpos, stack): + """Find the position just after the end of current parenthesized expression. + + Args: + line: a CleansedLines line. + startpos: start searching at this position. + stack: nesting stack at startpos. + + Returns: + On finding matching end: (index just after matching end, None) + On finding an unclosed expression: (-1, None) + Otherwise: (-1, new stack at end of this line) + """ + for i in xrange(startpos, len(line)): + char = line[i] + if char in '([{': + # Found start of parenthesized expression, push to expression stack + stack.append(char) + elif char == '<': + # Found potential start of template argument list + if i > 0 and line[i - 1] == '<': + # Left shift operator + if stack and stack[-1] == '<': + stack.pop() + if not stack: + return (-1, None) + elif i > 0 and Search(r'\boperator\s*$', line[0:i]): + # operator<, don't add to stack + continue + else: + # Tentative start of template argument list + stack.append('<') + elif char in ')]}': + # Found end of parenthesized expression. + # + # If we are currently expecting a matching '>', the pending '<' + # must have been an operator. Remove them from expression stack. + while stack and stack[-1] == '<': + stack.pop() + if not stack: + return (-1, None) + if ((stack[-1] == '(' and char == ')') or + (stack[-1] == '[' and char == ']') or + (stack[-1] == '{' and char == '}')): + stack.pop() + if not stack: + return (i + 1, None) + else: + # Mismatched parentheses + return (-1, None) + elif char == '>': + # Found potential end of template argument list. + + # Ignore "->" and operator functions + if (i > 0 and + (line[i - 1] == '-' or Search(r'\boperator\s*$', line[0:i - 1]))): + continue + + # Pop the stack if there is a matching '<'. Otherwise, ignore + # this '>' since it must be an operator. + if stack: + if stack[-1] == '<': + stack.pop() + if not stack: + return (i + 1, None) + elif char == ';': + # Found something that look like end of statements. If we are currently + # expecting a '>', the matching '<' must have been an operator, since + # template argument list should not contain statements. + while stack and stack[-1] == '<': + stack.pop() + if not stack: + return (-1, None) + + # Did not find end of expression or unbalanced parentheses on this line + return (-1, stack) + + +def CloseExpression(clean_lines, linenum, pos): + """If input points to ( or { or [ or <, finds the position that closes it. + + If lines[linenum][pos] points to a '(' or '{' or '[' or '<', finds the + linenum/pos that correspond to the closing of the expression. + + TODO(unknown): cpplint spends a fair bit of time matching parentheses. + Ideally we would want to index all opening and closing parentheses once + and have CloseExpression be just a simple lookup, but due to preprocessor + tricks, this is not so easy. + + Args: + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + pos: A position on the line. + + Returns: + A tuple (line, linenum, pos) pointer *past* the closing brace, or + (line, len(lines), -1) if we never find a close. Note we ignore + strings and comments when matching; and the line we return is the + 'cleansed' line at linenum. + """ + + line = clean_lines.elided[linenum] + if (line[pos] not in '({[<') or Match(r'<[<=]', line[pos:]): + return (line, clean_lines.NumLines(), -1) + + # Check first line + (end_pos, stack) = FindEndOfExpressionInLine(line, pos, []) + if end_pos > -1: + return (line, linenum, end_pos) + + # Continue scanning forward + while stack and linenum < clean_lines.NumLines() - 1: + linenum += 1 + line = clean_lines.elided[linenum] + (end_pos, stack) = FindEndOfExpressionInLine(line, 0, stack) + if end_pos > -1: + return (line, linenum, end_pos) + + # Did not find end of expression before end of file, give up + return (line, clean_lines.NumLines(), -1) + + +def FindStartOfExpressionInLine(line, endpos, stack): + """Find position at the matching start of current expression. + + This is almost the reverse of FindEndOfExpressionInLine, but note + that the input position and returned position differs by 1. + + Args: + line: a CleansedLines line. + endpos: start searching at this position. + stack: nesting stack at endpos. + + Returns: + On finding matching start: (index at matching start, None) + On finding an unclosed expression: (-1, None) + Otherwise: (-1, new stack at beginning of this line) + """ + i = endpos + while i >= 0: + char = line[i] + if char in ')]}': + # Found end of expression, push to expression stack + stack.append(char) + elif char == '>': + # Found potential end of template argument list. + # + # Ignore it if it's a "->" or ">=" or "operator>" + if (i > 0 and + (line[i - 1] == '-' or + Match(r'\s>=\s', line[i - 1:]) or + Search(r'\boperator\s*$', line[0:i]))): + i -= 1 + else: + stack.append('>') + elif char == '<': + # Found potential start of template argument list + if i > 0 and line[i - 1] == '<': + # Left shift operator + i -= 1 + else: + # If there is a matching '>', we can pop the expression stack. + # Otherwise, ignore this '<' since it must be an operator. + if stack and stack[-1] == '>': + stack.pop() + if not stack: + return (i, None) + elif char in '([{': + # Found start of expression. + # + # If there are any unmatched '>' on the stack, they must be + # operators. Remove those. + while stack and stack[-1] == '>': + stack.pop() + if not stack: + return (-1, None) + if ((char == '(' and stack[-1] == ')') or + (char == '[' and stack[-1] == ']') or + (char == '{' and stack[-1] == '}')): + stack.pop() + if not stack: + return (i, None) + else: + # Mismatched parentheses + return (-1, None) + elif char == ';': + # Found something that look like end of statements. If we are currently + # expecting a '<', the matching '>' must have been an operator, since + # template argument list should not contain statements. + while stack and stack[-1] == '>': + stack.pop() + if not stack: + return (-1, None) + + i -= 1 + + return (-1, stack) + + +def ReverseCloseExpression(clean_lines, linenum, pos): + """If input points to ) or } or ] or >, finds the position that opens it. + + If lines[linenum][pos] points to a ')' or '}' or ']' or '>', finds the + linenum/pos that correspond to the opening of the expression. + + Args: + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + pos: A position on the line. + + Returns: + A tuple (line, linenum, pos) pointer *at* the opening brace, or + (line, 0, -1) if we never find the matching opening brace. Note + we ignore strings and comments when matching; and the line we + return is the 'cleansed' line at linenum. + """ + line = clean_lines.elided[linenum] + if line[pos] not in ')}]>': + return (line, 0, -1) + + # Check last line + (start_pos, stack) = FindStartOfExpressionInLine(line, pos, []) + if start_pos > -1: + return (line, linenum, start_pos) + + # Continue scanning backward + while stack and linenum > 0: + linenum -= 1 + line = clean_lines.elided[linenum] + (start_pos, stack) = FindStartOfExpressionInLine(line, len(line) - 1, stack) + if start_pos > -1: + return (line, linenum, start_pos) + + # Did not find start of expression before beginning of file, give up + return (line, 0, -1) + + +def CheckForCopyright(filename, lines, error): + """Logs an error if no Copyright message appears at the top of the file.""" + + # We'll say it should occur by line 10. Don't forget there's a + # dummy line at the front. + for line in range(1, min(len(lines), 11)): + if re.search(r'Copyright', lines[line], re.I): break + else: # means no copyright line was found + error(filename, 0, 'legal/copyright', 5, + 'No copyright message found. ' + 'You should have a line: "Copyright [year] "') + + +def GetIndentLevel(line): + """Return the number of leading spaces in line. + + Args: + line: A string to check. + + Returns: + An integer count of leading spaces, possibly zero. + """ + indent = Match(r'^( *)\S', line) + if indent: + return len(indent.group(1)) + else: + return 0 + + +def GetHeaderGuardCPPVariable(filename): + """Returns the CPP variable that should be used as a header guard. + + Args: + filename: The name of a C++ header file. + + Returns: + The CPP variable that should be used as a header guard in the + named file. + + """ + + # Restores original filename in case that cpplint is invoked from Emacs's + # flymake. + filename = re.sub(r'_flymake\.h$', '.h', filename) + filename = re.sub(r'/\.flymake/([^/]*)$', r'/\1', filename) + # Replace 'c++' with 'cpp'. + filename = filename.replace('C++', 'cpp').replace('c++', 'cpp') + + fileinfo = FileInfo(filename) + file_path_from_root = fileinfo.RepositoryName() + if _root: + suffix = os.sep + # On Windows using directory separator will leave us with + # "bogus escape error" unless we properly escape regex. + if suffix == '\\': + suffix += '\\' + file_path_from_root = re.sub('^' + _root + suffix, '', file_path_from_root) + return re.sub(r'[^a-zA-Z0-9]', '_', file_path_from_root).upper() + '_' + + +def CheckForHeaderGuard(filename, clean_lines, error): + """Checks that the file contains a header guard. + + Logs an error if no #ifndef header guard is present. For other + headers, checks that the full pathname is used. + + Args: + filename: The name of the C++ header file. + clean_lines: A CleansedLines instance containing the file. + error: The function to call with any errors found. + """ + + # Don't check for header guards if there are error suppression + # comments somewhere in this file. + # + # Because this is silencing a warning for a nonexistent line, we + # only support the very specific NOLINT(build/header_guard) syntax, + # and not the general NOLINT or NOLINT(*) syntax. + raw_lines = clean_lines.lines_without_raw_strings + for i in raw_lines: + if Search(r'//\s*NOLINT\(build/header_guard\)', i): + return + + # Allow pragma once instead of header guards + for i in raw_lines: + if Search(r'^\s*#pragma\s+once', i): + return + + cppvar = GetHeaderGuardCPPVariable(filename) + + ifndef = '' + ifndef_linenum = 0 + define = '' + endif = '' + endif_linenum = 0 + for linenum, line in enumerate(raw_lines): + linesplit = line.split() + if len(linesplit) >= 2: + # find the first occurrence of #ifndef and #define, save arg + if not ifndef and linesplit[0] == '#ifndef': + # set ifndef to the header guard presented on the #ifndef line. + ifndef = linesplit[1] + ifndef_linenum = linenum + if not define and linesplit[0] == '#define': + define = linesplit[1] + # find the last occurrence of #endif, save entire line + if line.startswith('#endif'): + endif = line + endif_linenum = linenum + + if not ifndef or not define or ifndef != define: + error(filename, 0, 'build/header_guard', 5, + 'No #ifndef header guard found, suggested CPP variable is: %s' % + cppvar) + return + + # The guard should be PATH_FILE_H_, but we also allow PATH_FILE_H__ + # for backward compatibility. + if ifndef != cppvar: + error_level = 0 + if ifndef != cppvar + '_': + error_level = 5 + + ParseNolintSuppressions(filename, raw_lines[ifndef_linenum], ifndef_linenum, + error) + error(filename, ifndef_linenum, 'build/header_guard', error_level, + '#ifndef header guard has wrong style, please use: %s' % cppvar) + + # Check for "//" comments on endif line. + ParseNolintSuppressions(filename, raw_lines[endif_linenum], endif_linenum, + error) + match = Match(r'#endif\s*//\s*' + cppvar + r'(_)?\b', endif) + if match: + if match.group(1) == '_': + # Issue low severity warning for deprecated double trailing underscore + error(filename, endif_linenum, 'build/header_guard', 0, + '#endif line should be "#endif // %s"' % cppvar) + return + + # Didn't find the corresponding "//" comment. If this file does not + # contain any "//" comments at all, it could be that the compiler + # only wants "/**/" comments, look for those instead. + no_single_line_comments = True + for i in xrange(1, len(raw_lines) - 1): + line = raw_lines[i] + if Match(r'^(?:(?:\'(?:\.|[^\'])*\')|(?:"(?:\.|[^"])*")|[^\'"])*//', line): + no_single_line_comments = False + break + + if no_single_line_comments: + match = Match(r'#endif\s*/\*\s*' + cppvar + r'(_)?\s*\*/', endif) + if match: + if match.group(1) == '_': + # Low severity warning for double trailing underscore + error(filename, endif_linenum, 'build/header_guard', 0, + '#endif line should be "#endif /* %s */"' % cppvar) + return + + # Didn't find anything + error(filename, endif_linenum, 'build/header_guard', 5, + '#endif line should be "#endif // %s"' % cppvar) + + +def CheckHeaderFileIncluded(filename, include_state, error): + """Logs an error if a source file does not include its header.""" + + # Do not check test files + fileinfo = FileInfo(filename) + if Search(_TEST_FILE_SUFFIX, fileinfo.BaseName()): + return + + for ext in GetHeaderExtensions(): + basefilename = filename[0:len(filename) - len(fileinfo.Extension())] + headerfile = basefilename + '.' + ext + if not os.path.exists(headerfile): + continue + headername = FileInfo(headerfile).RepositoryName() + first_include = None + for section_list in include_state.include_list: + for f in section_list: + if headername in f[0] or f[0] in headername: + return + if not first_include: + first_include = f[1] + + error(filename, first_include, 'build/include', 5, + '%s should include its header file %s' % (fileinfo.RepositoryName(), + headername)) + + +def CheckForBadCharacters(filename, lines, error): + """Logs an error for each line containing bad characters. + + Two kinds of bad characters: + + 1. Unicode replacement characters: These indicate that either the file + contained invalid UTF-8 (likely) or Unicode replacement characters (which + it shouldn't). Note that it's possible for this to throw off line + numbering if the invalid UTF-8 occurred adjacent to a newline. + + 2. NUL bytes. These are problematic for some tools. + + Args: + filename: The name of the current file. + lines: An array of strings, each representing a line of the file. + error: The function to call with any errors found. + """ + for linenum, line in enumerate(lines): + if unicode_escape_decode('\ufffd') in line: + error(filename, linenum, 'readability/utf8', 5, + 'Line contains invalid UTF-8 (or Unicode replacement character).') + if '\0' in line: + error(filename, linenum, 'readability/nul', 5, 'Line contains NUL byte.') + + +def CheckForNewlineAtEOF(filename, lines, error): + """Logs an error if there is no newline char at the end of the file. + + Args: + filename: The name of the current file. + lines: An array of strings, each representing a line of the file. + error: The function to call with any errors found. + """ + + # The array lines() was created by adding two newlines to the + # original file (go figure), then splitting on \n. + # To verify that the file ends in \n, we just have to make sure the + # last-but-two element of lines() exists and is empty. + if len(lines) < 3 or lines[-2]: + error(filename, len(lines) - 2, 'whitespace/ending_newline', 5, + 'Could not find a newline character at the end of the file.') + + +def CheckForMultilineCommentsAndStrings(filename, clean_lines, linenum, error): + """Logs an error if we see /* ... */ or "..." that extend past one line. + + /* ... */ comments are legit inside macros, for one line. + Otherwise, we prefer // comments, so it's ok to warn about the + other. Likewise, it's ok for strings to extend across multiple + lines, as long as a line continuation character (backslash) + terminates each line. Although not currently prohibited by the C++ + style guide, it's ugly and unnecessary. We don't do well with either + in this lint program, so we warn about both. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + # Remove all \\ (escaped backslashes) from the line. They are OK, and the + # second (escaped) slash may trigger later \" detection erroneously. + line = line.replace('\\\\', '') + + if line.count('/*') > line.count('*/'): + error(filename, linenum, 'readability/multiline_comment', 5, + 'Complex multi-line /*...*/-style comment found. ' + 'Lint may give bogus warnings. ' + 'Consider replacing these with //-style comments, ' + 'with #if 0...#endif, ' + 'or with more clearly structured multi-line comments.') + + if (line.count('"') - line.count('\\"')) % 2: + error(filename, linenum, 'readability/multiline_string', 5, + 'Multi-line string ("...") found. This lint script doesn\'t ' + 'do well with such strings, and may give bogus warnings. ' + 'Use C++11 raw strings or concatenation instead.') + + +# (non-threadsafe name, thread-safe alternative, validation pattern) +# +# The validation pattern is used to eliminate false positives such as: +# _rand(); // false positive due to substring match. +# ->rand(); // some member function rand(). +# ACMRandom rand(seed); // some variable named rand. +# ISAACRandom rand(); // another variable named rand. +# +# Basically we require the return value of these functions to be used +# in some expression context on the same line by matching on some +# operator before the function name. This eliminates constructors and +# member function calls. +_UNSAFE_FUNC_PREFIX = r'(?:[-+*/=%^&|(<]\s*|>\s+)' +_THREADING_LIST = ( + ('asctime(', 'asctime_r(', _UNSAFE_FUNC_PREFIX + r'asctime\([^)]+\)'), + ('ctime(', 'ctime_r(', _UNSAFE_FUNC_PREFIX + r'ctime\([^)]+\)'), + ('getgrgid(', 'getgrgid_r(', _UNSAFE_FUNC_PREFIX + r'getgrgid\([^)]+\)'), + ('getgrnam(', 'getgrnam_r(', _UNSAFE_FUNC_PREFIX + r'getgrnam\([^)]+\)'), + ('getlogin(', 'getlogin_r(', _UNSAFE_FUNC_PREFIX + r'getlogin\(\)'), + ('getpwnam(', 'getpwnam_r(', _UNSAFE_FUNC_PREFIX + r'getpwnam\([^)]+\)'), + ('getpwuid(', 'getpwuid_r(', _UNSAFE_FUNC_PREFIX + r'getpwuid\([^)]+\)'), + ('gmtime(', 'gmtime_r(', _UNSAFE_FUNC_PREFIX + r'gmtime\([^)]+\)'), + ('localtime(', 'localtime_r(', _UNSAFE_FUNC_PREFIX + r'localtime\([^)]+\)'), + ('rand(', 'rand_r(', _UNSAFE_FUNC_PREFIX + r'rand\(\)'), + ('strtok(', 'strtok_r(', + _UNSAFE_FUNC_PREFIX + r'strtok\([^)]+\)'), + ('ttyname(', 'ttyname_r(', _UNSAFE_FUNC_PREFIX + r'ttyname\([^)]+\)'), + ) + + +def CheckPosixThreading(filename, clean_lines, linenum, error): + """Checks for calls to thread-unsafe functions. + + Much code has been originally written without consideration of + multi-threading. Also, engineers are relying on their old experience; + they have learned posix before threading extensions were added. These + tests guide the engineers to use thread-safe functions (when using + posix directly). + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + for single_thread_func, multithread_safe_func, pattern in _THREADING_LIST: + # Additional pattern matching check to confirm that this is the + # function we are looking for + if Search(pattern, line): + error(filename, linenum, 'runtime/threadsafe_fn', 2, + 'Consider using ' + multithread_safe_func + + '...) instead of ' + single_thread_func + + '...) for improved thread safety.') + + +def CheckVlogArguments(filename, clean_lines, linenum, error): + """Checks that VLOG() is only used for defining a logging level. + + For example, VLOG(2) is correct. VLOG(INFO), VLOG(WARNING), VLOG(ERROR), and + VLOG(FATAL) are not. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + if Search(r'\bVLOG\((INFO|ERROR|WARNING|DFATAL|FATAL)\)', line): + error(filename, linenum, 'runtime/vlog', 5, + 'VLOG() should be used with numeric verbosity level. ' + 'Use LOG() if you want symbolic severity levels.') + +# Matches invalid increment: *count++, which moves pointer instead of +# incrementing a value. +_RE_PATTERN_INVALID_INCREMENT = re.compile( + r'^\s*\*\w+(\+\+|--);') + + +def CheckInvalidIncrement(filename, clean_lines, linenum, error): + """Checks for invalid increment *count++. + + For example following function: + void increment_counter(int* count) { + *count++; + } + is invalid, because it effectively does count++, moving pointer, and should + be replaced with ++*count, (*count)++ or *count += 1. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + if _RE_PATTERN_INVALID_INCREMENT.match(line): + error(filename, linenum, 'runtime/invalid_increment', 5, + 'Changing pointer instead of value (or unused value of operator*).') + + +def IsMacroDefinition(clean_lines, linenum): + if Search(r'^#define', clean_lines[linenum]): + return True + + if linenum > 0 and Search(r'\\$', clean_lines[linenum - 1]): + return True + + return False + + +def IsForwardClassDeclaration(clean_lines, linenum): + return Match(r'^\s*(\btemplate\b)*.*class\s+\w+;\s*$', clean_lines[linenum]) + + +class _BlockInfo(object): + """Stores information about a generic block of code.""" + + def __init__(self, linenum, seen_open_brace): + self.starting_linenum = linenum + self.seen_open_brace = seen_open_brace + self.open_parentheses = 0 + self.inline_asm = _NO_ASM + self.check_namespace_indentation = False + + def CheckBegin(self, filename, clean_lines, linenum, error): + """Run checks that applies to text up to the opening brace. + + This is mostly for checking the text after the class identifier + and the "{", usually where the base class is specified. For other + blocks, there isn't much to check, so we always pass. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + pass + + def CheckEnd(self, filename, clean_lines, linenum, error): + """Run checks that applies to text after the closing brace. + + This is mostly used for checking end of namespace comments. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + pass + + def IsBlockInfo(self): + """Returns true if this block is a _BlockInfo. + + This is convenient for verifying that an object is an instance of + a _BlockInfo, but not an instance of any of the derived classes. + + Returns: + True for this class, False for derived classes. + """ + return self.__class__ == _BlockInfo + + +class _ExternCInfo(_BlockInfo): + """Stores information about an 'extern "C"' block.""" + + def __init__(self, linenum): + _BlockInfo.__init__(self, linenum, True) + + +class _ClassInfo(_BlockInfo): + """Stores information about a class.""" + + def __init__(self, name, class_or_struct, clean_lines, linenum): + _BlockInfo.__init__(self, linenum, False) + self.name = name + self.is_derived = False + self.check_namespace_indentation = True + if class_or_struct == 'struct': + self.access = 'public' + self.is_struct = True + else: + self.access = 'private' + self.is_struct = False + + # Remember initial indentation level for this class. Using raw_lines here + # instead of elided to account for leading comments. + self.class_indent = GetIndentLevel(clean_lines.raw_lines[linenum]) + + # Try to find the end of the class. This will be confused by things like: + # class A { + # } *x = { ... + # + # But it's still good enough for CheckSectionSpacing. + self.last_line = 0 + depth = 0 + for i in range(linenum, clean_lines.NumLines()): + line = clean_lines.elided[i] + depth += line.count('{') - line.count('}') + if not depth: + self.last_line = i + break + + def CheckBegin(self, filename, clean_lines, linenum, error): + # Look for a bare ':' + if Search('(^|[^:]):($|[^:])', clean_lines.elided[linenum]): + self.is_derived = True + + def CheckEnd(self, filename, clean_lines, linenum, error): + # If there is a DISALLOW macro, it should appear near the end of + # the class. + seen_last_thing_in_class = False + for i in xrange(linenum - 1, self.starting_linenum, -1): + match = Search( + r'\b(DISALLOW_COPY_AND_ASSIGN|DISALLOW_IMPLICIT_CONSTRUCTORS)\(' + + self.name + r'\)', + clean_lines.elided[i]) + if match: + if seen_last_thing_in_class: + error(filename, i, 'readability/constructors', 3, + match.group(1) + ' should be the last thing in the class') + break + + if not Match(r'^\s*$', clean_lines.elided[i]): + seen_last_thing_in_class = True + + # Check that closing brace is aligned with beginning of the class. + # Only do this if the closing brace is indented by only whitespaces. + # This means we will not check single-line class definitions. + indent = Match(r'^( *)\}', clean_lines.elided[linenum]) + if indent and len(indent.group(1)) != self.class_indent: + if self.is_struct: + parent = 'struct ' + self.name + else: + parent = 'class ' + self.name + error(filename, linenum, 'whitespace/indent', 3, + 'Closing brace should be aligned with beginning of %s' % parent) + + +class _NamespaceInfo(_BlockInfo): + """Stores information about a namespace.""" + + def __init__(self, name, linenum): + _BlockInfo.__init__(self, linenum, False) + self.name = name or '' + self.check_namespace_indentation = True + + def CheckEnd(self, filename, clean_lines, linenum, error): + """Check end of namespace comments.""" + line = clean_lines.raw_lines[linenum] + + # Check how many lines is enclosed in this namespace. Don't issue + # warning for missing namespace comments if there aren't enough + # lines. However, do apply checks if there is already an end of + # namespace comment and it's incorrect. + # + # TODO(unknown): We always want to check end of namespace comments + # if a namespace is large, but sometimes we also want to apply the + # check if a short namespace contained nontrivial things (something + # other than forward declarations). There is currently no logic on + # deciding what these nontrivial things are, so this check is + # triggered by namespace size only, which works most of the time. + if (linenum - self.starting_linenum < 10 + and not Match(r'^\s*};*\s*(//|/\*).*\bnamespace\b', line)): + return + + # Look for matching comment at end of namespace. + # + # Note that we accept C style "/* */" comments for terminating + # namespaces, so that code that terminate namespaces inside + # preprocessor macros can be cpplint clean. + # + # We also accept stuff like "// end of namespace ." with the + # period at the end. + # + # Besides these, we don't accept anything else, otherwise we might + # get false negatives when existing comment is a substring of the + # expected namespace. + if self.name: + # Named namespace + if not Match((r'^\s*};*\s*(//|/\*).*\bnamespace\s+' + + re.escape(self.name) + r'[\*/\.\\\s]*$'), + line): + error(filename, linenum, 'readability/namespace', 5, + 'Namespace should be terminated with "// namespace %s"' % + self.name) + else: + # Anonymous namespace + if not Match(r'^\s*};*\s*(//|/\*).*\bnamespace[\*/\.\\\s]*$', line): + # If "// namespace anonymous" or "// anonymous namespace (more text)", + # mention "// anonymous namespace" as an acceptable form + if Match(r'^\s*}.*\b(namespace anonymous|anonymous namespace)\b', line): + error(filename, linenum, 'readability/namespace', 5, + 'Anonymous namespace should be terminated with "// namespace"' + ' or "// anonymous namespace"') + else: + error(filename, linenum, 'readability/namespace', 5, + 'Anonymous namespace should be terminated with "// namespace"') + + +class _PreprocessorInfo(object): + """Stores checkpoints of nesting stacks when #if/#else is seen.""" + + def __init__(self, stack_before_if): + # The entire nesting stack before #if + self.stack_before_if = stack_before_if + + # The entire nesting stack up to #else + self.stack_before_else = [] + + # Whether we have already seen #else or #elif + self.seen_else = False + + +class NestingState(object): + """Holds states related to parsing braces.""" + + def __init__(self): + # Stack for tracking all braces. An object is pushed whenever we + # see a "{", and popped when we see a "}". Only 3 types of + # objects are possible: + # - _ClassInfo: a class or struct. + # - _NamespaceInfo: a namespace. + # - _BlockInfo: some other type of block. + self.stack = [] + + # Top of the previous stack before each Update(). + # + # Because the nesting_stack is updated at the end of each line, we + # had to do some convoluted checks to find out what is the current + # scope at the beginning of the line. This check is simplified by + # saving the previous top of nesting stack. + # + # We could save the full stack, but we only need the top. Copying + # the full nesting stack would slow down cpplint by ~10%. + self.previous_stack_top = [] + + # Stack of _PreprocessorInfo objects. + self.pp_stack = [] + + def SeenOpenBrace(self): + """Check if we have seen the opening brace for the innermost block. + + Returns: + True if we have seen the opening brace, False if the innermost + block is still expecting an opening brace. + """ + return (not self.stack) or self.stack[-1].seen_open_brace + + def InNamespaceBody(self): + """Check if we are currently one level inside a namespace body. + + Returns: + True if top of the stack is a namespace block, False otherwise. + """ + return self.stack and isinstance(self.stack[-1], _NamespaceInfo) + + def InExternC(self): + """Check if we are currently one level inside an 'extern "C"' block. + + Returns: + True if top of the stack is an extern block, False otherwise. + """ + return self.stack and isinstance(self.stack[-1], _ExternCInfo) + + def InClassDeclaration(self): + """Check if we are currently one level inside a class or struct declaration. + + Returns: + True if top of the stack is a class/struct, False otherwise. + """ + return self.stack and isinstance(self.stack[-1], _ClassInfo) + + def InAsmBlock(self): + """Check if we are currently one level inside an inline ASM block. + + Returns: + True if the top of the stack is a block containing inline ASM. + """ + return self.stack and self.stack[-1].inline_asm != _NO_ASM + + def InTemplateArgumentList(self, clean_lines, linenum, pos): + """Check if current position is inside template argument list. + + Args: + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + pos: position just after the suspected template argument. + Returns: + True if (linenum, pos) is inside template arguments. + """ + while linenum < clean_lines.NumLines(): + # Find the earliest character that might indicate a template argument + line = clean_lines.elided[linenum] + match = Match(r'^[^{};=\[\]\.<>]*(.)', line[pos:]) + if not match: + linenum += 1 + pos = 0 + continue + token = match.group(1) + pos += len(match.group(0)) + + # These things do not look like template argument list: + # class Suspect { + # class Suspect x; } + if token in ('{', '}', ';'): return False + + # These things look like template argument list: + # template + # template + # template + # template + if token in ('>', '=', '[', ']', '.'): return True + + # Check if token is an unmatched '<'. + # If not, move on to the next character. + if token != '<': + pos += 1 + if pos >= len(line): + linenum += 1 + pos = 0 + continue + + # We can't be sure if we just find a single '<', and need to + # find the matching '>'. + (_, end_line, end_pos) = CloseExpression(clean_lines, linenum, pos - 1) + if end_pos < 0: + # Not sure if template argument list or syntax error in file + return False + linenum = end_line + pos = end_pos + return False + + def UpdatePreprocessor(self, line): + """Update preprocessor stack. + + We need to handle preprocessors due to classes like this: + #ifdef SWIG + struct ResultDetailsPageElementExtensionPoint { + #else + struct ResultDetailsPageElementExtensionPoint : public Extension { + #endif + + We make the following assumptions (good enough for most files): + - Preprocessor condition evaluates to true from #if up to first + #else/#elif/#endif. + + - Preprocessor condition evaluates to false from #else/#elif up + to #endif. We still perform lint checks on these lines, but + these do not affect nesting stack. + + Args: + line: current line to check. + """ + if Match(r'^\s*#\s*(if|ifdef|ifndef)\b', line): + # Beginning of #if block, save the nesting stack here. The saved + # stack will allow us to restore the parsing state in the #else case. + self.pp_stack.append(_PreprocessorInfo(copy.deepcopy(self.stack))) + elif Match(r'^\s*#\s*(else|elif)\b', line): + # Beginning of #else block + if self.pp_stack: + if not self.pp_stack[-1].seen_else: + # This is the first #else or #elif block. Remember the + # whole nesting stack up to this point. This is what we + # keep after the #endif. + self.pp_stack[-1].seen_else = True + self.pp_stack[-1].stack_before_else = copy.deepcopy(self.stack) + + # Restore the stack to how it was before the #if + self.stack = copy.deepcopy(self.pp_stack[-1].stack_before_if) + else: + # TODO(unknown): unexpected #else, issue warning? + pass + elif Match(r'^\s*#\s*endif\b', line): + # End of #if or #else blocks. + if self.pp_stack: + # If we saw an #else, we will need to restore the nesting + # stack to its former state before the #else, otherwise we + # will just continue from where we left off. + if self.pp_stack[-1].seen_else: + # Here we can just use a shallow copy since we are the last + # reference to it. + self.stack = self.pp_stack[-1].stack_before_else + # Drop the corresponding #if + self.pp_stack.pop() + else: + # TODO(unknown): unexpected #endif, issue warning? + pass + + # TODO(unknown): Update() is too long, but we will refactor later. + def Update(self, filename, clean_lines, linenum, error): + """Update nesting state with current line. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + # Remember top of the previous nesting stack. + # + # The stack is always pushed/popped and not modified in place, so + # we can just do a shallow copy instead of copy.deepcopy. Using + # deepcopy would slow down cpplint by ~28%. + if self.stack: + self.previous_stack_top = self.stack[-1] + else: + self.previous_stack_top = None + + # Update pp_stack + self.UpdatePreprocessor(line) + + # Count parentheses. This is to avoid adding struct arguments to + # the nesting stack. + if self.stack: + inner_block = self.stack[-1] + depth_change = line.count('(') - line.count(')') + inner_block.open_parentheses += depth_change + + # Also check if we are starting or ending an inline assembly block. + if inner_block.inline_asm in (_NO_ASM, _END_ASM): + if (depth_change != 0 and + inner_block.open_parentheses == 1 and + _MATCH_ASM.match(line)): + # Enter assembly block + inner_block.inline_asm = _INSIDE_ASM + else: + # Not entering assembly block. If previous line was _END_ASM, + # we will now shift to _NO_ASM state. + inner_block.inline_asm = _NO_ASM + elif (inner_block.inline_asm == _INSIDE_ASM and + inner_block.open_parentheses == 0): + # Exit assembly block + inner_block.inline_asm = _END_ASM + + # Consume namespace declaration at the beginning of the line. Do + # this in a loop so that we catch same line declarations like this: + # namespace proto2 { namespace bridge { class MessageSet; } } + while True: + # Match start of namespace. The "\b\s*" below catches namespace + # declarations even if it weren't followed by a whitespace, this + # is so that we don't confuse our namespace checker. The + # missing spaces will be flagged by CheckSpacing. + namespace_decl_match = Match(r'^\s*namespace\b\s*([:\w]+)?(.*)$', line) + if not namespace_decl_match: + break + + new_namespace = _NamespaceInfo(namespace_decl_match.group(1), linenum) + self.stack.append(new_namespace) + + line = namespace_decl_match.group(2) + if line.find('{') != -1: + new_namespace.seen_open_brace = True + line = line[line.find('{') + 1:] + + # Look for a class declaration in whatever is left of the line + # after parsing namespaces. The regexp accounts for decorated classes + # such as in: + # class LOCKABLE API Object { + # }; + class_decl_match = Match( + r'^(\s*(?:template\s*<[\w\s<>,:=]*>\s*)?' + r'(class|struct)\s+(?:[A-Z_]+\s+)*(\w+(?:::\w+)*))' + r'(.*)$', line) + if (class_decl_match and + (not self.stack or self.stack[-1].open_parentheses == 0)): + # We do not want to accept classes that are actually template arguments: + # template , + # template class Ignore3> + # void Function() {}; + # + # To avoid template argument cases, we scan forward and look for + # an unmatched '>'. If we see one, assume we are inside a + # template argument list. + end_declaration = len(class_decl_match.group(1)) + if not self.InTemplateArgumentList(clean_lines, linenum, end_declaration): + self.stack.append(_ClassInfo( + class_decl_match.group(3), class_decl_match.group(2), + clean_lines, linenum)) + line = class_decl_match.group(4) + + # If we have not yet seen the opening brace for the innermost block, + # run checks here. + if not self.SeenOpenBrace(): + self.stack[-1].CheckBegin(filename, clean_lines, linenum, error) + + # Update access control if we are inside a class/struct + if self.stack and isinstance(self.stack[-1], _ClassInfo): + classinfo = self.stack[-1] + access_match = Match( + r'^(.*)\b(public|private|protected|signals)(\s+(?:slots\s*)?)?' + r':(?:[^:]|$)', + line) + if access_match: + classinfo.access = access_match.group(2) + + # Check that access keywords are indented +1 space. Skip this + # check if the keywords are not preceded by whitespaces. + indent = access_match.group(1) + if (len(indent) != classinfo.class_indent + 1 and + Match(r'^\s*$', indent)): + if classinfo.is_struct: + parent = 'struct ' + classinfo.name + else: + parent = 'class ' + classinfo.name + slots = '' + if access_match.group(3): + slots = access_match.group(3) + error(filename, linenum, 'whitespace/indent', 3, + '%s%s: should be indented +1 space inside %s' % ( + access_match.group(2), slots, parent)) + + # Consume braces or semicolons from what's left of the line + while True: + # Match first brace, semicolon, or closed parenthesis. + matched = Match(r'^[^{;)}]*([{;)}])(.*)$', line) + if not matched: + break + + token = matched.group(1) + if token == '{': + # If namespace or class hasn't seen a opening brace yet, mark + # namespace/class head as complete. Push a new block onto the + # stack otherwise. + if not self.SeenOpenBrace(): + self.stack[-1].seen_open_brace = True + elif Match(r'^extern\s*"[^"]*"\s*\{', line): + self.stack.append(_ExternCInfo(linenum)) + else: + self.stack.append(_BlockInfo(linenum, True)) + if _MATCH_ASM.match(line): + self.stack[-1].inline_asm = _BLOCK_ASM + + elif token == ';' or token == ')': + # If we haven't seen an opening brace yet, but we already saw + # a semicolon, this is probably a forward declaration. Pop + # the stack for these. + # + # Similarly, if we haven't seen an opening brace yet, but we + # already saw a closing parenthesis, then these are probably + # function arguments with extra "class" or "struct" keywords. + # Also pop these stack for these. + if not self.SeenOpenBrace(): + self.stack.pop() + else: # token == '}' + # Perform end of block checks and pop the stack. + if self.stack: + self.stack[-1].CheckEnd(filename, clean_lines, linenum, error) + self.stack.pop() + line = matched.group(2) + + def InnermostClass(self): + """Get class info on the top of the stack. + + Returns: + A _ClassInfo object if we are inside a class, or None otherwise. + """ + for i in range(len(self.stack), 0, -1): + classinfo = self.stack[i - 1] + if isinstance(classinfo, _ClassInfo): + return classinfo + return None + + def CheckCompletedBlocks(self, filename, error): + """Checks that all classes and namespaces have been completely parsed. + + Call this when all lines in a file have been processed. + Args: + filename: The name of the current file. + error: The function to call with any errors found. + """ + # Note: This test can result in false positives if #ifdef constructs + # get in the way of brace matching. See the testBuildClass test in + # cpplint_unittest.py for an example of this. + for obj in self.stack: + if isinstance(obj, _ClassInfo): + error(filename, obj.starting_linenum, 'build/class', 5, + 'Failed to find complete declaration of class %s' % + obj.name) + elif isinstance(obj, _NamespaceInfo): + error(filename, obj.starting_linenum, 'build/namespaces', 5, + 'Failed to find complete declaration of namespace %s' % + obj.name) + + +def CheckForNonStandardConstructs(filename, clean_lines, linenum, + nesting_state, error): + r"""Logs an error if we see certain non-ANSI constructs ignored by gcc-2. + + Complain about several constructs which gcc-2 accepts, but which are + not standard C++. Warning about these in lint is one way to ease the + transition to new compilers. + - put storage class first (e.g. "static const" instead of "const static"). + - "%lld" instead of %qd" in printf-type functions. + - "%1$d" is non-standard in printf-type functions. + - "\%" is an undefined character escape sequence. + - text after #endif is not allowed. + - invalid inner-style forward declaration. + - >? and ?= and )\?=?\s*(\w+|[+-]?\d+)(\.\d*)?', + line): + error(filename, linenum, 'build/deprecated', 3, + '>? and ))?' + # r'\s*const\s*' + type_name + '\s*&\s*\w+\s*;' + error(filename, linenum, 'runtime/member_string_references', 2, + 'const string& members are dangerous. It is much better to use ' + 'alternatives, such as pointers or simple constants.') + + # Everything else in this function operates on class declarations. + # Return early if the top of the nesting stack is not a class, or if + # the class head is not completed yet. + classinfo = nesting_state.InnermostClass() + if not classinfo or not classinfo.seen_open_brace: + return + + # The class may have been declared with namespace or classname qualifiers. + # The constructor and destructor will not have those qualifiers. + base_classname = classinfo.name.split('::')[-1] + + # Look for single-argument constructors that aren't marked explicit. + # Technically a valid construct, but against style. + explicit_constructor_match = Match( + r'\s+(?:inline\s+)?(explicit\s+)?(?:inline\s+)?%s\s*' + r'\(((?:[^()]|\([^()]*\))*)\)' + % re.escape(base_classname), + line) + + if explicit_constructor_match: + is_marked_explicit = explicit_constructor_match.group(1) + + if not explicit_constructor_match.group(2): + constructor_args = [] + else: + constructor_args = explicit_constructor_match.group(2).split(',') + + # collapse arguments so that commas in template parameter lists and function + # argument parameter lists don't split arguments in two + i = 0 + while i < len(constructor_args): + constructor_arg = constructor_args[i] + while (constructor_arg.count('<') > constructor_arg.count('>') or + constructor_arg.count('(') > constructor_arg.count(')')): + constructor_arg += ',' + constructor_args[i + 1] + del constructor_args[i + 1] + constructor_args[i] = constructor_arg + i += 1 + + variadic_args = [arg for arg in constructor_args if '&&...' in arg] + defaulted_args = [arg for arg in constructor_args if '=' in arg] + noarg_constructor = (not constructor_args or # empty arg list + # 'void' arg specifier + (len(constructor_args) == 1 and + constructor_args[0].strip() == 'void')) + onearg_constructor = ((len(constructor_args) == 1 and # exactly one arg + not noarg_constructor) or + # all but at most one arg defaulted + (len(constructor_args) >= 1 and + not noarg_constructor and + len(defaulted_args) >= len(constructor_args) - 1) or + # variadic arguments with zero or one argument + (len(constructor_args) <= 2 and + len(variadic_args) >= 1)) + initializer_list_constructor = bool( + onearg_constructor and + Search(r'\bstd\s*::\s*initializer_list\b', constructor_args[0])) + copy_constructor = bool( + onearg_constructor and + Match(r'(const\s+)?%s(\s*<[^>]*>)?(\s+const)?\s*(?:<\w+>\s*)?&' + % re.escape(base_classname), constructor_args[0].strip())) + + if (not is_marked_explicit and + onearg_constructor and + not initializer_list_constructor and + not copy_constructor): + if defaulted_args or variadic_args: + error(filename, linenum, 'runtime/explicit', 5, + 'Constructors callable with one argument ' + 'should be marked explicit.') + else: + error(filename, linenum, 'runtime/explicit', 5, + 'Single-parameter constructors should be marked explicit.') + elif is_marked_explicit and not onearg_constructor: + if noarg_constructor: + error(filename, linenum, 'runtime/explicit', 5, + 'Zero-parameter constructors should not be marked explicit.') + + +def CheckSpacingForFunctionCall(filename, clean_lines, linenum, error): + """Checks for the correctness of various spacing around function calls. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + # Since function calls often occur inside if/for/while/switch + # expressions - which have their own, more liberal conventions - we + # first see if we should be looking inside such an expression for a + # function call, to which we can apply more strict standards. + fncall = line # if there's no control flow construct, look at whole line + for pattern in (r'\bif\s*\((.*)\)\s*{', + r'\bfor\s*\((.*)\)\s*{', + r'\bwhile\s*\((.*)\)\s*[{;]', + r'\bswitch\s*\((.*)\)\s*{'): + match = Search(pattern, line) + if match: + fncall = match.group(1) # look inside the parens for function calls + break + + # Except in if/for/while/switch, there should never be space + # immediately inside parens (eg "f( 3, 4 )"). We make an exception + # for nested parens ( (a+b) + c ). Likewise, there should never be + # a space before a ( when it's a function argument. I assume it's a + # function argument when the char before the whitespace is legal in + # a function name (alnum + _) and we're not starting a macro. Also ignore + # pointers and references to arrays and functions coz they're too tricky: + # we use a very simple way to recognize these: + # " (something)(maybe-something)" or + # " (something)(maybe-something," or + # " (something)[something]" + # Note that we assume the contents of [] to be short enough that + # they'll never need to wrap. + if ( # Ignore control structures. + not Search(r'\b(if|for|while|switch|return|new|delete|catch|sizeof)\b', + fncall) and + # Ignore pointers/references to functions. + not Search(r' \([^)]+\)\([^)]*(\)|,$)', fncall) and + # Ignore pointers/references to arrays. + not Search(r' \([^)]+\)\[[^\]]+\]', fncall)): + if Search(r'\w\s*\(\s(?!\s*\\$)', fncall): # a ( used for a fn call + error(filename, linenum, 'whitespace/parens', 4, + 'Extra space after ( in function call') + elif Search(r'\(\s+(?!(\s*\\)|\()', fncall): + error(filename, linenum, 'whitespace/parens', 2, + 'Extra space after (') + if (Search(r'\w\s+\(', fncall) and + not Search(r'_{0,2}asm_{0,2}\s+_{0,2}volatile_{0,2}\s+\(', fncall) and + not Search(r'#\s*define|typedef|using\s+\w+\s*=', fncall) and + not Search(r'\w\s+\((\w+::)*\*\w+\)\(', fncall) and + not Search(r'\bcase\s+\(', fncall)): + # TODO(unknown): Space after an operator function seem to be a common + # error, silence those for now by restricting them to highest verbosity. + if Search(r'\boperator_*\b', line): + error(filename, linenum, 'whitespace/parens', 0, + 'Extra space before ( in function call') + else: + error(filename, linenum, 'whitespace/parens', 4, + 'Extra space before ( in function call') + # If the ) is followed only by a newline or a { + newline, assume it's + # part of a control statement (if/while/etc), and don't complain + if Search(r'[^)]\s+\)\s*[^{\s]', fncall): + # If the closing parenthesis is preceded by only whitespaces, + # try to give a more descriptive error message. + if Search(r'^\s+\)', fncall): + error(filename, linenum, 'whitespace/parens', 2, + 'Closing ) should be moved to the previous line') + else: + error(filename, linenum, 'whitespace/parens', 2, + 'Extra space before )') + + +def IsBlankLine(line): + """Returns true if the given line is blank. + + We consider a line to be blank if the line is empty or consists of + only white spaces. + + Args: + line: A line of a string. + + Returns: + True, if the given line is blank. + """ + return not line or line.isspace() + + +def CheckForNamespaceIndentation(filename, nesting_state, clean_lines, line, + error): + is_namespace_indent_item = ( + len(nesting_state.stack) > 1 and + nesting_state.stack[-1].check_namespace_indentation and + isinstance(nesting_state.previous_stack_top, _NamespaceInfo) and + nesting_state.previous_stack_top == nesting_state.stack[-2]) + + if ShouldCheckNamespaceIndentation(nesting_state, is_namespace_indent_item, + clean_lines.elided, line): + CheckItemIndentationInNamespace(filename, clean_lines.elided, + line, error) + + +def CheckForFunctionLengths(filename, clean_lines, linenum, + function_state, error): + """Reports for long function bodies. + + For an overview why this is done, see: + https://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Write_Short_Functions + + Uses a simplistic algorithm assuming other style guidelines + (especially spacing) are followed. + Only checks unindented functions, so class members are unchecked. + Trivial bodies are unchecked, so constructors with huge initializer lists + may be missed. + Blank/comment lines are not counted so as to avoid encouraging the removal + of vertical space and comments just to get through a lint check. + NOLINT *on the last line of a function* disables this check. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + function_state: Current function name and lines in body so far. + error: The function to call with any errors found. + """ + lines = clean_lines.lines + line = lines[linenum] + joined_line = '' + + starting_func = False + regexp = r'(\w(\w|::|\*|\&|\s)*)\(' # decls * & space::name( ... + match_result = Match(regexp, line) + if match_result: + # If the name is all caps and underscores, figure it's a macro and + # ignore it, unless it's TEST or TEST_F. + function_name = match_result.group(1).split()[-1] + if function_name == 'TEST' or function_name == 'TEST_F' or ( + not Match(r'[A-Z_]+$', function_name)): + starting_func = True + + if starting_func: + body_found = False + for start_linenum in range(linenum, clean_lines.NumLines()): + start_line = lines[start_linenum] + joined_line += ' ' + start_line.lstrip() + if Search(r'(;|})', start_line): # Declarations and trivial functions + body_found = True + break # ... ignore + elif Search(r'{', start_line): + body_found = True + function = Search(r'((\w|:)*)\(', line).group(1) + if Match(r'TEST', function): # Handle TEST... macros + parameter_regexp = Search(r'(\(.*\))', joined_line) + if parameter_regexp: # Ignore bad syntax + function += parameter_regexp.group(1) + else: + function += '()' + function_state.Begin(function) + break + if not body_found: + # No body for the function (or evidence of a non-function) was found. + error(filename, linenum, 'readability/fn_size', 5, + 'Lint failed to find start of function body.') + elif Match(r'^\}\s*$', line): # function end + function_state.Check(error, filename, linenum) + function_state.End() + elif not Match(r'^\s*$', line): + function_state.Count() # Count non-blank/non-comment lines. + + +_RE_PATTERN_TODO = re.compile(r'^//(\s*)TODO(\(.+?\))?:?(\s|$)?') + + +def CheckComment(line, filename, linenum, next_line_start, error): + """Checks for common mistakes in comments. + + Args: + line: The line in question. + filename: The name of the current file. + linenum: The number of the line to check. + next_line_start: The first non-whitespace column of the next line. + error: The function to call with any errors found. + """ + commentpos = line.find('//') + if commentpos != -1: + # Check if the // may be in quotes. If so, ignore it + if re.sub(r'\\.', '', line[0:commentpos]).count('"') % 2 == 0: + # Allow one space for new scopes, two spaces otherwise: + if (not (Match(r'^.*{ *//', line) and next_line_start == commentpos) and + ((commentpos >= 1 and + line[commentpos-1] not in string.whitespace) or + (commentpos >= 2 and + line[commentpos-2] not in string.whitespace))): + error(filename, linenum, 'whitespace/comments', 2, + 'At least two spaces is best between code and comments') + + # Checks for common mistakes in TODO comments. + comment = line[commentpos:] + match = _RE_PATTERN_TODO.match(comment) + if match: + # One whitespace is correct; zero whitespace is handled elsewhere. + leading_whitespace = match.group(1) + if len(leading_whitespace) > 1: + error(filename, linenum, 'whitespace/todo', 2, + 'Too many spaces before TODO') + + username = match.group(2) + if not username: + error(filename, linenum, 'readability/todo', 2, + 'Missing username in TODO; it should look like ' + '"// TODO(my_username): Stuff."') + + middle_whitespace = match.group(3) + # Comparisons made explicit for correctness -- pylint: disable=g-explicit-bool-comparison + if middle_whitespace != ' ' and middle_whitespace != '': + error(filename, linenum, 'whitespace/todo', 2, + 'TODO(my_username) should be followed by a space') + + # If the comment contains an alphanumeric character, there + # should be a space somewhere between it and the // unless + # it's a /// or //! Doxygen comment. + if (Match(r'//[^ ]*\w', comment) and + not Match(r'(///|//\!)(\s+|$)', comment)): + error(filename, linenum, 'whitespace/comments', 4, + 'Should have a space between // and comment') + + +def CheckAccess(filename, clean_lines, linenum, nesting_state, error): + """Checks for improper use of DISALLOW* macros. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + nesting_state: A NestingState instance which maintains information about + the current stack of nested blocks being parsed. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] # get rid of comments and strings + + matched = Match((r'\s*(DISALLOW_COPY_AND_ASSIGN|' + r'DISALLOW_IMPLICIT_CONSTRUCTORS)'), line) + if not matched: + return + if nesting_state.stack and isinstance(nesting_state.stack[-1], _ClassInfo): + if nesting_state.stack[-1].access != 'private': + error(filename, linenum, 'readability/constructors', 3, + '%s must be in the private: section' % matched.group(1)) + + else: + # Found DISALLOW* macro outside a class declaration, or perhaps it + # was used inside a function when it should have been part of the + # class declaration. We could issue a warning here, but it + # probably resulted in a compiler error already. + pass + + +def CheckSpacing(filename, clean_lines, linenum, nesting_state, error): + """Checks for the correctness of various spacing issues in the code. + + Things we check for: spaces around operators, spaces after + if/for/while/switch, no spaces around parens in function calls, two + spaces between code and comment, don't start a block with a blank + line, don't end a function with a blank line, don't add a blank line + after public/protected/private, don't have too many blank lines in a row. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + nesting_state: A NestingState instance which maintains information about + the current stack of nested blocks being parsed. + error: The function to call with any errors found. + """ + + # Don't use "elided" lines here, otherwise we can't check commented lines. + # Don't want to use "raw" either, because we don't want to check inside C++11 + # raw strings, + raw = clean_lines.lines_without_raw_strings + line = raw[linenum] + + # Before nixing comments, check if the line is blank for no good + # reason. This includes the first line after a block is opened, and + # blank lines at the end of a function (ie, right before a line like '}' + # + # Skip all the blank line checks if we are immediately inside a + # namespace body. In other words, don't issue blank line warnings + # for this block: + # namespace { + # + # } + # + # A warning about missing end of namespace comments will be issued instead. + # + # Also skip blank line checks for 'extern "C"' blocks, which are formatted + # like namespaces. + if (IsBlankLine(line) and + not nesting_state.InNamespaceBody() and + not nesting_state.InExternC()): + elided = clean_lines.elided + prev_line = elided[linenum - 1] + prevbrace = prev_line.rfind('{') + # TODO(unknown): Don't complain if line before blank line, and line after, + # both start with alnums and are indented the same amount. + # This ignores whitespace at the start of a namespace block + # because those are not usually indented. + if prevbrace != -1 and prev_line[prevbrace:].find('}') == -1: + # OK, we have a blank line at the start of a code block. Before we + # complain, we check if it is an exception to the rule: The previous + # non-empty line has the parameters of a function header that are indented + # 4 spaces (because they did not fit in a 80 column line when placed on + # the same line as the function name). We also check for the case where + # the previous line is indented 6 spaces, which may happen when the + # initializers of a constructor do not fit into a 80 column line. + exception = False + if Match(r' {6}\w', prev_line): # Initializer list? + # We are looking for the opening column of initializer list, which + # should be indented 4 spaces to cause 6 space indentation afterwards. + search_position = linenum-2 + while (search_position >= 0 + and Match(r' {6}\w', elided[search_position])): + search_position -= 1 + exception = (search_position >= 0 + and elided[search_position][:5] == ' :') + else: + # Search for the function arguments or an initializer list. We use a + # simple heuristic here: If the line is indented 4 spaces; and we have a + # closing paren, without the opening paren, followed by an opening brace + # or colon (for initializer lists) we assume that it is the last line of + # a function header. If we have a colon indented 4 spaces, it is an + # initializer list. + exception = (Match(r' {4}\w[^\(]*\)\s*(const\s*)?(\{\s*$|:)', + prev_line) + or Match(r' {4}:', prev_line)) + + if not exception: + error(filename, linenum, 'whitespace/blank_line', 2, + 'Redundant blank line at the start of a code block ' + 'should be deleted.') + # Ignore blank lines at the end of a block in a long if-else + # chain, like this: + # if (condition1) { + # // Something followed by a blank line + # + # } else if (condition2) { + # // Something else + # } + if linenum + 1 < clean_lines.NumLines(): + next_line = raw[linenum + 1] + if (next_line + and Match(r'\s*}', next_line) + and next_line.find('} else ') == -1): + error(filename, linenum, 'whitespace/blank_line', 3, + 'Redundant blank line at the end of a code block ' + 'should be deleted.') + + matched = Match(r'\s*(public|protected|private):', prev_line) + if matched: + error(filename, linenum, 'whitespace/blank_line', 3, + 'Do not leave a blank line after "%s:"' % matched.group(1)) + + # Next, check comments + next_line_start = 0 + if linenum + 1 < clean_lines.NumLines(): + next_line = raw[linenum + 1] + next_line_start = len(next_line) - len(next_line.lstrip()) + CheckComment(line, filename, linenum, next_line_start, error) + + # get rid of comments and strings + line = clean_lines.elided[linenum] + + # You shouldn't have spaces before your brackets, except maybe after + # 'delete []' or 'return []() {};' + if Search(r'\w\s+\[', line) and not Search(r'(?:delete|return)\s+\[', line): + error(filename, linenum, 'whitespace/braces', 5, + 'Extra space before [') + + # In range-based for, we wanted spaces before and after the colon, but + # not around "::" tokens that might appear. + if (Search(r'for *\(.*[^:]:[^: ]', line) or + Search(r'for *\(.*[^: ]:[^:]', line)): + error(filename, linenum, 'whitespace/forcolon', 2, + 'Missing space around colon in range-based for loop') + + +def CheckOperatorSpacing(filename, clean_lines, linenum, error): + """Checks for horizontal spacing around operators. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + # Don't try to do spacing checks for operator methods. Do this by + # replacing the troublesome characters with something else, + # preserving column position for all other characters. + # + # The replacement is done repeatedly to avoid false positives from + # operators that call operators. + while True: + match = Match(r'^(.*\boperator\b)(\S+)(\s*\(.*)$', line) + if match: + line = match.group(1) + ('_' * len(match.group(2))) + match.group(3) + else: + break + + # We allow no-spaces around = within an if: "if ( (a=Foo()) == 0 )". + # Otherwise not. Note we only check for non-spaces on *both* sides; + # sometimes people put non-spaces on one side when aligning ='s among + # many lines (not that this is behavior that I approve of...) + if ((Search(r'[\w.]=', line) or + Search(r'=[\w.]', line)) + and not Search(r'\b(if|while|for) ', line) + # Operators taken from [lex.operators] in C++11 standard. + and not Search(r'(>=|<=|==|!=|&=|\^=|\|=|\+=|\*=|\/=|\%=)', line) + and not Search(r'operator=', line)): + error(filename, linenum, 'whitespace/operators', 4, + 'Missing spaces around =') + + # It's ok not to have spaces around binary operators like + - * /, but if + # there's too little whitespace, we get concerned. It's hard to tell, + # though, so we punt on this one for now. TODO. + + # You should always have whitespace around binary operators. + # + # Check <= and >= first to avoid false positives with < and >, then + # check non-include lines for spacing around < and >. + # + # If the operator is followed by a comma, assume it's be used in a + # macro context and don't do any checks. This avoids false + # positives. + # + # Note that && is not included here. This is because there are too + # many false positives due to RValue references. + match = Search(r'[^<>=!\s](==|!=|<=|>=|\|\|)[^<>=!\s,;\)]', line) + if match: + error(filename, linenum, 'whitespace/operators', 3, + 'Missing spaces around %s' % match.group(1)) + elif not Match(r'#.*include', line): + # Look for < that is not surrounded by spaces. This is only + # triggered if both sides are missing spaces, even though + # technically should should flag if at least one side is missing a + # space. This is done to avoid some false positives with shifts. + match = Match(r'^(.*[^\s<])<[^\s=<,]', line) + if match: + (_, _, end_pos) = CloseExpression( + clean_lines, linenum, len(match.group(1))) + if end_pos <= -1: + error(filename, linenum, 'whitespace/operators', 3, + 'Missing spaces around <') + + # Look for > that is not surrounded by spaces. Similar to the + # above, we only trigger if both sides are missing spaces to avoid + # false positives with shifts. + match = Match(r'^(.*[^-\s>])>[^\s=>,]', line) + if match: + (_, _, start_pos) = ReverseCloseExpression( + clean_lines, linenum, len(match.group(1))) + if start_pos <= -1: + error(filename, linenum, 'whitespace/operators', 3, + 'Missing spaces around >') + + # We allow no-spaces around << when used like this: 10<<20, but + # not otherwise (particularly, not when used as streams) + # + # We also allow operators following an opening parenthesis, since + # those tend to be macros that deal with operators. + match = Search(r'(operator|[^\s(<])(?:L|UL|LL|ULL|l|ul|ll|ull)?<<([^\s,=<])', line) + if (match and not (match.group(1).isdigit() and match.group(2).isdigit()) and + not (match.group(1) == 'operator' and match.group(2) == ';')): + error(filename, linenum, 'whitespace/operators', 3, + 'Missing spaces around <<') + + # We allow no-spaces around >> for almost anything. This is because + # C++11 allows ">>" to close nested templates, which accounts for + # most cases when ">>" is not followed by a space. + # + # We still warn on ">>" followed by alpha character, because that is + # likely due to ">>" being used for right shifts, e.g.: + # value >> alpha + # + # When ">>" is used to close templates, the alphanumeric letter that + # follows would be part of an identifier, and there should still be + # a space separating the template type and the identifier. + # type> alpha + match = Search(r'>>[a-zA-Z_]', line) + if match: + error(filename, linenum, 'whitespace/operators', 3, + 'Missing spaces around >>') + + # There shouldn't be space around unary operators + match = Search(r'(!\s|~\s|[\s]--[\s;]|[\s]\+\+[\s;])', line) + if match: + error(filename, linenum, 'whitespace/operators', 4, + 'Extra space for operator %s' % match.group(1)) + + +def CheckParenthesisSpacing(filename, clean_lines, linenum, error): + """Checks for horizontal spacing around parentheses. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + # No spaces after an if, while, switch, or for + match = Search(r' (if\(|for\(|while\(|switch\()', line) + if match: + error(filename, linenum, 'whitespace/parens', 5, + 'Missing space before ( in %s' % match.group(1)) + + # For if/for/while/switch, the left and right parens should be + # consistent about how many spaces are inside the parens, and + # there should either be zero or one spaces inside the parens. + # We don't want: "if ( foo)" or "if ( foo )". + # Exception: "for ( ; foo; bar)" and "for (foo; bar; )" are allowed. + match = Search(r'\b(if|for|while|switch)\s*' + r'\(([ ]*)(.).*[^ ]+([ ]*)\)\s*{\s*$', + line) + if match: + if len(match.group(2)) != len(match.group(4)): + if not (match.group(3) == ';' and + len(match.group(2)) == 1 + len(match.group(4)) or + not match.group(2) and Search(r'\bfor\s*\(.*; \)', line)): + error(filename, linenum, 'whitespace/parens', 5, + 'Mismatching spaces inside () in %s' % match.group(1)) + if len(match.group(2)) not in [0, 1]: + error(filename, linenum, 'whitespace/parens', 5, + 'Should have zero or one spaces inside ( and ) in %s' % + match.group(1)) + + +def CheckCommaSpacing(filename, clean_lines, linenum, error): + """Checks for horizontal spacing near commas and semicolons. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + raw = clean_lines.lines_without_raw_strings + line = clean_lines.elided[linenum] + + # You should always have a space after a comma (either as fn arg or operator) + # + # This does not apply when the non-space character following the + # comma is another comma, since the only time when that happens is + # for empty macro arguments. + # + # We run this check in two passes: first pass on elided lines to + # verify that lines contain missing whitespaces, second pass on raw + # lines to confirm that those missing whitespaces are not due to + # elided comments. + if (Search(r',[^,\s]', ReplaceAll(r'\boperator\s*,\s*\(', 'F(', line)) and + Search(r',[^,\s]', raw[linenum])): + error(filename, linenum, 'whitespace/comma', 3, + 'Missing space after ,') + + # You should always have a space after a semicolon + # except for few corner cases + # TODO(unknown): clarify if 'if (1) { return 1;}' is requires one more + # space after ; + if Search(r';[^\s};\\)/]', line): + error(filename, linenum, 'whitespace/semicolon', 3, + 'Missing space after ;') + + +def _IsType(clean_lines, nesting_state, expr): + """Check if expression looks like a type name, returns true if so. + + Args: + clean_lines: A CleansedLines instance containing the file. + nesting_state: A NestingState instance which maintains information about + the current stack of nested blocks being parsed. + expr: The expression to check. + Returns: + True, if token looks like a type. + """ + # Keep only the last token in the expression + last_word = Match(r'^.*(\b\S+)$', expr) + if last_word: + token = last_word.group(1) + else: + token = expr + + # Match native types and stdint types + if _TYPES.match(token): + return True + + # Try a bit harder to match templated types. Walk up the nesting + # stack until we find something that resembles a typename + # declaration for what we are looking for. + typename_pattern = (r'\b(?:typename|class|struct)\s+' + re.escape(token) + + r'\b') + block_index = len(nesting_state.stack) - 1 + while block_index >= 0: + if isinstance(nesting_state.stack[block_index], _NamespaceInfo): + return False + + # Found where the opening brace is. We want to scan from this + # line up to the beginning of the function, minus a few lines. + # template + # class C + # : public ... { // start scanning here + last_line = nesting_state.stack[block_index].starting_linenum + + next_block_start = 0 + if block_index > 0: + next_block_start = nesting_state.stack[block_index - 1].starting_linenum + first_line = last_line + while first_line >= next_block_start: + if clean_lines.elided[first_line].find('template') >= 0: + break + first_line -= 1 + if first_line < next_block_start: + # Didn't find any "template" keyword before reaching the next block, + # there are probably no template things to check for this block + block_index -= 1 + continue + + # Look for typename in the specified range + for i in xrange(first_line, last_line + 1, 1): + if Search(typename_pattern, clean_lines.elided[i]): + return True + block_index -= 1 + + return False + + +def CheckBracesSpacing(filename, clean_lines, linenum, nesting_state, error): + """Checks for horizontal spacing near commas. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + nesting_state: A NestingState instance which maintains information about + the current stack of nested blocks being parsed. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + # Except after an opening paren, or after another opening brace (in case of + # an initializer list, for instance), you should have spaces before your + # braces when they are delimiting blocks, classes, namespaces etc. + # And since you should never have braces at the beginning of a line, + # this is an easy test. Except that braces used for initialization don't + # follow the same rule; we often don't want spaces before those. + match = Match(r'^(.*[^ ({>]){', line) + + if match: + # Try a bit harder to check for brace initialization. This + # happens in one of the following forms: + # Constructor() : initializer_list_{} { ... } + # Constructor{}.MemberFunction() + # Type variable{}; + # FunctionCall(type{}, ...); + # LastArgument(..., type{}); + # LOG(INFO) << type{} << " ..."; + # map_of_type[{...}] = ...; + # ternary = expr ? new type{} : nullptr; + # OuterTemplate{}> + # + # We check for the character following the closing brace, and + # silence the warning if it's one of those listed above, i.e. + # "{.;,)<>]:". + # + # To account for nested initializer list, we allow any number of + # closing braces up to "{;,)<". We can't simply silence the + # warning on first sight of closing brace, because that would + # cause false negatives for things that are not initializer lists. + # Silence this: But not this: + # Outer{ if (...) { + # Inner{...} if (...){ // Missing space before { + # }; } + # + # There is a false negative with this approach if people inserted + # spurious semicolons, e.g. "if (cond){};", but we will catch the + # spurious semicolon with a separate check. + leading_text = match.group(1) + (endline, endlinenum, endpos) = CloseExpression( + clean_lines, linenum, len(match.group(1))) + trailing_text = '' + if endpos > -1: + trailing_text = endline[endpos:] + for offset in xrange(endlinenum + 1, + min(endlinenum + 3, clean_lines.NumLines() - 1)): + trailing_text += clean_lines.elided[offset] + # We also suppress warnings for `uint64_t{expression}` etc., as the style + # guide recommends brace initialization for integral types to avoid + # overflow/truncation. + if (not Match(r'^[\s}]*[{.;,)<>\]:]', trailing_text) + and not _IsType(clean_lines, nesting_state, leading_text)): + error(filename, linenum, 'whitespace/braces', 5, + 'Missing space before {') + + # Make sure '} else {' has spaces. + if Search(r'}else', line): + error(filename, linenum, 'whitespace/braces', 5, + 'Missing space before else') + + # You shouldn't have a space before a semicolon at the end of the line. + # There's a special case for "for" since the style guide allows space before + # the semicolon there. + if Search(r':\s*;\s*$', line): + error(filename, linenum, 'whitespace/semicolon', 5, + 'Semicolon defining empty statement. Use {} instead.') + elif Search(r'^\s*;\s*$', line): + error(filename, linenum, 'whitespace/semicolon', 5, + 'Line contains only semicolon. If this should be an empty statement, ' + 'use {} instead.') + elif (Search(r'\s+;\s*$', line) and + not Search(r'\bfor\b', line)): + error(filename, linenum, 'whitespace/semicolon', 5, + 'Extra space before last semicolon. If this should be an empty ' + 'statement, use {} instead.') + + +def IsDecltype(clean_lines, linenum, column): + """Check if the token ending on (linenum, column) is decltype(). + + Args: + clean_lines: A CleansedLines instance containing the file. + linenum: the number of the line to check. + column: end column of the token to check. + Returns: + True if this token is decltype() expression, False otherwise. + """ + (text, _, start_col) = ReverseCloseExpression(clean_lines, linenum, column) + if start_col < 0: + return False + if Search(r'\bdecltype\s*$', text[0:start_col]): + return True + return False + +def CheckSectionSpacing(filename, clean_lines, class_info, linenum, error): + """Checks for additional blank line issues related to sections. + + Currently the only thing checked here is blank line before protected/private. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + class_info: A _ClassInfo objects. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + # Skip checks if the class is small, where small means 25 lines or less. + # 25 lines seems like a good cutoff since that's the usual height of + # terminals, and any class that can't fit in one screen can't really + # be considered "small". + # + # Also skip checks if we are on the first line. This accounts for + # classes that look like + # class Foo { public: ... }; + # + # If we didn't find the end of the class, last_line would be zero, + # and the check will be skipped by the first condition. + if (class_info.last_line - class_info.starting_linenum <= 24 or + linenum <= class_info.starting_linenum): + return + + matched = Match(r'\s*(public|protected|private):', clean_lines.lines[linenum]) + if matched: + # Issue warning if the line before public/protected/private was + # not a blank line, but don't do this if the previous line contains + # "class" or "struct". This can happen two ways: + # - We are at the beginning of the class. + # - We are forward-declaring an inner class that is semantically + # private, but needed to be public for implementation reasons. + # Also ignores cases where the previous line ends with a backslash as can be + # common when defining classes in C macros. + prev_line = clean_lines.lines[linenum - 1] + if (not IsBlankLine(prev_line) and + not Search(r'\b(class|struct)\b', prev_line) and + not Search(r'\\$', prev_line)): + # Try a bit harder to find the beginning of the class. This is to + # account for multi-line base-specifier lists, e.g.: + # class Derived + # : public Base { + end_class_head = class_info.starting_linenum + for i in range(class_info.starting_linenum, linenum): + if Search(r'\{\s*$', clean_lines.lines[i]): + end_class_head = i + break + if end_class_head < linenum - 1: + error(filename, linenum, 'whitespace/blank_line', 3, + '"%s:" should be preceded by a blank line' % matched.group(1)) + + +def GetPreviousNonBlankLine(clean_lines, linenum): + """Return the most recent non-blank line and its line number. + + Args: + clean_lines: A CleansedLines instance containing the file contents. + linenum: The number of the line to check. + + Returns: + A tuple with two elements. The first element is the contents of the last + non-blank line before the current line, or the empty string if this is the + first non-blank line. The second is the line number of that line, or -1 + if this is the first non-blank line. + """ + + prevlinenum = linenum - 1 + while prevlinenum >= 0: + prevline = clean_lines.elided[prevlinenum] + if not IsBlankLine(prevline): # if not a blank line... + return (prevline, prevlinenum) + prevlinenum -= 1 + return ('', -1) + + +def CheckBraces(filename, clean_lines, linenum, error): + """Looks for misplaced braces (e.g. at the end of line). + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + + line = clean_lines.elided[linenum] # get rid of comments and strings + + if Match(r'\s*{\s*$', line): + # We allow an open brace to start a line in the case where someone is using + # braces in a block to explicitly create a new scope, which is commonly used + # to control the lifetime of stack-allocated variables. Braces are also + # used for brace initializers inside function calls. We don't detect this + # perfectly: we just don't complain if the last non-whitespace character on + # the previous non-blank line is ',', ';', ':', '(', '{', or '}', or if the + # previous line starts a preprocessor block. We also allow a brace on the + # following line if it is part of an array initialization and would not fit + # within the 80 character limit of the preceding line. + prevline = GetPreviousNonBlankLine(clean_lines, linenum)[0] + if (not Search(r'[,;:}{(]\s*$', prevline) and + not Match(r'\s*#', prevline) and + not (GetLineWidth(prevline) > _line_length - 2 and '[]' in prevline)): + error(filename, linenum, 'whitespace/braces', 4, + '{ should almost always be at the end of the previous line') + + # An else clause should be on the same line as the preceding closing brace. + if Match(r'\s*else\b\s*(?:if\b|\{|$)', line): + prevline = GetPreviousNonBlankLine(clean_lines, linenum)[0] + if Match(r'\s*}\s*$', prevline): + error(filename, linenum, 'whitespace/newline', 4, + 'An else should appear on the same line as the preceding }') + + # If braces come on one side of an else, they should be on both. + # However, we have to worry about "else if" that spans multiple lines! + if Search(r'else if\s*\(', line): # could be multi-line if + brace_on_left = bool(Search(r'}\s*else if\s*\(', line)) + # find the ( after the if + pos = line.find('else if') + pos = line.find('(', pos) + if pos > 0: + (endline, _, endpos) = CloseExpression(clean_lines, linenum, pos) + brace_on_right = endline[endpos:].find('{') != -1 + if brace_on_left != brace_on_right: # must be brace after if + error(filename, linenum, 'readability/braces', 5, + 'If an else has a brace on one side, it should have it on both') + elif Search(r'}\s*else[^{]*$', line) or Match(r'[^}]*else\s*{', line): + error(filename, linenum, 'readability/braces', 5, + 'If an else has a brace on one side, it should have it on both') + + # Likewise, an else should never have the else clause on the same line + if Search(r'\belse [^\s{]', line) and not Search(r'\belse if\b', line): + error(filename, linenum, 'whitespace/newline', 4, + 'Else clause should never be on same line as else (use 2 lines)') + + # In the same way, a do/while should never be on one line + if Match(r'\s*do [^\s{]', line): + error(filename, linenum, 'whitespace/newline', 4, + 'do/while clauses should not be on a single line') + + # Check single-line if/else bodies. The style guide says 'curly braces are not + # required for single-line statements'. We additionally allow multi-line, + # single statements, but we reject anything with more than one semicolon in + # it. This means that the first semicolon after the if should be at the end of + # its line, and the line after that should have an indent level equal to or + # lower than the if. We also check for ambiguous if/else nesting without + # braces. + if_else_match = Search(r'\b(if\s*\(|else\b)', line) + if if_else_match and not Match(r'\s*#', line): + if_indent = GetIndentLevel(line) + endline, endlinenum, endpos = line, linenum, if_else_match.end() + if_match = Search(r'\bif\s*\(', line) + if if_match: + # This could be a multiline if condition, so find the end first. + pos = if_match.end() - 1 + (endline, endlinenum, endpos) = CloseExpression(clean_lines, linenum, pos) + # Check for an opening brace, either directly after the if or on the next + # line. If found, this isn't a single-statement conditional. + if (not Match(r'\s*{', endline[endpos:]) + and not (Match(r'\s*$', endline[endpos:]) + and endlinenum < (len(clean_lines.elided) - 1) + and Match(r'\s*{', clean_lines.elided[endlinenum + 1]))): + while (endlinenum < len(clean_lines.elided) + and ';' not in clean_lines.elided[endlinenum][endpos:]): + endlinenum += 1 + endpos = 0 + if endlinenum < len(clean_lines.elided): + endline = clean_lines.elided[endlinenum] + # We allow a mix of whitespace and closing braces (e.g. for one-liner + # methods) and a single \ after the semicolon (for macros) + endpos = endline.find(';') + if not Match(r';[\s}]*(\\?)$', endline[endpos:]): + # Semicolon isn't the last character, there's something trailing. + # Output a warning if the semicolon is not contained inside + # a lambda expression. + if not Match(r'^[^{};]*\[[^\[\]]*\][^{}]*\{[^{}]*\}\s*\)*[;,]\s*$', + endline): + error(filename, linenum, 'readability/braces', 4, + 'If/else bodies with multiple statements require braces') + elif endlinenum < len(clean_lines.elided) - 1: + # Make sure the next line is dedented + next_line = clean_lines.elided[endlinenum + 1] + next_indent = GetIndentLevel(next_line) + # With ambiguous nested if statements, this will error out on the + # if that *doesn't* match the else, regardless of whether it's the + # inner one or outer one. + if (if_match and Match(r'\s*else\b', next_line) + and next_indent != if_indent): + error(filename, linenum, 'readability/braces', 4, + 'Else clause should be indented at the same level as if. ' + 'Ambiguous nested if/else chains require braces.') + elif next_indent > if_indent: + error(filename, linenum, 'readability/braces', 4, + 'If/else bodies with multiple statements require braces') + + +def CheckTrailingSemicolon(filename, clean_lines, linenum, error): + """Looks for redundant trailing semicolon. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + + line = clean_lines.elided[linenum] + + # Block bodies should not be followed by a semicolon. Due to C++11 + # brace initialization, there are more places where semicolons are + # required than not, so we use a whitelist approach to check these + # rather than a blacklist. These are the places where "};" should + # be replaced by just "}": + # 1. Some flavor of block following closing parenthesis: + # for (;;) {}; + # while (...) {}; + # switch (...) {}; + # Function(...) {}; + # if (...) {}; + # if (...) else if (...) {}; + # + # 2. else block: + # if (...) else {}; + # + # 3. const member function: + # Function(...) const {}; + # + # 4. Block following some statement: + # x = 42; + # {}; + # + # 5. Block at the beginning of a function: + # Function(...) { + # {}; + # } + # + # Note that naively checking for the preceding "{" will also match + # braces inside multi-dimensional arrays, but this is fine since + # that expression will not contain semicolons. + # + # 6. Block following another block: + # while (true) {} + # {}; + # + # 7. End of namespaces: + # namespace {}; + # + # These semicolons seems far more common than other kinds of + # redundant semicolons, possibly due to people converting classes + # to namespaces. For now we do not warn for this case. + # + # Try matching case 1 first. + match = Match(r'^(.*\)\s*)\{', line) + if match: + # Matched closing parenthesis (case 1). Check the token before the + # matching opening parenthesis, and don't warn if it looks like a + # macro. This avoids these false positives: + # - macro that defines a base class + # - multi-line macro that defines a base class + # - macro that defines the whole class-head + # + # But we still issue warnings for macros that we know are safe to + # warn, specifically: + # - TEST, TEST_F, TEST_P, MATCHER, MATCHER_P + # - TYPED_TEST + # - INTERFACE_DEF + # - EXCLUSIVE_LOCKS_REQUIRED, SHARED_LOCKS_REQUIRED, LOCKS_EXCLUDED: + # + # We implement a whitelist of safe macros instead of a blacklist of + # unsafe macros, even though the latter appears less frequently in + # google code and would have been easier to implement. This is because + # the downside for getting the whitelist wrong means some extra + # semicolons, while the downside for getting the blacklist wrong + # would result in compile errors. + # + # In addition to macros, we also don't want to warn on + # - Compound literals + # - Lambdas + # - alignas specifier with anonymous structs + # - decltype + closing_brace_pos = match.group(1).rfind(')') + opening_parenthesis = ReverseCloseExpression( + clean_lines, linenum, closing_brace_pos) + if opening_parenthesis[2] > -1: + line_prefix = opening_parenthesis[0][0:opening_parenthesis[2]] + macro = Search(r'\b([A-Z_][A-Z0-9_]*)\s*$', line_prefix) + func = Match(r'^(.*\])\s*$', line_prefix) + if ((macro and + macro.group(1) not in ( + 'TEST', 'TEST_F', 'MATCHER', 'MATCHER_P', 'TYPED_TEST', + 'EXCLUSIVE_LOCKS_REQUIRED', 'SHARED_LOCKS_REQUIRED', + 'LOCKS_EXCLUDED', 'INTERFACE_DEF')) or + (func and not Search(r'\boperator\s*\[\s*\]', func.group(1))) or + Search(r'\b(?:struct|union)\s+alignas\s*$', line_prefix) or + Search(r'\bdecltype$', line_prefix) or + Search(r'\breturn\s*$', line_prefix) or + Search(r'\s+=\s*$', line_prefix)): + match = None + if (match and + opening_parenthesis[1] > 1 and + Search(r'\]\s*$', clean_lines.elided[opening_parenthesis[1] - 1])): + # Multi-line lambda-expression + match = None + + else: + # Try matching cases 2-3. + match = Match(r'^(.*(?:else|\)\s*const)\s*)\{', line) + if not match: + # Try matching cases 4-6. These are always matched on separate lines. + # + # Note that we can't simply concatenate the previous line to the + # current line and do a single match, otherwise we may output + # duplicate warnings for the blank line case: + # if (cond) { + # // blank line + # } + prevline = GetPreviousNonBlankLine(clean_lines, linenum)[0] + if prevline and Search(r'[;{}]\s*$', prevline): + match = Match(r'^(\s*)\{', line) + + # Check matching closing brace + if match: + (endline, endlinenum, endpos) = CloseExpression( + clean_lines, linenum, len(match.group(1))) + if endpos > -1 and Match(r'^\s*;', endline[endpos:]): + # Current {} pair is eligible for semicolon check, and we have found + # the redundant semicolon, output warning here. + # + # Note: because we are scanning forward for opening braces, and + # outputting warnings for the matching closing brace, if there are + # nested blocks with trailing semicolons, we will get the error + # messages in reversed order. + + # We need to check the line forward for NOLINT + raw_lines = clean_lines.raw_lines + ParseNolintSuppressions(filename, raw_lines[endlinenum-1], endlinenum-1, + error) + ParseNolintSuppressions(filename, raw_lines[endlinenum], endlinenum, + error) + + error(filename, endlinenum, 'readability/braces', 4, + "You don't need a ; after a }") + + +def CheckEmptyBlockBody(filename, clean_lines, linenum, error): + """Look for empty loop/conditional body with only a single semicolon. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + + # Search for loop keywords at the beginning of the line. Because only + # whitespaces are allowed before the keywords, this will also ignore most + # do-while-loops, since those lines should start with closing brace. + # + # We also check "if" blocks here, since an empty conditional block + # is likely an error. + line = clean_lines.elided[linenum] + matched = Match(r'\s*(for|while|if)\s*\(', line) + if matched: + # Find the end of the conditional expression. + (end_line, end_linenum, end_pos) = CloseExpression( + clean_lines, linenum, line.find('(')) + + # Output warning if what follows the condition expression is a semicolon. + # No warning for all other cases, including whitespace or newline, since we + # have a separate check for semicolons preceded by whitespace. + if end_pos >= 0 and Match(r';', end_line[end_pos:]): + if matched.group(1) == 'if': + error(filename, end_linenum, 'whitespace/empty_conditional_body', 5, + 'Empty conditional bodies should use {}') + else: + error(filename, end_linenum, 'whitespace/empty_loop_body', 5, + 'Empty loop bodies should use {} or continue') + + # Check for if statements that have completely empty bodies (no comments) + # and no else clauses. + if end_pos >= 0 and matched.group(1) == 'if': + # Find the position of the opening { for the if statement. + # Return without logging an error if it has no brackets. + opening_linenum = end_linenum + opening_line_fragment = end_line[end_pos:] + # Loop until EOF or find anything that's not whitespace or opening {. + while not Search(r'^\s*\{', opening_line_fragment): + if Search(r'^(?!\s*$)', opening_line_fragment): + # Conditional has no brackets. + return + opening_linenum += 1 + if opening_linenum == len(clean_lines.elided): + # Couldn't find conditional's opening { or any code before EOF. + return + opening_line_fragment = clean_lines.elided[opening_linenum] + # Set opening_line (opening_line_fragment may not be entire opening line). + opening_line = clean_lines.elided[opening_linenum] + + # Find the position of the closing }. + opening_pos = opening_line_fragment.find('{') + if opening_linenum == end_linenum: + # We need to make opening_pos relative to the start of the entire line. + opening_pos += end_pos + (closing_line, closing_linenum, closing_pos) = CloseExpression( + clean_lines, opening_linenum, opening_pos) + if closing_pos < 0: + return + + # Now construct the body of the conditional. This consists of the portion + # of the opening line after the {, all lines until the closing line, + # and the portion of the closing line before the }. + if (clean_lines.raw_lines[opening_linenum] != + CleanseComments(clean_lines.raw_lines[opening_linenum])): + # Opening line ends with a comment, so conditional isn't empty. + return + if closing_linenum > opening_linenum: + # Opening line after the {. Ignore comments here since we checked above. + bodylist = list(opening_line[opening_pos+1:]) + # All lines until closing line, excluding closing line, with comments. + bodylist.extend(clean_lines.raw_lines[opening_linenum+1:closing_linenum]) + # Closing line before the }. Won't (and can't) have comments. + bodylist.append(clean_lines.elided[closing_linenum][:closing_pos-1]) + body = '\n'.join(bodylist) + else: + # If statement has brackets and fits on a single line. + body = opening_line[opening_pos+1:closing_pos-1] + + # Check if the body is empty + if not _EMPTY_CONDITIONAL_BODY_PATTERN.search(body): + return + # The body is empty. Now make sure there's not an else clause. + current_linenum = closing_linenum + current_line_fragment = closing_line[closing_pos:] + # Loop until EOF or find anything that's not whitespace or else clause. + while Search(r'^\s*$|^(?=\s*else)', current_line_fragment): + if Search(r'^(?=\s*else)', current_line_fragment): + # Found an else clause, so don't log an error. + return + current_linenum += 1 + if current_linenum == len(clean_lines.elided): + break + current_line_fragment = clean_lines.elided[current_linenum] + + # The body is empty and there's no else clause until EOF or other code. + error(filename, end_linenum, 'whitespace/empty_if_body', 4, + ('If statement had no body and no else clause')) + + +def FindCheckMacro(line): + """Find a replaceable CHECK-like macro. + + Args: + line: line to search on. + Returns: + (macro name, start position), or (None, -1) if no replaceable + macro is found. + """ + for macro in _CHECK_MACROS: + i = line.find(macro) + if i >= 0: + # Find opening parenthesis. Do a regular expression match here + # to make sure that we are matching the expected CHECK macro, as + # opposed to some other macro that happens to contain the CHECK + # substring. + matched = Match(r'^(.*\b' + macro + r'\s*)\(', line) + if not matched: + continue + return (macro, len(matched.group(1))) + return (None, -1) + + +def CheckCheck(filename, clean_lines, linenum, error): + """Checks the use of CHECK and EXPECT macros. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + + # Decide the set of replacement macros that should be suggested + lines = clean_lines.elided + (check_macro, start_pos) = FindCheckMacro(lines[linenum]) + if not check_macro: + return + + # Find end of the boolean expression by matching parentheses + (last_line, end_line, end_pos) = CloseExpression( + clean_lines, linenum, start_pos) + if end_pos < 0: + return + + # If the check macro is followed by something other than a + # semicolon, assume users will log their own custom error messages + # and don't suggest any replacements. + if not Match(r'\s*;', last_line[end_pos:]): + return + + if linenum == end_line: + expression = lines[linenum][start_pos + 1:end_pos - 1] + else: + expression = lines[linenum][start_pos + 1:] + for i in xrange(linenum + 1, end_line): + expression += lines[i] + expression += last_line[0:end_pos - 1] + + # Parse expression so that we can take parentheses into account. + # This avoids false positives for inputs like "CHECK((a < 4) == b)", + # which is not replaceable by CHECK_LE. + lhs = '' + rhs = '' + operator = None + while expression: + matched = Match(r'^\s*(<<|<<=|>>|>>=|->\*|->|&&|\|\||' + r'==|!=|>=|>|<=|<|\()(.*)$', expression) + if matched: + token = matched.group(1) + if token == '(': + # Parenthesized operand + expression = matched.group(2) + (end, _) = FindEndOfExpressionInLine(expression, 0, ['(']) + if end < 0: + return # Unmatched parenthesis + lhs += '(' + expression[0:end] + expression = expression[end:] + elif token in ('&&', '||'): + # Logical and/or operators. This means the expression + # contains more than one term, for example: + # CHECK(42 < a && a < b); + # + # These are not replaceable with CHECK_LE, so bail out early. + return + elif token in ('<<', '<<=', '>>', '>>=', '->*', '->'): + # Non-relational operator + lhs += token + expression = matched.group(2) + else: + # Relational operator + operator = token + rhs = matched.group(2) + break + else: + # Unparenthesized operand. Instead of appending to lhs one character + # at a time, we do another regular expression match to consume several + # characters at once if possible. Trivial benchmark shows that this + # is more efficient when the operands are longer than a single + # character, which is generally the case. + matched = Match(r'^([^-=!<>()&|]+)(.*)$', expression) + if not matched: + matched = Match(r'^(\s*\S)(.*)$', expression) + if not matched: + break + lhs += matched.group(1) + expression = matched.group(2) + + # Only apply checks if we got all parts of the boolean expression + if not (lhs and operator and rhs): + return + + # Check that rhs do not contain logical operators. We already know + # that lhs is fine since the loop above parses out && and ||. + if rhs.find('&&') > -1 or rhs.find('||') > -1: + return + + # At least one of the operands must be a constant literal. This is + # to avoid suggesting replacements for unprintable things like + # CHECK(variable != iterator) + # + # The following pattern matches decimal, hex integers, strings, and + # characters (in that order). + lhs = lhs.strip() + rhs = rhs.strip() + match_constant = r'^([-+]?(\d+|0[xX][0-9a-fA-F]+)[lLuU]{0,3}|".*"|\'.*\')$' + if Match(match_constant, lhs) or Match(match_constant, rhs): + # Note: since we know both lhs and rhs, we can provide a more + # descriptive error message like: + # Consider using CHECK_EQ(x, 42) instead of CHECK(x == 42) + # Instead of: + # Consider using CHECK_EQ instead of CHECK(a == b) + # + # We are still keeping the less descriptive message because if lhs + # or rhs gets long, the error message might become unreadable. + error(filename, linenum, 'readability/check', 2, + 'Consider using %s instead of %s(a %s b)' % ( + _CHECK_REPLACEMENT[check_macro][operator], + check_macro, operator)) + + +def CheckAltTokens(filename, clean_lines, linenum, error): + """Check alternative keywords being used in boolean expressions. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + # Avoid preprocessor lines + if Match(r'^\s*#', line): + return + + # Last ditch effort to avoid multi-line comments. This will not help + # if the comment started before the current line or ended after the + # current line, but it catches most of the false positives. At least, + # it provides a way to workaround this warning for people who use + # multi-line comments in preprocessor macros. + # + # TODO(unknown): remove this once cpplint has better support for + # multi-line comments. + if line.find('/*') >= 0 or line.find('*/') >= 0: + return + + for match in _ALT_TOKEN_REPLACEMENT_PATTERN.finditer(line): + error(filename, linenum, 'readability/alt_tokens', 2, + 'Use operator %s instead of %s' % ( + _ALT_TOKEN_REPLACEMENT[match.group(1)], match.group(1))) + + +def GetLineWidth(line): + """Determines the width of the line in column positions. + + Args: + line: A string, which may be a Unicode string. + + Returns: + The width of the line in column positions, accounting for Unicode + combining characters and wide characters. + """ + if isinstance(line, unicode): + width = 0 + for uc in unicodedata.normalize('NFC', line): + if unicodedata.east_asian_width(uc) in ('W', 'F'): + width += 2 + elif not unicodedata.combining(uc): + width += 1 + return width + else: + return len(line) + + +def CheckStyle(filename, clean_lines, linenum, file_extension, nesting_state, + error): + """Checks rules from the 'C++ style rules' section of cppguide.html. + + Most of these rules are hard to test (naming, comment style), but we + do what we can. In particular we check for 2-space indents, line lengths, + tab usage, spaces inside code, etc. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + file_extension: The extension (without the dot) of the filename. + nesting_state: A NestingState instance which maintains information about + the current stack of nested blocks being parsed. + error: The function to call with any errors found. + """ + + # Don't use "elided" lines here, otherwise we can't check commented lines. + # Don't want to use "raw" either, because we don't want to check inside C++11 + # raw strings, + raw_lines = clean_lines.lines_without_raw_strings + line = raw_lines[linenum] + prev = raw_lines[linenum - 1] if linenum > 0 else '' + + if line.find('\t') != -1: + error(filename, linenum, 'whitespace/tab', 1, + 'Tab found; better to use spaces') + + # One or three blank spaces at the beginning of the line is weird; it's + # hard to reconcile that with 2-space indents. + # NOTE: here are the conditions rob pike used for his tests. Mine aren't + # as sophisticated, but it may be worth becoming so: RLENGTH==initial_spaces + # if(RLENGTH > 20) complain = 0; + # if(match($0, " +(error|private|public|protected):")) complain = 0; + # if(match(prev, "&& *$")) complain = 0; + # if(match(prev, "\\|\\| *$")) complain = 0; + # if(match(prev, "[\",=><] *$")) complain = 0; + # if(match($0, " <<")) complain = 0; + # if(match(prev, " +for \\(")) complain = 0; + # if(prevodd && match(prevprev, " +for \\(")) complain = 0; + scope_or_label_pattern = r'\s*\w+\s*:\s*\\?$' + classinfo = nesting_state.InnermostClass() + initial_spaces = 0 + cleansed_line = clean_lines.elided[linenum] + while initial_spaces < len(line) and line[initial_spaces] == ' ': + initial_spaces += 1 + # There are certain situations we allow one space, notably for + # section labels, and also lines containing multi-line raw strings. + # We also don't check for lines that look like continuation lines + # (of lines ending in double quotes, commas, equals, or angle brackets) + # because the rules for how to indent those are non-trivial. + if (not Search(r'[",=><] *$', prev) and + (initial_spaces == 1 or initial_spaces == 3) and + not Match(scope_or_label_pattern, cleansed_line) and + not (clean_lines.raw_lines[linenum] != line and + Match(r'^\s*""', line))): + error(filename, linenum, 'whitespace/indent', 3, + 'Weird number of spaces at line-start. ' + 'Are you using a 2-space indent?') + + if line and line[-1].isspace(): + error(filename, linenum, 'whitespace/end_of_line', 4, + 'Line ends in whitespace. Consider deleting these extra spaces.') + + # Check if the line is a header guard. + is_header_guard = False + if file_extension in GetHeaderExtensions(): + cppvar = GetHeaderGuardCPPVariable(filename) + if (line.startswith('#ifndef %s' % cppvar) or + line.startswith('#define %s' % cppvar) or + line.startswith('#endif // %s' % cppvar)): + is_header_guard = True + # #include lines and header guards can be long, since there's no clean way to + # split them. + # + # URLs can be long too. It's possible to split these, but it makes them + # harder to cut&paste. + # + # The "$Id:...$" comment may also get very long without it being the + # developers fault. + # + # Doxygen documentation copying can get pretty long when using an overloaded + # function declaration + if (not line.startswith('#include') and not is_header_guard and + not Match(r'^\s*//.*http(s?)://\S*$', line) and + not Match(r'^\s*//\s*[^\s]*$', line) and + not Match(r'^// \$Id:.*#[0-9]+ \$$', line) and + not Match(r'^\s*/// [@\\](copydoc|copydetails|copybrief) .*$', line)): + line_width = GetLineWidth(line) + if line_width > _line_length: + error(filename, linenum, 'whitespace/line_length', 2, + 'Lines should be <= %i characters long' % _line_length) + + if (cleansed_line.count(';') > 1 and + # allow simple single line lambdas + not Match(r'^[^{};]*\[[^\[\]]*\][^{}]*\{[^{}\n\r]*\}', + line) and + # for loops are allowed two ;'s (and may run over two lines). + cleansed_line.find('for') == -1 and + (GetPreviousNonBlankLine(clean_lines, linenum)[0].find('for') == -1 or + GetPreviousNonBlankLine(clean_lines, linenum)[0].find(';') != -1) and + # It's ok to have many commands in a switch case that fits in 1 line + not ((cleansed_line.find('case ') != -1 or + cleansed_line.find('default:') != -1) and + cleansed_line.find('break;') != -1)): + error(filename, linenum, 'whitespace/newline', 0, + 'More than one command on the same line') + + # Some more style checks + CheckBraces(filename, clean_lines, linenum, error) + CheckTrailingSemicolon(filename, clean_lines, linenum, error) + CheckEmptyBlockBody(filename, clean_lines, linenum, error) + CheckAccess(filename, clean_lines, linenum, nesting_state, error) + CheckSpacing(filename, clean_lines, linenum, nesting_state, error) + CheckOperatorSpacing(filename, clean_lines, linenum, error) + CheckParenthesisSpacing(filename, clean_lines, linenum, error) + CheckCommaSpacing(filename, clean_lines, linenum, error) + CheckBracesSpacing(filename, clean_lines, linenum, nesting_state, error) + CheckSpacingForFunctionCall(filename, clean_lines, linenum, error) + CheckCheck(filename, clean_lines, linenum, error) + CheckAltTokens(filename, clean_lines, linenum, error) + classinfo = nesting_state.InnermostClass() + if classinfo: + CheckSectionSpacing(filename, clean_lines, classinfo, linenum, error) + + +_RE_PATTERN_INCLUDE = re.compile(r'^\s*#\s*include\s*([<"])([^>"]*)[>"].*$') +# Matches the first component of a filename delimited by -s and _s. That is: +# _RE_FIRST_COMPONENT.match('foo').group(0) == 'foo' +# _RE_FIRST_COMPONENT.match('foo.cc').group(0) == 'foo' +# _RE_FIRST_COMPONENT.match('foo-bar_baz.cc').group(0) == 'foo' +# _RE_FIRST_COMPONENT.match('foo_bar-baz.cc').group(0) == 'foo' +_RE_FIRST_COMPONENT = re.compile(r'^[^-_.]+') + + +def _DropCommonSuffixes(filename): + """Drops common suffixes like _test.cc or -inl.h from filename. + + For example: + >>> _DropCommonSuffixes('foo/foo-inl.h') + 'foo/foo' + >>> _DropCommonSuffixes('foo/bar/foo.cc') + 'foo/bar/foo' + >>> _DropCommonSuffixes('foo/foo_internal.h') + 'foo/foo' + >>> _DropCommonSuffixes('foo/foo_unusualinternal.h') + 'foo/foo_unusualinternal' + + Args: + filename: The input filename. + + Returns: + The filename with the common suffix removed. + """ + for suffix in itertools.chain( + ('%s.%s' % (test_suffix.lstrip('_'), ext) + for test_suffix, ext in itertools.product(_test_suffixes, GetNonHeaderExtensions())), + ('%s.%s' % (suffix, ext) + for suffix, ext in itertools.product(['inl', 'imp', 'internal'], GetHeaderExtensions()))): + if (filename.endswith(suffix) and len(filename) > len(suffix) and + filename[-len(suffix) - 1] in ('-', '_')): + return filename[:-len(suffix) - 1] + return os.path.splitext(filename)[0] + + +def _ClassifyInclude(fileinfo, include, is_system): + """Figures out what kind of header 'include' is. + + Args: + fileinfo: The current file cpplint is running over. A FileInfo instance. + include: The path to a #included file. + is_system: True if the #include used <> rather than "". + + Returns: + One of the _XXX_HEADER constants. + + For example: + >>> _ClassifyInclude(FileInfo('foo/foo.cc'), 'stdio.h', True) + _C_SYS_HEADER + >>> _ClassifyInclude(FileInfo('foo/foo.cc'), 'string', True) + _CPP_SYS_HEADER + >>> _ClassifyInclude(FileInfo('foo/foo.cc'), 'foo/foo.h', False) + _LIKELY_MY_HEADER + >>> _ClassifyInclude(FileInfo('foo/foo_unknown_extension.cc'), + ... 'bar/foo_other_ext.h', False) + _POSSIBLE_MY_HEADER + >>> _ClassifyInclude(FileInfo('foo/foo.cc'), 'foo/bar.h', False) + _OTHER_HEADER + """ + # This is a list of all standard c++ header files, except + # those already checked for above. + is_cpp_h = include in _CPP_HEADERS + + # Headers with C++ extensions shouldn't be considered C system headers + if is_system and os.path.splitext(include)[1] in ['.hpp', '.hxx', '.h++']: + is_system = False + + if is_system: + if is_cpp_h: + return _CPP_SYS_HEADER + else: + return _C_SYS_HEADER + + # If the target file and the include we're checking share a + # basename when we drop common extensions, and the include + # lives in . , then it's likely to be owned by the target file. + target_dir, target_base = ( + os.path.split(_DropCommonSuffixes(fileinfo.RepositoryName()))) + include_dir, include_base = os.path.split(_DropCommonSuffixes(include)) + target_dir_pub = os.path.normpath(target_dir + '/../public') + target_dir_pub = target_dir_pub.replace('\\', '/') + if target_base == include_base and ( + include_dir == target_dir or + include_dir == target_dir_pub): + return _LIKELY_MY_HEADER + + # If the target and include share some initial basename + # component, it's possible the target is implementing the + # include, so it's allowed to be first, but we'll never + # complain if it's not there. + target_first_component = _RE_FIRST_COMPONENT.match(target_base) + include_first_component = _RE_FIRST_COMPONENT.match(include_base) + if (target_first_component and include_first_component and + target_first_component.group(0) == + include_first_component.group(0)): + return _POSSIBLE_MY_HEADER + + return _OTHER_HEADER + + + +def CheckIncludeLine(filename, clean_lines, linenum, include_state, error): + """Check rules that are applicable to #include lines. + + Strings on #include lines are NOT removed from elided line, to make + certain tasks easier. However, to prevent false positives, checks + applicable to #include lines in CheckLanguage must be put here. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + include_state: An _IncludeState instance in which the headers are inserted. + error: The function to call with any errors found. + """ + fileinfo = FileInfo(filename) + line = clean_lines.lines[linenum] + + # "include" should use the new style "foo/bar.h" instead of just "bar.h" + # Only do this check if the included header follows google naming + # conventions. If not, assume that it's a 3rd party API that + # requires special include conventions. + # + # We also make an exception for Lua headers, which follow google + # naming convention but not the include convention. + match = Match(r'#include\s*"([^/]+\.h)"', line) + if match and not _THIRD_PARTY_HEADERS_PATTERN.match(match.group(1)): + error(filename, linenum, 'build/include_subdir', 4, + 'Include the directory when naming .h files') + + # we shouldn't include a file more than once. actually, there are a + # handful of instances where doing so is okay, but in general it's + # not. + match = _RE_PATTERN_INCLUDE.search(line) + if match: + include = match.group(2) + is_system = (match.group(1) == '<') + duplicate_line = include_state.FindHeader(include) + if duplicate_line >= 0: + error(filename, linenum, 'build/include', 4, + '"%s" already included at %s:%s' % + (include, filename, duplicate_line)) + return + + for extension in GetNonHeaderExtensions(): + if (include.endswith('.' + extension) and + os.path.dirname(fileinfo.RepositoryName()) != os.path.dirname(include)): + error(filename, linenum, 'build/include', 4, + 'Do not include .' + extension + ' files from other packages') + return + + if not _THIRD_PARTY_HEADERS_PATTERN.match(include): + include_state.include_list[-1].append((include, linenum)) + + # We want to ensure that headers appear in the right order: + # 1) for foo.cc, foo.h (preferred location) + # 2) c system files + # 3) cpp system files + # 4) for foo.cc, foo.h (deprecated location) + # 5) other google headers + # + # We classify each include statement as one of those 5 types + # using a number of techniques. The include_state object keeps + # track of the highest type seen, and complains if we see a + # lower type after that. + error_message = include_state.CheckNextIncludeOrder( + _ClassifyInclude(fileinfo, include, is_system)) + if error_message: + error(filename, linenum, 'build/include_order', 4, + '%s. Should be: %s.h, c system, c++ system, other.' % + (error_message, fileinfo.BaseName())) + canonical_include = include_state.CanonicalizeAlphabeticalOrder(include) + if not include_state.IsInAlphabeticalOrder( + clean_lines, linenum, canonical_include): + error(filename, linenum, 'build/include_alpha', 4, + 'Include "%s" not in alphabetical order' % include) + include_state.SetLastHeader(canonical_include) + + + +def _GetTextInside(text, start_pattern): + r"""Retrieves all the text between matching open and close parentheses. + + Given a string of lines and a regular expression string, retrieve all the text + following the expression and between opening punctuation symbols like + (, [, or {, and the matching close-punctuation symbol. This properly nested + occurrences of the punctuations, so for the text like + printf(a(), b(c())); + a call to _GetTextInside(text, r'printf\(') will return 'a(), b(c())'. + start_pattern must match string having an open punctuation symbol at the end. + + Args: + text: The lines to extract text. Its comments and strings must be elided. + It can be single line and can span multiple lines. + start_pattern: The regexp string indicating where to start extracting + the text. + Returns: + The extracted text. + None if either the opening string or ending punctuation could not be found. + """ + # TODO(unknown): Audit cpplint.py to see what places could be profitably + # rewritten to use _GetTextInside (and use inferior regexp matching today). + + # Give opening punctuations to get the matching close-punctuations. + matching_punctuation = {'(': ')', '{': '}', '[': ']'} + closing_punctuation = set(itervalues(matching_punctuation)) + + # Find the position to start extracting text. + match = re.search(start_pattern, text, re.M) + if not match: # start_pattern not found in text. + return None + start_position = match.end(0) + + assert start_position > 0, ( + 'start_pattern must ends with an opening punctuation.') + assert text[start_position - 1] in matching_punctuation, ( + 'start_pattern must ends with an opening punctuation.') + # Stack of closing punctuations we expect to have in text after position. + punctuation_stack = [matching_punctuation[text[start_position - 1]]] + position = start_position + while punctuation_stack and position < len(text): + if text[position] == punctuation_stack[-1]: + punctuation_stack.pop() + elif text[position] in closing_punctuation: + # A closing punctuation without matching opening punctuations. + return None + elif text[position] in matching_punctuation: + punctuation_stack.append(matching_punctuation[text[position]]) + position += 1 + if punctuation_stack: + # Opening punctuations left without matching close-punctuations. + return None + # punctuations match. + return text[start_position:position - 1] + + +# Patterns for matching call-by-reference parameters. +# +# Supports nested templates up to 2 levels deep using this messy pattern: +# < (?: < (?: < [^<>]* +# > +# | [^<>] )* +# > +# | [^<>] )* +# > +_RE_PATTERN_IDENT = r'[_a-zA-Z]\w*' # =~ [[:alpha:]][[:alnum:]]* +_RE_PATTERN_TYPE = ( + r'(?:const\s+)?(?:typename\s+|class\s+|struct\s+|union\s+|enum\s+)?' + r'(?:\w|' + r'\s*<(?:<(?:<[^<>]*>|[^<>])*>|[^<>])*>|' + r'::)+') +# A call-by-reference parameter ends with '& identifier'. +_RE_PATTERN_REF_PARAM = re.compile( + r'(' + _RE_PATTERN_TYPE + r'(?:\s*(?:\bconst\b|[*]))*\s*' + r'&\s*' + _RE_PATTERN_IDENT + r')\s*(?:=[^,()]+)?[,)]') +# A call-by-const-reference parameter either ends with 'const& identifier' +# or looks like 'const type& identifier' when 'type' is atomic. +_RE_PATTERN_CONST_REF_PARAM = ( + r'(?:.*\s*\bconst\s*&\s*' + _RE_PATTERN_IDENT + + r'|const\s+' + _RE_PATTERN_TYPE + r'\s*&\s*' + _RE_PATTERN_IDENT + r')') +# Stream types. +_RE_PATTERN_REF_STREAM_PARAM = ( + r'(?:.*stream\s*&\s*' + _RE_PATTERN_IDENT + r')') + + +def CheckLanguage(filename, clean_lines, linenum, file_extension, + include_state, nesting_state, error): + """Checks rules from the 'C++ language rules' section of cppguide.html. + + Some of these rules are hard to test (function overloading, using + uint32 inappropriately), but we do the best we can. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + file_extension: The extension (without the dot) of the filename. + include_state: An _IncludeState instance in which the headers are inserted. + nesting_state: A NestingState instance which maintains information about + the current stack of nested blocks being parsed. + error: The function to call with any errors found. + """ + # If the line is empty or consists of entirely a comment, no need to + # check it. + line = clean_lines.elided[linenum] + if not line: + return + + match = _RE_PATTERN_INCLUDE.search(line) + if match: + CheckIncludeLine(filename, clean_lines, linenum, include_state, error) + return + + # Reset include state across preprocessor directives. This is meant + # to silence warnings for conditional includes. + match = Match(r'^\s*#\s*(if|ifdef|ifndef|elif|else|endif)\b', line) + if match: + include_state.ResetSection(match.group(1)) + + + # Perform other checks now that we are sure that this is not an include line + CheckCasts(filename, clean_lines, linenum, error) + CheckGlobalStatic(filename, clean_lines, linenum, error) + CheckPrintf(filename, clean_lines, linenum, error) + + if file_extension in GetHeaderExtensions(): + # TODO(unknown): check that 1-arg constructors are explicit. + # How to tell it's a constructor? + # (handled in CheckForNonStandardConstructs for now) + # TODO(unknown): check that classes declare or disable copy/assign + # (level 1 error) + pass + + # Check if people are using the verboten C basic types. The only exception + # we regularly allow is "unsigned short port" for port. + if Search(r'\bshort port\b', line): + if not Search(r'\bunsigned short port\b', line): + error(filename, linenum, 'runtime/int', 4, + 'Use "unsigned short" for ports, not "short"') + else: + match = Search(r'\b(short|long(?! +double)|long long)\b', line) + if match: + error(filename, linenum, 'runtime/int', 4, + 'Use int16/int64/etc, rather than the C type %s' % match.group(1)) + + # Check if some verboten operator overloading is going on + # TODO(unknown): catch out-of-line unary operator&: + # class X {}; + # int operator&(const X& x) { return 42; } // unary operator& + # The trick is it's hard to tell apart from binary operator&: + # class Y { int operator&(const Y& x) { return 23; } }; // binary operator& + if Search(r'\boperator\s*&\s*\(\s*\)', line): + error(filename, linenum, 'runtime/operator', 4, + 'Unary operator& is dangerous. Do not use it.') + + # Check for suspicious usage of "if" like + # } if (a == b) { + if Search(r'\}\s*if\s*\(', line): + error(filename, linenum, 'readability/braces', 4, + 'Did you mean "else if"? If not, start a new line for "if".') + + # Check for potential format string bugs like printf(foo). + # We constrain the pattern not to pick things like DocidForPrintf(foo). + # Not perfect but it can catch printf(foo.c_str()) and printf(foo->c_str()) + # TODO(unknown): Catch the following case. Need to change the calling + # convention of the whole function to process multiple line to handle it. + # printf( + # boy_this_is_a_really_long_variable_that_cannot_fit_on_the_prev_line); + printf_args = _GetTextInside(line, r'(?i)\b(string)?printf\s*\(') + if printf_args: + match = Match(r'([\w.\->()]+)$', printf_args) + if match and match.group(1) != '__VA_ARGS__': + function_name = re.search(r'\b((?:string)?printf)\s*\(', + line, re.I).group(1) + error(filename, linenum, 'runtime/printf', 4, + 'Potential format string bug. Do %s("%%s", %s) instead.' + % (function_name, match.group(1))) + + # Check for potential memset bugs like memset(buf, sizeof(buf), 0). + match = Search(r'memset\s*\(([^,]*),\s*([^,]*),\s*0\s*\)', line) + if match and not Match(r"^''|-?[0-9]+|0x[0-9A-Fa-f]$", match.group(2)): + error(filename, linenum, 'runtime/memset', 4, + 'Did you mean "memset(%s, 0, %s)"?' + % (match.group(1), match.group(2))) + + if Search(r'\busing namespace\b', line): + if Search(r'\bliterals\b', line): + error(filename, linenum, 'build/namespaces_literals', 5, + 'Do not use namespace using-directives. ' + 'Use using-declarations instead.') + else: + error(filename, linenum, 'build/namespaces', 5, + 'Do not use namespace using-directives. ' + 'Use using-declarations instead.') + + # Detect variable-length arrays. + match = Match(r'\s*(.+::)?(\w+) [a-z]\w*\[(.+)];', line) + if (match and match.group(2) != 'return' and match.group(2) != 'delete' and + match.group(3).find(']') == -1): + # Split the size using space and arithmetic operators as delimiters. + # If any of the resulting tokens are not compile time constants then + # report the error. + tokens = re.split(r'\s|\+|\-|\*|\/|<<|>>]', match.group(3)) + is_const = True + skip_next = False + for tok in tokens: + if skip_next: + skip_next = False + continue + + if Search(r'sizeof\(.+\)', tok): continue + if Search(r'arraysize\(\w+\)', tok): continue + + tok = tok.lstrip('(') + tok = tok.rstrip(')') + if not tok: continue + if Match(r'\d+', tok): continue + if Match(r'0[xX][0-9a-fA-F]+', tok): continue + if Match(r'k[A-Z0-9]\w*', tok): continue + if Match(r'(.+::)?k[A-Z0-9]\w*', tok): continue + if Match(r'(.+::)?[A-Z][A-Z0-9_]*', tok): continue + # A catch all for tricky sizeof cases, including 'sizeof expression', + # 'sizeof(*type)', 'sizeof(const type)', 'sizeof(struct StructName)' + # requires skipping the next token because we split on ' ' and '*'. + if tok.startswith('sizeof'): + skip_next = True + continue + is_const = False + break + if not is_const: + error(filename, linenum, 'runtime/arrays', 1, + 'Do not use variable-length arrays. Use an appropriately named ' + "('k' followed by CamelCase) compile-time constant for the size.") + + # Check for use of unnamed namespaces in header files. Registration + # macros are typically OK, so we allow use of "namespace {" on lines + # that end with backslashes. + if (file_extension in GetHeaderExtensions() + and Search(r'\bnamespace\s*{', line) + and line[-1] != '\\'): + error(filename, linenum, 'build/namespaces', 4, + 'Do not use unnamed namespaces in header files. See ' + 'https://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Namespaces' + ' for more information.') + + +def CheckGlobalStatic(filename, clean_lines, linenum, error): + """Check for unsafe global or static objects. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + # Match two lines at a time to support multiline declarations + if linenum + 1 < clean_lines.NumLines() and not Search(r'[;({]', line): + line += clean_lines.elided[linenum + 1].strip() + + # Check for people declaring static/global STL strings at the top level. + # This is dangerous because the C++ language does not guarantee that + # globals with constructors are initialized before the first access, and + # also because globals can be destroyed when some threads are still running. + # TODO(unknown): Generalize this to also find static unique_ptr instances. + # TODO(unknown): File bugs for clang-tidy to find these. + match = Match( + r'((?:|static +)(?:|const +))(?::*std::)?string( +const)? +' + r'([a-zA-Z0-9_:]+)\b(.*)', + line) + + # Remove false positives: + # - String pointers (as opposed to values). + # string *pointer + # const string *pointer + # string const *pointer + # string *const pointer + # + # - Functions and template specializations. + # string Function(... + # string Class::Method(... + # + # - Operators. These are matched separately because operator names + # cross non-word boundaries, and trying to match both operators + # and functions at the same time would decrease accuracy of + # matching identifiers. + # string Class::operator*() + if (match and + not Search(r'\bstring\b(\s+const)?\s*[\*\&]\s*(const\s+)?\w', line) and + not Search(r'\boperator\W', line) and + not Match(r'\s*(<.*>)?(::[a-zA-Z0-9_]+)*\s*\(([^"]|$)', match.group(4))): + if Search(r'\bconst\b', line): + error(filename, linenum, 'runtime/string', 4, + 'For a static/global string constant, use a C style string ' + 'instead: "%schar%s %s[]".' % + (match.group(1), match.group(2) or '', match.group(3))) + else: + error(filename, linenum, 'runtime/string', 4, + 'Static/global string variables are not permitted.') + + if (Search(r'\b([A-Za-z0-9_]*_)\(\1\)', line) or + Search(r'\b([A-Za-z0-9_]*_)\(CHECK_NOTNULL\(\1\)\)', line)): + error(filename, linenum, 'runtime/init', 4, + 'You seem to be initializing a member variable with itself.') + + +def CheckPrintf(filename, clean_lines, linenum, error): + """Check for printf related issues. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + # When snprintf is used, the second argument shouldn't be a literal. + match = Search(r'snprintf\s*\(([^,]*),\s*([0-9]*)\s*,', line) + if match and match.group(2) != '0': + # If 2nd arg is zero, snprintf is used to calculate size. + error(filename, linenum, 'runtime/printf', 3, + 'If you can, use sizeof(%s) instead of %s as the 2nd arg ' + 'to snprintf.' % (match.group(1), match.group(2))) + + # Check if some verboten C functions are being used. + if Search(r'\bsprintf\s*\(', line): + error(filename, linenum, 'runtime/printf', 5, + 'Never use sprintf. Use snprintf instead.') + match = Search(r'\b(strcpy|strcat)\s*\(', line) + if match: + error(filename, linenum, 'runtime/printf', 4, + 'Almost always, snprintf is better than %s' % match.group(1)) + + +def IsDerivedFunction(clean_lines, linenum): + """Check if current line contains an inherited function. + + Args: + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + Returns: + True if current line contains a function with "override" + virt-specifier. + """ + # Scan back a few lines for start of current function + for i in xrange(linenum, max(-1, linenum - 10), -1): + match = Match(r'^([^()]*\w+)\(', clean_lines.elided[i]) + if match: + # Look for "override" after the matching closing parenthesis + line, _, closing_paren = CloseExpression( + clean_lines, i, len(match.group(1))) + return (closing_paren >= 0 and + Search(r'\boverride\b', line[closing_paren:])) + return False + + +def IsOutOfLineMethodDefinition(clean_lines, linenum): + """Check if current line contains an out-of-line method definition. + + Args: + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + Returns: + True if current line contains an out-of-line method definition. + """ + # Scan back a few lines for start of current function + for i in xrange(linenum, max(-1, linenum - 10), -1): + if Match(r'^([^()]*\w+)\(', clean_lines.elided[i]): + return Match(r'^[^()]*\w+::\w+\(', clean_lines.elided[i]) is not None + return False + + +def IsInitializerList(clean_lines, linenum): + """Check if current line is inside constructor initializer list. + + Args: + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + Returns: + True if current line appears to be inside constructor initializer + list, False otherwise. + """ + for i in xrange(linenum, 1, -1): + line = clean_lines.elided[i] + if i == linenum: + remove_function_body = Match(r'^(.*)\{\s*$', line) + if remove_function_body: + line = remove_function_body.group(1) + + if Search(r'\s:\s*\w+[({]', line): + # A lone colon tend to indicate the start of a constructor + # initializer list. It could also be a ternary operator, which + # also tend to appear in constructor initializer lists as + # opposed to parameter lists. + return True + if Search(r'\}\s*,\s*$', line): + # A closing brace followed by a comma is probably the end of a + # brace-initialized member in constructor initializer list. + return True + if Search(r'[{};]\s*$', line): + # Found one of the following: + # - A closing brace or semicolon, probably the end of the previous + # function. + # - An opening brace, probably the start of current class or namespace. + # + # Current line is probably not inside an initializer list since + # we saw one of those things without seeing the starting colon. + return False + + # Got to the beginning of the file without seeing the start of + # constructor initializer list. + return False + + +def CheckForNonConstReference(filename, clean_lines, linenum, + nesting_state, error): + """Check for non-const references. + + Separate from CheckLanguage since it scans backwards from current + line, instead of scanning forward. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + nesting_state: A NestingState instance which maintains information about + the current stack of nested blocks being parsed. + error: The function to call with any errors found. + """ + # Do nothing if there is no '&' on current line. + line = clean_lines.elided[linenum] + if '&' not in line: + return + + # If a function is inherited, current function doesn't have much of + # a choice, so any non-const references should not be blamed on + # derived function. + if IsDerivedFunction(clean_lines, linenum): + return + + # Don't warn on out-of-line method definitions, as we would warn on the + # in-line declaration, if it isn't marked with 'override'. + if IsOutOfLineMethodDefinition(clean_lines, linenum): + return + + # Long type names may be broken across multiple lines, usually in one + # of these forms: + # LongType + # ::LongTypeContinued &identifier + # LongType:: + # LongTypeContinued &identifier + # LongType< + # ...>::LongTypeContinued &identifier + # + # If we detected a type split across two lines, join the previous + # line to current line so that we can match const references + # accordingly. + # + # Note that this only scans back one line, since scanning back + # arbitrary number of lines would be expensive. If you have a type + # that spans more than 2 lines, please use a typedef. + if linenum > 1: + previous = None + if Match(r'\s*::(?:[\w<>]|::)+\s*&\s*\S', line): + # previous_line\n + ::current_line + previous = Search(r'\b((?:const\s*)?(?:[\w<>]|::)+[\w<>])\s*$', + clean_lines.elided[linenum - 1]) + elif Match(r'\s*[a-zA-Z_]([\w<>]|::)+\s*&\s*\S', line): + # previous_line::\n + current_line + previous = Search(r'\b((?:const\s*)?(?:[\w<>]|::)+::)\s*$', + clean_lines.elided[linenum - 1]) + if previous: + line = previous.group(1) + line.lstrip() + else: + # Check for templated parameter that is split across multiple lines + endpos = line.rfind('>') + if endpos > -1: + (_, startline, startpos) = ReverseCloseExpression( + clean_lines, linenum, endpos) + if startpos > -1 and startline < linenum: + # Found the matching < on an earlier line, collect all + # pieces up to current line. + line = '' + for i in xrange(startline, linenum + 1): + line += clean_lines.elided[i].strip() + + # Check for non-const references in function parameters. A single '&' may + # found in the following places: + # inside expression: binary & for bitwise AND + # inside expression: unary & for taking the address of something + # inside declarators: reference parameter + # We will exclude the first two cases by checking that we are not inside a + # function body, including one that was just introduced by a trailing '{'. + # TODO(unknown): Doesn't account for 'catch(Exception& e)' [rare]. + if (nesting_state.previous_stack_top and + not (isinstance(nesting_state.previous_stack_top, _ClassInfo) or + isinstance(nesting_state.previous_stack_top, _NamespaceInfo))): + # Not at toplevel, not within a class, and not within a namespace + return + + # Avoid initializer lists. We only need to scan back from the + # current line for something that starts with ':'. + # + # We don't need to check the current line, since the '&' would + # appear inside the second set of parentheses on the current line as + # opposed to the first set. + if linenum > 0: + for i in xrange(linenum - 1, max(0, linenum - 10), -1): + previous_line = clean_lines.elided[i] + if not Search(r'[),]\s*$', previous_line): + break + if Match(r'^\s*:\s+\S', previous_line): + return + + # Avoid preprocessors + if Search(r'\\\s*$', line): + return + + # Avoid constructor initializer lists + if IsInitializerList(clean_lines, linenum): + return + + # We allow non-const references in a few standard places, like functions + # called "swap()" or iostream operators like "<<" or ">>". Do not check + # those function parameters. + # + # We also accept & in static_assert, which looks like a function but + # it's actually a declaration expression. + whitelisted_functions = (r'(?:[sS]wap(?:<\w:+>)?|' + r'operator\s*[<>][<>]|' + r'static_assert|COMPILE_ASSERT' + r')\s*\(') + if Search(whitelisted_functions, line): + return + elif not Search(r'\S+\([^)]*$', line): + # Don't see a whitelisted function on this line. Actually we + # didn't see any function name on this line, so this is likely a + # multi-line parameter list. Try a bit harder to catch this case. + for i in xrange(2): + if (linenum > i and + Search(whitelisted_functions, clean_lines.elided[linenum - i - 1])): + return + + decls = ReplaceAll(r'{[^}]*}', ' ', line) # exclude function body + for parameter in re.findall(_RE_PATTERN_REF_PARAM, decls): + if (not Match(_RE_PATTERN_CONST_REF_PARAM, parameter) and + not Match(_RE_PATTERN_REF_STREAM_PARAM, parameter)): + error(filename, linenum, 'runtime/references', 2, + 'Is this a non-const reference? ' + 'If so, make const or use a pointer: ' + + ReplaceAll(' *<', '<', parameter)) + + +def CheckCasts(filename, clean_lines, linenum, error): + """Various cast related checks. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + # Check to see if they're using an conversion function cast. + # I just try to capture the most common basic types, though there are more. + # Parameterless conversion functions, such as bool(), are allowed as they are + # probably a member operator declaration or default constructor. + match = Search( + r'(\bnew\s+(?:const\s+)?|\S<\s*(?:const\s+)?)?\b' + r'(int|float|double|bool|char|int32|uint32|int64|uint64)' + r'(\([^)].*)', line) + expecting_function = ExpectingFunctionArgs(clean_lines, linenum) + if match and not expecting_function: + matched_type = match.group(2) + + # matched_new_or_template is used to silence two false positives: + # - New operators + # - Template arguments with function types + # + # For template arguments, we match on types immediately following + # an opening bracket without any spaces. This is a fast way to + # silence the common case where the function type is the first + # template argument. False negative with less-than comparison is + # avoided because those operators are usually followed by a space. + # + # function // bracket + no space = false positive + # value < double(42) // bracket + space = true positive + matched_new_or_template = match.group(1) + + # Avoid arrays by looking for brackets that come after the closing + # parenthesis. + if Match(r'\([^()]+\)\s*\[', match.group(3)): + return + + # Other things to ignore: + # - Function pointers + # - Casts to pointer types + # - Placement new + # - Alias declarations + matched_funcptr = match.group(3) + if (matched_new_or_template is None and + not (matched_funcptr and + (Match(r'\((?:[^() ]+::\s*\*\s*)?[^() ]+\)\s*\(', + matched_funcptr) or + matched_funcptr.startswith('(*)'))) and + not Match(r'\s*using\s+\S+\s*=\s*' + matched_type, line) and + not Search(r'new\(\S+\)\s*' + matched_type, line)): + error(filename, linenum, 'readability/casting', 4, + 'Using deprecated casting style. ' + 'Use static_cast<%s>(...) instead' % + matched_type) + + if not expecting_function: + CheckCStyleCast(filename, clean_lines, linenum, 'static_cast', + r'\((int|float|double|bool|char|u?int(16|32|64))\)', error) + + # This doesn't catch all cases. Consider (const char * const)"hello". + # + # (char *) "foo" should always be a const_cast (reinterpret_cast won't + # compile). + if CheckCStyleCast(filename, clean_lines, linenum, 'const_cast', + r'\((char\s?\*+\s?)\)\s*"', error): + pass + else: + # Check pointer casts for other than string constants + CheckCStyleCast(filename, clean_lines, linenum, 'reinterpret_cast', + r'\((\w+\s?\*+\s?)\)', error) + + # In addition, we look for people taking the address of a cast. This + # is dangerous -- casts can assign to temporaries, so the pointer doesn't + # point where you think. + # + # Some non-identifier character is required before the '&' for the + # expression to be recognized as a cast. These are casts: + # expression = &static_cast(temporary()); + # function(&(int*)(temporary())); + # + # This is not a cast: + # reference_type&(int* function_param); + match = Search( + r'(?:[^\w]&\(([^)*][^)]*)\)[\w(])|' + r'(?:[^\w]&(static|dynamic|down|reinterpret)_cast\b)', line) + if match: + # Try a better error message when the & is bound to something + # dereferenced by the casted pointer, as opposed to the casted + # pointer itself. + parenthesis_error = False + match = Match(r'^(.*&(?:static|dynamic|down|reinterpret)_cast\b)<', line) + if match: + _, y1, x1 = CloseExpression(clean_lines, linenum, len(match.group(1))) + if x1 >= 0 and clean_lines.elided[y1][x1] == '(': + _, y2, x2 = CloseExpression(clean_lines, y1, x1) + if x2 >= 0: + extended_line = clean_lines.elided[y2][x2:] + if y2 < clean_lines.NumLines() - 1: + extended_line += clean_lines.elided[y2 + 1] + if Match(r'\s*(?:->|\[)', extended_line): + parenthesis_error = True + + if parenthesis_error: + error(filename, linenum, 'readability/casting', 4, + ('Are you taking an address of something dereferenced ' + 'from a cast? Wrapping the dereferenced expression in ' + 'parentheses will make the binding more obvious')) + else: + error(filename, linenum, 'runtime/casting', 4, + ('Are you taking an address of a cast? ' + 'This is dangerous: could be a temp var. ' + 'Take the address before doing the cast, rather than after')) + + +def CheckCStyleCast(filename, clean_lines, linenum, cast_type, pattern, error): + """Checks for a C-style cast by looking for the pattern. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + cast_type: The string for the C++ cast to recommend. This is either + reinterpret_cast, static_cast, or const_cast, depending. + pattern: The regular expression used to find C-style casts. + error: The function to call with any errors found. + + Returns: + True if an error was emitted. + False otherwise. + """ + line = clean_lines.elided[linenum] + match = Search(pattern, line) + if not match: + return False + + # Exclude lines with keywords that tend to look like casts + context = line[0:match.start(1) - 1] + if Match(r'.*\b(?:sizeof|alignof|alignas|[_A-Z][_A-Z0-9]*)\s*$', context): + return False + + # Try expanding current context to see if we one level of + # parentheses inside a macro. + if linenum > 0: + for i in xrange(linenum - 1, max(0, linenum - 5), -1): + context = clean_lines.elided[i] + context + if Match(r'.*\b[_A-Z][_A-Z0-9]*\s*\((?:\([^()]*\)|[^()])*$', context): + return False + + # operator++(int) and operator--(int) + if context.endswith(' operator++') or context.endswith(' operator--'): + return False + + # A single unnamed argument for a function tends to look like old style cast. + # If we see those, don't issue warnings for deprecated casts. + remainder = line[match.end(0):] + if Match(r'^\s*(?:;|const\b|throw\b|final\b|override\b|[=>{),]|->)', + remainder): + return False + + # At this point, all that should be left is actual casts. + error(filename, linenum, 'readability/casting', 4, + 'Using C-style cast. Use %s<%s>(...) instead' % + (cast_type, match.group(1))) + + return True + + +def ExpectingFunctionArgs(clean_lines, linenum): + """Checks whether where function type arguments are expected. + + Args: + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + + Returns: + True if the line at 'linenum' is inside something that expects arguments + of function types. + """ + line = clean_lines.elided[linenum] + return (Match(r'^\s*MOCK_(CONST_)?METHOD\d+(_T)?\(', line) or + (linenum >= 2 and + (Match(r'^\s*MOCK_(?:CONST_)?METHOD\d+(?:_T)?\((?:\S+,)?\s*$', + clean_lines.elided[linenum - 1]) or + Match(r'^\s*MOCK_(?:CONST_)?METHOD\d+(?:_T)?\(\s*$', + clean_lines.elided[linenum - 2]) or + Search(r'\bstd::m?function\s*\<\s*$', + clean_lines.elided[linenum - 1])))) + + +_HEADERS_CONTAINING_TEMPLATES = ( + ('', ('deque',)), + ('', ('unary_function', 'binary_function', + 'plus', 'minus', 'multiplies', 'divides', 'modulus', + 'negate', + 'equal_to', 'not_equal_to', 'greater', 'less', + 'greater_equal', 'less_equal', + 'logical_and', 'logical_or', 'logical_not', + 'unary_negate', 'not1', 'binary_negate', 'not2', + 'bind1st', 'bind2nd', + 'pointer_to_unary_function', + 'pointer_to_binary_function', + 'ptr_fun', + 'mem_fun_t', 'mem_fun', 'mem_fun1_t', 'mem_fun1_ref_t', + 'mem_fun_ref_t', + 'const_mem_fun_t', 'const_mem_fun1_t', + 'const_mem_fun_ref_t', 'const_mem_fun1_ref_t', + 'mem_fun_ref', + )), + ('', ('numeric_limits',)), + ('', ('list',)), + ('', ('map', 'multimap',)), + ('', ('allocator', 'make_shared', 'make_unique', 'shared_ptr', + 'unique_ptr', 'weak_ptr')), + ('', ('queue', 'priority_queue',)), + ('', ('set', 'multiset',)), + ('', ('stack',)), + ('', ('char_traits', 'basic_string',)), + ('', ('tuple',)), + ('', ('unordered_map', 'unordered_multimap')), + ('', ('unordered_set', 'unordered_multiset')), + ('', ('pair',)), + ('', ('vector',)), + + # gcc extensions. + # Note: std::hash is their hash, ::hash is our hash + ('', ('hash_map', 'hash_multimap',)), + ('', ('hash_set', 'hash_multiset',)), + ('', ('slist',)), + ) + +_HEADERS_MAYBE_TEMPLATES = ( + ('', ('copy', 'max', 'min', 'min_element', 'sort', + 'transform', + )), + ('', ('forward', 'make_pair', 'move', 'swap')), + ) + +_RE_PATTERN_STRING = re.compile(r'\bstring\b') + +_re_pattern_headers_maybe_templates = [] +for _header, _templates in _HEADERS_MAYBE_TEMPLATES: + for _template in _templates: + # Match max(..., ...), max(..., ...), but not foo->max, foo.max or + # type::max(). + _re_pattern_headers_maybe_templates.append( + (re.compile(r'[^>.]\b' + _template + r'(<.*?>)?\([^\)]'), + _template, + _header)) + +# Other scripts may reach in and modify this pattern. +_re_pattern_templates = [] +for _header, _templates in _HEADERS_CONTAINING_TEMPLATES: + for _template in _templates: + _re_pattern_templates.append( + (re.compile(r'(\<|\b)' + _template + r'\s*\<'), + _template + '<>', + _header)) + + +def FilesBelongToSameModule(filename_cc, filename_h): + """Check if these two filenames belong to the same module. + + The concept of a 'module' here is a as follows: + foo.h, foo-inl.h, foo.cc, foo_test.cc and foo_unittest.cc belong to the + same 'module' if they are in the same directory. + some/path/public/xyzzy and some/path/internal/xyzzy are also considered + to belong to the same module here. + + If the filename_cc contains a longer path than the filename_h, for example, + '/absolute/path/to/base/sysinfo.cc', and this file would include + 'base/sysinfo.h', this function also produces the prefix needed to open the + header. This is used by the caller of this function to more robustly open the + header file. We don't have access to the real include paths in this context, + so we need this guesswork here. + + Known bugs: tools/base/bar.cc and base/bar.h belong to the same module + according to this implementation. Because of this, this function gives + some false positives. This should be sufficiently rare in practice. + + Args: + filename_cc: is the path for the source (e.g. .cc) file + filename_h: is the path for the header path + + Returns: + Tuple with a bool and a string: + bool: True if filename_cc and filename_h belong to the same module. + string: the additional prefix needed to open the header file. + """ + fileinfo_cc = FileInfo(filename_cc) + if not fileinfo_cc.Extension().lstrip('.') in GetNonHeaderExtensions(): + return (False, '') + + fileinfo_h = FileInfo(filename_h) + if not fileinfo_h.Extension().lstrip('.') in GetHeaderExtensions(): + return (False, '') + + filename_cc = filename_cc[:-(len(fileinfo_cc.Extension()))] + matched_test_suffix = Search(_TEST_FILE_SUFFIX, fileinfo_cc.BaseName()) + if matched_test_suffix: + filename_cc = filename_cc[:-len(matched_test_suffix.group(1))] + + filename_cc = filename_cc.replace('/public/', '/') + filename_cc = filename_cc.replace('/internal/', '/') + + filename_h = filename_h[:-(len(fileinfo_h.Extension()))] + if filename_h.endswith('-inl'): + filename_h = filename_h[:-len('-inl')] + filename_h = filename_h.replace('/public/', '/') + filename_h = filename_h.replace('/internal/', '/') + + files_belong_to_same_module = filename_cc.endswith(filename_h) + common_path = '' + if files_belong_to_same_module: + common_path = filename_cc[:-len(filename_h)] + return files_belong_to_same_module, common_path + + +def UpdateIncludeState(filename, include_dict, io=codecs): + """Fill up the include_dict with new includes found from the file. + + Args: + filename: the name of the header to read. + include_dict: a dictionary in which the headers are inserted. + io: The io factory to use to read the file. Provided for testability. + + Returns: + True if a header was successfully added. False otherwise. + """ + headerfile = None + try: + headerfile = io.open(filename, 'r', 'utf8', 'replace') + except IOError: + return False + linenum = 0 + for line in headerfile: + linenum += 1 + clean_line = CleanseComments(line) + match = _RE_PATTERN_INCLUDE.search(clean_line) + if match: + include = match.group(2) + include_dict.setdefault(include, linenum) + return True + + +def CheckForIncludeWhatYouUse(filename, clean_lines, include_state, error, + io=codecs): + """Reports for missing stl includes. + + This function will output warnings to make sure you are including the headers + necessary for the stl containers and functions that you use. We only give one + reason to include a header. For example, if you use both equal_to<> and + less<> in a .h file, only one (the latter in the file) of these will be + reported as a reason to include the . + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + include_state: An _IncludeState instance. + error: The function to call with any errors found. + io: The IO factory to use to read the header file. Provided for unittest + injection. + """ + required = {} # A map of header name to linenumber and the template entity. + # Example of required: { '': (1219, 'less<>') } + + for linenum in range(clean_lines.NumLines()): + line = clean_lines.elided[linenum] + if not line or line[0] == '#': + continue + + # String is special -- it is a non-templatized type in STL. + matched = _RE_PATTERN_STRING.search(line) + if matched: + # Don't warn about strings in non-STL namespaces: + # (We check only the first match per line; good enough.) + prefix = line[:matched.start()] + if prefix.endswith('std::') or not prefix.endswith('::'): + required[''] = (linenum, 'string') + + for pattern, template, header in _re_pattern_headers_maybe_templates: + if pattern.search(line): + required[header] = (linenum, template) + + # The following function is just a speed up, no semantics are changed. + if not '<' in line: # Reduces the cpu time usage by skipping lines. + continue + + for pattern, template, header in _re_pattern_templates: + matched = pattern.search(line) + if matched: + # Don't warn about IWYU in non-STL namespaces: + # (We check only the first match per line; good enough.) + prefix = line[:matched.start()] + if prefix.endswith('std::') or not prefix.endswith('::'): + required[header] = (linenum, template) + + # The policy is that if you #include something in foo.h you don't need to + # include it again in foo.cc. Here, we will look at possible includes. + # Let's flatten the include_state include_list and copy it into a dictionary. + include_dict = dict([item for sublist in include_state.include_list + for item in sublist]) + + # Did we find the header for this file (if any) and successfully load it? + header_found = False + + # Use the absolute path so that matching works properly. + abs_filename = FileInfo(filename).FullName() + + # For Emacs's flymake. + # If cpplint is invoked from Emacs's flymake, a temporary file is generated + # by flymake and that file name might end with '_flymake.cc'. In that case, + # restore original file name here so that the corresponding header file can be + # found. + # e.g. If the file name is 'foo_flymake.cc', we should search for 'foo.h' + # instead of 'foo_flymake.h' + abs_filename = re.sub(r'_flymake\.cc$', '.cc', abs_filename) + + # include_dict is modified during iteration, so we iterate over a copy of + # the keys. + header_keys = list(include_dict.keys()) + for header in header_keys: + (same_module, common_path) = FilesBelongToSameModule(abs_filename, header) + fullpath = common_path + header + if same_module and UpdateIncludeState(fullpath, include_dict, io): + header_found = True + + # If we can't find the header file for a .cc, assume it's because we don't + # know where to look. In that case we'll give up as we're not sure they + # didn't include it in the .h file. + # TODO(unknown): Do a better job of finding .h files so we are confident that + # not having the .h file means there isn't one. + if not header_found: + for extension in GetNonHeaderExtensions(): + if filename.endswith('.' + extension): + return + + # All the lines have been processed, report the errors found. + for required_header_unstripped in sorted(required, key=required.__getitem__): + template = required[required_header_unstripped][1] + if required_header_unstripped.strip('<>"') not in include_dict: + error(filename, required[required_header_unstripped][0], + 'build/include_what_you_use', 4, + 'Add #include ' + required_header_unstripped + ' for ' + template) + + +_RE_PATTERN_EXPLICIT_MAKEPAIR = re.compile(r'\bmake_pair\s*<') + + +def CheckMakePairUsesDeduction(filename, clean_lines, linenum, error): + """Check that make_pair's template arguments are deduced. + + G++ 4.6 in C++11 mode fails badly if make_pair's template arguments are + specified explicitly, and such use isn't intended in any case. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + match = _RE_PATTERN_EXPLICIT_MAKEPAIR.search(line) + if match: + error(filename, linenum, 'build/explicit_make_pair', + 4, # 4 = high confidence + 'For C++11-compatibility, omit template arguments from make_pair' + ' OR use pair directly OR if appropriate, construct a pair directly') + + +def CheckRedundantVirtual(filename, clean_lines, linenum, error): + """Check if line contains a redundant "virtual" function-specifier. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + # Look for "virtual" on current line. + line = clean_lines.elided[linenum] + virtual = Match(r'^(.*)(\bvirtual\b)(.*)$', line) + if not virtual: return + + # Ignore "virtual" keywords that are near access-specifiers. These + # are only used in class base-specifier and do not apply to member + # functions. + if (Search(r'\b(public|protected|private)\s+$', virtual.group(1)) or + Match(r'^\s+(public|protected|private)\b', virtual.group(3))): + return + + # Ignore the "virtual" keyword from virtual base classes. Usually + # there is a column on the same line in these cases (virtual base + # classes are rare in google3 because multiple inheritance is rare). + if Match(r'^.*[^:]:[^:].*$', line): return + + # Look for the next opening parenthesis. This is the start of the + # parameter list (possibly on the next line shortly after virtual). + # TODO(unknown): doesn't work if there are virtual functions with + # decltype() or other things that use parentheses, but csearch suggests + # that this is rare. + end_col = -1 + end_line = -1 + start_col = len(virtual.group(2)) + for start_line in xrange(linenum, min(linenum + 3, clean_lines.NumLines())): + line = clean_lines.elided[start_line][start_col:] + parameter_list = Match(r'^([^(]*)\(', line) + if parameter_list: + # Match parentheses to find the end of the parameter list + (_, end_line, end_col) = CloseExpression( + clean_lines, start_line, start_col + len(parameter_list.group(1))) + break + start_col = 0 + + if end_col < 0: + return # Couldn't find end of parameter list, give up + + # Look for "override" or "final" after the parameter list + # (possibly on the next few lines). + for i in xrange(end_line, min(end_line + 3, clean_lines.NumLines())): + line = clean_lines.elided[i][end_col:] + match = Search(r'\b(override|final)\b', line) + if match: + error(filename, linenum, 'readability/inheritance', 4, + ('"virtual" is redundant since function is ' + 'already declared as "%s"' % match.group(1))) + + # Set end_col to check whole lines after we are done with the + # first line. + end_col = 0 + if Search(r'[^\w]\s*$', line): + break + + +def CheckRedundantOverrideOrFinal(filename, clean_lines, linenum, error): + """Check if line contains a redundant "override" or "final" virt-specifier. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + # Look for closing parenthesis nearby. We need one to confirm where + # the declarator ends and where the virt-specifier starts to avoid + # false positives. + line = clean_lines.elided[linenum] + declarator_end = line.rfind(')') + if declarator_end >= 0: + fragment = line[declarator_end:] + else: + if linenum > 1 and clean_lines.elided[linenum - 1].rfind(')') >= 0: + fragment = line + else: + return + + # Check that at most one of "override" or "final" is present, not both + if Search(r'\boverride\b', fragment) and Search(r'\bfinal\b', fragment): + error(filename, linenum, 'readability/inheritance', 4, + ('"override" is redundant since function is ' + 'already declared as "final"')) + + + + +# Returns true if we are at a new block, and it is directly +# inside of a namespace. +def IsBlockInNameSpace(nesting_state, is_forward_declaration): + """Checks that the new block is directly in a namespace. + + Args: + nesting_state: The _NestingState object that contains info about our state. + is_forward_declaration: If the class is a forward declared class. + Returns: + Whether or not the new block is directly in a namespace. + """ + if is_forward_declaration: + return len(nesting_state.stack) >= 1 and ( + isinstance(nesting_state.stack[-1], _NamespaceInfo)) + + + return (len(nesting_state.stack) > 1 and + nesting_state.stack[-1].check_namespace_indentation and + isinstance(nesting_state.stack[-2], _NamespaceInfo)) + + +def ShouldCheckNamespaceIndentation(nesting_state, is_namespace_indent_item, + raw_lines_no_comments, linenum): + """This method determines if we should apply our namespace indentation check. + + Args: + nesting_state: The current nesting state. + is_namespace_indent_item: If we just put a new class on the stack, True. + If the top of the stack is not a class, or we did not recently + add the class, False. + raw_lines_no_comments: The lines without the comments. + linenum: The current line number we are processing. + + Returns: + True if we should apply our namespace indentation check. Currently, it + only works for classes and namespaces inside of a namespace. + """ + + is_forward_declaration = IsForwardClassDeclaration(raw_lines_no_comments, + linenum) + + if not (is_namespace_indent_item or is_forward_declaration): + return False + + # If we are in a macro, we do not want to check the namespace indentation. + if IsMacroDefinition(raw_lines_no_comments, linenum): + return False + + return IsBlockInNameSpace(nesting_state, is_forward_declaration) + + +# Call this method if the line is directly inside of a namespace. +# If the line above is blank (excluding comments) or the start of +# an inner namespace, it cannot be indented. +def CheckItemIndentationInNamespace(filename, raw_lines_no_comments, linenum, + error): + line = raw_lines_no_comments[linenum] + if Match(r'^\s+', line): + error(filename, linenum, 'runtime/indentation_namespace', 4, + 'Do not indent within a namespace') + + +def ProcessLine(filename, file_extension, clean_lines, line, + include_state, function_state, nesting_state, error, + extra_check_functions=None): + """Processes a single line in the file. + + Args: + filename: Filename of the file that is being processed. + file_extension: The extension (dot not included) of the file. + clean_lines: An array of strings, each representing a line of the file, + with comments stripped. + line: Number of line being processed. + include_state: An _IncludeState instance in which the headers are inserted. + function_state: A _FunctionState instance which counts function lines, etc. + nesting_state: A NestingState instance which maintains information about + the current stack of nested blocks being parsed. + error: A callable to which errors are reported, which takes 4 arguments: + filename, line number, error level, and message + extra_check_functions: An array of additional check functions that will be + run on each source line. Each function takes 4 + arguments: filename, clean_lines, line, error + """ + raw_lines = clean_lines.raw_lines + ParseNolintSuppressions(filename, raw_lines[line], line, error) + nesting_state.Update(filename, clean_lines, line, error) + CheckForNamespaceIndentation(filename, nesting_state, clean_lines, line, + error) + if nesting_state.InAsmBlock(): return + CheckForFunctionLengths(filename, clean_lines, line, function_state, error) + CheckForMultilineCommentsAndStrings(filename, clean_lines, line, error) + CheckStyle(filename, clean_lines, line, file_extension, nesting_state, error) + CheckLanguage(filename, clean_lines, line, file_extension, include_state, + nesting_state, error) + CheckForNonConstReference(filename, clean_lines, line, nesting_state, error) + CheckForNonStandardConstructs(filename, clean_lines, line, + nesting_state, error) + CheckVlogArguments(filename, clean_lines, line, error) + CheckPosixThreading(filename, clean_lines, line, error) + CheckInvalidIncrement(filename, clean_lines, line, error) + CheckMakePairUsesDeduction(filename, clean_lines, line, error) + CheckRedundantVirtual(filename, clean_lines, line, error) + CheckRedundantOverrideOrFinal(filename, clean_lines, line, error) + if extra_check_functions: + for check_fn in extra_check_functions: + check_fn(filename, clean_lines, line, error) + +def FlagCxx11Features(filename, clean_lines, linenum, error): + """Flag those c++11 features that we only allow in certain places. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + include = Match(r'\s*#\s*include\s+[<"]([^<"]+)[">]', line) + + # Flag unapproved C++ TR1 headers. + if include and include.group(1).startswith('tr1/'): + error(filename, linenum, 'build/c++tr1', 5, + ('C++ TR1 headers such as <%s> are unapproved.') % include.group(1)) + + # Flag unapproved C++11 headers. + if include and include.group(1) in ('cfenv', + 'condition_variable', + 'fenv.h', + 'future', + 'mutex', + 'thread', + 'chrono', + 'ratio', + 'regex', + 'system_error', + ): + error(filename, linenum, 'build/c++11', 5, + ('<%s> is an unapproved C++11 header.') % include.group(1)) + + # The only place where we need to worry about C++11 keywords and library + # features in preprocessor directives is in macro definitions. + if Match(r'\s*#', line) and not Match(r'\s*#\s*define\b', line): return + + # These are classes and free functions. The classes are always + # mentioned as std::*, but we only catch the free functions if + # they're not found by ADL. They're alphabetical by header. + for top_name in ( + # type_traits + 'alignment_of', + 'aligned_union', + ): + if Search(r'\bstd::%s\b' % top_name, line): + error(filename, linenum, 'build/c++11', 5, + ('std::%s is an unapproved C++11 class or function. Send c-style ' + 'an example of where it would make your code more readable, and ' + 'they may let you use it.') % top_name) + + +def FlagCxx14Features(filename, clean_lines, linenum, error): + """Flag those C++14 features that we restrict. + + Args: + filename: The name of the current file. + clean_lines: A CleansedLines instance containing the file. + linenum: The number of the line to check. + error: The function to call with any errors found. + """ + line = clean_lines.elided[linenum] + + include = Match(r'\s*#\s*include\s+[<"]([^<"]+)[">]', line) + + # Flag unapproved C++14 headers. + if include and include.group(1) in ('scoped_allocator', 'shared_mutex'): + error(filename, linenum, 'build/c++14', 5, + ('<%s> is an unapproved C++14 header.') % include.group(1)) + + +def ProcessFileData(filename, file_extension, lines, error, + extra_check_functions=None): + """Performs lint checks and reports any errors to the given error function. + + Args: + filename: Filename of the file that is being processed. + file_extension: The extension (dot not included) of the file. + lines: An array of strings, each representing a line of the file, with the + last element being empty if the file is terminated with a newline. + error: A callable to which errors are reported, which takes 4 arguments: + filename, line number, error level, and message + extra_check_functions: An array of additional check functions that will be + run on each source line. Each function takes 4 + arguments: filename, clean_lines, line, error + """ + lines = (['// marker so line numbers and indices both start at 1'] + lines + + ['// marker so line numbers end in a known way']) + + include_state = _IncludeState() + function_state = _FunctionState() + nesting_state = NestingState() + + ResetNolintSuppressions() + + CheckForCopyright(filename, lines, error) + ProcessGlobalSuppresions(lines) + RemoveMultiLineComments(filename, lines, error) + clean_lines = CleansedLines(lines) + + if file_extension in GetHeaderExtensions(): + CheckForHeaderGuard(filename, clean_lines, error) + + for line in range(clean_lines.NumLines()): + ProcessLine(filename, file_extension, clean_lines, line, + include_state, function_state, nesting_state, error, + extra_check_functions) + FlagCxx11Features(filename, clean_lines, line, error) + nesting_state.CheckCompletedBlocks(filename, error) + + CheckForIncludeWhatYouUse(filename, clean_lines, include_state, error) + + # Check that the .cc file has included its header if it exists. + if _IsSourceExtension(file_extension): + CheckHeaderFileIncluded(filename, include_state, error) + + # We check here rather than inside ProcessLine so that we see raw + # lines rather than "cleaned" lines. + CheckForBadCharacters(filename, lines, error) + + CheckForNewlineAtEOF(filename, lines, error) + +def ProcessConfigOverrides(filename): + """ Loads the configuration files and processes the config overrides. + + Args: + filename: The name of the file being processed by the linter. + + Returns: + False if the current |filename| should not be processed further. + """ + + abs_filename = os.path.abspath(filename) + cfg_filters = [] + keep_looking = True + while keep_looking: + abs_path, base_name = os.path.split(abs_filename) + if not base_name: + break # Reached the root directory. + + cfg_file = os.path.join(abs_path, "CPPLINT.cfg") + abs_filename = abs_path + if not os.path.isfile(cfg_file): + continue + + try: + with open(cfg_file) as file_handle: + for line in file_handle: + line, _, _ = line.partition('#') # Remove comments. + if not line.strip(): + continue + + name, _, val = line.partition('=') + name = name.strip() + val = val.strip() + if name == 'set noparent': + keep_looking = False + elif name == 'filter': + cfg_filters.append(val) + elif name == 'exclude_files': + # When matching exclude_files pattern, use the base_name of + # the current file name or the directory name we are processing. + # For example, if we are checking for lint errors in /foo/bar/baz.cc + # and we found the .cfg file at /foo/CPPLINT.cfg, then the config + # file's "exclude_files" filter is meant to be checked against "bar" + # and not "baz" nor "bar/baz.cc". + if base_name: + pattern = re.compile(val) + if pattern.match(base_name): + _cpplint_state.PrintInfo('Ignoring "%s": file excluded by ' + '"%s". File path component "%s" matches pattern "%s"\n' % + (filename, cfg_file, base_name, val)) + return False + elif name == 'linelength': + global _line_length + try: + _line_length = int(val) + except ValueError: + _cpplint_state.PrintError('Line length must be numeric.') + elif name == 'extensions': + global _valid_extensions + try: + extensions = [ext.strip() for ext in val.split(',')] + _valid_extensions = set(extensions) + except ValueError: + sys.stderr.write('Extensions should be a comma-separated list of values;' + 'for example: extensions=hpp,cpp\n' + 'This could not be parsed: "%s"' % (val,)) + elif name == 'headers': + global _header_extensions + try: + extensions = [ext.strip() for ext in val.split(',')] + _header_extensions = set(extensions) + except ValueError: + sys.stderr.write('Extensions should be a comma-separated list of values;' + 'for example: extensions=hpp,cpp\n' + 'This could not be parsed: "%s"' % (val,)) + elif name == 'root': + global _root + _root = val + else: + _cpplint_state.PrintError( + 'Invalid configuration option (%s) in file %s\n' % + (name, cfg_file)) + + except IOError: + _cpplint_state.PrintError( + "Skipping config file '%s': Can't open for reading\n" % cfg_file) + keep_looking = False + + # Apply all the accumulated filters in reverse order (top-level directory + # config options having the least priority). + for cfg_filter in reversed(cfg_filters): + _AddFilters(cfg_filter) + + return True + + +def ProcessFile(filename, vlevel, extra_check_functions=None): + """Does google-lint on a single file. + + Args: + filename: The name of the file to parse. + + vlevel: The level of errors to report. Every error of confidence + >= verbose_level will be reported. 0 is a good default. + + extra_check_functions: An array of additional check functions that will be + run on each source line. Each function takes 4 + arguments: filename, clean_lines, line, error + """ + + _SetVerboseLevel(vlevel) + _BackupFilters() + + if not ProcessConfigOverrides(filename): + _RestoreFilters() + return + + lf_lines = [] + crlf_lines = [] + try: + # Support the UNIX convention of using "-" for stdin. Note that + # we are not opening the file with universal newline support + # (which codecs doesn't support anyway), so the resulting lines do + # contain trailing '\r' characters if we are reading a file that + # has CRLF endings. + # If after the split a trailing '\r' is present, it is removed + # below. + if filename == '-': + lines = codecs.StreamReaderWriter(sys.stdin, + codecs.getreader('utf8'), + codecs.getwriter('utf8'), + 'replace').read().split('\n') + else: + lines = codecs.open(filename, 'r', 'utf8', 'replace').read().split('\n') + + # Remove trailing '\r'. + # The -1 accounts for the extra trailing blank line we get from split() + for linenum in range(len(lines) - 1): + if lines[linenum].endswith('\r'): + lines[linenum] = lines[linenum].rstrip('\r') + crlf_lines.append(linenum + 1) + else: + lf_lines.append(linenum + 1) + + except IOError: + _cpplint_state.PrintError( + "Skipping input '%s': Can't open for reading\n" % filename) + _RestoreFilters() + return + + # Note, if no dot is found, this will give the entire filename as the ext. + file_extension = filename[filename.rfind('.') + 1:] + + # When reading from stdin, the extension is unknown, so no cpplint tests + # should rely on the extension. + if filename != '-' and file_extension not in GetAllExtensions(): + _cpplint_state.PrintError('Ignoring %s; not a valid file name ' + '(%s)\n' % (filename, ', '.join(GetAllExtensions()))) + else: + ProcessFileData(filename, file_extension, lines, Error, + extra_check_functions) + + # If end-of-line sequences are a mix of LF and CR-LF, issue + # warnings on the lines with CR. + # + # Don't issue any warnings if all lines are uniformly LF or CR-LF, + # since critique can handle these just fine, and the style guide + # doesn't dictate a particular end of line sequence. + # + # We can't depend on os.linesep to determine what the desired + # end-of-line sequence should be, since that will return the + # server-side end-of-line sequence. + if lf_lines and crlf_lines: + # Warn on every line with CR. An alternative approach might be to + # check whether the file is mostly CRLF or just LF, and warn on the + # minority, we bias toward LF here since most tools prefer LF. + for linenum in crlf_lines: + Error(filename, linenum, 'whitespace/newline', 1, + 'Unexpected \\r (^M) found; better to use only \\n') + + _cpplint_state.PrintInfo('Done processing %s\n' % filename) + _RestoreFilters() + + +def PrintUsage(message): + """Prints a brief usage string and exits, optionally with an error message. + + Args: + message: The optional error message. + """ + sys.stderr.write(_USAGE) + + if message: + sys.exit('\nFATAL ERROR: ' + message) + else: + sys.exit(0) + + +def PrintCategories(): + """Prints a list of all the error-categories used by error messages. + + These are the categories used to filter messages via --filter. + """ + sys.stderr.write(''.join(' %s\n' % cat for cat in _ERROR_CATEGORIES)) + sys.exit(0) + + +def ParseArguments(args): + """Parses the command line arguments. + + This may set the output format and verbosity level as side-effects. + + Args: + args: The command line arguments: + + Returns: + The list of filenames to lint. + """ + try: + (opts, filenames) = getopt.getopt(args, '', ['help', 'output=', 'verbose=', + 'counting=', + 'filter=', + 'root=', + 'repository=', + 'linelength=', + 'extensions=', + 'exclude=', + 'headers=', + 'quiet', + 'recursive']) + except getopt.GetoptError: + PrintUsage('Invalid arguments.') + + verbosity = _VerboseLevel() + output_format = _OutputFormat() + filters = '' + counting_style = '' + recursive = False + + for (opt, val) in opts: + if opt == '--help': + PrintUsage(None) + elif opt == '--output': + if val not in ('emacs', 'vs7', 'eclipse', 'junit'): + PrintUsage('The only allowed output formats are emacs, vs7, eclipse ' + 'and junit.') + output_format = val + elif opt == '--verbose': + verbosity = int(val) + elif opt == '--filter': + filters = val + if not filters: + PrintCategories() + elif opt == '--counting': + if val not in ('total', 'toplevel', 'detailed'): + PrintUsage('Valid counting options are total, toplevel, and detailed') + counting_style = val + elif opt == '--root': + global _root + _root = val + elif opt == '--repository': + global _repository + _repository = val + elif opt == '--linelength': + global _line_length + try: + _line_length = int(val) + except ValueError: + PrintUsage('Line length must be digits.') + elif opt == '--exclude': + global _excludes + if not _excludes: + _excludes = set() + _excludes.update(glob.glob(val)) + elif opt == '--extensions': + global _valid_extensions + try: + _valid_extensions = set(val.split(',')) + except ValueError: + PrintUsage('Extensions must be comma seperated list.') + elif opt == '--headers': + global _header_extensions + try: + _header_extensions = set(val.split(',')) + except ValueError: + PrintUsage('Extensions must be comma seperated list.') + elif opt == '--recursive': + recursive = True + elif opt == '--quiet': + global _quiet + _quiet = True + + if not filenames: + PrintUsage('No files were specified.') + + if recursive: + filenames = _ExpandDirectories(filenames) + + if _excludes: + filenames = _FilterExcludedFiles(filenames) + + _SetOutputFormat(output_format) + _SetVerboseLevel(verbosity) + _SetFilters(filters) + _SetCountingStyle(counting_style) + + return filenames + +def _ExpandDirectories(filenames): + """Searches a list of filenames and replaces directories in the list with + all files descending from those directories. Files with extensions not in + the valid extensions list are excluded. + + Args: + filenames: A list of files or directories + + Returns: + A list of all files that are members of filenames or descended from a + directory in filenames + """ + expanded = set() + for filename in filenames: + if not os.path.isdir(filename): + expanded.add(filename) + continue + + for root, _, files in os.walk(filename): + for loopfile in files: + fullname = os.path.join(root, loopfile) + if fullname.startswith('.' + os.path.sep): + fullname = fullname[len('.' + os.path.sep):] + expanded.add(fullname) + + filtered = [] + for filename in expanded: + if os.path.splitext(filename)[1][1:] in GetAllExtensions(): + filtered.append(filename) + + return filtered + +def _FilterExcludedFiles(filenames): + """Filters out files listed in the --exclude command line switch. File paths + in the switch are evaluated relative to the current working directory + """ + exclude_paths = [os.path.abspath(f) for f in _excludes] + return [f for f in filenames if os.path.abspath(f) not in exclude_paths] + +def main(): + filenames = ParseArguments(sys.argv[1:]) + backup_err = sys.stderr + try: + # Change stderr to write with replacement characters so we don't die + # if we try to print something containing non-ASCII characters. + sys.stderr = codecs.StreamReader(sys.stderr, 'replace') + + _cpplint_state.ResetErrorCounts() + for filename in filenames: + ProcessFile(filename, _cpplint_state.verbose_level) + _cpplint_state.PrintErrorCounts() + + if _cpplint_state.output_format == 'junit': + sys.stderr.write(_cpplint_state.FormatJUnitXML()) + + finally: + sys.stderr = backup_err + + sys.exit(_cpplint_state.error_count > 0) + + +if __name__ == '__main__': + main() diff --git a/scripts/python/cpplint_wrap.py b/scripts/python/cpplint_wrap.py new file mode 100644 index 000000000..c94a7bb1a --- /dev/null +++ b/scripts/python/cpplint_wrap.py @@ -0,0 +1,37 @@ +## wraps local cpplint to produce verbose output without code harness +import cpplint +import sys + +def main(): + FILTERS=('cpplint --verbose=0 --linelength=100 --filter=-legal/copyright,-build/include_order,' + '-build/c++11,-build/namespaces,-build/class,-build/include,-build/include_subdir,-readability/inheritance,' + '-readability/function,-readability/casting,-readability/namespace,-readability/alt_tokens,' + '-readability/braces,-readability/fn_size,-whitespace/comments,-whitespace/braces,-whitespace/empty_loop_body,' + '-whitespace/indent,-whitespace/newline,-runtime/explicit,-runtime/arrays,-runtime/int,-runtime/references,' + '-runtime/string,-runtime/operator,-runtime/printf').split(' ') + + result = False + files = sys.argv[1:] + for loopfile in files: + newargs = FILTERS + [loopfile] + sys.argv = newargs + + try: + cpplint.main() + except SystemExit as e: + last_result = e.args[0] + result = result or last_result + if (last_result): + write_code_lines(loopfile) + sys.exit(result) + +def write_code_lines(filename): + with open(filename, 'r') as f: + linenum = 1 + for line in f: + if (not '// by md-split' in line): + sys.stdout.write('%3d %s' % (linenum, line)) + linenum += 1 + +if __name__ == '__main__': + main() diff --git a/scripts/python/md-split.py b/scripts/python/md-split.py new file mode 100755 index 000000000..dfa324d1c --- /dev/null +++ b/scripts/python/md-split.py @@ -0,0 +1,207 @@ +#! /usr/bin/env python + +# A script that splits a Markdown file into plain text (for spell checking) and c++ files. + + +from __future__ import absolute_import, print_function, unicode_literals + +import os +import shutil +import io +import argparse + +import re +TAG_REGEX = re.compile(r'(|<[^>]*>)') +NAMED_A_TAG_REGEX = re.compile(r'.*name ?= ?"([^"]*)"') + +def main(): + """ + This script ended up ugly, so in case somebody wants to reimplement, here is the spec that grew by time. + + What it should do it take a markdown file, and split it into more files. A targetfile should have the same + number of lines as the original, with source code snippets and markdown non-words removed, for spell-checking. + + Each code snipped should go into a separate file in codedir. + + Each code snipped should get additional C++ code around it to help compile the line in context, with + some heuristic guessing of what is needed around. The wrapping code should have a token in each line allowing + other tools to filter out these lines + + The name for each file chosen consists os the section id in the markdown document, a counter for the snippet inside the section. + + Snippets without code (only comments) or containing lines starting with ??? should not yeld files, + but the counter for naming snippets should still increment. + """ + parser = argparse.ArgumentParser(description='Split md file into plain text and code blocks') + parser.add_argument('sourcefile', + help='which file to read') + parser.add_argument('targetfile', + help='where to put plain text') + parser.add_argument('codedir', + help='where to put codeblocks') + args = parser.parse_args() + + # ensure folder exists + if not os.path.exists(args.codedir): + os.makedirs(args.codedir) + + + if os.path.exists(args.targetfile): + os.remove(args.targetfile) + + code_block_index = 0 + last_header = '' + linenum = 0 + with io.open(args.sourcefile, 'r') as read_filehandle: + with io.open(args.targetfile, 'w') as text_filehandle: + for line in read_filehandle: + linenum += 1 + indent_depth = is_code(line) + if indent_depth: + (line, linenum) = process_code(read_filehandle, + text_filehandle, + line, linenum, + args.sourcefile, args.codedir, + last_header, code_block_index, + indent_depth) + code_block_index += 1 + # reach here either line was not code, or was code + # and we dealt with n code lines + if indent_depth < 4 or not is_code(line, indent_depth): + # store header id for codeblock + section_id = get_marker(line) + if section_id is not None: + code_block_index = 0 + last_header = section_id + sline = stripped(line) + text_filehandle.write(sline) + + assert line_length(args.sourcefile) == line_length(args.targetfile) + + +def process_code(read_filehandle, text_filehandle, line, linenum, sourcefile, codedir, name, index, indent_depth): + fenced = (line.strip() == '```') + if fenced: + try: + line = read_filehandle.readLine() + linenum += 1 + text_filehandle.write('\n') + except StopIteration: + return ('', linenum) + start_linenum = linenum + has_actual_code = False + has_question_marks = False + linebuffer = [] + while ((fenced and line.strip() != '```') or (not fenced and is_inside_code(line, indent_depth))): + # copy comments to plain text for spell check + comment_idx = line.find('//') + no_comment_line = line + if comment_idx >= 0: + no_comment_line = line[:comment_idx].strip() + text_filehandle.write(line[comment_idx + 2:]) + else: + # write empty line so line numbers stay stable + text_filehandle.write('\n') + + if (not has_actual_code + and not line.strip().startswith('//') + and not line.strip().startswith('???') + and not line.strip() == ''): + has_actual_code = True + + if (not line.strip() == '```'): + if ('???' == no_comment_line or '...' == no_comment_line): + has_question_marks = True + linebuffer.append(dedent(line, indent_depth) if not fenced else line) + try: + line = read_filehandle.readline() + linenum += 1 + except StopIteration: + line = '' + break + codefile = os.path.join(codedir, '%s%s.cpp' % (name, index)) + if fenced: + text_filehandle.write('\n') + + if (has_actual_code and not has_question_marks): + linebuffer = clean_trailing_newlines(linebuffer) + write_with_harness(codefile, sourcefile, start_linenum, linebuffer) + return (line, linenum) + + +def clean_trailing_newlines(linebuffer): + result = [] + code_started = False + linebuffer.reverse() + for line in linebuffer: + if not code_started and line == '\n': + continue + code_started = True + result.append(line) + result.reverse() + return result + + +def write_with_harness(codefile, sourcefile, start_linenum, linebuffer): + '''write output with additional lines to make code likely compilable''' + # add commonly used headers, so that lines can likely compile. + # This is work in progress, the main issue remains handling class + # declarations in in-function code differently + with io.open(codefile, 'w') as code_filehandle: + code_filehandle.write('''\ +#include // by md-split +#include // by md-split +#include // by md-split +#include // by md-split +#include // by md-split +#include // by md-split +#include // by md-split +#include // by md-split +#include // by md-split +#include // by md-split +#include // by md-split +#include // by md-split +using namespace std; // by md-split +// %s : %s +''' % (sourcefile, start_linenum)) + # TODO: if not toplevel code, wrap inside class + for codeline in linebuffer: + code_filehandle.write(codeline) + + +def is_code(line, indent_depth = 4): + '''returns the indent depth, 0 means not code in markup''' + if line.startswith(' ' * indent_depth): + return len(line) - len(line.lstrip(' ')) + return 0 + +def is_inside_code(line, indent_depth): + return is_code(line, indent_depth) > 0 or line.strip() == '' + +def stripped(line): + # Remove well-formed html tags, fixing mistakes by legitimate users + sline = TAG_REGEX.sub('', line) + sline = re.sub('[()\[\]#*]', ' ', line) + return sline + +def dedent(line, indent_depth): + if line.startswith(' ' * indent_depth): + return line[indent_depth:] + if line.startswith('\t'): + return line[1:] + return line + +def get_marker(line): + matchlist = TAG_REGEX.findall(line) + if matchlist: + namematch = NAMED_A_TAG_REGEX.match(line) + if namematch: + return namematch.group(1) # group 0 is full match + + return None + +def line_length(filename): + return sum(1 for line in open(filename)) + +if __name__ == '__main__': + main() diff --git a/talks/Contracts-for-Dependable-C++.pdf b/talks/Contracts-for-Dependable-C++.pdf new file mode 100644 index 000000000..759480dcf Binary files /dev/null and b/talks/Contracts-for-Dependable-C++.pdf differ diff --git a/talks/Large-Scale-C++-With-Modules.pdf b/talks/Large-Scale-C++-With-Modules.pdf new file mode 100644 index 000000000..876e77331 Binary files /dev/null and b/talks/Large-Scale-C++-With-Modules.pdf differ diff --git a/talks/MacIntosh - A Few Good Types.pdf b/talks/MacIntosh - A Few Good Types.pdf new file mode 100644 index 000000000..b71a7ad29 Binary files /dev/null and b/talks/MacIntosh - A Few Good Types.pdf differ diff --git a/talks/MacIntosh - Static Analysis and C++.pdf b/talks/MacIntosh - Static Analysis and C++.pdf new file mode 100644 index 000000000..aab615727 Binary files /dev/null and b/talks/MacIntosh - Static Analysis and C++.pdf differ diff --git a/talks/README.md b/talks/README.md index 2f3644fb3..963f294c4 100644 --- a/talks/README.md +++ b/talks/README.md @@ -1,11 +1,13 @@ The guidelines were introduced during a number of talks at [CppCon](http://cppcon.org) 2015. Here are video recordings of those talks: -- Keynote: Writing Good C++ 14 (Bjarne Stroustrup): [https://www.youtube.com/watch?t=9&v=1OEu9C51K2A] -- Writing good C++ 14 By Default (Herb Sutter): -- More than lint: modern static analysis for C++ (Neil MacIntosh): -- A few good types: `Evolving array_view` and `string_view` for safe C++ code (Neil MacIntosh): +- [Keynote: Writing Good C++ 14 (Bjarne Stroustrup)](https://www.youtube.com/watch?t=9&v=1OEu9C51K2A) +- [Writing good C++ 14 By Default (Herb Sutter)](https://www.youtube.com/watch?v=hEx5DNLWGgA]) +- [Large Scale C++ With Modules: What You Should Know (Gabriel Dos Reis)](https://www.youtube.com/watch?v=RwdQA0pGWa4) +- [Contracts for Dependable C++ (Gabriel Dos Reis)](https://www.youtube.com/watch?v=Hjz1eBx91g8) +- [Static analysis and C++: more than lint (Neil MacIntosh)](https://www.youtube.com/watch?v=rKlHvAw1z50) +- [A few good types: Evolving `array_view` and `string_view` for safe C++ code (Neil MacIntosh)](https://www.youtube.com/watch?v=C4Z3c4Sv52U) -The YouTube channel for [CppCon](http://cppcon.org) is here: https://www.youtube.com/channel/UCMlGfpWw-RUdWX_JbLCukXg +The YouTube channel for [CppCon](http://cppcon.org) is [here](https://www.youtube.com/channel/UCMlGfpWw-RUdWX_JbLCukXg). -Slides from the talks are available in this folder. \ No newline at end of file +Slides from the talks are available in this folder.