MISRA C/C++, AUTOSAR C++, CERT C/C++とC/C++工業標準をコンパイルする作業のまとめです。

<この項は書きかけです。順次追記します。>

工業標準は、しばしば架空の仕様について議論する危険性を含んでいます。

実際に仕事で行っていることは、機密事項で競合他社に教えるわけにはいかないからかもしれません。

常に、架空の仕様と現実の仕様のせめぎ合いの中にいるかもしれません。

IT関係では、MulticsというOSの失敗と、ISO/OSIという通信仕様の失敗を例として示していることがあります。

それ以外にも、Process standardという分類では、具体的な試験仕様でないかぎり、架空の議論に巻き込まれているかもしれません。

さらに、バベルの塔のように、部分ごとに用語の整合性が取れていなかったり、OSIのように整合性を取ろうとして肥大化して実用的に使える部分が少なくなってしまうという両極端に走るかもしれません。

C言語標準、C++言語標準を検討するにあたって、
実用的なコンパイラでコンパイルするとどうなるかを確認し、
少なくとも複数種類のコンパイラで実装しているものを標準化するようにしていることが大事だと感じてきました。

セキュリティのように、実装できていないが目標としたいという規定が一部混じることはやむを得ないかもしれません。
言語そのものの信頼性を確保するために。

ただし、現在実装できていないことを、顧客に明示的に示さない限り、
仕様の出発点としての国際規格の役割を果たすことはできないかもしれません。

安全に関する視点も同様かもしれません。

ただし、計算機の標準化をしていないのに、プログラミング言語だけ標準化するのには無理があります。

プログラミング言語が、どのような計算機の上では動くかを示すのに、計算機の標準がない上で、言語の標準だけ完備することは、ほぼ不可能です。

例えば、レジスタ（register）に関連する扱いで、
8bit, 16bit, 32bitのレジスタを持ったCPUと、
32bitのレジスタしか持たないCPUとでは、
振る舞いが異なり、場合によっては言語に対する有利不利ができます。

＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞

いいね　💚、フォローをお願いします。

Please press the like icon 💚　and follow me for your happy life.