買ってよかったC++ および 国際規格(C++ + POSIX)の公開・審議
国際規格で、Rationale(論拠)という付属書があったのは、記憶の限りでは、POSIXとC言語である。
ISO/IEC JTC1 SC7から、ISO/IEC JTC1 SC22(C/C++などプログラミング言語）へのLiaison担当時代は、審議文書は有償で発行しているDISも無償で検討する作業があった。
最終的に発行した規格、翻訳したJISは個人または組織で有償で購入していた。
この記事は、「買ってよかった技術書を紹介しよう！」
参加記事です。規格原案と発行規格の差異を確認するとともに、
SampleのExampleをコンパイルしてみています。
黄色がC言語規格。薄緑がOS。
C言語全体が対応しているのはPOSIX OS。OSEK/VDX, AUTOSAR Classic Platform(CP) OSは、C言語のFreestandingという部分集合（Subset)に対応している。
ISO/IEC JTC1 SC22 WG21では、可能な限り作業文書を公開し、幅広い意見を求めています。
一連の記事はコード断片をコンパイルできる形にする方法を検討してコンパイル、リンク、実行して、規格案の原文と処理系(g++, Clang++)との違いを確認し、技術内容を検討し、ISO/IEC JTC1 SC22 WG21にフィードバックするために公開作業をしてきました。
C++N4910:2022 Standard Working Draft on ISO/IEC 14882(0) sample code compile list
C++N4741:2018 Standard Working Draft on ISO/IEC 14882 sample code compile list
POSIXは、Open Groupで規格を公開している。審議はOpen GroupとIEEEの共同作業である。
IEEEは、ISO/IEC JTC1とA Liaisonで、規格の共同発行をしている。
ISO/IEC/IEEEという３団体共同規格のものもある。
特徴としては、IEEEはJISと同様、審議している人の名前を公開している。
ISO、IECは、審議している人の名前を公開していない。
C/C++は、DTU(Technical University of Denmark)が出資しているopen-std.orgで審議文書を公開している。規格文書はISOから発行している。
この２つ以外に、Public Available Standardという区分で、国際規格になった文書を無償公開しているものがある。
ISO/IEC JTC1の規格を公開するには、あらかじめSC Plenaryで決議をし、JTC1に具申しISO/IEC での議決が必要であった。
審議過程を公開するには、Liaison団体、共同審議団体との連名で行うとともに、
公開するWebの合意と出資者の確認があればいいような気がする。
DIS以前の審議過程の公開は、ISOの公式規格とは異なる著作権管理対象である。
審議過程の公開は、審議に協力していない団体が、その結果の審査などをしている場合には、
関係者の賛成が得られない可能性があるかもしれない。
また、ITUは、特定の最新規格以外を公開している。
<この項は書きかけです。順次追記します。>
Posix
The Open Group
The Open Group is a global consortium that enables the achievement of business objectives through technology standards. Our diverse membership of more than 800 organizations includes customers, systems and solutions suppliers, tool vendors, integrators, academics, and consultants across multiple industries.
POSIXには、当初の版はNISTからTest Suiteを公開していた。
PCTS:151-2, POSIX Test Suite
ISO/IEC JTC1 SC22
sponosred by DTU(Technical University of Denmark)
目的(purpose)
C++N3242, 2011を複数の処理系(compiler)で編纂(compile)することにより、
C++言語標準のコード断片の意味
C++言語標準の意味
処理系の標準対応状況
を把握することにより、
(1)どのC++言語機能を使うか、
(2)どの処理系を主たる用途で用い、どの処理系を検査用途で用いるか
の資料を作る
<この項は書きかけです。順次追記します。>
成果(outcome)
各処理系での対応関係が分かる。
各処理系での必要なヘッダファイル、コンパイルオプション等が分かる
手順(procedure)
一度、処理した結果をresearchmap.jpに掲載している。
https://researchmap.jp/jodlit3dy-1797580/#_1797580
Qiita側で作成した雛形に、
- 情報源から項目略称を含む見出しを複写・貼り付け
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf - 情報源の頁番号のファイル名を決め、表題、見出し項目、ファイル名欄に記載
- researchmapのURLを貼り付け
- researchmapから算譜(source code)固有の部分を複写・貼り付け
- 算譜(source code)をvi c-number.cppで保存
- c1.sh c-numberで編纂(compile)
- error を検索and/or参考資料等でなくす努力
- cppall.sh c-numberで再編纂(compile)実行(go)
- a.sh c-numberで算譜(source code)を整形し切り貼り(copy and paste)
- 実行結果を切り貼り(copy and paste)
#researchmapとの違い
- 処理系
最新の処理系を使っている。ただしvisual C++は未処理（近日中に処理予定） - 表題の文字をそのまま利用して char * msg変数に代入、出力
- main関数の戻りはreturn EXIT_SUCCESS
- errorの出ない処理への変更
- 意味のある出力の追加
必ずしも4), 5)は十分に進んでいるとは限らない。
参考(reference)
C++N4606符号断片編纂一覧(example code compile list)
C++N4606 Working Draft 2016, ISO/IEC 14882, C++ standard(1) Example code compile list
https://qiita.com/kaizen_nagoya/items/df5d62c35bd6ed1c3d43/
C++N4741符号断片編纂一覧(example code compile list)
C++N4741, 2018 Standard Working Draft on ISO/IEC 14882 sample code compile list
https://qiita.com/kaizen_nagoya/items/3294c014044550896010
コンパイル用shell script C版(clangとgcc)とC++版(clang++とg++)
https://qiita.com/kaizen_nagoya/items/74220c0577a512c2d7da
Clang/Clang++(LLVM) gcc/g++(GNU) コンパイラ警告等比較
https://qiita.com/kaizen_nagoya/items/9a82b958cc3aeef0403f
Qiitaに投稿するCのStyle例(暫定)
https://qiita.com/kaizen_nagoya/items/946df1528a6a1ef2bc0d
C Puzzle Bookの有り難み5つ、C言語規格及びCコンパイラの特性を認識
https://qiita.com/kaizen_nagoya/items/d89a48c1536a02ecdec9
どうやって MISRA Example Suiteをコンパイルするか
https://qiita.com/kaizen_nagoya/items/fbdbff5ff696e2ca7f00
「C++完全理解ガイド」の同意できること上位10
https://qiita.com/kaizen_nagoya/items/aa5744e0c4a8618c7671
Autosar Guidelines C++14 example code compile list(1-169)
https://qiita.com/kaizen_nagoya/items/8ccbf6675c3494d57a76
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
参考資料
C++N3242, 2011資料作成の覚書
Posix Test Suite docker downloads, tar, install。docker(110)
Posix Test Suite 解凍方法(Windows power shell版）
言語規格、コーディング標準の使い方
最新のC言語規格の案
言語規格、コーディング標準の使い方を間違えていて、言語規格、コーディング標準を批判している書き込みにしばしば出会う。
その人の書いているコードがいいコードであれば、その人の言語規格、コーディング標準に対する意見はどうでもいい。
白い猫でも、黒い猫でも鼠を取る猫がいい猫だという言い伝えがある。
言語規格、コーディング標準の使い方を間違えているプログラマでも、
言語規格、コーディング標準をうまく使っているプログラマでも、
いいプログラムを書くプログラマがいいプログラマだ。
言語規格(language standard)、コーディング標準(coding standard)
は、編集器(editor)、編纂器(compiler), 連携器(linker), 配置器(locator), 虫取り器(debugger),
設計環境(IDE:Integrated Development Environment)などに比べれば、作業効率への影響は多くない。
言語規格、コーディング標準に適合するだけのコードを書いていてはよいコードを書いたことにならない。
言語規格、コーディング標準は、その時代の道具類の最低限を決めるものであったり、過去との整合性を取るための文書化を促すものであったりする。
適合していることを良いとは主張していない。
よいプログラムを書いたことがない人が、言語規格、コーディング標準に適合したプログラムを書くことを強制する場合がある。
それらの人には、その方が質が落ちるときの責任を取るつもりがあるかどうかを確認するとよい。
いくつかの言語では、ほとんどの時代で、言語規格、コーディング標準は後追いで、言語規格、コーディング標準を逸脱するものがいいコードである場合がある。
たとえば、MISRA Cでは、時間制約がある場合には、コーディング標準を逸脱した方がよいコードの場合が多いため、最初から逸脱の手続きを決めている。
逸脱の手続きを知ることなく、MISRA Cを批判している人がいるのには驚き。
逸脱の数が多いほど、質のよいコードである可能性が高いことは、ある分野では有効な仮説である。
課題としては、受け取る側の技術力が低いと、逸脱の手続きを理解できず、言語規格、コーディング標準に適合したコードをという場合があるかもしれない。
技術力が低い顧客には、高いお金を吹っかけるのが一つの解決策かもしれない。
技術者のやる気をなくすのだから。
課題は、逸脱をきちんと文書化しても、その費用を払おうとしない顧客がいることかもしれない。
違法？
言語規格、コーディング標準は、よりよい言語を作るための出発点であって、守るとよいことを書いたものではない。
法体系では、WTO/TBT協定、日本工業標準化法が根拠である。
これらの体系では、国際規格、日本工業規格との違いがあれば、違いを明記することを推奨している。MISRAで言えば、逸脱の手続き。
守ることがいいことだと法的に主張していない。
「違法」という概念は存在しない。違法という用語を使っている人は、言語規格、コーディング標準の誤解を増幅させたい意図があるのか、その習慣に浸かってしまっているか、どちらとも気がついていない段階なのかのいずれかなのかもしれない。
法律というものを知らないのかもしれない。
法の適用に関する通則法第3条（法律と同一の効力を有する慣習）
第三条 公の秩序又は善良の風俗に反しない慣習は、法令の規定により認められたもの又は法令に規定されていない事項に関するものに限り、法律と同一の効力を有する。
民法第92条
法令中の公の秩序に関しない規定と異なる慣習がある場合において、法律行為の当事者がその慣習による意思を有しているものと認められるときは、その慣習に従う。
商法第1条
２ 商事に関し、この法律に定めがない事項については商慣習に従い、商慣習がないときは、民法 （明治二十九年法律第八十九号）の定めるところによる。
逸脱(deviation)
たとえば、
//コメントを使うなというMISRA Cに対して、
日本が決めたVerilog HDLのスタイルガイドでは、
/* */コメントを使わずに//コメントを使えと決めている。
MISRA Cを決めたヨーロッパのメンバに聞くと、
自分たちは、最初から標準逸脱で
//コメントを使うことを決めているという。
日本では、
Verilog HDLでは//を使い
Cでは/* */を使うというねじれをおこしていても、
全体で//を使うということを決めていたのは、自分たち含めて極少数だった。
自動車関係のソフトウェアの日本での遅れがあるとすれば、言語規格、コーディング標準の使い方に顔を出していたのだろうか。
MISRA C 2012のTechnical Corrigendum 1の21.X訂正意見はすべて日本からだった件
https://qiita.com/kaizen_nagoya/items/152c1de26b0831c02f41
からすると、日本は一部の進んだ人たちと、その他に分類できるのかもしれない。
分析(analysis)
IT業界では、分析手法を体系的に教育したり、訓練することがあまりない場合がある。
設計意図からの逸脱があった場合に、どう対応するかを、致命度、頻度に応じて検討し対策を考えておく。
分析と設計は作業の両面で、設計は分析しながらするとよい。
作業標準などで別に定義している場合があるのは、使う技法、ソフトが違う場合があるからかもしれない。分析技法と設計技法、分析ソフトと設計ソフトが一体になっているのが統合開発環境だと思うとよいかも。その意味では、分析の機能が弱いのかも。
道具としての最近の提案は下記。
安全分析の図的表現方法、及び設計文書と親和性の高いツールの提案
ガイオ・テクノロジー（株）技術開発本部 技術戦略室 技術戦略グループ 田中 伸明 名古屋市工業研究所 小川 清
https://www.gaio.co.jp/newslist/anzen_org2019/
編纂(compile)
どうやって MISRA Example Suiteをコンパイルするか
https://qiita.com/kaizen_nagoya/items/fbdbff5ff696e2ca7f00
言語規格、コーディング標準のコード断片は、日本ではすべてコンパイルして議論しているのが背景にあるのかもしれない。
Autosar Guidelines C++14 example code compile list(1-169)
https://qiita.com/kaizen_nagoya/items/8ccbf6675c3494d57a76#_reference-3a2b9cfd1b05f6a444c2
ISO/IEC TS 17961:2013 C Secure Coding Rules(1) All list(to be confirmed)
https://qiita.com/kaizen_nagoya/items/54e056195c4f11b850a1
C++N4741, 2018 Standard Working Draft on ISO/IEC 14882 sample code compile list
https://qiita.com/kaizen_nagoya/items/3294c014044550896010#_reference-f497f51f139bf9b5b948
C++N4606 Working Draft 2016, ISO/IEC 14882, C++ standard(1) sample coding list
https://qiita.com/kaizen_nagoya/items/df5d62c35bd6ed1c3d43/
C++N3242, 2011 sample code compile list on clang++ and g++
https://qiita.com/kaizen_nagoya/items/685b5c1a2c17c1bf1318
参照(reference)
すべての参照文献を最新に更新しているのも日本の貢献だったりする。
MISRA-C 2012 Referenceに掲載している文献の入手可能性を確認
SEI CERT C++ Coding Standard AA. Bibliography 確認中。
データサイエンティストの気づき!「勉強して仕事に役立てない人。大嫌い!!」『それ自分かも?』ってなった!!!
N2176 Programming Language C2018 (aka C2017)
を整理しようとして、少し放置していた。
<この項は書きかけです。順次追記します。>
最新のC言語規格の案は
N2731, 3.14 memory location
original:
古い作業
C言語国際規格 ISO/IEC 9899 C2011原案N1570 コンパイル例
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.