Linuxは、開発環境が40年前と同レベル (819ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
55: 2018/03/15(木) 10:44:40.56 ID:lnWZyj3L(1/14)調 AAS
えっ!?
外部ﾘﾝｸ[html]:www.jaist.ac.jp
>autoconf/automakeのバージョンを少し上げただけで、 それまでに作成した
>configure.inに対してautoconf/automakeを実行すると エラーや警告を生じる
>ようになる場合が多々あります。 むやみに最新バージョンをインストールし
>ないほうがよいようです。
>以降の記述でも、autoconf/automakeのバージョンによってはエラーや警告
>が発生する場合があります。
56(1): 2018/03/15(木) 10:52:04.96 ID:lnWZyj3L(2/14)調 AAS
どっちの関数があるかないかによって、自分のコードにこんなの書かされる。
片方の環境しかなければ、もう片方のテストはしないってことだよね。
#ifdef HAVE_GETCWD
getcwd(pathname, sizeof(pathname));
#else
# ifdef HAVE_GETWD
getwd(pathname);
# endif
#endif
このようなコードを何回も書くのは駄目コードだ。なぜなら、1文字でも間違って
いればバグるのに、テストも出来ないから。
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));
などの書き間違いがあったらどうなるか。
, . ; : の間違いがあるが良く見ないと分からない。
これならまだコンパイル・エラーになるだけなので
まだ良くて、一度もテストしないなら、コンパイルは通るのに、
実行段階で結果だけがおかしくなることもありうる。その場合は
もっとたちが悪い。
59(1): 2018/03/15(木) 14:49:32.28 ID:lnWZyj3L(4/14)調 AAS
>>58
頭の言いプログラマなら、別の方法を探す。
馬鹿だからその「解」が見つからない。
61: 2018/03/15(木) 15:07:39.22 ID:lnWZyj3L(5/14)調 AAS
>>60
1つの方法としては、新規に共通(互換)ライブラリを作れば良い。
上の例だと最も単純には、
1. getcwd(pathname, sizeof(pathname));
2. getwd(pathname);
の「1」の方はアプリ・プログラムでは使わずに、必ず2を使うようにする。
そして2が存在しない環境向けには、
xxx getwd(zzz *pathname) // zzz は恐らく char
{
・・
aaa = getcwd(pathname, 最大パス文字数);
・・・
}
のような感じのライブラリ関数を提供してしまう。こうしてしまえば、
autotool なんてアプリをビルドする際には全く使わなくて良くなる。
長いパス名が使える環境向けには、「最大パス文字数」を動的に可変に
する方法も有り得る。そうするには工夫が必要だが不可能なことではない。
63(1): 2018/03/15(木) 15:25:01.52 ID:lnWZyj3L(6/14)調 AAS
>>62
シンボル名の「衝突」と言っても色々な場合があり、一概には言えないが、
新しい共通ライブラリ関数は、例えば
cmn_getwd()
のように先頭に 「cmn_」を付けてしまって、アプリは、「cmn_xxx」の
方だけを使うようにすれば、衝突の心配が１つ消える。
65(3): 2018/03/15(木) 16:15:21.72 ID:lnWZyj3L(7/14)調 AAS
>>64
それは色々なやり方があるが、2つだけ書いておく:
1. そのライブラリのソースだけは、プラットフォームごとに場合分けしてしまう。
2. 何らかのツールで、関数ごとに使えるかどうかチェックし、1,0のフラグを
マクロに設定するヘッダフィルを作成し、そのマクロで#ifdefで場合分けする。
どちらの方法でも、ライブラリだけを誰かが集中的に徹底的にテストとバグ取りして、
ライブラリを作る人だけは、全プラットフォームでテストを徹底的にしさえすれば、
>>56-57 のような危険が生じる可能性を限りなく0に近づけられる。
67(1): 2018/03/15(木) 16:37:22.78 ID:lnWZyj3L(8/14)調 AAS
>>66
だったら、プリプロセッサを改良すれば良いよ。
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の方法のようにすれば、モジュール別テストの効果で
非常に安定なプログラムを作り得る。
72(1): 2018/03/15(木) 17:20:34.61 ID:lnWZyj3L(11/14)調 AAS
>>71
一応、何度も「衝突回避」と書いてあるけど、「関数が定義されているか
どうかによる場合分け」みたいなことだよね。
その部分だけは、何らかのツールを使えばよい。最も単純な物でよければ、シェル
スクリプトでもいける。コンパイラ処理系によって違ってくるが、使うライブラリ
全てについて、ライブラリアンやリンカなどでexport symbolの一覧を出して、
関数名(シンボル名)が出力されるかを調べれば良い。それは、
librarian -list_exports xxx.lib | grep シンボル名
が1文字以上の何かを出力すれば真、何も出力しなければ偽、という
様な論理で良い。それをシェルスクリプトに書けば良い。
73: 2018/03/15(木) 17:23:35.45 ID:lnWZyj3L(12/14)調 AAS
スマンが、用事があるのでしばらく抜ける。
76: 2018/03/15(木) 17:37:50.07 ID:lnWZyj3L(13/14)調 AAS
いや、実際に上司などからも、滅多にいない最高レベルのプログラマだと評されていたの
でそれはない。
77: 2018/03/15(木) 17:38:50.81 ID:lnWZyj3L(14/14)調 AAS
さらにいえば、昔から神童だと言われてきた。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.033s