mirror of
https://github.com/isocpp/CppCoreGuidelines.git
synced 2024-03-22 13:30:58 +08:00
Merge pull request #162 from tkruse/fix-biblio
fix citations/references/bibliography.
This commit is contained in:
Gabriel Dos Reis
commit
f2c4d1459c
|
|
@ -172,7 +172,7 @@ Remember:
|
|||
|
||||
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 a 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))
|
||||
that make the use of the most error-prone features of C++ redundant, so that they can be banned (in our set of rules).
|
||||
|
|
@ -10774,15 +10774,14 @@ Somewhat brief, pre-C++11, and (not unreasonably) adjusted to its domain.
|
|||
<a name="SS-books"></a>
|
||||
## 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.
|
||||
* <a name="BS2005"></a>
|
||||
Bjarne Stroustrup: [A rationale for semantically enhanced library languages](http://www.stroustrup.com/SELLrationale.pdf).
|
||||
* [[Meyers14]](#Meyers14) Scott Meyers: Effective Modern C++ (???). Addison-Wesley 2014. Beware of overly technical and overly definite rules.
|
||||
* [[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. Recommended.
|
||||
* [[Stroustrup05]](#Stroustrup05) 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).
|
||||
* [[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.
|
||||
* Stroustrup: [The C++ Programming Language (4th Edition)](http://www.stroustrup.com/4th.html).
|
||||
* [[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)
|
||||
|
|
@ -10805,7 +10804,8 @@ Primarily a teaching tool.
|
|||
* [isocpp.org](http://www.isocpp.com)
|
||||
* [Bjarne Stroustrup's home pages](http://www.stroustrup.com)
|
||||
* [WG21](http://www.open-std.org/jtc1/sc22/wg21/)
|
||||
* [Boost](http://www.boost.org)
|
||||
* <a name="Boost"></a>
|
||||
[Boost](http://www.boost.org)
|
||||
* [Adobe open source](http://www.adobe.com/open-source.html)
|
||||
* [Poco libraries](http://pocoproject.org/)
|
||||
|
||||
|
|
@ -11861,7 +11861,7 @@ If the class definition and the constructor body are in separate files, the long
|
|||
|
||||
**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
|
||||
|
||||
### <a name="???">Use of `=`, `{}`, and `()` as initializers</a>
|
||||
|
||||
|
|
@ -11873,7 +11873,7 @@ If your design wants virtual dispatch into a derived class from a base class con
|
|||
|
||||
* *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 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]](#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:
|
||||
|
|
@ -11917,7 +11917,7 @@ If the requirements above are met, the design guarantees that `PostInitialize` h
|
|||
|
||||
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)
|
||||
|
||||
|
||||
|
||||
|
|
@ -11991,7 +11991,7 @@ In this rare case, you could make the destructor public and nonvirtual but clear
|
|||
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**: [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
|
||||
**References**: [[C++CS]](#C++CS) 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
|
||||
|
||||
|
||||
|
||||
|
|
@ -12067,9 +12067,9 @@ The standard library forbids all destructors used with it from throwing. You can
|
|||
|
||||
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]](#C++03) §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]](#C++03) §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`:
|
||||
|
|
@ -12088,7 +12088,7 @@ 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**: 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
|
||||
**References**: [[C++CS]](#C++CS) Item 51; [[C++03]](#C++03) §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
|
||||
|
||||
|
||||
|
||||
|
|
@ -12174,7 +12174,7 @@ Prefer compiler-generated (including `=default`) special members; only these can
|
|||
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**: [[C++CS]](#C++CS) Item 52; [[Cline99]](#Cline99) §30.01-14¸ [[Koenig97]](#Koenig97) §4¸ [[Stroustrup00]](#Stroustrup00) §5.5, §10.4¸ [[SuttHysl04b]](#SuttHysl04b)
|
||||
|
||||
|
||||
|
||||
|
|
@ -12403,3 +12403,55 @@ Aternatively, we will decide that no change is needed and delete the entry.
|
|||
* 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)
|
||||
|
||||
* rules for arithmetic
|
||||
|
||||
|
||||
|
||||
# Bibliography
|
||||
|
||||
* <a name="Alexandrescu01"></a>
|
||||
[Alexandrescu01] A. Alexandrescu. Modern C++ Design (Addison-Wesley, 2001).
|
||||
* <a name="C++03"></a>
|
||||
[C++03] ISO/IEC 14882:2003(E), Programming LanguagesC++ (updated ISO and ANSI C++ Standard including the contents of [C++98] plus errata corrections).
|
||||
* <a name="C++CS"></a>
|
||||
[C++CS]
|
||||
* <a name="Cargill92"></a>
|
||||
[Cargill92] T. Cargill. C++ Programming Style (Addison-Wesley, 1992).
|
||||
* <a name="Cline99"></a>
|
||||
[Cline99] M. Cline, G. Lomow, and M. Girou. C++ FAQs (2ndEdition) (Addison-Wesley, 1999).
|
||||
* <a name="Dewhurst03"></a>
|
||||
[Dewhurst03] S. Dewhurst. C++ Gotchas (Addison-Wesley, 2003).
|
||||
* <a name="Henricson97"></a>
|
||||
[Henricson97] M. Henricson and E. Nyquist. Industrial Strength C++ (Prentice Hall, 1997).
|
||||
* <a name="Koenig97"></a>
|
||||
[Koenig97] A. Koenig and B. Moo. Ruminations on C++ (Addison-Wesley, 1997).
|
||||
* <a name="Lakos96"></a>
|
||||
[Lakos96] J. Lakos. Large-Scale C++ Software Design (Addison-Wesley, 1996).
|
||||
* <a name="Meyers96"></a>
|
||||
[Meyers96] S. Meyers. More Effective C++ (Addison-Wesley, 1996).
|
||||
* <a name="Meyers97"></a>
|
||||
[Meyers97] S. Meyers. Effective C++ (2ndEdition) (Addison-Wesley, 1997).
|
||||
* <a name="Meyers97"></a>
|
||||
[Meyers14] S. Meyers. Effective Modern C++ (Addison-Wesley, 2014).
|
||||
* <a name="Murray93"></a>
|
||||
[Murray93] R. Murray. C++ Strategies and Tactics (Addison-Wesley, 1993).
|
||||
* <a name="Stroustrup00"></a>
|
||||
[Stroustrup00] B. Stroustrup. The C++ Programming Language (Special 3rdEdition) (Addison-Wesley, 2000).
|
||||
* <a name="Stroustrup05"></a>
|
||||
[Stroustrup05] B. Stroustrup. [A rationale for semantically enhanced library languages](http://www.stroustrup.com/SELLrationale.pdf).
|
||||
* <a name="Stroustrup13"></a>
|
||||
[Stroustrup13] B. Stroustrup. [The C++ Programming Language (4th Edition)](http://www.stroustrup.com/4th.html). Addison Wesley 2013.
|
||||
* <a name="Stroustrup14"></a>
|
||||
[Stroustrup14] B. Stroustrup. [A Tour of C++](http://www.stroustrup.com/Tour.html).
|
||||
Addison Wesley 2014.
|
||||
* <a name="SuttHysl04b"></a>
|
||||
[SuttHysl04b] H. Sutter and J. Hyslop. "Collecting Shared Objects" (C/C++ Users Journal, 22(8), August 2004).
|
||||
* <a name="SuttAlex05"></a>
|
||||
[SuttAlex05] H. Sutter and A. Alexandrescu. C++ Coding Standards. Addison-Wesley 2005.
|
||||
* <a name="Sutter00"></a>
|
||||
[Sutter00] H. Sutter. Exceptional C++ (Addison-Wesley, 2000).
|
||||
* <a name="Sutter02"></a>
|
||||
[Sutter02] H. Sutter. More Exceptional C++ (Addison-Wesley, 2002).
|
||||
* <a name="Sutter04"></a>
|
||||
[Sutter04] H. Sutter. Exceptional C++ Style (Addison-Wesley, 2004).
|
||||
* <a name="Taligent94"></a>
|
||||
[Taligent94] Taligent's Guide to Designing Programs (Addison-Wesley, 1994).
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user