- 22 11月, 2019 4 次提交
-
-
由 hsutter 提交于
-
由 Zachary Henkel 提交于
* Address items called out in Issue 1424 * Fix issues caught by CI * Updates based on PR review
-
由 Zachary Henkel 提交于
-
由 Zachary Henkel 提交于
-
- 16 10月, 2019 1 次提交
-
-
由 Mark Nelson 提交于
When a reference in the Bibliography is available online, it would seem to be nice to have a link. In this example, the original article was published in C/C++ User's Journal, with the content later ported to the DDJ web site. The DDJ site is no longer reliable, but a good copy exists in archive.org, and I've linked to it here.
-
- 11 10月, 2019 1 次提交
-
-
由 shaneasd 提交于
-
- 09 10月, 2019 1 次提交
-
-
由 johansin 提交于
Otherwise rather suggests a quadratic growth.
-
- 27 9月, 2019 1 次提交
-
-
由 Taewon Park 提交于
Fixed markdown links in E.15 which direct readers to Github repository, not currently viewing page
-
- 06 9月, 2019 2 次提交
-
-
由 Tom Lankhorst 提交于
The example that is 'intended' to be faster is actually faster on clang 8 /w -O3, and marginally slower than the 'simple' example on GCC 9.1 /w -O3 http://quick-bench.com/DrXvcvhjS1zDmMkgxrzIjbMByYA http://quick-bench.com/03VXPgDSxiMAmZMItiEA0iwTJgM
-
由 Elviss Strazdins 提交于
-
- 05 9月, 2019 1 次提交
-
-
由 Mike B 提交于
typo
-
- 19 8月, 2019 1 次提交
-
-
由 Simon Daester 提交于
It doesn't make sense otherwise
-
- 16 8月, 2019 1 次提交
-
-
由 Jonathan Wakely 提交于
Fixes #1491
-
- 09 8月, 2019 1 次提交
-
-
由 hsutter 提交于
-
- 08 8月, 2019 1 次提交
-
-
由 beinhaerter 提交于
* make the sample in Sd-factory compileable (closes #1488) - make the sample in Sd-factory compileable - fixed wrong capitalization: create/Create -> create - `make_shared` cannot access protected constructors, so made them public. To still have access protection introduced a protected `class Token` in each class. That token can only be created by the class itself (and derived classes) and needs to be passed to the constructor. - changed order: `public` first, then `protected` - same sample for C.50 and Sd-factory - removed spurious "see Item 49.1" as it is unclear what this means * line length * tabs -> spaces * spelling * input from cubbimew - added back in Item 49.1 - added link for items as suggested ("in [SuttAlex05](#SuttAlex05)") * changed link to Item 49.1 to link to C.82
-
- 02 8月, 2019 9 次提交
-
-
由 hsutter 提交于
-
由 hsutter 提交于
-
由 Herb Sutter 提交于
This PR affirms that all virtual functions, *including destructors*, should be declared exactly one of `virtual`, `override`, or `final`, and takesa pass through the document to make the examples and guidance consistent with that. Of course a virtual destructor is a virtual function: It behaves polymorphically, and it has a vtable entry that can be overwritten == overridden in a derived class exactly the same as any other derived virtual override. See also [class.virtual]/7: "Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual; see [class.dtor] and [class.free]." However, the following exception text currently appears in C.128: > If a base class destructor is declared `virtual`, one should avoid declaring derived class destructors `virtual` or `override`. Some code base and tools might insist on `override` for destructors, but that is not the recommendation of these guidelines. ... but this exception is (a) not well-founded, and (b) inconsistent with the Guidelines' practice in other examples and with the rationale a few lines earlier for C.128 itself. Re (a): - The exception is overly broad: The rationale given for this exception is entirely against marking destructors `override` (not `virtual`). So clearly the exception to write neither keyword is too broad: At most, the exception should be to write `virtual` rather than `override`. - Explicit `virtual` is primarily for class users, not class authors: The arguments given in #721 favoring this exception are from the viewpoint of the implementation of the function (even then, the arguments are debatable and debated). But `virtual`, `override`, and `final` are primarily for the far larger audience of *class users and call sites* of the function, for whom of course we should document each declared function that is polymorphic, *especially* the destructor -- this tells calling code whether the function is safe to call through a (smart or built-in) pointer or reference to base, which will nearly always be the case for such types. We should not make the reader of the code go way to look in the base classes to figure out whether a function declared in this class is virtual or not -- the reason this Item exists is primarily to avoid that implicit virtual antipattern via convention and automated enforcement. For class users, all virtual functions including destructors are equally polymorphic. Re (b): The Guidelines already don't follow this. For instance, two Items later (in C.130) we have this example that correctly uses `override`: ~~~ virtual ~D() override; ~~~ ... though per C.128 it should not also specify `virtual` (also fixed in this PR). Finally, the exception also contradicts the rationale given earlier in the same Item.
-
由 beinhaerter 提交于
- typo "a" -> "as" - added "???" to mark incomplete sentence - typo "than" -> "that" - "scanf using s" -> "scanf using %s" (same as for printf) - added missing comma
-
由 beinhaerter 提交于
- added space between two sentences - added missing closing bracket - typo "of" -> "or"
-
由 beinhaerter 提交于
- E.15: "of" -> "or" - E.27: capitalization
-
由 beinhaerter 提交于
* ES section, different stuff - ES.26: same capitalization for all function names in example - ES.34: fix wrong formatting (first line of example was formatted as text) - ES.46: corrected value in comment (new value read out in debugger) - ES.46: Capitalize Enforcement bullet points (as in other ES rules) - ES.65: fix formatting of code after list (compare https://meta.stackexchange.com/a/34325/172717) * review-feedback from jwakely and: - ES.46/ES.47: added period at end of sentence
-
由 beinhaerter 提交于
-
由 Chris Guzak 提交于
* exception in SF.7 for issue 1440, allow std::literals * PR feedback * add UDLs to spelling dictionary * put in alpha order
-
- 29 7月, 2019 1 次提交
-
-
由 Werner Henze 提交于
-
- 23 7月, 2019 3 次提交
-
-
由 Sergey Zubkov 提交于
-
由 beinhaerter 提交于
-
由 beinhaerter 提交于
-
- 10 7月, 2019 2 次提交
-
-
由 cclauss 提交于
[Travis are now recommending removing the __sudo__ tag](https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration). "_If you currently specify __sudo: false__ in your __.travis.yml__, we recommend removing that configuration_"
-
由 beinhaerter 提交于
-
- 09 7月, 2019 1 次提交
-
-
由 Tyler Young 提交于
-
- 08 7月, 2019 1 次提交
-
-
由 beinhaerter 提交于
-
- 03 7月, 2019 3 次提交
- 02 7月, 2019 2 次提交
-
-
由 beinhaerter 提交于
-
由 beinhaerter 提交于
-
- 01 7月, 2019 2 次提交
-
-
由 beinhaerter 提交于
- remove unnecessary space in section Reason
-
由 beinhaerter 提交于
-
- 26 6月, 2019 1 次提交
-
-
由 Jonathan Wakely 提交于
-