Skip to content

Commit 55083af

Browse files
committed
fix line length
1 parent 46b4a20 commit 55083af

File tree

1 file changed

+35
-20
lines changed

1 file changed

+35
-20
lines changed

CppCoreGuidelines.md

Lines changed: 35 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -595,7 +595,8 @@ Ideally we catch all errors (that are not errors in the programmer's logic) at e
595595

596596
##### Example, bad
597597

598-
extern void f(int* p); // separately compiled, possibly dynamically loaded
598+
// separately compiled, possibly dynamically loaded
599+
extern void f(int* p);
599600

600601
void g(int n)
601602
{
@@ -608,11 +609,12 @@ Here, a crucial bit of information (the number of elements) has been so thorough
608609

609610
We can of course pass the number of elements along with the pointer:
610611

611-
extern void f2(int* p, int n); // separately compiled, possibly dynamically loaded
612+
// separately compiled, possibly dynamically loaded
613+
extern void f2(int* p, int n);
612614

613615
void g2(int n)
614616
{
615-
f2(new int[n], m); // bad: the wrong number of elements can be passed to f()
617+
f2(new int[n], m); // bad: a wrong number of elements can be passed to f()
616618
}
617619

618620
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.
@@ -1000,7 +1002,8 @@ The use of a non-local control is potentially confusing, but controls only imple
10001002

10011003
Reporting through non-local variables (e.g., `errno`) is easily ignored. For example:
10021004

1003-
fprintf(connection, "logging: %d %d %d\n", x, y, s); // don't: no test of printf's return value
1005+
// don't: no test of printf's return value
1006+
fprintf(connection, "logging: %d %d %d\n", x, y, s);
10041007

10051008
What if the connection goes down so that no logging output is produced? See I.??.
10061009

@@ -1439,7 +1442,8 @@ This is a major source of errors.
14391442
int printf(const char* ...); // bad: return negative number if output fails
14401443

14411444
template <class F, class ...Args>
1442-
explicit thread(F&& f, Args&&... args); // good: throw system_error if unable to start the new thread
1445+
// good: throw system_error if unable to start the new thread
1446+
explicit thread(F&& f, Args&&... args);
14431447

14441448
##### Note: What is an error?
14451449

@@ -1993,7 +1997,8 @@ Functions with complex control structures are more likely to be long and more li
19931997
Consider:
19941998

19951999
double simpleFunc(double val, int flag1, int flag2)
1996-
// simpleFunc: takes a value and calculates the expected ASIC output, given the two mode flags.
2000+
// simpleFunc: takes a value and calculates the expected ASIC output,
2001+
// given the two mode flags.
19972002
{
19982003

19992004
double intermediate;
@@ -2036,12 +2041,14 @@ We can refactor:
20362041
}
20372042

20382043
double simpleFunc(double val, int flag1, int flag2)
2039-
// simpleFunc: takes a value and calculates the expected ASIC output, given the two mode flags.
2044+
// simpleFunc: takes a value and calculates the expected ASIC output,
2045+
// given the two mode flags.
20402046
{
20412047
if (flag1 > 0)
20422048
return func1_muon(val, flag2);
20432049
if (flag1 == -1)
2044-
return func1_tau(-val, flag1, flag2); // handled by func1_tau: flag1 = -flag1;
2050+
// handled by func1_tau: flag1 = -flag1;
2051+
return func1_tau(-val, flag1, flag2);
20452052
return 0.;
20462053
}
20472054

@@ -2327,7 +2334,8 @@ For advanced uses (only), where you really need to optimize for rvalues passed t
23272334

23282335
int multiply(int, int); // just input ints, pass by value
23292336

2330-
string& concatenate(string&, const string& suffix); // suffix is input-only but not as cheap as an int, pass by const&
2337+
// suffix is input-only but not as cheap as an int, pass by const&
2338+
string& concatenate(string&, const string& suffix);
23312339

23322340
void sink(unique_ptr<widget>); // input only, and consumes the widget
23332341

@@ -2875,8 +2883,8 @@ After the return from a function its local objects no longer exist:
28752883
void h()
28762884
{
28772885
int* p = f();
2878-
int z = *p; // read from abandoned stack frame (bad)
2879-
g(p); // pass pointer to abandoned stack frame to function (bad)
2886+
int z = *p; // read from abandoned stack frame (bad)
2887+
g(p); // pass pointer to abandoned stack frame to function (bad)
28802888
}
28812889

28822890
Here on one popular implementation I got the output:
@@ -3076,7 +3084,8 @@ Functions can't capture local variables or be declared at local scope; if you ne
30763084

30773085
##### Example
30783086

3079-
// writing a function that should only take an int or a string -- overloading is natural
3087+
// writing a function that should only take an int or a string
3088+
// -- overloading is natural
30803089
void f(int);
30813090
void f(const string&);
30823091

@@ -3303,12 +3312,14 @@ but:
33033312

33043313
class Date {
33053314
public:
3306-
Date(int yy, Month mm, char dd); // validate that {yy, mm, dd} is a valid date and initialize
3315+
// validate that {yy, mm, dd} is a valid date and initialize
3316+
Date(int yy, Month mm, char dd);
33073317
// ...
33083318
private:
33093319
int y;
33103320
Month m;
33113321
char d; // day
3322+
Date(int yy, Month mm, char dd);
33123323
};
33133324

33143325
##### Note
@@ -3338,7 +3349,8 @@ An explicit distinction between interface and implementation improves readabilit
33383349
// ... some representation ...
33393350
public:
33403351
Date();
3341-
Date(int yy, Month mm, char dd); // validate that {yy, mm, dd} is a valid date and initialize
3352+
// validate that {yy, mm, dd} is a valid date and initialize
3353+
Date(int yy, Month mm, char dd);
33423354

33433355
int day() const;
33443356
Month month() const;
@@ -3565,7 +3577,10 @@ Regular types are easier to understand and reason about than types that are not
35653577
vector<Record> vr;
35663578
};
35673579

3568-
bool operator==(const Bundle& a, const Bundle& b) { return a.name == b.name && a.vr == b.vr; }
3580+
bool operator==(const Bundle& a, const Bundle& b)
3581+
{
3582+
return a.name == b.name && a.vr == b.vr;
3583+
}
35693584

35703585
Bundle b1 { "my bundle", {r1, r2, r3}};
35713586
Bundle b2 = b1;
@@ -4671,9 +4686,9 @@ If the state of a base class object must depend on the state of a derived part o
46714686

46724687
class B {
46734688
protected:
4674-
B() { /* ... */ } // create an imperfectly initialized object
4689+
B() { /* ... */ } // create an imperfectly initialized object
46754690

4676-
virtual void PostInitialize() // to be called right after construction
4691+
virtual void PostInitialize() // to be called right after construction
46774692
{
46784693
// ...
46794694
f(); // GOOD: virtual dispatch is safe
@@ -4684,17 +4699,17 @@ If the state of a base class object must depend on the state of a derived part o
46844699
virtual void f() = 0;
46854700

46864701
template<class T>
4687-
static shared_ptr<T> Create() // interface for creating objects
4702+
static shared_ptr<T> Create() // interface for creating objects
46884703
{
46894704
auto p = make_shared<T>();
46904705
p->PostInitialize();
46914706
return p;
46924707
}
46934708
};
46944709

4695-
class D : public B { /* "¦ */ }; // some derived class
4710+
class D : public B { /* "¦ */ }; // some derived class
46964711

4697-
shared_ptr<D> p = D::Create<D>(); // creating a D object
4712+
shared_ptr<D> p = D::Create<D>(); // creating a D object
46984713

46994714
By making the constructor `protected` we avoid an incompletely constructed object escaping into the wild.
47004715
By providing the factory function `Create()`, we make construction (on the free store) convenient.

0 commit comments

Comments
 (0)