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

コブラさんの書き込み (2004-04-26 18:16) より:
このレベルでは、もうソースが読みにくい＝「必ず読みやすく書く」という個々人の主観が
ある方向に集束した「理想」云々以前に、ある概念を実現する仕組みとして必ず
「やらなければならない」レベルのもので、ここで他人の読みやすさまで考慮していると、
マルチタスクでコンピュータが動かなくなる、致命的な問題に飛び火する事になるでしょう。

はにまるさんの書き込み (2004-04-26 17:47) より:

setjmp/longjmp って データベース で言うロールバッグ機能と同意義では無いでしょうか？

MSDNより：
一般に、これらの関数は、通常の呼び出し規約や復帰規約に従わずに、以前に呼び出したルーチンのエラー処理コードまたは回復コードに実行制御を渡すときに使用します。

Solaris 2.5.1 setjmp(3C)より：
These functions are useful for dealing with errors and
interrupts encountered in a low-level subroutine of a pro-
gram.

コード:

#include <stdio.h> #include <setjmp.h> #include <signal.h> #include <unistd.h> jmp_buf env; static void signal_handler(); main() { int returned_from_longjump, processing = 1; unsigned int time_interval = 4; if ((returned_from_longjump = setjmp(env)) != 0) switch (returned_from_longjump) { case SIGINT: printf("longjumped from interrupt %d\n",SIGINT); break; case SIGALRM: printf("longjumped from alarm %d\n",SIGALRM); break; } (void) signal(SIGINT, signal_handler); (void) signal(SIGALRM, signal_handler); alarm(time_interval); while (processing) { printf(" waiting for you to INTERRUPT (cntrl-C) ...\n"); sleep(1); } /* end while forever loop */ } static void signal_handler(sig) int sig; { switch (sig) { case SIGINT: ... /* process for interrupt */ longjmp(env,sig); /* break never reached */ case SIGALRM: ... /* process for alarm */ longjmp(env,sig); /* break never reached */ default: exit(sig); }) }

はにまるさんの書き込み (2004-04-23 11:22) より:

　あなたの答えは、今年技術者になった方の為の返答です。
　あなたの答えは、基礎技術を飛ばしてきた方の為の返答です。
　あなたの答えは、これから設計者を目指す方への基本的アドバイスです。
　あなたの答えは、小難しい技術論に追われ簡単な説明を忘れた方の為の返答です。

では、教えてください。
なぜ「ＧＯＴＯ文」を使っては、いけないのですか？

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

結局、現在の「簡単に表現する」とは、表現が悪いですが伝わり易い表現を用いると
「バカでも開発出来る」構成にする事では無いでしょうか？
つまり、関数の構成は１番、管理方法も１番です。

はにまるさんの書き込み (2004-04-27 11:59) より:
　　　１．バカでも開発出来る構成にする場合

　　　　　(1)システム内の端数処理は四捨五入に統一
　　　　　(2)システム内の除算で除数が０の場合、０を返す。

　　　　　Function 除算関数 (被除数,除数) AS Long


　　　２．端数処理、０除算を明示指定しないとエラーにする構成にする。

　　　　　Function 除算関数 (被除数,除数,端数処理区分,０除算エラー区分) AS Long
　　　　　　　　　　　　　　　：
　　　　　　　　　　　　　　　：
　　　　　　　　　　　　　　　：
結局、現在の「簡単に表現する」とは、表現が悪いですが伝わり易い表現を用いると
「バカでも開発出来る」構成にする事では無いでしょうか？
つまり、関数の構成は１番、管理方法も１番です。

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