Guidelines for the use of the C++14 language in critical and safety-related systems, No.839 , 2021-11

他の文書は、改定がなくても新しい文書としてNoChangeで発行する。C++は2019年からNoChangeでは発行していない。ただし、最新の文書で検索すると出てくる。

一覧はこちら。

AUTOSAR R21-11(0) 仕様ダウンロード一覧。単語帳。参考文献資料作成

ソースコードをコンパイルしてみた報告一覧はこちら。

Autosar Guidelines C++14 example code compile list(1-169)

用語(terms)

Term	Description
Real-time application (RTA)	A real-time application is a program that guarantees response within defined time constraints. The latency must be less than a defined value, usually measured in seconds or milliseconds. Whether or not a given application program qualifies as an RTA depends on the worst-case execution time (WCET) - themaximum length of time a defined task requires on a given hardware platform.
MISRA	Motor Industry Software Reliability Association.
HIC++	High Integrity C++ Coding Standard.
cvalue expression	An expression that should not undergo further conversions, either implicitly or explicitly, is called a cvalue expression.
Ownership	Ownership of a resource means that the resource’s lifetime is fully managed by the single class instance or tied with the class instance lifetime. See also: chapter 6.18.5
One definition rule	The rule states that: There shall be one and only one definition of any variable, function, class type, enumeration type, or template in a translation unit. Some of these may have multiple declarations, but only one definition is allowed. There shall be one and only one definition of every noninline function or variable that is odr-used in the entire program. An inline function definition is required in every translation unit where it is odr-used. There shall be one and only one definition of a class in any translation unit where the class is used in a way that requires it to be complete. There can be more than one definition of any class, enumeration type, inline function with external linkage, class template, non-static function template, static data member of a class template, member function of a class template, partial template specialization in a program, as long as all of the following is true: – each definition consists of the same sequence of tokens (typically, appears in the same header file) – name lookup from within each definition finds the same entities (after overload-resolution), except that constants with internal or no linkage may refer to different objects as long as they are not ODR-used and have the same values in every definition. – overloaded operators, including conversion, allocation, and deallocation functions refer to the same function from each definition (unless referring to one defined within the definition) – the language linkage is the same (e.g. the include file isn’t inside an extern “C” block) – the three rules above apply to every default argument used in each definition – if the definition is for a class with an implicitlydeclared constructor, every translation unit where it is odr-used must call the same constructor for the base and members – if the definition is for a template, then all these requirements apply to both names at the point of definition and dependent names at the point of instantiation If all these requirements are satisfied, the program behaves as if there is only one definition in the entire program. Otherwise, the behavior is undefined.
ODR-use	An object is odr-used if its address is taken, or a reference is bound to it. A function is odr-used if a function call to it is made or its address is taken.
POD Type	POD (Plain Old Data) type is the type that is compatible with types used in the C programming language, can be manipulated using C library functions, and can be exchanged with C libraries directly in its binary form.
Trivially Copyable Class	A class (C++ Language Standard [3], chapter 9): where each copy constructor, move constructor, copy assignment operator, move assigment operator is either deleted or trivial that has at least one non-deleted copy constructor, move constructor, copy assignment operator, or move assignment operator, and that has a trivial, non-deleted destructor
Standard-Layout Class	A class that (C++ Language Standard [3], chapter 9): has no non-static data members of type non-standardlayout class (or array of such types) or reference has no virtual functions and no virtual base classes has the same access control for all non-static data members has no non-standard-layout base classes has at most one base class subobject of any given type has all non-static data members and bit-fields in the class and its base classes first declared in the same class has no element of the set M(X) of types as a base class where M(X) is defined as follows: – If X is a non-union class type, the set M(X) is empty if X has no (possibly inherited) non-static data members; otherwise, it consists of the type of the first non-static data member of X (where said member may be an anonymous union), X0, and the elements of M(X0). – If X is a union type, the set M(X) is the union of all M(Ui) and the set containing all Ui, where each Ui is the type of the i-th non-static data member of X. – If X is a non-class type, the set M(X) is empty.
Dataflow Anomaly	The state of a variable at a point in a program can be described using the following terms: Undefined (U): The value of the variable is indeterminate. Referenced (R): The variable is used in some way (e.g. in an expression). Defined (D): The variable is explicitly initialized or assigned a value. Given the above, the following dataflow anomalies can be defined: UR dataflow anomaly: Variable not assigned a value before the specified use (this may result in undefined behavior). DU dataflow anomaly: Variable is assigned a value that is never subsequently used. DD dataflow anomaly: Variable is assigned a value twice with no intermediate use.
Dead Code	Dead code (also known as redundant code) consists of evaluated expressions whose removal would not affect the output program.
Unreachable Code	Unreachable code is code to which there is no syntactic (control flow) path, e.g. a function which is never called, either directly or indirectly.
Diamond Problem	The “diamond problem” is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If there is a method provided by class A, that is overriden in both B and C and D does not override it, then there is an ambiguity which version of the method does D actually inherit. See: Wikipedia.org for more details.
Interface class	An interface class is a class which has following properties: if there are any, all member functions are public pure virtual if there are any, all data members are public static constexpr
Extended precision format	The IEEE Standard for Floating-Point Arithmetic (IEEE 754) specifies extended precision formats, that are recommended for allowing a greater precision format than that provided by the basic formats. For an extended format the exponent range must be as great as that of the next wider basic format. For instance, 64-bit extended precision binary number must have an “exponent max” of at least 16383, which is equal to “exponent max” of 128- bit binary floating-point. The 80-bit extended format meets this requirement.
Fundamental types	C++ built-in types defined in C++ Language Standard [3] in chapter 3.9.1, e.g. char, signed char, unsigned char, int, long long int, wchar_t, bool, float, double, void, std::nullptr_t, etc.
Scalar types	The following types are scalar types: integral types floating point types pointers and pointers to members enumerations std::nullptr_t
glvalue	A glvalue is an expression whose evaluation determines the identity of an object, bit-field, or function.
xvalue	An xvalue refers to an object, usually near the end of its lifetime, so that its resources may be moved.
prvalue	A prvalue is an expression whose evaluation initializes an object or a bit-field, or computes the value of the operand of an operator.
rvalue	An rvalue is an xvalue or a prvalue.
lvalue	An lvalue is a glvalue that is not an xvalue.
Implicitly-defined default constructor	Implicitly-defined default constructor calls default constructors of its base classes and non-static data members. It has exactly the same effect as a user-defined constructor with empty body and empty initializer list.
Implicitly-defined copy constructor	Implicitly-defined copy constructor of a class type (class or struct) performs full member-wise copy of the object’s bases and nonstatic data members, in their initialization order, using direct initialization.
Implicitly-defined move constructor	Implicitly-defined move constructor of a class type (class or struct) performs full member-wise move of the object’s bases and non-static members, in their initialization order, using direct initialization with an xvalue argument.
Implicitly-defined copy assignment operator	Implicitly-defined copy assignment operator of a class type (class or struct) performs full member-wise copy assignment of the object’s bases and non-static data members, in their initialization order, using built-in assignment for the scalars and copy assignment operator for class types.
Implicitly-defined move assignment operator	Implicitly-defined move assignment operator of a class type (class or struct) performs full member-wise move assignment of the object’s direct bases and immediate non-static data members, in their initialization order, using built-in assignment for the scalars, member-wise move-assignment for arrays, and move assignment operator for class types (called non-virtually).
Implicitly-defined destructor	Implicitly-defined destructor has an empty body. After the body of the destructor is executed, the destructors for all non-static nonvariant data members of the class are called, in reverse order of declaration. Then it calls destructors of all direct non-virtual base classes, in reverse order of construction, and then it calls the destructors of all virtual bases.
Is-a relationship	Subsumption relationship between types. If one class B is a subclass of another class A (i.e. B is a more specialized concept than A), then B class specification implies A class specification and a B class object can be used for any expression that requires an A class object.
Has-a relationship	Composition relationship where one object is a part or member of another object with respect to the rules of ownership.
Single point of exit	Approach background: IEC 61508 [19], as one of methods for providing modular approach. ISO26262 part 6 [5] with the requirement for ASIL A-D. MISRA-C++ 2008 with the rule M6-6-5. AUTOSAR Coding Guidelines consider that the only reason for such an approach is improving robustness of resource handling, e.g. ensuring that resources are properly released in case of an early exit from the function. However, it is fully ensured by other rules existing in the document that: enforce usage of smart pointers and memory management objects for expressing lifetime semantics (A18-5-2) enforce allocate local objects on stack (A18-5-8) recommend usage of RAII (A15-1-4, A18-5-2) Single point of exit is considered to decrease code readability and will not bring any additional benefits for improving coding standards, thus it is not enforced by the AUTOSAR Coding Guidelines.

