＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

なぜ「ＧＯＴＯ文」を使っては、いけないのですか？

«前のページへ 4|5|6|7|8|9|10|11|12|13|14 次のページへ»
投稿者投稿内容
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-04-27 15:33
引用:

Jittaさんの書き込み (2004-04-27 12:59) より:
・それが経験に基づく先人の知恵である。

非常に表現が難しいですが、
「先人の知恵」は伝達され易い様にキーワード化され点の状態にあると思います。
ただ、点はどの方向にも線が引けてしまう問題を含み、それが
「場合によりけり」的な発言になっていると考えます。

今となれば、「グローバル変数」は議論の結果、思いもよらずパターン化が出来ました。
不充分だと感じた方は、もっと高度なパターン化を望まれている方と思いますし、
また、パターンの方向性に違いを感じとった結果、自分のアーキテクチャ方針が他の人と
異なる事を実感した人もいるのでは無いでしょうか？

今は、ネットワーク技術向上の結果、物理的な情報伝達を阻害する物が減り
先人の知恵を点の状態にして置く必要性は、ある程度薄れたと考えます。

これからは、論理的な情報伝達を阻害する物。
つまり「考え方」を変えなければ行けないと考えます。

今回の議論は、点の知識を線の知識に変換する物と考えて頂ければと思います。
そして、点の数が減り、線が数が増えたとき、
アーキテクチャーの議論が活発になると考えています。
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2004-04-27 16:28
るぱんです。

個人的な意見です。
「先人の知恵」は点で良いと考えています。

そこから「なんで？」って思えれば、線にできるからです。
ただ、その、「線」にする作業をいっしょにやってくれる人が
ネット上に居つづければ問題ないのかな？と。

特定の個人ではなく、不特定多数の共同作業者が・・・。と言う意味です。

「線」の状態で置かれていても初心者にはみずらいものでしょうし、
「点」を「線」にする作業が「経験」なのではないでしょうか？
コブラ
ぬし
会議室デビュー日: 2003/07/18
投稿数: 1038
お住まい・勤務地: 神奈川
投稿日時: 2004-04-27 17:26
おぉぉっ・・・Jitta氏のこのコードは！！
思わず首を２回縦に振って頷いてしまいました。

これを応用したら、オペレーティングシステムのタスク切り替え機構が・・・
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-04-27 17:28
引用:

Beatleさんの書き込み (2004-04-27 13:14) より:
このような低級命令（マシン語に近い）をアプリに入れると一般的には読みにくくなります。
　　　：
　　（中略）
　　　：
読みやすさ、判りやすさを絶対視するならGOTO、jump等の、低級命令はできるだけ避ける
事です。（もちろん使わなければならない場合もありますが。）

Beatleさんの発言をヒントにして、

ＧＯＴＯ文の問題は、表現の柔軟さにあるのでは無いでしょうか？

ＧＯＴＯ文が「処理を飛ばす／戻る／繰返す／処理を呼ぶ／処理中断」の
どれを示すのか判断する事が面倒であり、またその結果、
処理の区切が即時に判断出来ず、理解する為に頭に置くソース量が増えて
プログラムが分かり難いと感じると思いました。

つまり、その考えから対策として、
　・多重ループから抜ける場合、　　Goto exit_for_multi_loop
　・繰返処理で次行を読む場合、　　Goto read_next_record
等、ラベルにジャンプする意味を明記すると、問題が緩和されると思います。

また、超高級言語の解り易さとは、人の思考に近い記述が出来る所にあり、
言語制約を受けずに、思考を記述が出来る事にあると考えました。

つまり、思考パターンを網羅出来ていない言語では
それをサポートする為に低級命令は必要と考えますし、
無理して言語仕様に合わせた処理文より
思想パターンに合わせたＧＯＴＯ文の方が良いとも考えれます。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-04-27 17:50
引用:

るぱんさんの書き込み (2004-04-27 13:27) より:

何を持って「読みやすいか」？
を明示的に定義しないと意味がないと思います。

　私の 2004-04-27 12:59分でどうです？
引用:

１．処理の実行手順が整理されている
２．プログラムの流れがドキュメントに整理されて記述されている
３．ドキュメントとソースが一致している
４．ソース上の箇所を容易にドキュメント上で探すことができる
　　または、質問がある都度、すぐにドキュメントを示すことができる
５．この２つをいつまでも（システムが代替わりするまで）自分で保守できる

１，２は、つまり仕様書のことです。３は、書いたコードが仕様書と一致しているという、当たり前のことです。１〜３までが満足されているなら、４の前半が満足されるはずです。ここで一致していないことがあるから、後半を条件に追加しています。そして、システムは「作りっぱなし」ではないでしょうから、５が重要となってきます。


