Page MenuHomeFreeBSD
Files F153841247

D50983.id157459.diff
No OneTemporary
Actions

D50983.id157459.diff
View Options

diff --git a/share/man/man9/style.9 b/share/man/man9/style.9
--- a/share/man/man9/style.9
+++ b/share/man/man9/style.9
@@ -766,8 +766,7 @@
.Pp
Values in
.Ic return
-statements should be enclosed in parentheses where possible.
-For example, parentheses cannot be used if the value is a C++ braced-init-list.
+statements should be enclosed in parentheses.
.Pp
Use
.Xr err 3
@@ -918,6 +917,170 @@
rather than individual clauses.
Do not add these annotations without empirical evidence of the likelihood of the
branch.
+.Ss C++
+KNF style was originally defined as a style primarily for C.
+C++ introduces several new idioms which do not have an existing corollary
+in KNF C such as inline function definitions in classes.
+C++ is also not always compatible with some KNF guidelines such as
+enclosing return values in parentheses.
+For C++ code, FreeBSD aims to follow broadly accepted C++ practices while
+also following the general shape of KNF.
+This section enumerates C++ specific guidelines that differ from KNF C.
+.Pp
+The preferred suffixes for C++ source files are
+.Dq .cc
+and
+.Dq .hh .
+Header files should use a suffix unlike headers from the STL.
+.Pp
+Return values should generally not be enclosed in parantheses.
+When converting existing C code to C++,
+existing return values may remain in parantheses.
+.Pp
+Namespace declarations should use cuddle braces similar to structure and
+class definitions.
+Declarations within a namespace should be indented.
+Nested namespaces should be declared using a single namespace declaration.
+.Bd -literal
+namespace foo::bar {
+}
+.Ed
+.Pp
+Inline function prototypes should follow the same style used for standalone
+function protoypes except that a space should be used between a function's
+return type and name.
+.Pp
+Function definitions at the top-level should use a newline after the function
+type similar to C function definitions.
+.Pp
+Nested inline function definitions inside of a class, structure, or namespace
+should not use a newline after the function type.
+Instead, these should follow the style of inline function prototypes.
+This is more common C++ style and is more compact for small methods such as
+getters and setters.
+.Pp
+Inline functions whose body consists of a single statement may use a single
+line for the function body.
+Inline functions with an empty body should always use a single line.
+.Bd -literal
+struct widget {
+ int foo() { return 4; }
+ int bar();
+};
+
+int
+widget::bar()
+{
+ return 6;
+}
+.Ed
+.Pp
+Default and deleted methods should be declared as a single line.
+.Bd -literal
+class box {
+ ~box() = default;
+};
+.Ed
+.Pp
+In template declarations, the
+.Ic template
+keyword and list of template parameters may be followed by a newline
+before the templated declaration.
+TODO: Should this be mandatory?
+.Bd -literal
+template <class T>
+class box<T> {
+};
+.Ed
+.Pp
+The
+.Ic &
+for reference variables should be placed on the variable name rather
+than the type similar to the style used with
+.Ic *
+for pointers.
+.Bd -literal
+ int x;
+ int &xp = &x;
+.Ed
+.Pp
+TODO: What about multiline constructors with initializers:
+.Bd -literal
+class auth {
+ auth(const char *secret) : a_secret(secret) {}
+
+ auth(const char *secret, const char *mutual_user,
+ const char *mutual_secret) : a_secret(secret),
+ a_mutual_user(mutual_user), a_mutual_secret(mutual_secret) {}
+
+vs
+
+ auth(const char *secret, const char *mutual_user,
+ const char *mutual_secret) :
+ a_secret(secret), a_mutual_user(mutual_user),
+ a_mutual_secret(mutual_secret)
+ {}
+
+vs
+
+ auth(const char *secret, const char *mutual_user,
+ const char *mutual_secret)
+ : a_secret(secret), a_mutual_user(mutual_user),
+ a_mutual_secret(mutual_secret)
+ {}
+
+vs
+
+ auth(const char *secret, const char *mutual_user,
+ const char *mutual_secret)
+ : a_secret(secret), a_mutual_user(mutual_user),
+ a_mutual_secret(mutual_secret)
+ {}
+.Ed
+.Pp
+TODO: Naming convention for private members: foo_ vs _foo
+.Pp
+TODO: Permit space after
+.Ic operator() Ns
+?
+.Pp
+STL containers should be used in preference to
+.Xr queue 3
+or
+.Xr tree 3
+macros.
+.Pp
+.Ic nullptr
+should be used instead of
+.Dv NULL .
+.Pp
+The
+.Ic auto
+keyword can be used in various contexts which improve readability.
+Examples include iterators, non-trivial types of ranged-for values,
+and return values of
+.Fn make_unique .
+Place any qualifiers before
+.Ic auto ,
+for example:
+.Ic const auto .
+.Pp
+Use
+.Ic new
+and
+.Ic delete
+instead of
+.Xr malloc 3 .
+.Pp
+Use
+.Fn make_unique
+and
+.Fn make_shared
+to create smart pointers instead of
+.Ic new .
+.Pp
+TODO: Do we want to ban iostream in the hopes of adopting <format> once
+we can require C++23?
.Sh FILES
.Bl -tag -width indent
.It Pa /usr/src/tools/build/checkstyle9.pl

File Metadata

Mime Type
text/plain
Expires
Sat, Apr 25, 4:35 AM (8 h, 42 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
32109391
Default Alt Text
D50983.id157459.diff (4 KB)

Event Timeline