Edited at

[C][C++]の国際規格案の例題をコンパイルするときの課題7つ。

More than 1 year has passed since last update.


C/C++の国際規格案は、ISO/IEC JTC1SC22の各WGが資料を公開して審議している。


標準化委員会

20190116追記 

http://www.open-std.org/jtc1/sc22/wg14/www/standards

http://www.open-std.org/jtc1/sc22/wg21/docs/standards

C/C++の標準化は、かなりの文書を公開している。


Ratonale(根拠)

C言語では当初(C1990)Rationaleという理由書も公開していた。C1999でもRationaleは発行している。

http://www.open-std.org/jtc1/sc22/wg14/www/docs/C99RationaleV5.10.pdf


Cの精神

20180224追記

C1990/C1999では、Cの精神を記載している。

ここでのプログラマは、Cコンパイラを書くプログラマ、OSを書くプログラマ、OSとコンパイラを利用して応用(application)を書くプログラマの三種類のプログラマがいることを想定しよう。


プログラマを信頼する。

Trust the programmer.

Cコンパイラのプログラマのことか、応用を書くプログラマかで意味が異なる。ここでは応用を書くプログラマとする。次の項目の前提を宣言している。


プログラマが理由があってしようとすることを妨げてはいけない。

Don’t prevent the programmer from doing what needs

to be done.

Cコンパイラは、応用を書くプログラマになるべく制約を与えないようにする。その理由がCプログラマは、Cコンパイラが提供しない機能も実現する能力があると仮定する。


言語を小さく、簡単に保つ。

Keep the language small and simple.

OSを小さく簡単に書くUnix, minix, Linuxのように小さな処理を書くには、言語も小さく簡単であるとよい。試験のしやすさもある。


1つの操作(os)には1つの方法だけを提供する。

Provide only one way to do an operation.

ここでの条件を満たそうとすると、未定義、未規定、処理系定義など、任意性が発生してしまう。しかし、一つのOS、一つの処理では、そのうちの一つの方法に限定しないと体系が保てない。


可搬性を保障できなくても高速にする。

Make it fast, even if it is not guaranteed to be portable.

CPUの高速化に対応した処理が書けれないと、CPUに同梱する言語として採用されない。CPUの高速化に追従するための機能は、ひとまず移植できるかどうか、移植したとして高速化は保留して置いてもよい。


安心(security)による方針転換

C2011では、Rationaleという文書ではなくN番号の文書を作成した。

http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1250.pdf

ここではCの精神から、安心(security)への方針転換がうかがえる。


公開

国際規格の委員でなくても、意見を申し立てることが可能である。しかし、国際規格の作成過程や、意見の申し立ての経験がないと、何をどうしたらいいかわからないかもしれない。実際のコードなら、コンパイル・実行できれば意見を出せる可能性は大きい。

実際に、C/C++国際規格案には、コード断片がたくさんある。そこで、実際にC/C++国際規格案を、1989年頃から30年近くコンパイルしてきた経験に基づいて、C/C++の国際規格案の例題をコンパイルするときの課題7つ。


課題1 どのコンパイラでコンパイルするか

C/C++コンパイラで、利用者数が多いものは試しておくとよい。

GCC/G++(GNU), CLANG/CLANG++(LLVM), Visual C/C++の3つは試しておくとよい。

それ以外に仕事で実際に使っているC++コンパイラがあれば、そのコンパイラと近いもの、遠いものを知るのに3つのコンパイラとの比較があるとよい。


未定義、未規定、処理系定義

20190116追記 

C言語規格には、未定義、未規定、処理系定義など、C言語規格で決めないことによって、CPUの発展を促すという側面がある。例えば、16bit, 32bitの違いによる未定義、未規定、処理系定義を考えるには、16bitCPU用のコンパイラを動かさないとピンと来ないことがある。

16bit CPUのコンパイラは、Cだけに限定すれば、Open Watcomを強くお薦めする。1998年当時、10種類くらいのコンパイラで、C言語適合性を確認した際に、最高得点を弾きだしたのが、Watcom Cだったと記憶している。

http://ftp.openwatcom.org/archive/11.0c/


課題2 コード断片に何をたすのか。

C++の国際規格案の例題の多くは、コードの断片である。そのため、コンパイルできるようにヘッダ、関数などの追記が必要である。

参考にするとよいのが、 C puzzle bookである。C puzzle bookはコンパイルできる形式で提供することにより、プログラマが考え始めるきっかけを与えている。

https://www.amazon.co.jp/dp/4877830294


課題3 出力確認は必要か。

