Linuxは、開発環境が40年前と同レベル (819ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
57(3): 2018/03/15(木) 11:03:36.94 ID:lnWZyj3L(3/14)調 AAS
例えば、マクロ名を間違って、
#ifdef HAVE_GETCVD
#ifdef _HAVE_GETCWD
#ifdef HAVE_GET_CWD
#ifdef HAVE_GTECWD
#ifdef HAVE_GETCW
などと書いてしまったらどうなるか。このようなミスは、ヒューマンエラーなので、
頭の良さや経験や能力に関わらず、誰にでも起こりうる（なのに、エラーになら
ない。）。
また、それとは別に、例えば、その環境では
getcwd(pathname, sizeof(pathname));
の部分をコンパイラがパースすらしない場合、
getcwd(pathname. sizeof(pathname));
getcwd(pathname, sizeof(pathname)):
getcwd(pathname, sizoef(pathname)):
getcwd(pathname, sizeof(pathnmae));
などの書き間違いがあったらどうなるか。
, . ; : の間違いがあるが良く見ないと分からない。
これならまだコンパイル・エラーになるだけなので
まだ良くて、一度もテストしないなら、コンパイルは通るのに、
実行段階で結果だけがおかしくなることもありうる。その場合は
もっとたちが悪い。
65(3): 2018/03/15(木) 16:15:21.72 ID:lnWZyj3L(7/14)調 AAS
>>64
それは色々なやり方があるが、2つだけ書いておく:
1. そのライブラリのソースだけは、プラットフォームごとに場合分けしてしまう。
2. 何らかのツールで、関数ごとに使えるかどうかチェックし、1,0のフラグを
マクロに設定するヘッダフィルを作成し、そのマクロで#ifdefで場合分けする。
どちらの方法でも、ライブラリだけを誰かが集中的に徹底的にテストとバグ取りして、
ライブラリを作る人だけは、全プラットフォームでテストを徹底的にしさえすれば、
>>56-57 のような危険が生じる可能性を限りなく0に近づけられる。
69: 2018/03/15(木) 17:00:13.27 ID:lnWZyj3L(9/14)調 AAS
>>68
>プリプロセッサが改良できるならあなたが最初に上げた問題点も解決するのでは？
いや、それだけだと「>>57」の前半の問題は解決するが、後半の問題は残る。
>>65の方法を使えば、両方の問題を解決できる。モジュール別テストは強力だから。
70: 2018/03/15(木) 17:04:19.91 ID:lnWZyj3L(10/14)調 AAS
>>68
>具体的に改良点も挙げずに言われても無意味ですし
>>57の前半の問題を根本的に解決したければ、gccの前処理(プリプロセス)部分
に独自の前処理指令を追加すれば良い。
ただ、そこまでしなくても、>>65の方法のようにすれば、モジュール別テストの効果で
非常に安定なプログラムを作り得る。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.039s