　システム全体のどの部分であっても、goto、つまり*流れを無視するようなこと*をすると混乱します。たとえば、何らかの関わりのある入力は、１つの画面で入力できるようにまとめないでしょうか。もちろん、「概要−詳細」などの場合は複数の画面に分かれるでしょうが、それは「gosub」などの関数呼び出しに喩えます。「goto」は、１連のデータを、複数の画面で無秩序に入力することに喩えます。「while」は、１ページ内をスクロールできることに喩えます。あちらこちらへジャンプする（画面が分割されている）なら、とても使いづらいものとなるでしょう。

*流れを無視するようなこと
つまり、自然な流れで、流れを制御するのは別扱い、ということ
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-04-27 18:02
引用:

はにまるさんの書き込み (2004-04-27 14:08) より:

割込等のメインフロー以外のフローを解決する際にalarm関数と併用すると楽チンよ！

　いや、違いますって。
　引用したソースコードでalarmを使っているのは、そのまま放っておくていつまで経っても終わらないからです。signalでインターラプトとアラームのハンドラを定義して、その中でシグナル番号を返すことにより、「こうやってエラー処理を分けられる」ということを示す為のものであり、setjmp/longjmpだけならSIGINTだけでかまいません。SIGINTではなく、発生することが予想される割り込みに対して（たとえばSIGUSR1）ハンドラを用意すればいいので、alarmは便宜上のものです。

　FTPだったかな？処理し出すと止まらないんですよね。それでalarmでタイムアウトをさせするようにして、その為にsetjmp/longjmpを使ったのを思い出しました。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-04-27 18:37
引用:

Jittaさんの書き込み (2004-04-27 18:02) より:

大歩危かましていました。(誤：alram関数 →正：signal関数）
と言う事でラストチャンスを！（涙の訴え！

コード:
        (void) signal(SIGINT, signal_handler);
        (void) signal(SIGALRM, signal_handler);

これで今後、自動的に指定シグナルの発生時に対応した関数を呼び出す定義を
していると認識しています。

また、alarm関数で待機後に SIGALRM のシグナルが発生する事によって
コード:
        (void) signal(SIGALRM, signal_handler);

で定義された signal_handler関数が呼び出され
コード:
        if ((returned_from_longjump = setjmp(env)) != 0)

に制御が戻り、
コード:
            switch (returned_from_longjump)     {

の判断で
コード:
              case SIGALRM:
                printf("longjumped from alarm %d\n",SIGALRM);
                break;

が実行され待機終了を知らせる。
と、前回ここまで理解はしましたが、

正直SIGINTとSIGUSR1（ユーザ定義のシグナル？）が
何で発生するか解りませんでした。

ん？見なおすと
コード:
          printf(" waiting for you to INTERRUPT (cntrl-C) ...\n");

Ctrlキー＋Cで SIGINT が発生する？？？？？

以上で如何でしょう？正解？不正解？
なんだか、「Ｃ言語に挑戦コーナー」になってしまった。
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2004-04-27 18:37
引用:

Jittaさんの書き込み (2004-04-27 17:50) より:
引用:

るぱんさんの書き込み (2004-04-27 13:27) より:

何を持って「読みやすいか」？
を明示的に定義しないと意味がないと思います。

　私の 2004-04-27 12:59分でどうです？
引用:

１．処理の実行手順が整理されている
２．プログラムの流れがドキュメントに整理されて記述されている
３．ドキュメントとソースが一致している
４．ソース上の箇所を容易にドキュメント上で探すことができる
　　または、質問がある都度、すぐにドキュメントを示すことができる
５．この２つをいつまでも（システムが代替わりするまで）自分で保守できる

１，２は、つまり仕様書のことです。３は、書いたコードが仕様書と一致しているという、当たり前のことです。１〜３までが満足されているなら、４の前半が満足されるはずです。ここで一致していないことがあるから、後半を条件に追加しています。そして、システムは「作りっぱなし」ではないでしょうから、５が重要となってきます。

るぱんです。

仕様書が殆ど存在していない現場で旧システムの仕様書とリプレイス案の仕様書を書いている身の上ですので、仕様書が有れば・・・と言う条件で納得です。

ただ、経験が少ないせいか、今少し納得しきれていない所です。
そこで、わかりやすいソースコードってどんなもの？と言うスレを立ててみました。

是非是非書き込みしてみてください。宜しくお願いします。
«前のページへ 4|5|6|7|8|9|10|11|12|13|14 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）