C/C++でも関数は入力を出力に変換する機能。コンパイルできるだけだと、理解が進まないかもしれない。出力する関数に仕立てることが鍵。ただし、コードの断片だと、どういう処理の断片のつもりかが推測できないことがある。

ここでも参考にするとよいのが、 C puzzle bookである。これは、C言語の難しさを確認するのによい教材である。

ネットでC Puzzle Bookをよい本だと書いていない感想を見ることがある。この本の意味を理解していないからということがわかる。C Puzzle Bookは、C言語の仕様のうち、未定義、未規定、処理系定義が、出力にどのような影響を与えるかを示し、プログラマが、未定義、未規定、処理系定義とどう付き合うべきかを考えるきっかけを与えるものである。日本の一部の企業にあるような、規定を守ることが大事だというC言語の精神に反する規制をしたり、CPUの能力を最大限引き出す効率的なプログラムを否定したりする傾向への警鐘にもなっていることに気がつくとよい。


課題4 PDFファイルからのソースコードの抽出

国際規格およびその原案等はPDFファイルとして公開していることがある。PDFファイルから、ソースコードを抽出する際に、 'コードでエラーになったり、 /* /の が制御コードになることがある。今の所、手打ちで変更している。

https://researchmap.jp/jomp9wnrd-1797580/#_1797580


課題5 引用の方法

国際規格には、著作権があり、PAS(Public Available Standard)の宣言をして電子的に公開している場合であっても、その著作権を尊重した引用の仕方が大事である。国際規格名を書くだけでなく、冊子体であればページ番号も記載するとよい。

電子版であれば、検索で容易に到達できる。Kindle提供の資料のようにページ番号を打たない資料もあるかもしれない。


課題6 公開方法

引用する場合には、著作権法上妥当な引用方法であっても、商用利用の場合には、利益が出る場合には、著作物における価値計算をして、著作権料の支払いを申し出るとよい。商用利用でない場合には、学術利用であることを明記し、学術ネットワークで公開するとよい。

学術利用のつもりであっても、商用サービスで広告の掲載等がある場所での公開は、その商用サービス側と協議し、商用利用の手続きをとるとよい。


20180116追記 引用例 及び 公開方法例

https://researchmap.jp/jonadbfiv-1797580/#_1797580


20180224追記 目的と成果の項目を下記を参考に追記予定

https://researchmap.jp/jovqfzcc8-1797580/#_1797580


課題7 日本語の注釈をつけるか、英語の注釈をつけるか。

文字コードの変換、文字コード由来のコンパイルエラーを避けるために、英語の注釈を奨励します。


C/C++コンパイル一覧


C2011コンパイル一覧@researchmap

https://researchmap.jp/jownvh0ye-1797580/#_1797580


ISO/IEC 14882 C++ cpp2011 コンパイル一覧

ISO/IEC 14882 C++ standard. bit-field

https://qiita.com/kaizen_nagoya/items/e731e6d02258fe559056


CPP2011コンパイル一(下記URLから<次の記事へ>)@researchmap

https://researchmap.jp/joxl86n45-1797580/#_1797580


参考文献

C Puzzle Bookの有り難み5つ、C言語規格及びCコンパイラの特性を認識

https://qiita.com/kaizen_nagoya/items/d89a48c1536a02ecdec9

MISRA C まとめ #include

https://qiita.com/kaizen_nagoya/items/f1a79a7cbd281607c7c9

コンパイル用shell script C版(clangとgcc)とC++版(clang++とg++)

https://qiita.com/kaizen_nagoya/items/74220c0577a512c2d7da

'wchar.h' file not found で困った clang++ macOS

https://qiita.com/kaizen_nagoya/items/de15cd46d657517fac11

プログラミング言語が設計書である3つの理由

https://qiita.com/kaizen_nagoya/items/34daa0403eaca5e8b5a6

「C言語規格&MISRA-C:みんなで楽しいCプログラミング」NGK2013B名古屋合同懇親会2013忘年会昼の部

https://www.slideshare.net/kaizenjapan/ngk2013b-2013

SWESTまとめ C言語規格の断片をコンパイルすることの重要性はSWESTでもなんども推奨している。

https://qiita.com/drafts/62e56ae151554d6200c0

C2x Charter(C2x 憲章)

https://qiita.com/yohhoy/items/3e2fb952dc65e4bf2802

C17 (not C++17)

https://qiita.com/yohhoy/items/1447c8608c65023b6ad1

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


文書履歴

ver 0.10 初稿 20180114

ver 0.11 researchmap URL追記 20180221

ver 0.12 Qiita URL追記 20180324

ver 0.13 誤記訂正 20180422