Guidelines for the use of the C++14 language in critical and safety-related systems , AUTOSAR 22-11, AP, No.839 obsolete
AUTOSAR Countdown Calendar 2022
2022/12/09日の投稿です。
AUTOSARが、今年の版、R22-11公開しました。公開行事の模様は
AUTOSAR R22-11 Release Event 20221208
下記URL順次確認中です。
間違っていたら、いいね を押していただいて、コメント欄にご報告くださると幸いです。
編集リクエストが、構造的な変更をしている最中に、構造的な編集リクエストをしていただくと、
何をどう直したらいいかわからなくなってしまいます。自動修復ツールがつくれていません。ごめんなさい。
文書は検索してダウンロードすることができます。
クラウドサービスにありがちな、あるのにないかのような検索結果が出ることがあります。
AUTOSAR R22-11 Qiita 記事一覧はこちらに編集中です。
ソースコードをコンパイルしてみた報告一覧はこちら。
Autosar Guidelines C++14 example code compile list(1-169)
<この項は書きかけです。順次追記します。>
文書変更(Document Change)
古いファイルのまま新しいURLに置いている。
No content changes とすら言っていない。
用語(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として一覧を示している。
Glossary も 入れましょう。
https://www.autosar.org/fileadmin/standards/foundation/22-11/AUTOSAR_TR_Glossary.pdf
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
Countdown Calendar 2022
今年企画した6つのCountdown Calendarと、それぞれの記事一つをご紹介します。
AUTOSAR Countdown Calendar 2022
AUTOSAR References to ISO, IEC, ITU, IEEE, RFC and SEA etc.
Automotive Handbook Countdown Calendar 2022
Basic principles, ボッシュ自動車handbook(英語)11版まとめ<2>
2022 いいねをいただいた記事ランキング(O.K.版) Countdown Calendar 2022
2022年１月下旬 いいねをいただいた記事 16
CDCale(O.K.) Countdown Calendar 2022
「会議は15分未満」に。小耳にはさんだ話。
ABC language (O.K.版） Advent Calendar 2022
LLVMソースコードのコンパイルをしようと思ってハマった罠とそこから脱出するための努力
ABC maker(O.K版） Advent Calendar 2022
JAXA/IPA クリティカルソフトウェアワークショップ WOCS言語関連発表(改定版)
CountdownCalendar2022 報告
関連文書(Related document)
AUTOSAR Abstract Platformへの道（詳細編）
2023年1月 記事数一覧
年末100記事を30点に仕上げる。
2023 書き初め
「はじめてのCAN/CANFD 」 ベクタージャパン ＜エンジニア夏休み企画>【読書感想文】
三方良し Udemy 車載LAN入門講座 CAN通信編
詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(1) 著者 ＜エンジニア夏休み企画 読書感想文＞
詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(2)参考文献 ＜エンジニア夏休み企画>【読書感想文】
詳解 車載ネットワーク CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために
AUTOSAR Abstract Platform User Group Weekly Report(1) 2022.1.8
AUTOSAR Abstract Platform User Group Weekly Report(2) 2022.1.15
更新資料 Abstract Platform, Vehicle Modelへの対応版
Guidelines for the use of the C++14 language in critical and safety-related systems, No.839, AP, AUTOSAR 22-11 obsolete
https://qiita.com/kaizen_nagoya/items/9d20c56c5a51c58e08e4
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20221209
ver. 0.02 URL追記 20230102
ver. 0.03 URL追記 20230203