英日

日本語は仮訳

no.	count	word	日本語
1	5014	a	一つの
2	3682	the	その
3	2736	of	の
4	2035	std	standard(短縮名）
5	2015	c	c
6	1699	to	に
7	1610	and	と
8	1591	in	の
9	1460	not	ない
10	1425	be	です
11	1370	is	です
12	1261	guidelines	指針
13	1240	for	にとって
14	1174	compliant	準拠
15	1143	rule	規則
16	1140	autosar	AUTomotive Open System Architecture(短縮名)
17	1022	_t	_t
18	966	use	使用する
19	911	shall	しなければならない
20	905	int	integer（短縮名）
21	807	non	非（接頭辞）
22	803	m	m
23	780	class	級
24	749	id	identifier, 識別子(短縮名）
25	739	an	と
26	714	differences	違い
27	713	or	また
28	704	that	それ
29	682	no	いいえ
30	662	type	型
31	633	language	言語
32	631	required	必要
33	579	function	働き
34	578	related	関連している
35	576	document	資料
36	558	f	f
37	556	see	見る
38	554	safety	安全性
39	554	void	空所
40	545	small	小さい
41	544	implementation	実装
42	543	release	公開
43	524	critical	致命的
44	523	used	使用済み
45	521	systems	系
46	510	ap	adaptive platform(短縮名)
47	509	autosar_rs_cpp	autosar_rs_cpp
48	509	confidential	信頼
49	495	if	もしも
50	494	include	含む
51	487	const	constant(短縮名）
52	482	b	b
53	459	except	それ外
54	459	with	と
55	456	by	により
56	451	x	x
57	448	it	それ
58	435	this	これ
59	431	are	それは
60	411	exception	例外
61	407	t	t
62	401	automated	自動化
63	397	as	なので
64	392	return	戻る
65	374	cpp	c plus plus(短縮名）
66	371	e	e
67	362	also	また
68	360	operator	操作者
69	340	object	物体
70	337	only	それだけ
71	327	public	公衆
72	307	av	av
73	302	example	例
74	298	from	から
75	289	functions	関数
76	285	i	私
77	280	uint	unsigned integer(短縮名）
78	278	do	行う
79	278	rejected	拒否した
80	276	rationale	理論的根拠
81	275	will	意思
82	273	misra	Motor Industry Software Reliability Association(短縮名）
83	263	all	すべて
84	263	v	v
85	260	standard	標準
86	259	error	誤り
87	255	pointer	指示子
88	255	z	z
89	251	name	名前
90	246	defined	定義済み
91	239	on	の上
92	238	default	既定値
93	232	using	使って
94	230	code	符号
95	225	template	雛形
96	222	memory	記憶装置
97	217	d	d
98	216	new	新着
99	216	should	したほうがいい
100	214	can	できる

参考(reference)

bibliographyとして一覧を示している。

ISO/IEC 14882:2003, The C++ Standard Incorporating Technical Corrigendum 1, International Organization for Standardization, 2003.
ISO/IEC 14882:2011, ISO International Standard ISO/IEC 14882:2011(E) - Programming
Language C++, International Organization of Standardization, 2011.
ISO/IEC 14882:2014, ISO International Standard ISO/IEC 14882:2014(E) - Programming
Language C++, International Organization for Standardization, 2016.
ISO 26262-6, Road vehicles - Functional safety - Part 6: Product development at the software level, International Organization for Standardization, 2011.
ISO 26262-6, Road vehicles - Functional safety - Part 6: Product development at the software level, International Organization for Standardization, 2011.
ISO 26262-8, Road vehicles - Functional safety - Part 8: Supporting processes,
International Organization for Standardization, 2011.
MISRA C++:2008 Guidelines for the use of the C++ language in critical systems, The
Motor Industry Software Reliability Association, 2008.
Joint Strike Fighter Air Vehicle C++ Coding Standards for the System Development and Demonstration Program, Document Number 2RDU00001 Rev C, Lockheed
Martin Corporation, 2005.
High Integrity C++ Coding Standard Version 4.0, Programming Research Ltd, 2013.
Software Engineering Institute CERT C++ Coding Standard, Software Engineering
Institute Division at Carnegie Mellon University, 2016.
Bjarne Stroustrup, Herb Sutter, C++ Core Guidelines, 2017.
Google C++ Style Guide, Google, 2017.
Scott Meyers, Effective Modern C++, ISBN: 978-1-491-90399-5, O’Reilly, 2015.
Bjarne Stroustrup, The C++ Programming Language, Fourth Edition, ISBN: 978-
0-321-56384-2, Addison-Wesley, 2013.
Joshua Bloch, Effective Java, Second Edition, ISBN: 978-0321356680, AddisonWesley, 2008
cppreference.com, online reference for the C and C++ languages and standard
libraries, 2017
stackoverflow.com, community of programmers, 2017
open-std.org, site holding a number of web pages for groups producing open
standards, 2017
IEC 61508-3, Functional safety of electrical/electronic/programmable electronic
safety-related systems – Annex C, Overview of techniques and measures for
achieving software safety integrity, International Electrotechnical Commission,
2010.

全く同じ行があるが、その後、３年以上治っていない。

ISO 26262-6, Road vehicles - Functional safety - Part 6: Product development at the software level, International Organization for Standardization, 2011.

ならびから行くと、-7の可能性はある。

ISO 26262-7:2011
Road vehicles — Functional safety — Part 7: Production and operation

その後継の規格が出ている。言及がないのはなぜかわかっていない。

ISO 26262-6:2018
Road vehicles — Functional safety — Part 6: Product development at the software level

ISO 26262-8:2018
Road vehicles — Functional safety — Part 8: Supporting processes

IEC TS 61508-3-1:2016
Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3-1: Software requirements - Reuse of pre-existing software elements to implement all or part of a safety function

Glossary も　参考に入れましょう。
https://www.autosar.org/fileadmin/standards/foundation/22-11/AUTOSAR_TR_Glossary.pdf

関連文書(Related document)

Guidelines for the use of the C++14 language in critical and safety-related systems , AUTOSAR 22-11, AP, No.839

文書履歴(document history)

ver. 0.01 初稿 20221229
ver. 0.02 URL追記　20230102