TODO List
For more items on the TODO list, please see C++ Coding Standard Development Guidelines .
These rules need professional editing:
- CON56-CPP. Do not speculatively lock a non-recursive mutex that is already owned by the calling thread
- EXP56-CPP. Do not call a function with a mismatched language linkage
- EXP63-CPP. Do not rely on the value of a moved-from object
These rules should be preserved:
Content by label
There is no content with the specified labels
These rules should be updated:
Content by label
There is no content with the specified labels
These rules should be deleted:
Content by label
There is no content with the specified labels
These rules are covered by C and do not require a C++ rule:
Content by label
There is no content with the specified labels
These rules have notes associated with them:
- CTR50-CPP. Guarantee that container indices and iterators are within the valid range
- CTR58-CPP. Predicate function objects should not be mutable
- DCL51-CPP. Do not declare or define a reserved identifier
- DCL54-CPP. Overload allocation and deallocation functions as a pair in the same scope
- DCL59-CPP. Do not define an unnamed namespace in a header file
- DCL60-CPP. Obey the one-definition rule
- ERR57-CPP. Do not leak resources when handling exceptions
- ERR59-CPP. Do not throw an exception across execution boundaries
- EXP50-CPP. Do not depend on the order of evaluation for side effects
- EXP54-CPP. Do not access an object outside of its lifetime
- EXP60-CPP. Do not pass a nonstandard-layout type object across execution boundaries
- FIO51-CPP. Close files when they are no longer needed
- MEM50-CPP. Do not access freed memory
- MEM51-CPP. Properly deallocate dynamically allocated resources
- MEM55-CPP. Honor replacement dynamic storage management requirements
- MEM56-CPP. Do not store an already-owned pointer value in an unrelated smart pointer
- MSC54-CPP. A signal handler must be a plain old function
- OOP51-CPP. Do not slice derived objects
Incomplete pages in C++ use the incomplete tag. Pages with hidden notes in them use the notes tag.
But C++ rules that were copied from C and not updated are marked with the incomplete-cpp tag.
C++ rules that are accurate, but need their sample code updated (from C) are tagged with the update-code tag.
Update references to C (eg C99) to references to C++
Pages should have tags to indicate the status of their corresponding checker in Compass Rose:
| Tag | Meaning |
| rose-complete | ROSE catches all violations |
| rose-partial | ROSE catches some violations |
| rose-possible | ROSE could catch some or all violations, but doesn't yet. |
| rose-gcc | ROSE doesn't catch violations, but will soon, GCC catches violations |
| unenforceable | These rules can't be checked automatically. |
| rose-nonapplicable | These rules could be checked automatically in theory, but not by ROSE. |
| rose-na-macros | ROSE could check these rules if it recognized macro usage. |
| rose-na-exptypes | ROSE could check these rules if it recognized derived types in expressions, such as size_t . |
| rose-na-multiple-files | ROSE could check these rules if it operated on multiple files at once. |
| rose-false-positive | ROSE could enforce this rule, but could not avoid catching some false positives. |
At this point, all rules should have one of these tags. That is, they should be completely or partially checked by ROSE, or they should be marked 'rose-possible', in that we will try to check them with ROSE, or they should have one of the nonapplicable tags indicating we don't think they can be checked with ROSE.
There are some rules in other standards that might make good C++ rules. They are tagged exportable-c++ . Port to C++ those rules that are truly applicable.
review -> review + review-one -> review + review-two -> No tags
significant changes -> review or incomplete