Cpp core guidelines

Dec. 7, 2015

  https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

  After 2-3 hours reading, Julia found out that she learns quickly through the reading comparing to Cpp conference videos. So, she plans to read the whole document - 452 pages, and then, memorize the guidelines; and then, she spends less time on videos.

  Most of guidelines are well documented with readable examples. So, it is good to write down some study notes.

  Her most favorite guideline on Dec. 7, 2015, is called to "express the intent", the first day reading.

P.3: Express intent

Here are things Julia likes, "the index is exposed", "index outlives the scope of loop", good warnings.
---

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

int 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 may or may not be intended. The reader cannot know from just this section of code.

Better:

for (const auto& x : v) { /* do something with x */ }

---
Second favorite tip:

F.2: A function should perform a single logical operation

Dec. 8, 2015

Favorite guidelines, review again. 

P.4: Ideally, a program should be statically type safe

P.5: Prefer compile-time checking to run-time checking

 I.4: Make interfaces precisely and strongly typed

ES.5: Keep scopes small

ES.20: Always initialize an object

ES.23: Prefer the {} initializer syntax

ES.78: Always end a non-empty case with a break

ES.41: If in doubt about operator precedence, parenthesize

ES.45: Avoid "magic constants"; use symbolic constants

ES.46: Avoid lossy (narrowing, truncating) arithmetic conversions

T.20: Avoid "concepts" without meaningful semantics

Dec. 22, 2015
P.4: Ideally, the program should be statically type safe
Problem areas: unions, casts, array decays, range errors, narrow conversions.

Alternatives:
unions - use invariant
casts - template can help
array decay - use span
range error - use span

type safe - a new keyword, and get some examples about the area.

further reading:


http://stackoverflow.com/questions/208959/c-variant
http://www.boost.org/doc/libs/1_36_0/doc/html/variant.html

Thinking in C++
http://web.mit.edu/merolish/ticpp/TicV2.html

C# type safe compile time
http://stackoverflow.com/questions/6927642/is-there-a-name-for-this-pattern-c-compile-time-type-safety-with-params-arg

https://en.wikipedia.org/wiki/Type_safety
http://en.cppreference.com/w/cpp/language/dynamic_cast

P.6. What cannot be checked at compile time should be checkable at run time
http://okmij.org/ftp/Computation/Subtyping/Preventing-Trouble.html

http://okmij.org/ftp/Computation/Subtyping/Trouble.html#Problem

To be continued.