5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Cでgotoを使わない理由を考察するスレ goto loop2;

1 :仕様書無しさん:03/11/30 21:49
why?

前スレ
Cでgotoを使わない理由を考察するスレ
http://pc.2ch.net/test/read.cgi/prog/1053627318/

2 :仕様書無しさん:03/11/30 21:51
2 なのか?


3 :仕様書無しさん:03/11/30 22:02
3

4 :仕様書無しさん:03/11/30 22:23
#if 0

5 :仕様書無しさん:03/11/30 23:53
#endif

977 名前:828[sage] 投稿日:03/11/30 22:36
勝手に終わらないで欲しかったのだが。

>「議論をするつもりはない」とのお考えだと判断して良いですかね。
つもりがなかったらそもそもこのスレに書き込んでいないわけですが。

>私はあなたの言う「違反者」ではありませんよ。
ですね。はじめから法の外にいるという立場のようですから。

>構造化プログラミングは万能かも知れないですが、
>全ての場合において最適解であるかというと、私は懐疑的です。
だから、いいか、悪いかではなくて
慣例、習慣、法律などの決まりごとにそって生きるのが人間で、その方が生き易い。
多少融通が効かない事はあるだろうけど、世の中の全ての人が大岡越前になれるわけではない
(と私は思っているのですが、あなたに言わせると「ご愁傷様」らしいですね。
あなたは世界中の裁判官が大岡裁きができるとお考えですか?)

でもまあ、私の経験だと、これくらいやり込められるとほとんどのナナシは
自作自演やら荒らしやらのアンフェアな方法に出る2ちゃんで、
正々堂々と意見と意見の戦いで通された事は感謝と尊敬の念を感じました。
後輩から教わった話ですが、年寄りというのは
若者に理解されない話を頑なにすることで、若者の中の新しい文化への
情熱や信念を強固にさせる役割もあるんだそうです。

いつまでも頑なな頑固ジジイであれ!>>124


6 :仕様書無しさん:03/11/30 23:56
void main();

7 :仕様書無しさん:03/11/30 23:58
>>1
おまえウザイんだよ。
もうこんな糞スレ立てんなヴォケ
ダイクストラがgoto使わない理由を証明しているなら
こんなスレイラネーだろカスが

とっとと削除依頼出して来い!

8 :仕様書無しさん:03/12/01 00:45
ぐだぐだ言わずにgotoを使わなければかけないコードを示せば議論は終わる。

9 :仕様書無しさん:03/12/01 01:03
>>8
「gotoを使わなければかけないコード」
は存在しないと数学的に証明されてるよ。

10 :仕様書無しさん:03/12/01 01:05
>>8
誰かが議論していたとでも言うような口ぶりだな。

11 :仕様書無しさん:03/12/01 01:18
まちがえた!
http://pc.2ch.net/test/read.cgi/prog/1053627318/991-994n
(誤)Dim lCnt As Long, sLoop As String, bQuot As Boolean, sNewSource As String

(正)Dim lCnt As Long, sLoop As String, bQuot As Boolean

12 :仕様書無しさん:03/12/01 02:33
goto使ったらタイーホというわけではないが、
「やだー あのひとgoto使ってる〜 ありえな〜いw」って感じか?

13 :仕様書無しさん:03/12/01 03:07
つか、C使ってる時点で
「やだー あのプロジェクトC使ってる〜 ありえな〜いw」
だろう。

14 :仕様書無しさん:03/12/01 03:09
もうgotoは秋田のでファイル/関数/データ名の名前の付け方の
MSによる謝罪と賠償を求めるのが面白いと思うのですが。


15 :仕様書無しさん:03/12/01 03:18
>>13
それは確かにw

16 :仕様書無しさん:03/12/01 03:50
>>13
おまえは、ただのアプリ屋だろゴミは氏ね!


17 :仕様書無しさん:03/12/01 03:54
>>16
うむ、>>13ではないが、日本のシェアを圧倒する国産コンパイラ、国産OSを頼む。

18 :仕様書無しさん:03/12/01 03:55
>>16
できればCPUから頼む。

19 :Mr.名無しさん:03/12/01 04:01
Σ・・・MSの配下に成り下がったTRON・・・
もう、だめぽ。


20 : :03/12/01 04:32
Y氏 好循環  I氏 悪循環  (日本)
 (健康体)  (喘息)

1.(神が喘息であるかないかを決める)
  Y        I
2.喘息でない人  喘息の人は
は体力がある   体力がない
Y I
3.        行動力、
         五感(嗅覚)が鈍り感性が変化
         する
  Y        I
4.神は異常な感性の人間は本来人に迷惑をかけるから外に出てはいけないと思っている。
Y I
5.変化なし    アトピーになる
Y I
6.正常な感性   外に出なくなりさらに異常な感         性になる
Y I
7.正常な人間    異常な人間(レッテル)

21 : :03/12/01 04:33
Y I
8. 死
  Y        I
9.      来世
Y I
10.神は異常な人間は人に迷惑をかけるので行動を抑制する必要がある
Y I
11.神は異常な人間は人に迷惑をかけるので行動を抑制する必要があると思っている。
Y I
12.神が喘息であるかないかを決める
  Y        I
13.喘息でない   喘息である
  Y        I
     1.に戻る

22 : :03/12/01 04:34
アトピー性皮膚炎の治し方

行動力=ガッツ=体力

アトピー性皮膚炎の患者は、
感覚の鈍い人間が多い。
それはなぜか。
幼少期喘息になるから、
体力がつかないため、
五感が弱るからである。
解決方法は、
五感を強くしてやればいい。
体力をつけることですぐに五感が正常になり、
行動力も湧くのである。
五感が正常になり、体力もつけば、
アトピー性皮膚炎も不思議と消えることが多い。



23 :仕様書無しさん:03/12/01 13:39
>>22
それが本当なら本にして売り出せよ。
大もうけできるぞ!


24 :仕様書無しさん:03/12/01 21:17
そういえば、世の中でgotoが使われなくなったのと
アトピー性皮膚炎が流行りだしたのは同時だな・・

25 :仕様書無しさん:03/12/01 23:12
>>24
そうだったのか!やはり人間的にはgotoを平気で使えるような
世界情勢が一番だとゆう漏れの学説が正しかったんだなw


26 :仕様書無しさん:03/12/01 23:53
中級者レベルぐらいだとgoto使う以上にベターなコーディングを思いつかない
ことも多いと思うよ。で、その中級者が職場では一番レベルが高いということも
多いので、goto使わないベストなコーディング方法を教えることが出来る人が
いない。

goto使うときってこういうときでしょ。

27 :仕様書無しさん:03/12/02 00:04
なに言ってんだコイツ?

28 :仕様書無しさん:03/12/02 00:30
そっか。アトピーには goto 療法が効くのか。
おい、だれか学会に発表しろ。ノーベル賞ものだぞ!


29 :仕様書無しさん:03/12/02 00:50
アトピー以外にインポを初めとしてあらゆる性病には
有効らしいぞ。


30 :仕様書無しさん:03/12/02 01:27
>>22
なんだか本当に、それで直りそうな気がするw

31 :仕様書無しさん:03/12/02 01:41
とりあえず、goto使うやつにアトピーはいないって事か?

32 :仕様書無しさん:03/12/02 02:50
>>31
チョツト違うな、gotoも使えないゴミはアトピーになるんだよ!!!


33 :仕様書無しさん:03/12/02 03:26
>>26
いい加減なこと言うな。

34 :仕様書無しさん:03/12/02 06:10
多重ループから抜けるときgoto以上に分かりやすいものがあれば教えてください

35 :仕様書無しさん:03/12/02 06:20
>>34
ラベルbreak

36 :35:03/12/02 06:21
違った、無い。

37 :仕様書無しさん:03/12/02 07:11
>>34
そんなちょこざいな便利さなど問題じゃないよ。
goto使えば、逆に多重ループの内側に飛び込めたりもするわけで、
コーディング規約に、gotoのこの使い方は良いとかこれは悪いとか、
いろいろ規制を設けないといけなくなる。めんどいでしょ?
要はイリーガルな使用ができるステートメントは省くべきということでは?

38 :仕様書無しさん:03/12/02 07:15
>>34
多重ループなんか作るな。再考しろ

39 :仕様書無しさん:03/12/02 07:45
>>37
規約には「ループからの脱出時のみ可」とでも書けばいいんじゃないですか?

40 :仕様書無しさん:03/12/02 09:54
>>37
×要はイリーガルな使用ができるステートメントは省くべきということでは?
○要は解析性が極端に低下する使用法が可能なステートメントは省くべきということでは?
「イリーガル」という形容は間違いだろう。


41 :仕様書無しさん:03/12/02 09:59
>>34 return

42 :仕様書無しさん:03/12/02 10:25
>41
同一関数内では利用できない

43 :仕様書無しさん:03/12/02 10:40
>>40
100行以上などの長大な関数がかけてしまうC言語も使用を避けるべきですな!

44 :仕様書無しさん:03/12/02 10:42
>>43
関数長すぎるとエラー出す言語ってあるの?

45 :仕様書無しさん:03/12/02 10:47
VCでは関数が長すぎると、IDEがスクロールしにくくなる。

46 :仕様書無しさん:03/12/02 11:22
>>44
無いと思うよ。ネストの上限が5っていう言語なら見たことあるけど。

47 :仕様書無しさん:03/12/02 12:39
>>44
goto使うとエラー出るの?

48 :仕様書無しさん:03/12/02 13:08
>>47
おまえの頭がエラーだわなw

49 :仕様書無しさん:03/12/02 13:19
>>37
そうだな、よし!
switch 〜 case も危険だから使用禁止にするぞ!

  switch (id) {
    int i=0, j=0;
    for (i=0; i<n; i++)
      for (j=0; j<m; j++) {
        :
        :
  case 0:
        :
        :
      }
  case 1:
    :
    :
  }


50 :仕様書無しさん:03/12/02 14:58
>>49
C言語では、idなどという曖昧な変数名を使用できてしまい解析性が著しく低下して
しまうので、変数の使用はそもそも禁止されてるんじゃないかな?
だって、いろいろ規制を設けないといけなくてめんどくさい場合は、禁止するらしいから。

まぁ、結果として、switchも使えないから安心してちょ。

51 :仕様書無しさん:03/12/02 17:26
>>50
実に論旨不明瞭だな。
>idなどという曖昧な変数名を使用できてしまい解析性が著しく低下してしまうので
「idという変数名を使用することが、解析性が著しく低下する原因」というわけじゃないぞ
そんなことで解析性が低下すると思っているのは、すでに十分に解析性が低い証拠だ。

52 :49:03/12/02 18:02
>>51
いや、だって id ってグローバル変数ですよ!?

53 :仕様書無しさん:03/12/02 18:04
>>51
ええと、
『どんな変数名(例えば意味づけの曖昧な変数名)を使っても、「解析性が著しく
 低下する原因」となる可能性は無い』
という主張?

54 :仕様書無しさん:03/12/02 18:08
あぁ、しかも>>51には、変数宣言以外にも、「解析性が著しく低下する原因」となる
C言語の特性が存在することが示唆されているな…。なんか、どんどん使える範囲が
狭まっていく…

55 :仕様書無しさん:03/12/02 19:42
>>37
おまえのところは、コードのレビューもせずに
個々のPGが勝手にコード書いてるのか?

56 :仕様書無しさん:03/12/02 19:56
っていうか、おまいら何で今時「C言語」の話題なんだ?
しかもいまさらgoto論なんて、時代錯誤もいいとこだな。
おまいらどうせ学生だろ?
いまどきCやってる奴なんて、学校関係者ぐらいのもんだからな。
教育現場では頑なに UNIX + C だからなw

57 :仕様書無しさん:03/12/02 20:27
>56
おまいの発言が一番学生っぽいぞ。
それともよっぽどちんけな仕事しかしたことないのか?

58 :56:03/12/02 20:41
>>57
チンカスで悪かったな! この道程・モーほーお宅野郎!

59 :仕様書無しさん:03/12/02 21:23
>>58=>>56はチンカスらしい。
自分で言ってるぐらいだからな

60 :仕様書無しさん:03/12/02 22:49
>>52
グローバル変数は使用禁止だ。したがって命名は無関係だ。

>>53
>『どんな変数名(例えば意味づけの曖昧な変数名)を使っても、
>「解析性が著しく低下する原因」となる可能性は無い』?
no

>>54
yes。自分でもそう思っているんだろ。
>どんどん使える範囲が狭まっていく…
俺が「使用禁止にすべき」だと思うのは「グローバル変数」だけだけど。

61 :仕様書無しさん:03/12/02 22:54
でもC++ってグローバル定数とグローバル関数(API)だらけでぐちゃぐちゃだよね。
入力支援ない上に名前長すぎて覚えられないよ。
どうやって覚えてるの?語呂合わせ?

62 :仕様書無しさん:03/12/02 23:04
>>55
どうやったらそういう解釈になるのかさっぱりわからんが。。。
個々のPGがコーディング規約に沿って勝手にコード書いた後、
コードレビューしてるけど。


63 :仕様書無しさん:03/12/02 23:18
つまり、コードを評価する能力がないということか。

64 :仕様書無しさん:03/12/02 23:23
>>61
#C++は、ベンダによってライブラリセット(表現おかしい?)の方言が激しいって聞いたけど、
#その悩みはこの方言(ベンダ固有)が理由なのかなあ。
残念ながらここはcがテーマなんだ。

65 :仕様書無しさん:03/12/02 23:30
>>60
グローバル変数使用禁止の理由教えて。俺は命名こそが大事だと思うんだが。
クラスだって巨大化すれば、メンバ変数もグローバルみたいなもんだよ(笑

>>61
STLもMFCもJAVAも、大概はヘルプやレファレンスやサンプル見ながら書くよ。
経験つめば次第に覚えるんだろうけど、他人が作った関数やクラスを利用
するんだから、全部を頭に入れるのは難しいよね。


66 :49:03/12/02 23:32
>>49 >>50 >>52 がネタだってことに
いい加減気付いて欲しいなぁ…
因みに、>>49 みたいな事が出来るのはマジ。

ところでさ、「コードレビュー」ってどういうメリットがあるの?

67 :仕様書無しさん:03/12/02 23:35
>>65
でもさあ。コントロール用のIDC_HOGEとか、メニュー用のIDM_HOGEとか、
あれをなんでグローバル宣言するの?
1つの「物」についてあっちこっちにソースが分散して気持ち悪いよ。
取ったり付けたりする時に追跡しきれる?

68 :仕様書無しさん:03/12/02 23:36
グローバル変数はちょっとなあ・・・

どこででも直にアクセスできるのは値を保証できないからダメだろ。
絶対に値をロックしないし、どこからででもアクセスできなきゃ困るとかいう
珍しいパターンでもない限り出番がない。

あとクラスが巨大化するのは設計自体が間違っていると思われ

69 :仕様書無しさん:03/12/02 23:36
>>63
お宅の思考回路は理解できん。

70 :仕様書無しさん:03/12/02 23:40
>>60
> >>53
> >『どんな変数名(例えば意味づけの曖昧な変数名)を使っても、
> >「解析性が著しく低下する原因」となる可能性は無い』?
> no

変数の名づけ方によっては「解析性が著しく低下する原因」になり得るんだよね?
>>37, >>40の基準によるならば、変数宣言も省かなければならないのでは?という皮肉。
分かってると思うけど。

71 :仕様書無しさん:03/12/02 23:49
>>67
>でもさあ。コントロール用のIDC_HOGEとか、メニュー用のIDM_HOGEとか、
>あれをなんでグローバル宣言するの?
んなこたぁ MS に聞けば?
C++ の問題じゃない事くらい判らない?

72 :仕様書無しさん:03/12/02 23:53
定数は別に重ならなきゃOKだろ。じゃなきゃ、クラスもグローバル領域に宣言するのも
ダメということになる。
(分散オブジェクト環境みたいにいちいちネームサービスから探すか?)

73 :仕様書無しさん:03/12/02 23:56
>>66
個人が書いたコードをみんなで検証するとバグの早期発見とか、あと勉強にもなるよ。
>>67
コントロールIDはdefineだよ。IDは普通、一意の方が良いよね。
>>68
そこを命名によって、他モジュールから参照されるもの、
自モジュールのみから参照されるものというように分ければ良いんだよ。
もちろん変数だけでなく、関数もだけど。
そのへんきちんとすれば、Cでもオブジェクト指向的なコードが
書けると思う。

74 :仕様書無しさん:03/12/03 00:01
>自モジュールのみから参照されるものというように分ければ良いんだよ。
要するにネームスペースやスコープ制御ができないCがクソということで。

75 :60:03/12/03 00:02
>>70
yes
正確には「変数名」に限らず、(命名を行う)全ての識別子。

76 :仕様書無しさん:03/12/03 00:05
んじゃ、識別子の命名は解析性が著しく低下する原因にならなければ行ってOK、と。
ということは、「グローバル変数は確実に解析性が著しく低下する原因になる」ということですね?

77 :仕様書無しさん:03/12/03 00:06
>>73
>そのへんきちんとすれば、Cでもオブジェクト指向的なコードが
>書けると思う。
それは単なるカテゴライズであって
カプセル化ですらなく
まして OOP とは無関係。

78 :仕様書無しさん:03/12/03 00:09
読み易さ
 goto >>>>>>>>>> 関数ポインタ

79 :仕様書無しさん:03/12/03 00:17
無名関数とクロージャがほしい

80 :仕様書無しさん:03/12/03 00:19
>>73
モジュール内のグローバル変数(ファイルスコープ)の危険性は無視ですか?

81 :仕様書無しさん:03/12/03 00:23
>>74
まあ「cがクソ」と断じるのは勝手だが、
同様な理由で「C++がクソ」と言われる時期もいずれくると思っていたほうがいい。
いくらソフトウエア工学的理論が発達し、それをサポートする言語処理系が出来たとしても、
コンピュータがチューリングマシンの写像であることは当分変わらないのだから、
アセンブラレベルの理解が可能なcをマスターしておくことは無駄ではないと思うが。

82 :仕様書無しさん:03/12/03 00:24
すでにC++はクソだってことは有名だが

83 :仕様書無しさん:03/12/03 00:26
なるほど〜。MSが悪いだけかあ。
言語仕様上そうしなきゃいけなかったのかと思った。

84 :仕様書無しさん:03/12/03 00:40
変数の副作用が怖ければ、関数型言語でも使ってろよ!
チューリング等価だぜ。

85 :仕様書無しさん:03/12/03 00:46
>>81
オブジェクトがどう振舞うかを記述する作業の中で、
アセンブラ云々を意識すると本質を見失う可能性あり。

86 :60:03/12/03 00:48
>>76
yesだ。「くどいな」と感じたが、ちゃんと私見を書こう。
>「グローバル変数は確実に解析性が著しく低下する原因になる」?
グローバル変数を使用することによってコーディング工数を低減させることは可能だ。
「解析性が著しく低下する」ことなしに。
しかしこれには「常人の短期記憶の容量を超えない範囲での使用」という条件がつく。
グローバル変数の使用を許可しても「常人の短期記憶の容量を超えない範囲での使用」
という条件を守られない場合の方が多い。これは「確実に解析性が著しく低下する」わけだ。
以上が解析性のみに限った話。
グローバル変数の使用は、解析性に限らず生産性/保守性全般に悪影響を及ぼす。

87 :仕様書無しさん:03/12/03 00:55
>>77
なんで?呼ばなければカプセル化と一緒でしょ?
private関数をコンパイル通る通らないに関係なく、外から呼ぼうとする人って
あまりいないよね。つまりはprivateだよ、publicだよって(命名規則で)印つけとけば
カプセル化はできる。

それでも外から呼んじゃうようなスキルの低い人にも絶対呼ばせないように、
OOPが登場してきたわけだ。コンパイラ様々。君はオブジェクト指向言語に
足向けて寝ないように(笑


88 :81:03/12/03 00:56
>>85
そりゃそうだ。
クラス設計時にアセンブラレベルまで意識できる人間なぞ俺はしらん。また意識する必要もない。
#設計作業群は多層構造だ。

89 :仕様書無しさん:03/12/03 01:02
>>87
情報の隠蔽用にクラスを作っているのなら、
オブジェクト指向の考え方を勉強することをお勧めする。

90 :仕様書無しさん:03/12/03 01:03
>グローバル変数の使用は、解析性に限らず生産性/保守性全般に悪影響を及ぼす。
「常人の短期記憶の容量を超えない範囲での使用」をしている準グローバルな変数、
つまりインスタンス変数やクラス変数、モジュール変数(ファイルスコープ)などにも
全て問題があると?

まぁ、関数型言語の参照透過性の節には、それが破れることによる害悪が延々と
書いてあるわけだけども…

91 :仕様書無しさん:03/12/03 01:04
>>89
はじめはそれだけでも良いんじゃない?

92 :仕様書無しさん:03/12/03 01:05
>>30
goto文なんかばかり使ったコード読まされたら
アトピーになったような不快な気分を味わうってことだろ

93 :仕様書無しさん:03/12/03 01:05
>>89
誰もそんなことは言ってないし…

94 :仕様書無しさん:03/12/03 01:06
>>93
いや、87はOOPの意義を履き違えてるだろ。

95 :仕様書無しさん:03/12/03 01:07
gotoを解禁してからというもの、これは便利だなぁと実感するようになったけど、やばいかな。

96 :仕様書無しさん:03/12/03 01:08
>>92
つまり、goto否定原理主義者は、「先天的に」gotoに対するアレルギー体質を持っており、
gotoを使うことの可否に関わらず、必ず症状は出てしまうわけだ。
まぁ、ちょっと可哀想では有るがな…

97 :仕様書無しさん:03/12/03 01:09
>>87
ファイルスコープなら、staticにしとけば大抵自動的にガードできるだろ。

98 :仕様書無しさん:03/12/03 01:10
>>94
概念と実装を混同してない?

99 :仕様書無しさん:03/12/03 01:15
private/publicの区別をつけないとOOP出来ないわけでもなかろう。
(もちろん、アクセスの制限をつけるのは有用ではあるが)

100 :仕様書無しさん:03/12/03 01:17
100ゲット

101 :仕様書無しさん:03/12/03 01:23
>>86

いってることはもっともだが、プログラムの保守は他人がやるケースも多い。
「常人の短期記憶の容量」といっても難しいんだよね。

常識外れのアホプログラマーがガンガン問い合わせのメール送ってくることも
あるから、それを避ける意味でもグローバル変数は避けるのがよい。

自分を守るためにも。

102 :60:03/12/03 01:27
>>90
yes
#どうもC++屋が多いな。スレタイの言語はcなのに。

103 :仕様書無しさん:03/12/03 01:28
今時珍しいストイックな人だな。

104 :86:03/12/03 01:32
>>101
賛成。グローバル変数は使用禁止。
ただ「禁止」って言ってもグローバル変数に泣かされた経験のない人間には
少し細かく説明した方が良いと思ったから書いただけです。

105 :仕様書無しさん:03/12/03 01:38
>>89,>>94
>>93が代弁してくれてるが、誰もそんなこと言ってないよ。
命名、カプセル化と、発言の経緯をみてごらん。

で、いちいち反論するのもつかれてきたのであとご自由に。
...とか書くとえらい攻撃されそーで恐いが(笑


106 :仕様書無しさん:03/12/03 01:41
グローバル変数を禁止させたかと思ったら、巨大な構造体(グローバル変数っぽい
メンバが詰まってる)を全ての関数の引数に付けられたりして…

107 :仕様書無しさん:03/12/03 01:47
まあ、おまいらがそうでも良いアプリケーションを書いている
裏側では膨大なグローバル変数が使われている訳だが。


108 :仕様書無しさん:03/12/03 01:50
裏側のソースなんて読まないし、自分には責任ないんでOK!

109 :仕様書無しさん:03/12/03 01:50
>>106
たまにそういう超弩級馬鹿がいるな・・・。

110 :仕様書無しさん:03/12/03 01:50
>>106
実際、それに近いコードに出会ったことある。
しかも関数(の作者)ごとに微妙に引数名が違ってて検索するのにも一苦労だったなぁ。

111 :仕様書無しさん:03/12/03 01:51
あと、引数の数がむちゃくちゃ多くて、それらを全部、ほとんどの関数で持ち回りしてるとか…

112 :仕様書無しさん:03/12/03 01:55
しかもポインタで渡してて、内容書き換わって返って来るから最低。
全部の関数がvoidになってたときには爆発した。

113 :仕様書無しさん:03/12/03 01:56
>>110
引数名が一致していることなぞ期待するのが誤りだ
そんなときは型名で検索するのが普通なのではないか

114 :仕様書無しさん:03/12/03 01:58
ここにもコードレビューを実施すべき理由が

115 :仕様書無しさん:03/12/03 02:01
>>113
それじゃぁ、関数定義の先頭しか引っかからないし。

116 :仕様書無しさん:03/12/03 02:06
スレッド処理はむしろグローバル変数の方が扱いと思うけどね。
静的領域にあるのに下手に隠蔽されているとどつぼにはまる。
他人が書いたコードの保守ならなおさら。

117 :仕様書無しさん:03/12/03 02:12
>>116
扱いやすいのか扱いにくいのかきちんと書いてくれ。

118 :仕様書無しさん:03/12/03 04:32
>>34
ラベルつきcontinue
ラベルつきbreak

try-catch 内で 多重ループ内でthrow new なんたらException();

なんたらException()でcatch

119 :仕様書無しさん:03/12/03 04:34
>>65
> >>60
> グローバル変数使用禁止の理由教えて。俺は命名こそが大事だと思うんだが。
> クラスだって巨大化すれば、メンバ変数もグローバルみたいなもんだよ(笑
藻前は「分割・統治せよ!!!!!!!!!!!!!!!!!!!!!!!!!」の原則に逆らうつもりか!!!!



120 :仕様書無しさん:03/12/03 04:38
>>96
もまえはgoto肯定原理者で人を不快にさせる病原菌をもっている。
ウザイから我らにうつすな。

121 :仕様書無しさん:03/12/03 04:42
>>106
> グローバル変数を禁止させたかと思ったら、巨大な構造体(グローバル変数っぽい
> メンバが詰まってる)を全ての関数の引数に付けられたりして…


そいつは
直径が100万光年ある超巨大原子のようだ(藁
知ってるか? こんな原子が宇宙のどこかにあるんだってよ(ワラ

原子がオブジェクトで
原子核が電子によって隠蔽されたフィールド(C++でいういところのメンバ変数(プ 死語))で
電子がメソッド(C++でいういところのメンバ変数(プ 死語))だな(藁


122 :Mr.名無しさん:03/12/03 04:46
喪前ら落ち着け、この中で会社に飼われているゴミPG以外は
居るのか?飼われているゴミに反応して如何するの?
サラリーマンPGの様なゴミに惑わされるな。


123 :仕様書無しさん:03/12/03 05:05
もしこの世に自分の金玉と同じサイズの超巨大原子があったら?

それは近くにDQN-COBOLerが潜んでいる危険性があるということだ〜

124 :仕様書無しさん:03/12/03 05:12
基本的にサラリーマンの様な家畜が意見を述べる事自体が
間違いなのだが!飛べない豚は氏ね!!!


125 :仕様書無しさん:03/12/03 05:19
恐ろしいのはカプセル化されていない超巨大原子だ。

超巨大なプラスイオンが超強力な電場を作り感電する!
金玉の直径が1cmだとして、その中に入る陽子中性子電子の数はいくつだっ!?
陽子の数、電子の数だけクーロン力が増える!
何エレクトロンボルトだ!?

恐ろしいクーロン力だ!その超巨大原子がコンピュータを破壊する!
超巨大原子(COBOLer)が超強力なクーロン力、超極力な電圧、すなわち静電気で
オープン系システムを破壊する。
恐るべきCOBOLerの大量のpublicなフィールド(プラスイオン)は人間に害を与える!
恐怖の開放電磁フィールド(公開メンバ変数)だっ!
このプラスイオンを撒き散らす恐怖の電磁フィールドは
トルマリンゴ(マイナスイオン新参者)でも防ぎきれない!

さらに恐るべきはアイソトープ(ポインタ操作)だ!
使い方を少しでも誤れば全員放射能で金玉原子にブッ殺されてあの世(デスマーチ)に!



126 :仕様書無しさん:03/12/03 05:24
本当の事を言って置くが
C++の様なゴミしか知らない屑は可哀想だなwww


127 :仕様書無しさん:03/12/03 05:52
超巨大原子(無計画なプロジェクト)は崩壊し、
最終的に鉛(寂れたシステムまたは破綻したプロジェクト)に変わった・・・・。
超巨大原子が引き起こした悲劇は終わった・・・・・・。
これからもこのような悲劇は起さないで欲しい。

お前らよ、無理をするな、超巨大原子など作る必要は無いのだよ。
妙な元素(オペレータ定義、新言語作成など)を自作することばかり考える必要はないのだよ。
ランタノイドやアクチノイド(無謀なクラス設計の例)のように無駄にひとつの原子(クラス)内に
たくさんの電子(メソッド)や陽子中性子(フィールド)を
大量に詰め込む(定義する)必要など無いのだよ。
(動作が)不安定になって原子崩壊(スパゲティコード化)する原因を作るだけなのだよ。

人類、そしてこのよに存在する全ての生命体(すなわち、Java, Smalltalk)はつまらない原子に頼らず
炭素、酸素、水素、窒素といった限られた少ない部品(クラス)の組み合わせだけで分子(デザインパターン)、
ポリマー(Iteratorパターン)、有機化合物(フレームワーク)、
高分子化合物(アークテクチャーパターン)、細胞核・ミトコンドリア・etc(コンポーネント)、細胞(パッケージ)、
生命(人工知能)などを作り上げることができるのだ。

例えば酸素クラスと水素クラスという組み合わせでシンプルで人間、生命にとってかけがえの無い
すばらしき美しい水分子クラスができたのだ。なのにおまいらはプルトニウムとかしか作らない!!

フレームワーク(有機化合物)を作らずしてグローバル変数とポインタ演算だらけのコード(プルトニウム)を
作るだと!? それは許されん!!!!

システム障害・サーバダウン・デスマーチ(ビキニ環礁水爆実験、チェルノブイリ原発事故)を起させてたまるものか!

植物はなあ、もっとも効率よくエネルギーを代謝しているのだぞ。
それにくらべ自動車、発電所や工場はなんとエネルギーの無駄遣いをしていることか。
おれたちは発電所がなかったらプログラマとしてやっていけないが、いつか生命体からエネルギーを
大量に確保する技術の恩恵を受けるべきだ。人類と地球の将来のために。

128 :仕様書無しさん:03/12/03 07:37
おやくそく
・長文ネタやる時はテーマを思いっきり絞るか、短いセンテンスを重ねるか、読んで楽しめるように工夫しましょう。

129 :仕様書無しさん:03/12/03 07:48
>>127
逝って良し

130 :仕様書無しさん:03/12/03 09:44
・・・つくづく勝者のいねえプロジェクトだよナ・・・
誰がいつgoto使ってもいい・・・すべては自由・・・
約束事なんか何もねえ

・・・そして巨大な構造体を引数にするのも自由だ
永遠に保守性なんか上がらねえ

ハマるヤツとキレるヤツ・・・ それだけだ
・・・クソ判断だったな コボラー課長よ・・・

131 :仕様書無しさん:03/12/03 10:02
>>130
お気の毒に。
>・・・クソ判断だったな コボラー課長よ・・・
これが元凶だったようですね。言語設計思想からして全然違うのに。
「なんかで成功するとその方法が常に通用すると思いこんでしまう」という技術者失格な奴が多いんだね。
#この傾向はコボラー達に色濃いと思うのは俺の偏見か。

132 :仕様書無しさん:03/12/03 10:06
>>120
いえ、それは病原菌の性ではなく、gotoアトピー患者が過敏なだけです。

133 :仕様書無しさん:03/12/03 11:01
>>132 うん
アレルギー体質の治療ってアレルゲンを遠ざけることではなくて、
アレルゲンに対する過敏性を解消することなんだよね。
アレルギー体質患者のためにもgotoを見せてやらなければ。

134 :仕様書無しさん:03/12/03 12:27
>>131
コボーラに限らず、学生〜新人の期間に特定の環境しか習得しなかったやつは大抵そんな感じだ。

135 :仕様書無しさん:03/12/03 16:07
それで134は使えない新人と言われるわけだ。
明日からコンビニ行けよ

136 :仕様書無しさん:03/12/04 01:28
c言語研修でgotoを使わせてみなかったのは失敗だった。
goto使えない奴はいつまでたっても使えないのかも。

137 :このスレの中に:03/12/04 01:31
NIFTYのプログラマーフォーラムでうざい長文を書くヤシが
何人かいるな。かえれ!

138 :仕様書無しさん:03/12/04 01:50
だからgotoなんて使うとタイプライブラリがNULLで
スタックがヒープにくい込むわけでDCOMが
フーリエ変換なわけよ。わからねーだろーなー。

ps. おっと忘れてた、新聞配達行かなきゃ

139 :仕様書無しさん:03/12/06 00:08
おまいらgotoくらいでびびってんじゃねーよ
金玉ついてんのか〜

140 :仕様書無しさん:03/12/06 00:24
>>139
びびっている奴は、びびっていることを決して白状しない
「見るのが不快」「怖い」という負の感情を隠すために
「構造化がルールだから」とかいう理屈をこねたり、
「PGやめろ」とかいう怒りの感情を表明するのが典型的な反応だ。
まあ「gotoを全面否定する論理的な根拠」ってのは存在しないから、
このような反応をするのも仕方ないが。

141 :仕様書無しさん:03/12/06 01:17
>>139
女子プログラマーもいるぞ(w

142 :ななし:03/12/06 01:28
「gotoが使えないならsetjump(),longjump()を使えばいいじゃない」by マリー

143 :仕様書無しさん:03/12/06 01:34
今どきなら「throwを使えばいいじゃない」のほうがより適切と思う

144 :仕様書無しさん:03/12/06 01:38
先生!ループの前から深いループ中に飛び込むのにsetjump(), longjump()は使えません!

145 :仕様書無しさん:03/12/06 01:48
#define setjump() LABEL:
#define longjump() goto LABEL
じゃだめ?(w

146 :ななし:03/12/06 02:18
>>144
それってgoto使ってもstack吹っ飛ぶんじゃないの?

147 :仕様書無しさん:03/12/06 02:29
>>146
まずは、吐き出されたアセンブラを見たら?

148 :仕様書無しさん:03/12/06 03:25
>>140
いや、びびってるよ。
整備されたソースコードがボロボロになっていくなんて考えただけでも怖い。
gotoを見るのは確かに不快だ。
構造化は混沌に秩序をもたらすルールだよな?

パフォーマンス追求以外の理由でgotoを使うやつは馬鹿だ。
プログラミングが下手だという理由で馬鹿呼ばわりされるのではない、
馬鹿げた事を正当化しようとするから馬鹿呼ばわりされるのだ。

149 :仕様書無しさん:03/12/06 10:12
>>144
ループの中に飛び込むなら switch 〜 case 使わないとね。

150 :仕様書無しさん:03/12/06 11:34
>>148
>構造化は混沌に秩序をもたらすルール
確かにそうだ。
しかし「秩序をもたらす」のは「構造化プログラム設計」であって「構造化コード」ではない。
gotoはコードに属する問題であり、プログラム設計に属する問題ではないんだ。
これを無視して一概に「構造化」を語るのは誤りだ。

151 :仕様書無しさん:03/12/06 14:08
あほですか?
「構造化されたコード」を書くことによって「構造化されたプログラム設計」が実現されるんだろうが。
コードレベルですでに構造化が壊れてるようなものしか書けない奴に、設計なんて語る資格なし。

152 :仕様書無しさん:03/12/06 14:11
>>151
つまりあなたはは抽象的思考ができないということですね。

153 :仕様書無しさん:03/12/06 14:21
goto hell;

154 :仕様書無しさん:03/12/06 14:31
hell:
goto heaven;

155 :仕様書無しさん:03/12/06 19:49
>>150
構造化フロー制御の話だろ?
わからないくせに出てくるな馬鹿

156 :仕様書無しさん:03/12/06 21:57
>>151=155
わかったからもう出てくるなあほが

157 :仕様書無しさん:03/12/07 01:40
なかなか素敵だ(´,_ゝ`)プッ

158 :仕様書無しさん:03/12/07 01:56
結論:
前方参照ジャンプが出来ないので、setjump(), longjump()はgotoの代わりにはならない。

159 :150:03/12/07 02:15
>>151
ボトムアップのみの一方的な視点だな。
ボトムアップは場合によっては有効だが、トップダウンの方が有効な場合の方が多いだろう。
#これは業務アプリが最大の分野であるがためだが
>「構造化されたコード」を書くことによって「構造化されたプログラム設計」が実現されるんだろうが。
「構造化プログラム設計」って言葉の意味を知っているのか?コードとは無関係だぞ
関数間の参照/被参照の依存関係&個々の関数の強度と結合度のことだ

160 :仕様書無しさん:03/12/07 03:29
構造化の点からいくとbreakやcontinueも使わない方が良い

161 :仕様書無しさん:03/12/07 03:45
>>160
当然、「最終行以外のreturnも」だよね。
goto禁止論者に聞きたいんだけど、この三種の文、
「break(多分caseラベルbreak除く)」「continue」「最終行以外のreturn」
のそれぞれの使用可/不可を答えて欲しいな。

162 :仕様書無しさん:03/12/07 09:49
>>161
全部アリコに決まってんだろ

163 :仕様書無しさん:03/12/07 10:07
最終行以外のreturnは何で駄目?

164 :仕様書無しさん:03/12/07 10:16
>>163
構造化の妨げになるため

165 :仕様書無しさん:03/12/07 10:24
>>164
どうして構造化の妨げになるの?

166 :仕様書無しさん:03/12/07 10:33
>>165
164では無いが。
・連接反復選択の三種の制御構造のみを使用する
・入口と出口は一つずつ
の条件で、全ての論理が記述可能だ。
という構造化定理(ストラクチャード定理)というものが大昔に証明された。
これに準拠して記述するのを「構造化プログラミング」という。
#本当は構造化原理主義
出口が複数あるのは純粋な意味での構造化プログラミングでは無いからだ。

167 :仕様書無しさん:03/12/07 10:47
なるほど
ハマスと同類ですね
くだらないルールに拘る奴等は

168 :仕様書無しさん:03/12/07 11:40
gotoを使うのはかまわんが、用も無いのに使う奴は馬鹿。

169 :仕様書無しさん:03/12/07 12:21
用も無いのに使う奴は馬鹿
用も無いのに使う奴は馬鹿
用も無いのに使う奴は馬鹿
用も無いのに使う奴は馬鹿
用も無いのに使う奴は馬鹿
用も無いのに使う奴は馬鹿

おまえって。。。

170 :仕様書無しさん:03/12/07 12:23
なんか分岐して出口一つにすると行数が多くなって嫌とか言って
そこら中にreturnばらまいてるコード結構あるね。
そういうコードは保守するとき、苦労するんだべさ。

171 :仕様書無しさん:03/12/07 12:24
フラグ使うのもダメってよくいうけど
使わないサンプル書いてくれ

172 :仕様書無しさん:03/12/07 12:26
>break(多分caseラベルbreak除く)
>continue
この二つはまったく考え無しに使う。
条件チェックを複雑にしないためのシンタックスシュガーだから
構造化を崩しているとは思っていない。

>最終行以外のreturn
滅多に使わない。大抵の場合は戻り値を一時変数に格納するだけで
最終行のreturnで問題ない。
(このスタイルは一時期VBを使わなければいけなかった時に身についたもので苦肉の策だったんだが、
結果的にとてもよいスタイルが身についたと思っている。デバッグ出力や一時的な変更などがすごく楽だ)
ただ抜けるために複雑な条件にしないといけない場合は使うが。

どちらにしてもわかりきった範囲にしか飛ばないのだから自由自在のgotoとは別物だと考える。

173 :仕様書無しさん:03/12/07 12:46
>>172
>>最終行以外のreturn
>滅多に使わない。大抵の場合は戻り値を一時変数に格納するだけで
>最終行のreturnで問題ない。

こうしたいがためにコードを複雑にしているアフォがなんと多いことか。

174 :仕様書無しさん:03/12/07 12:55
>>166
そして、その「論理的には」可能な「完全な構造化」を
現実に実装できると思い込んでいる脳足りんが
goto を使うな、と言っている。

処理の流れを有向グラフにしたら
「完全な構造化」が如何に無駄なものか
判りそうなものなのにな。

175 :仕様書無しさん:03/12/07 15:38
>条件チェックを複雑にしないためのシンタックスシュガーだから
gotoもループ脱出や例外処理のシンタックスシュガーですw

176 :仕様書無しさん:03/12/07 15:42
>>174
連中は、まず「gotoは『絶対』使ってはダメ」という原則がアプリオリにあって、
それに、構造化だの保守性だの適当な理由をつけてるだけだから、一貫性が
内容に見えてもそれを指摘するのは全くの無駄だよ。

177 :仕様書無しさん:03/12/07 15:57
try-catchでgoto文の代わりができるいらねえだろgotoなんて

邪魔邪魔

goto文はアージャイル開発の敵!

178 :仕様書無しさん:03/12/07 16:12
C++の話をもちだす>>177はアフォ

179 :仕様書無しさん:03/12/07 16:14
// 悪い関数の例 (9行)
int func(int arg) {
 int result;
 if (arg > 0 && arg < 100) {
  result = 1;
 } else {
  result = 2;
 }
 return result;
}
// 良い関数の例 (7行)
int func(int arg) {
 if (arg > 0 && arg < 100) {
  return 1;
 } else {
  return 2;
 }
}

180 :仕様書無しさん:03/12/07 16:15
>>176
うん、まあそうなんだけどね。でもそういう正論を言ったら話が終わってしまう。
「goto禁止論者をからかう」という背景で話をすることによって、
「goto誤用の撲滅に一歩でも近づけたらいいな」という個人的な楽しみが失われるな。

181 :仕様書無しさん:03/12/07 16:17
ようはこういうことだ、
まともなプログラムが組めない輩が安易に
GOTO文を使うなってことだ。逆にロジックを
ちゃんと組める熟練した人間なら必要に応じ
てバシバシつかってもいんじゃないかな。

182 :仕様書無しさん:03/12/07 16:20
>>179
問題です。
その func の戻り値をデバッグの為に printf で出力したいと思いました。
func はあちこちで使われています。
変更が少なくてすむのはどっち?

また初期コストと変更のコストで削減した時に効果が高いのはどっち?

183 :仕様書無しさん:03/12/07 16:20
>>179
// 良い関数の例 (1行)
int func(int arg) { return (arg > 0 && arg < 100)?1:2; }
じゃダメか?

184 :仕様書無しさん:03/12/07 16:21
>>181
>逆にロジックをちゃんと組める熟練した人間
あ!本物のプログラマ発見!!

185 :仕様書無しさん:03/12/07 16:33
>>182
意味不明だなあ。「funcの戻り値を出力」って、普通funcの参照元でやるよ。
func内部で出力するの?。

あのさあ開発コストを負担する組織と保守コストを負担する組織が必ずしも同一でない
って事は認めるよね。
そのような現状で「開発コストと保守コストの総和の最小化」なんて言っても
開発しかしない組織は聞く耳なんか持たないんだよ。
開発しかしない組織は開発コストにしか興味が無いんだってば。

186 :仕様書無しさん:03/12/07 16:43
>開発しかしない組織は聞く耳なんか持たないんだよ。
すげー優秀ですね。普通は開発ってトライ&エラーの連続だと思うんですけど
開発って変更の連続ですよね。ビルド通ったらバグもエラーもなく動かしちゃう人達ってほんと尊敬します。



187 :仕様書無しさん:03/12/07 16:45
>>185
>意味不明だなあ。「funcの戻り値を出力」って、普通funcの参照元でやるよ。
>func内部で出力するの?。

DBC的には内部でチェックのが正しげ

188 :仕様書無しさん:03/12/07 17:11
>>182
デバッガ使え。

189 :仕様書無しさん:03/12/07 17:13
>>188
ヲチポを増やすと重くなります。
一時変数resultに格納するとヲチポは一つで済みます。

190 :仕様書無しさん:03/12/07 17:22
まあデバッガで検証できるレベルのバグは大したことはない。
問題はタイミングによって挙動が変わるような処理だ。
そういう場面でもっともお手軽でかつ確実な方法がprintfによる出力。

191 :仕様書無しさん:03/12/07 17:25
>>186
テスティングフレームワークを使ってテストケースが書いてあれば、
戻り値チェックだけで(ry

192 :仕様書無しさん:03/12/07 17:29
>>190
デバッガのマニュアルを読んでみよう。
ブレークポイント以外にもいろいろ使い方あるよ。

193 :仕様書無しさん:03/12/07 17:38
天才や本物のプログラマはgotoも最終行以外のreturnも恐れずに使う。
一般プログラマのように常に勉強をし続け、良いスタイルを身につけ続けていかないと
ちゃんとプログラミングができない者たちは天才や本物のプログラマの真似をしてはいけない。

194 :仕様書無しさん:03/12/07 17:49
>>190
printfを入れるだけで出なくなることもあるけどな。

195 :仕様書無しさん:03/12/07 17:58
組み込み、制御系では実機とデバッグ環境に違いがあって
製品組み込み後の総合テスト的なデバッグではデバッガはまずつかえんね。


196 :仕様書無しさん:03/12/07 18:33
それは組込系に限った話ではないのでは?

197 :仕様書無しさん:03/12/07 19:08
>>171 フラグ使っているサンプルを書いてみ。使っていないサンプルに直してやるから。

198 :仕様書無しさん:03/12/07 20:42
>>182
int func(int arg)
#ifdef DEBUG
{
  int _func(int);
  int result = _func(arg);
  printf("%d\n", result);
  return result;
}
static int _func(int arg)
#endif
{
  // 本当のfuncの処理

199 :仕様書無しさん:03/12/07 21:07
>>198
そーれーはーさーすーがーにーあーぶーなーいー
と思われ。
そういうプリプロセッサの使い方をいつもしているの?

200 :仕様書無しさん:03/12/07 21:16
>>199はネタだろ?

201 :仕様書無しさん:03/12/07 21:22
天才や本物のプログラマはgotoも最終行以外のreturnも恐れずに使う。
一般プログラマのように常に勉強をし続け、良いスタイルを身につけ続けていかないと
ちゃんとプログラミングができない者たちは天才や本物のプログラマの真似をしてはいけない。


202 :仕様書無しさん:03/12/07 22:40
現場で必要とされるのは、そんな「天才」だの「本物」じゃないだろ。
誰が読んでも分かり易い、メンテナンスや拡張がし易いコードの書ける
プログラマだろう。

203 :仕様書無しさん:03/12/07 23:27
ネタニマジレス?

204 :仕様書無しさん:03/12/07 23:30
>>199
解説よろしく

205 :仕様書無しさん:03/12/07 23:49
東大出身のPGが書いた大量のフラグを使ったプログラムを見て
フラグを間違えずに使える奴こそ、「天才」だと思った。

206 :仕様書無しさん:03/12/07 23:54
膨大な規約をスキなく覚えかつ実践できる奴もね。

207 :仕様書無しさん:03/12/08 00:09
>>202
俺は
「誰が読んでも分かり易い、メンテナンスや拡張がし易いコードの書けるプログラマ」
が本物だと思うが。

208 :仕様書無しさん:03/12/08 00:13
そんなものが存在すると思ってるうちは自己満足なコードしか書けない。

209 :199:03/12/08 00:23
>>204
解説って・・・>>198は、
DEBUGが定義されているときはfuncは_funcを参照してその返り値を出力し、
DEBUGが定義されていないときはるときはfuncは「本当のfuncの処理」を行う。
つまりDEBUGの定義/非定義によって全然違うプログラムになってしまう。
このような使用方法は非常に危険だから「危ない」って言っただけだが。

210 :仕様書無しさん:03/12/08 00:34
>全然違うプログラムになってしまう。
ネタ?

211 :仕様書無しさん:03/12/08 01:21
日本人って「手段を目的と取り違える倒錯」に陥りやすいよね。
社会科学系の学者には先の敗戦の主因もそこにある、という人もいる。

この話題は実はすごくシンプルなことなんじゃないだろうか?
「gotoを使わない」のは、主にコードの可読性を上げる、という目的の手段のはず。
だからコードの可読性が重要なプロジェクトで、かつコードの可読性を悪くすると
思われるケースではgotoを使うべきではない。

逆に、コードの可読性に資するのではれば(そんなケースが実際にあるかどうかは
別として)躊躇なく使えばいいし、あるいはコードの可読性以上に重要な目的があって
その目的にかなうなら、使うのは仕方がない。

で、実際そのようなケースがあるのかどうかだが、私はほとんどないと思う。
強いて言えばVBでCのcontinueの代用として使うケースと、ワンチップマイコン
みたいにスタック領域が大きくとれないシステムで「あるルーチンAをコールして
リターン」の代わりに直接そのルーチンAに飛ばすときぐらいか。

話は変わりますが、私は関数内ルーチン(gosub)は、場合によっては
非常に有用だと思うんですが皆さん的にはどうでしょう。

212 :ななし:03/12/08 01:27
文句があるならカーニハンとリッチに言いなさい。

213 :仕様書無しさん:03/12/08 01:31
>>211
いいたいことは判るが、「可読性」を定量的に量れないと無意味。
gotoを使ったコードのほうが可読性が高いと思う奴もいるので。

214 :仕様書無しさん:03/12/08 01:32
>>209
デコレータパターン

215 :仕様書無しさん:03/12/08 01:37
>>211
とりあえず、このスレと前スレを読み返してみたら?

216 :仕様書無しさん:03/12/08 01:41
>>213
goto否定原理主義者的には、「gotoを使ったほうが読みやすくなるようなコードを
書くほうが悪い。」だそうですが。

217 :仕様書無しさん:03/12/08 01:48
手段を目的と取り違える倒錯

218 :仕様書無しさん:03/12/08 02:31
gotoを使ったコードは常に可読性が劣る

なぜならgotoを使ったほうが可読性が良くなる場面など存在しないからだ

もし存在しているように見えるなら、それは書き方が悪い

その場合、gotoを使用しないもっと良い書き方が常に存在する

なぜその書き方がよいかというと、gotoを使わないほうが可読性が良いからだ

219 :仕様書無しさん:03/12/08 03:49
>218
気持ちはわからんでもないが、
小学生並の主観のみの意見は説得力ないわな
もうちょっとがんばれ

220 :仕様書無しさん:03/12/08 09:49
>>219 >218は「goto否定論者への単なる煽り」にしかみえないんだが。

221 :仕様書無しさん:03/12/08 11:07
gotoを使わないコードって可読性良い?
俺の見た範囲ではむしろフラグとか使いまくりでダメダメだったよーな気がします。


222 :仕様書無しさん:03/12/08 11:44
>>218は、「可読性」を「保守性」に変えて読んでもいいな。

223 :仕様書無しさん:03/12/08 12:13
goto 使いたくなる例;

┌──┤
│  <X?>─┐
│   │   │
│  [ A ]  │
│   │   │
│  <Y?>─┤
│   │   │
│  [ B ]  │
│   │   │
│  <Z?>─┤
│   │   │
│  [ C ]  │
└──┘   │
     ┌──┘

224 :223:03/12/08 12:16
いや、これは C なら break 使えば済むな…
まぁ構造化理論でいくと goto と break は等価だから、と言い訳しておこう。

225 :仕様書無しさん:03/12/08 12:20
>>223
for(;;){
if(! X ?) break;
[A]
if(! Y ?) break;
[B]
if(! Z ?) break;
[c]
}

...goto使うまでもないが?

226 :>>225:03/12/08 12:34
...かぶりますたね

227 :仕様書無しさん:03/12/08 14:46
breack文やcontinue文が用途を限定したgoto文として考案されたものである
って事を知らない人もいるのだね。

228 :仕様書無しさん:03/12/08 14:54
>227
照れるなよ。
自分のことだろ?

229 :仕様書無しさん:03/12/08 14:58
breakやcontinueは、もともと問題が少ないgotoの使い方だから、
シンタックスシュガー化されたわけだね。
C++の例外も同様(gotoの機能に限って言えば)。
あと、label付きcontinueやbreakができる言語もあるな…

230 :仕様書無しさん:03/12/08 15:03
breackってのはジュースかなにかですか?

231 :仕様書無しさん:03/12/08 15:18
地方限定か?

232 :goto使い隊:03/12/08 15:48
do{
if(! X) break;
[A]

if(! Y) break;
[B]

if(! Z) break;
[C]
}while(0);


...って書くくらいならさ、
if(! X) goto next_block;
[A]

if(! Y) goto next_block;
[B]

if(! Z) goto next_block;
[C]

next_block:
でいーじゃん?


233 :仕様書無しさん:03/12/08 16:08
前スレにそれに関する論争があったな…

234 :仕様書無しさん:03/12/08 16:51
「gotoを使うと常に可読性が悪くなる」という根拠の無い信念
を持つ人間がいなくならない限りgoto論争は終わらないな。

言語研修のときに「gotoは使うな」って言われて、
仕事内容が「比較的ロジックが単純であるカテゴリの業務アプリ」だったりすると、
gotoなぞ使わなくとも済むからね。
上記のような根拠の無い信念が形成されるというわけだ。
その種の人間は年々沢山、増えるから「goto論争は終わらない」というしかけ。

235 :仕様書無しさん:03/12/08 18:20
goto肯定派は大阪人の交通マナーは素晴らしいと思うの?

赤でも危なくないから渡るんじゃい!って、
危なくないと思ってるのは自分だけ。
こういう人達が蔓延っている中から
いつも酒飲みながら運転するトラックのドライバーとかが出てきて
罪もない幼子の命を奪ったりするんだよ?

236 :仕様書無しさん:03/12/08 18:21
>>234
ロジックが複雑だと感じたときは
考え直せ
たいてい 簡単なロジックの組み合わせに直せる。


237 :仕様書無しさん:03/12/08 18:32
>>235
せいぜい80Km/hで高速を走らない一般ドライバー程度のことだyo


>>236
gotoの方が簡単だろ?

238 :仕様書無しさん:03/12/08 18:43
>>235 500m先まで見えてて、車が全く見えなくても100m先の横断歩道まで歩くタイプ?

239 :仕様書無しさん:03/12/08 18:52
横断歩道は車のためにある。
歩行者のためにあるわけではない。

240 :仕様書無しさん:03/12/08 19:29
>>235
そういうの、我田引水って言うんだよっ

241 :仕様書無しさん:03/12/08 20:09
>>237
複雑なロジックの時点で簡単ではない


242 :仕様書無しさん:03/12/08 20:14
それで妙なネストや意味の無い関数分けが増えるのか…

243 :仕様書無しさん:03/12/08 20:24
おい旧世代のイキモノ
とっとと進化するか滅べ

244 :235:03/12/08 20:29
>>237
それが割れ窓。

>>238
もう>>239が説明してくれてるけど、運転者の話をしている。
運転者は責任があるから、この比喩に相応しいが、歩行者は一般的に責任が非常に軽いので
相応しくない。

>>240
つまりお前は負けを認めたわけだな?
反論できないんだろ?

gotoを使う奴は人殺しのトラックドライバーと同じ。

反論あるやつはちゃんと反論してみろよ。

245 :仕様書無しさん:03/12/08 20:46
> gotoを使う奴は人殺しのトラックドライバーと同じ。
全く違う。同じ部分なんて一つも無い。

反論してみました。

246 :235:03/12/08 21:02
>>245
gotoを誤用するとスパゲティになるのは認めるな?
交通ルールが世の中から無くなったら交通事故が多発して死亡者が後をたたないのは認めるな?

構造化フロー制御でgotoの誤用が防げるのは認めるな?(認めないなら構造化フロー制御の構文をもう使うな)
交通ルールで交通事故が防げるのは認めるな?ほとんどの交通事故が交通ルールを無視した為に起こっている事も認めるな?

構造化フロー制御はプログラミングの世界の交通ルールだ。
たしかに誰もいない赤信号を待つのは馬鹿らしいかもしれないが、
それを守らないと必ず大きな事故をひきおこす(これを割れ窓のセオリーと呼ぶ。)

さあ、矛盾の指摘なり、反論なりまともにしてみろ。

247 :仕様書無しさん:03/12/08 21:10
一応ツッコんどくが・・・例えが悪いよ。

248 :仕様書無しさん:03/12/08 21:10
深夜
人も車もいない道路
目的地は目の前
道路を横断すれば数秒
歩道橋を渡れば5分

それでもあなたは歩道橋を渡りますか?

249 :仕様書無しさん:03/12/08 21:16
>>248
>239

250 :仕様書無しさん:03/12/08 21:41
goto使うったって
数万、数十万ステップ、それ以上に1箇所あるかないかだろ。
なんの問題があるんだ?
それよりもgotoを使わないことを意識した糞コードが
山のようにあるほうが実際迷惑だな。

251 :仕様書無しさん:03/12/08 21:46
>>246
245ではないが。力の入ったレスに敬意を感じたのでレスさせてくれ。
>gotoを誤用するとスパゲティになるのは認めるな?
>交通ルールが世の中から無くなったら交通事故が多発して死亡者が後をたたないのは認めるな?
>構造化フロー制御でgotoの誤用が防げるのは認めるな?
全部認める

>交通ルールで交通事故が防げるのは認めるな?
認めない。
交通ルールなんて国によって内容とその量に格段の開きがあるぞ。
交通ルールに違反する気なぞ全く無くとも、前方不注意で起こる事故だってある。
>ほとんどの交通事故が交通ルールを無視した為に起こっている事も認めるな?
知らないよ。

>構造化フロー制御はプログラミングの世界の交通ルールだ。
規約になっていなければ、絶対に認めない。そんなことを勝手に決められてたまるか。
このあたりが焦点だろう。

>たしかに誰もいない赤信号を待つのは馬鹿らしいかもしれないが、
>それを守らないと必ず大きな事故をひきおこす(これを割れ窓のセオリーと呼ぶ。)
割れ窓理論って
たった1枚の割れ窓の放置から起きる荒廃の始まりで、街は荒れ、無秩序状態となって犯罪は多発し、地域共同体を作っていた住民は街から逃げ出し、街が崩壊する
ってやつだな。
「gotoは割れ窓である」ということ自体を認めない。

以下は俺の意見
「大きな事故を引き起こす」ってのは「gotoの誤用」が原因の一つになりうることを認める。
しかし「gotoの誤用」は「大きな事故を引き起こす」原因群の最大の悪玉ではない。
また「gotoの誤用」を起こさないための仕組みとして「goto使用禁止」を選択するのは不適切だろう。
#大きな事故を引き起こさない事がそんなに重要ならば、
#goto使用禁止を叫ぶより、もっと有効な行動があるのではないか

252 :仕様書無しさん:03/12/08 21:46
>gotoを使わないことを意識した糞コード

早い話おまえみたいなクソ低レベルな奴がいなければ何の問題も無い

253 :211:03/12/08 21:54
なんかとてつもなく頭が悪い人が何人かいるような......。
なんでこんな思考力ない人たちがPGなんかしてるんだろ?

>>246
こういう人のことを「土人」っていうんだろうね。
「手段」の妥当性は目的に対する合理性で評価されるべきです。
目的を忘れて手段に固執するのはフェティシズムです。変態さんです。
「村の掟」で自縄自縛する前近代人です。

一般に「gotoを忌避すべし」とされるのは、gotoの乱用は一般に
コードの可読性を下げるからです。「それがルールだから」ではありません。
「ルールだから守る」があなたにとって説得的であるとすれば、
それはあなたが近代社会の住人ではないからです。

>構造化フロー制御はプログラミングの世界の交通ルールだ。
>たしかに誰もいない赤信号を待つのは馬鹿らしいかもしれないが、
考え方が倒錯しています。交通ルールの目的(の1つ)は交通事故を
避けることです。だから交通事故の抑止に対する合理性がないルールが
仮にあるとすれば、そんなルールは破棄されるべきです。
「悪法も法」なんていうのは近代を理解せぬ愚か者のセリフです。

同様にgotoを使うことが目的(コードの可読性の確保)に合致するなら、
gotoを使わない理由はありません。繰り返しますが、目的を忘れて
手段に固執するのはバカげています。

>....(これを割れ窓のセオリーと呼ぶ。)
呼びません。全然違うよ。恥を上塗りしないうちにググルがよろし。

254 :仕様書無しさん:03/12/08 21:55
goto使う奴 -> 野蛮なテロリスト
goto使わなくても普通にコード書ける奴 -> 文明人

255 :仕様書無しさん:03/12/08 21:56
>>250
支持。
gotoなどより糞コードの方が保守性低下に直結する悪玉だ

256 :仕様書無しさん:03/12/08 22:04
>>253
各論を支持する。
が、「頭が悪い」とか「思考力ない」とか「愚か者」とか「恥を上塗」とかは書くな。

257 :仕様書無しさん:03/12/08 22:09
>>244
>つまりお前は負けを認めたわけだな?
意味わかってない人ハケーン( ・∀・ )
自分の書いたレスのどこが悪いのか良く考えてみようね(5点)

258 :仕様書無しさん:03/12/08 22:11
宗教だよ。
goto使いたい奴は使えばいい。

俺は使いたくないし、絶対に使わなければならないような状況になったことは無い。
使った方が良い場合というのにもほとんどお目にかからない。ゼロに近い。

俺の知ってる奴の中でgoto使う奴は、考え無しにいきなりコーディングする奴が多い。
確かに動けばまぁ良いけどよ。

「イヌの旨さは日本人には分からないニダ」って所か?


259 :仕様書無しさん:03/12/08 22:16
>>235もそうだけど、goto使用禁止原理主義者って結局↓の>>176の通りなんだよね。
議論にすらならないというか。>>218でそれが皮肉られたのが分からなかったのかなぁ?

176 名前:仕様書無しさん[sage] 投稿日:03/12/07 15:42
>>174
連中は、まず「gotoは『絶対』使ってはダメ」という原則がアプリオリにあって、
それに、構造化だの保守性だの適当な理由をつけてるだけだから、一貫性が
内容に見えてもそれを指摘するのは全くの無駄だよ。
~~~~

無い様
だね(補足)。

260 :仕様書無しさん:03/12/08 22:17
gotoこそプログラミングの本質である。
ジャンプのないプログラミングなんてクリープのない(略

261 :仕様書無しさん:03/12/08 22:19
隠し味だね!

262 :仕様書無しさん:03/12/08 22:23
少し意味合いは違うかも知れないけど、
GUIのイベントループやシグナルハンドリングも本質的にはgotoなんだよね。
#元に戻ってくるからbasicのgosubみたいなものか

263 :仕様書無しさん:03/12/08 22:34
>>262
そうだね。でも関数参照自体もgotoだね。
「GUIのイベントループやシグナルハンドリング」は非同期だっていうおまけがついてるけど。

264 :仕様書無しさん:03/12/08 22:35
GoToも使いこなせん香具師はPGヤメレ!

265 :仕様書無しさん:03/12/08 22:37
goto使う使わないでどうにかなる奴は率直にいって能力が低い。
こんな糞スレにたむろって1000以上の糞レスつけてる奴は人生の愉しみ方を知らない。

266 :235:03/12/08 22:40
>>248
goto使用者が運転免許証も持っていない事=世論の流れを知らない事はわかった。

>>250
>それよりもgotoを使わないことを意識した糞コード
これも先に突っ込まれたが、一つだけいいことを教えてやる。
gotoを使わないで初心者時代を過ごした人間は、無意識にgotoを使うことは無い。
あんたにとって「これgotoを使わないでどうやって書こう」が不自然なように
我々にとって「これgotoを使ってどう書こう?」や「このコードは何故gotoを使っているんだろう」は
極めて不自然だ。
そしてこの事実はこのスレで何度も出ている嘘をも暴く。
goto肯定派のほとんどが
「初心者時代はgotoを使わず、わかるようになってからgotoを使う」などというルートは踏んでいない。

267 :235:03/12/08 22:40
>>251
>>交通ルールで交通事故が防げるのは認めるな?
>認めない。
たとえば一時停止がルール化されていなかったら、
あなたが今まで成長するまでに車にひき殺されてるかも、と思いませんか?

>交通ルールなんて国によって内容とその量に格段の開きがあるぞ。
いや、全部防げるとか完璧だとかは言っていないです。
交通ルールが事故を減らせるでしょう?と言っているのです。

>交通ルールに違反する気なぞ全く無くとも、前方不注意で起こる事故だってある。
直進中に前方を注意していないのは既にルール違反だと思いますが。

>>ほとんどの交通事故が交通ルールを無視した為に起こっている事も認めるな?
>知らないよ。
ちょっと書き方に一貫性がなかった。悪かった。
ここだけ歩行者や軽車両側にも交通ルールを守る義務がある事を前提とさせてくれ。
少なくとも日本の交通ルールは全員が厳守すれば車両の故障、土砂崩れなどの天災的なもの、
アクセルとブレーキの踏み間違いなどのどうしようもないレベルを除いて
ほとんどの事故はなくなる。これは事実だ。

>>構造化フロー制御はプログラミングの世界の交通ルールだ。
>規約になっていなければ、絶対に認めない。そんなことを勝手に決められてたまるか。
>このあたりが焦点だろう。
構造化構文をすべて捨てるか?
約束事に則って物事を行う事の大事さを知っている人間が、なぜgoto利用に拘るのか理解できない。

>「gotoは割れ窓である」ということ自体を認めない。
簡単に乱用できて、乱用が破滅的事態を引き起こす物だという事はわかっていますか?
初心者/能力の低い人が逃げの手段に使う事がままある機能だという事はわかっていますか?
本当に意味のある使い方ならbreakのように誰か偉い先生がとっくに言語機能に組み込んでいるはずだと思いませんか?

268 :235:03/12/08 22:41
>>253
>一般に「gotoを忌避すべし」とされるのは、gotoの乱用は一般に
>コードの可読性を下げるからです。「それがルールだから」ではありません。
gotoの乱用が一般的にコードの可読性を下げるので、構造化というルールができました。
これは卵が先か、鶏が先かではありません。あきらかにgotoの乱用が先です。
(もともとはgoto...jump/branch命令しかなかったのですから当然です。)

>だから交通事故の抑止に対する合理性がないルールが
>仮にあるとすれば、そんなルールは破棄されるべきです。
つまり赤信号でも人がいなければ通行してよいとルールを改定すべきだと
言っているんですよね?
goto肯定派も明文化できるまともなgotoの利用法があるなら提唱すべきでは?
(breakやcontinueは少なくともそうでしょう。)
偉い先生は何故だれもあなた方のいう「正しいgotoの利用法」を提唱しないんですかね?

>>....(これを割れ窓のセオリーと呼ぶ。)
>呼びません。全然違うよ。恥を上塗りしないうちにググルがよろし。
はぁ?どこがどう違うの?>>251のような反論なら
こちらにも反論の余地があるけど、あんたみたいに「どこが違うのか」すら指摘できないのは
問題外なんだけど。

269 :仕様書無しさん:03/12/08 22:46
構造化はルールでは有りません。終わり。

270 :仕様書無しさん:03/12/08 22:47
235は人生の愉しみ方を知らない。

271 :仕様書無しさん:03/12/08 22:50
>>235は、日本のドライバーのほとんどが日常的に交通ルールを破っていることを
どう思っているんだろう?

272 :仕様書無しさん:03/12/08 22:50
>>262
おまえがJavaにポインタがあるかないか論争の仕掛け人だな。

273 :235:03/12/08 22:54
>>271
みんなが破っているから破ってもいいんだと言いたいのか?
まさしく割れ窓の一枚目が割られる瞬間だぞ。

言っておくが発信前に車両の前後左右および下を確認するのはルールだ。
下に子供がもぐりこんで遊んでいるのを見逃して殺してしまって裁判所で
「誰も発信前に車の下なんか見てる人居ませんよ」って言っても
お前は人殺しだぞ。

274 :仕様書無しさん:03/12/08 22:56
ええと、スピード違反のことを言ってるんだけど。

275 :仕様書無しさん:03/12/08 23:09
交通板に池

276 :251:03/12/08 23:14
>>267
>構造化構文をすべて捨てるか?
>約束事に則って物事を行う事の大事さを知っている人間が、なぜgoto利用に拘るのか理解できない。
「goto禁止が約束事である」ことを認めない。構造化構文は当然捨てないよ。なぜそう両極端に考える?
有用だと思う文は全て使うんだ。

>簡単に乱用できて、乱用が破滅的事態を引き起こす物だという事はわかっていますか?
>初心者/能力の低い人が逃げの手段に使う事がままある機能だという事はわかっていますか?
コードレビューをすることがgoto誤用の一番有効な防止策。
goto誤用のみならず他の「コードにおける破滅的事態を引き起こす物」にも有効だしね。
#わざわざ「誤用」を「乱用」に言いかえているのは「薬物乱用」という言葉のネガティブイメージを利用
#しようという無意識の戦略があったのかな?

>本当に意味のある使い方ならbreakのように誰か偉い先生がとっくに言語機能に組み込んでいるはずだと
>思いませんか?
breakは単なるgotoの機能限定版。
「本当に意味がある使い方が存在しない」のなら言語仕様にgotoは存在しないだろう。
言い換える。
cの言語仕様にgotoが存在するのは、言語設計者が「本当に意味がある使い方が存在する」と判断したからだ。

277 :仕様書無しさん:03/12/08 23:22
まぁ、gotoを使わないことは「ルール(それも法律と比較するような)」ではないわけだから、
その時点で>>235の論は成り立たないわな。もちろん、「gotoを使わないこと」をルールと
することを妨げているわけじゃないよ?

まぁ、敢えて>>235の比喩の下で言うなら、赤信号では必ず止まる事が「ルールでない」
世界で、「周りに誰もいないのに」必ず赤信号で止まれというのも、そりゃおかしいだろ
って事ですな。

>>235は、まず、構造化が交通ルールと比喩するに足る「ルール」であることを示してください。

278 :211:03/12/08 23:28
>>256
失礼。

>>268
>偉い先生は何故だれもあなた方のいう「正しいgotoの利用法」を提唱しないんですかね?
それは一言でいえば「不毛」だからじゃないでしょうか。
つまり(1)「『goto絶対に禁止』の弊害」を悟るのは、「gotoの乱用の弊害」を
悟るより遥かに易しい(ただし、普通の思考力があれば)し、(2)そもそもgotoが
有用な場面はあまりないから。

>はぁ?どこがどう違うの
だからググれと......。
「破れ窓理論」は、乱れた環境が犯罪に対する心理的な閾を下げる、
とする仮説。

一方、信号を守らないと事故に繋がるのは、不特定多数が「信号は概ね守られる」
という期待を前提に行動するから。環境は関係ない。

279 :仕様書無しさん:03/12/08 23:32
>>偉い先生は何故だれもあなた方のいう「正しいgotoの利用法」を提唱しないんですかね?
>それは一言でいえば「不毛」だからじゃないでしょうか。

というか、してるじゃん(新しい構文として)。
C以外は知らないのか?

280 :235:03/12/08 23:42
>有用だと思う文は全て使うんだ。
何度も繰り返しているが、その考え方が誰も居ない赤信号は通るべきだと主張する人間のやり方なんだよ。

>コードレビューをすることがgoto誤用の一番有効な防止策。
あんたがコードレビューをする時に使うgotoの正しい使い方の説明と間違った使い方の説明をしてみてくれ。
曖昧なものじゃなくて、本当に有用なら歴史の穴として構文に組み込むべきだし、
曖昧な物だったりすればgotoの乱用を引き起こすはじめの割れた窓だ。

#わざわざ「誤用」を「乱用」に言いかえているのは「薬物乱用」という言葉のネガティブイメージを利用
#しようという無意識の戦略があったのかな?
無意識じゃない。本当は薬物中毒者の比喩を出そうかとすら思った。
(これ以上抽象論になると余計わかりづらくなりそうなのでやめておいた)
薬物中毒者が「いつでもやめられる」と言いながら薬に手を染めていく様は
まさしく割れ窓の一枚目を放置する人間と同じだな。

>cの言語仕様にgotoが存在するのは、言語設計者が「本当に意味がある使い方が存在する」と判断したからだ。
だとしたら酷い判断ミスだな。
(Cの文法に判断ミスがないとは言わせない。関数ポインタの書式や配列の書式はカーニハン自らも反省しているようだし、
それ以外にもconstの位置などは随分とわかりづらいルールになっている。)
俺はCにおけるgotoはパフォーマンス上どうしてもgotoが使いたい時の為にあるのだと思う。
決してgotoを使ったほうが美しいとかわかりやすいとか、そういう理由で残してあるのではないだろう。
(あとトランスレータの目的語として使われたりする時も有効だと思うが、これは人間の仕事じゃない。)

>>251以外
今日は寝るので明日までに(少なくとも>>251くらいの)まともな反論を書いておけよ。

281 :245:03/12/08 23:47
おぉ。上手い具合にボロボロにされてる。

喩えを使って非難するやつってさぁ。ほんと反論が簡単だよ。
喩えを否定すればもうボロボロ。喩えなんて所詮喩えなんで、
違うといえば当然違うからねぇ。

282 :仕様書無しさん:03/12/08 23:49
なんか235が一番まぬけに思えるのはもれだけ?

283 :仕様書無しさん:03/12/08 23:57
んじゃ、そろそろ、悪質な使い方をされうるswitchの禁止の話でもするか?
あぁ、変数名が任意につけられるってのも悪質なコードが量産されて
「割れ窓の一枚目」になってしまう可能性があるから、禁止したほうがいいな。

…って前同じ事書いたような気がするな…
あの時は、C言語自体使うべきでないって結論だっけwww

284 :仕様書無しさん:03/12/09 00:00
藻前ら全員「プログラミング禁止」ってことで、結論は出たみたいだな。

285 :仕様書無しさん:03/12/09 00:00
>>281
そうそう。反論できないところには、本当に律儀に反論しないからね…
だから、我田引水だって言われてるのに…。

286 :仕様書無しさん:03/12/09 00:04
>>284
ついでに、悪質な言動や間違った言動をしてしまう自然言語も
「割れ窓の一枚目」を作らないためにも禁止したほうが良くないだろうか?

287 :211:03/12/09 00:04
>>283
そういう話がジョークで済まないところが日本の悲しいところだと思う。
別にコーディングに限らなくても。

手段を目的化してそれに固執する困った人が、周りにどれだけ多いことか。。

288 :仕様書無しさん:03/12/09 00:06
自由人気取ってんのかオマエwww

289 :仕様書無しさん:03/12/09 00:09
固執しない、ということと、自由に(=我侭に)振舞うということは違うね。
本当の自由は云々ってよく言われることでしょ?

290 :仕様書無しさん:03/12/09 00:13
さてさて、>>235は、無理な比喩とそれに基づく勝手な前提を取り除けば、
そんなに間違ったことは言っていないと思うので、まずそういう感じで出直して
もらえれば、かなり有意義な議論になるのではないかと思う。

291 :仕様書無しさん:03/12/09 00:24
とりあえず18才未満はgoto使用禁止という法律を作る所から始めては
どうか。

292 :仕様書無しさん:03/12/09 00:26
235から喩えとったら何もねーじゃねかよ

293 :251:03/12/09 01:45
>>280
#だいぶ興奮しているね。悪口が書いてあっても感情的になったら駄目だよ。眠れるかな?

>>有用だと思う文は全て使うんだ。
>何度も繰り返しているが、その考え方が誰も居ない赤信号は通るべきだと主張する人間のやり方なんだよ。
やり方って・・・。「誰も居ない赤信号は通るべきだと主張」なぞしていないぞ。
「私は、誰も居ない赤信号は通る」という主張だが。
私は290ではないが、>>290をレスしたい。正確には
×無理な比喩とそれに基づく勝手な前提
○勝手な前提とそれに基づく無理な比喩
と思うが。

>あんたがコードレビューをする時に使うgotoの正しい使い方の説明と間違った使い方の説明をしてみてくれ。>曖昧なものじゃなくて、本当に有用なら歴史の穴として構文に組み込むべきだし、
>曖昧な物だったりすればgotoの乱用を引き起こすはじめの割れた窓だ。
誤用か誤用で無いかの判断は一筋縄ではいかないよ。個人毎/プロジェクト毎に判断は違うだろう。
「曖昧」とは違う。多種多様なんだ。
gotoについてのコーディング規約が「極力使用しない」という曖昧な表現が多いのはこれが原因だな。
つまり「XXXのときだけ使用可」って書きたくてもXXXの部分が決められないわけ。
私の判断を聞いてどうなるかが理解できないが。「正しい使い方」の方を書いてみる。
多重ネストからのネスト直後への脱出と有限状態遷移の表現だ。それ以外は全部誤用だ。曖昧かな?
#前者は、gotoでなくreturnを使うほうがベターである場合も多い。
#そのときはプログラム設計の修正もしてもらうけどね。前者はjavaのbreakにあるね。


294 :251:03/12/09 01:46
>だとしたら酷い判断ミスだな。Cの文法に判断ミスがないとは言わせない。
総論は認める。だがgotoについては認めない。
#構造化構文+goto有りの言語はすべて判断ミスであるとの主張なの?

>俺はCにおけるgotoはパフォーマンス上どうしてもgotoが使いたい時の為にあるのだと思う。
ふーん。私はそういうケースにぶつかったことは無い。最近のコンパイラは優秀だしなあ。
というかそんな時はインラインアセンブラの使用が常道と思っていたが。

>決してgotoを使ったほうが美しいとかわかりやすいとか、そういう理由で残してあるのではないだろう。
うーん。何度も同じようなレスを書くのはいやだから白状する。
私は前スレの124だ。前スレの699と700がレスだ。
つまり、「gotoを使ったほうがわかりやすい場合がある」という主張だ。
少なくとも(私を含めて)複数の人間がそう表明している。
#あなたはもしかして前スレの828ですか。言っていることがとても似ている。

答えさせるばかりでなく、答えて欲しいな。>>161 への回答をお願いしたい。

295 :235:03/12/09 06:31
朝なので急ぎ足。想定範囲のみ答える。残りは帰ってきてから。

>>293
そうくると思った。誤用かどうかは酷く曖昧なんだ。
聖書読めよ。人が人を裁く事の難しさを考えろ。
もちろんそれはgoto否定派も同じだが、goto否定派には
構造化フロー制御という偉い先生が唱えてくれて一般に知れ渡った方法論がある。
人が生きるために法律というルールに寄り添わざるをえないように、
高級言語でのプログラミングでは構造化フロー制御から外れたら
生きている人間が生きている人間を裁かなければならないんだ。

296 :仕様書無しさん:03/12/09 06:52
多重ループから一気に抜けたいんですが、当然goto使いますよね

297 :仕様書無しさん:03/12/09 07:11
>>295
なんか、言ってることがむちゃくちゃなんだけど、大丈夫かなぁ?

へんしゅう-きょう -シフキヤウ [0] 【偏執狂】
⇒モノマニア

モノマニア [3] _monomania_
(1)一つのことに異常な執着をもち,常軌を逸した行動をする人。偏執狂(ヘンシユウキヨウ)。偏狂。
(2)一つのことにこること。また,その人。

>>296
「多重ループになるような設計が悪い」
「一気に抜けたくなるような設計が悪い」
否定原理主義的な模範解答です。問題のすり替え。

298 :仕様書無しさん:03/12/09 07:51
>>296
>>296
>>296
>>296
>>296
>>296
>>296
>>296


299 :仕様書無しさん:03/12/09 07:53
breakという原罪を背負ってコーディングしているのか。

300 :仕様書無しさん:03/12/09 07:59
>>296みたいに限定された使い方でもダメだとかいう奴は
たぶんbreakやcontinueやswitchも当然ダメだと言うんだろうなぁ
なんて効率の悪いやり方だ

301 :仕様書無しさん:03/12/09 08:11
>>300
「多重ループになるような設計が悪い」
「一気に抜けたくなるような設計が悪い」

↑あなたこれ理解できないの?

302 :仕様書無しさん:03/12/09 08:41
>>301
お前が理解してないことは理解してますよ?

303 :仕様書無しさん:03/12/09 08:52
>構造化フロー制御という偉い先生が唱えてくれて一般に知れ渡った方法論がある。
副作用のある変数の使い方もやめよう。偉い先生が唱えてますよ。
ルールです。反したら死刑。

304 :仕様書無しさん:03/12/09 15:47
>>295
>構造化フロー制御という偉い先生が唱えてくれて一般に知れ渡った方法論がある。
やっと判ったよ。
頭が悪くて自分で考えられないから
「なんか偉い人が言ってるから間違いない」と思い込む、
一種の宗教なわけか…そりゃ判り合える筈もないな。
そうか、構造化フロー制御か…

ところで君、オブジェクト指向に関して
どこかのスレで同様の頓珍漢な会話してなかった?

305 :仕様書無しさん:03/12/09 15:51
>304
こやつはどこのスレでもそうだよ(´,_ゝ`)プッ
ばか丸出しでかわいいやつさ。
でも飽きてきたな。

306 :仕様書無しさん:03/12/09 17:19
>ところで君、オブジェクト指向に関して
>どこかのスレで同様の頓珍漢な会話してなかった?
お前らはただ宗教論争がしたいだけちゃうんかと(ry

307 :仕様書無しさん:03/12/09 17:29
「勝手な前提とそれに基づく無理な比喩」
ところでオマイラ、↑の「勝手な前提」と「無理な比喩」ってなんだか分かってるかい?

308 :仕様書無しさん:03/12/09 19:26
>>301
ネタだよね?本気で言ってないよね?

309 :仕様書無しさん:03/12/09 19:32
「前方へ戻るgotoは、ちゃんとループを作る命令が整った言語が使える以上
あえて使う意味は無い」なら分かる。

「後方へ飛ぶgotoを使った方がシンプルにかつ分かりやすく記述できる場合
(特に深いループから一気に抜ける等)」
も禁止にしなければならない理由が分からない。




310 :仕様書無しさん:03/12/09 20:35
街中を素っ裸で歩いたら恥ずかしい。
なぜだろう? 自分だけ服を着ていないからか?

チンポを公衆の面前に晒すと捕まっちゃうわけだ。
それはそういう法律になってるわけで、チンポが恥ずかしいとか汚いとかそういう問題じゃなくて、
それは悪いことなんだよね。

なんでチンポ出して歩いちゃだめなんだろう? 別に恥ずかしくないからいいじゃん。
うまくいけば俺のディックに一目惚れした女が寄って来るかも知れないし、そしたらすばやくファックできるし、
ションベンも1ステップで済むぜ。
素っ裸で街歩いて悪い理由が見つからない。


というわけでgoto使っちゃダメよと偉い方が言ってんだから素直にそれに従えよ。
みんながgoto使わないんだからお前も使うな。社会の秩序を乱して歌舞いたつもりか? 粋なツモリ?
思考を停止しろ。gotoは使わない。思考を停止しろ。gotoは使わない思考を停止しろgotoは…………

それではハッピーファッ王!

311 :仕様書無しさん:03/12/09 20:44
よしわかった!これからはforやwhileでできることでも全部gotoで書くよ。

312 :仕様書無しさん:03/12/09 20:58
>>311 ifが抜けているよ

313 :211:03/12/09 20:59
前方/後方ってのはあんまり関係ないのでは?
continueとかbreakの機能からの連想でそう言いたくなるのは理解できますが。

goto使いたくなるときって、だいたい同じ条件式を2回(n回)
評価したくないときじゃないかな。

314 :仕様書無しさん:03/12/09 21:00
>>310
そういう「法律」を認めない

315 :仕様書無しさん:03/12/09 21:01
>>314
タハー!

316 :仕様書無しさん:03/12/09 21:28
そうだお前、俺の腹の中にしょうべんしろ。


317 :仕様書無しさん:03/12/09 21:44
>>310
ヽ(・∀・)バカハケーン(・∀・)ノ

勝手な前提と無理な比喩どころじゃねぇなwww

318 :仕様書無しさん:03/12/09 21:50
まぁ、権威主義を認めるとしても…
偉い人が「gotoは絶対使ってはダメ。これはルールです。」(意訳)と
言っているということだけど、具体的なソースを示してもらえませんか?

319 :仕様書無しさん:03/12/09 21:50
>>317

320 :仕様書無しさん:03/12/09 21:51
あー、認めるとしても→認めるという前提だとしても、ね。

321 :仕様書無しさん:03/12/09 21:54
必死だなwww

322 :仕様書無しさん:03/12/09 21:57
>>321

323 :仕様書無しさん:03/12/09 21:59
基本的な処理をgoto無しで書いたとしても例外処理にgotoを使ってしまう。
アルゴリズムで対処できない例外として処理を分割したいから。
人間もパソコンもデータも完璧で間違いを犯さないならgotoを排除できるかもしれない。

324 :仕様書無しさん:03/12/09 22:01
だから。。。構造化プログラミングてのはな(ry

325 :仕様書無しさん:03/12/09 22:02
プ

326 :仕様書無しさん:03/12/09 22:04
>>313

ってゆーか「例外」処理だな goto が必要と思う時

327 :仕様書無しさん:03/12/09 22:11
ここにも冬厨が……

328 :仕様書無しさん:03/12/09 22:13
>>317
おまえ面白くなーい
帰っていいよ

329 :仕様書無しさん:03/12/09 22:31
>>313
> goto使いたくなるときって、だいたい同じ条件式を2回(n回)
> 評価したくないときじゃないかな。
int count = 0;

loop:
  if(1){
  }else{
  }
  if(count > 10){
    count++;
    goto loop;
  }

330 :309:03/12/09 22:36
前方へのgotoは認めません

331 :211:03/12/09 22:40
>>329
???何が言いたいの?
なんでそこでわざわざgotoなんか使ってコードの可読性を下げる必要があるのか、
理解できませんが。。

332 :仕様書無しさん:03/12/09 22:41
「前方」って書くと>>329じゃなくて例外処理みたいな場合を思い浮かべるんだけど、どう?
前方参照、後方参照の前方という解釈だとね。

でも、まぁ、「先頭に戻る」ためのgotoを使うべき場面って、思いかないね。

333 :仕様書無しさん:03/12/09 23:38
とんだネタスレだな

334 :仕様書無しさん:03/12/09 23:41
>>333
gotoだけにな

335 :235:03/12/09 23:52
>>293
>だいぶ興奮しているね。悪口が書いてあっても感情的になったら駄目だよ。眠れるかな?
おかげさまで皆様の五寸釘の呪いにもめげずぐっすりと。

>>だとしたら酷い判断ミスだな。Cの文法に判断ミスがないとは言わせない。
>総論は認める。だがgotoについては認めない。
>#構造化構文+goto有りの言語はすべて判断ミスであるとの主張なの?
パフォーマンス上の都合とか。

>#あなたはもしかして前スレの828ですか。言っていることがとても似ている。
前スレが落ちているので確認できない。でも前スレの最後の頃からいるからそうかもしれない。

>答えさせるばかりでなく、答えて欲しいな。>>161 への回答をお願いしたい。
名無しで答えてた。
>>172 >>182 >>184 >>186 >>187 >>189 >>193 ここらへん。

>>303
変数のエイリアシングの事?

336 :235:03/12/09 23:53
>>304
>「なんか偉い人が言ってるから間違いない」と思い込む
これをそのまま返せばgoto肯定派は
「偉い人が言ってるけど(全然偉くも有名でもない)俺にとって不愉快な話だから、間違っているに違いない」と思い込んでるわけだ。
俺の書いた>>266の後半部分に答えられるか?

>ところで君、オブジェクト指向に関して
>どこかのスレで同様の頓珍漢な会話してなかった?
自らトンチンカンだと思って話す奴はいないだろう。
goto肯定派は自分でトンチンカンだと思っていないだろう?

>>305
誰?引きこもり?妄想激しすぎるんじゃないの?

>>310
あんたは思考を再開したほうがいいんじゃないか(藁。
何故gotoを使ってはいけないのかもう一度よく考えろよ。

>>318
そう読めたあなたの我田引水な思考回路のソース(ファイル)を晒して下さい。

>>323
人間が間違いを犯すからgotoを排除するんですよ。

337 :仕様書無しさん:03/12/09 23:58
>>335
>>303
>変数のエイリアシングの事?
関数型言語で言われてることだね>副作用

338 :仕様書無しさん:03/12/10 00:05
>>318
"Go To Statement Considered Harmful" Edsger W. Dijkstra
http://www.acm.org/classics/oct95/

339 :仕様書無しさん:03/12/10 00:09
goto使い = 馬鹿

340 :仕様書無しさん:03/12/10 00:19
>俺の書いた>>266の後半部分に答えられるか?

(初心者ゆえ)gotoを恐れずに使い

(自分のコードを見返しor他人に指摘されて)自分のgotoの使い方の間違いに気づく

gotoをめったに使わなくなる(が、過去の経験から問題ない使い方も知っている)

ってのが、普通のプログラマのたどる道だと思うが。
否定原理主義の人は、こういうプロセスを踏まず、いきなり「使ってはならない」から
始まるから不自然に感じるんだろうね。そして、結果バランスを欠いた思想を持って
しまう(人もいる。>>297参照)。

341 :仕様書無しさん:03/12/10 00:21
(goto使い = 馬鹿) = 馬鹿の一つ覚え

342 :仕様書無しさん:03/12/10 00:23
>>335は、議論として、なかなかいい方向だね。
変な比喩なんか使わずに、そういう風にレスを続ければよかったのに…

343 :仕様書無しさん:03/12/10 01:50
>>331
>>313を読んだら分かるんで無い?

>>340
>>297の多重ループは設計上、どうしようも無い時がもしかしたら、あるかもしんない。
しかし、「一気に抜けたくなる設計」ってのは極悪じゃないか?

それと全然、関係ないのだが「普通」と言うことは軽々しく使わないほうが良い。


344 :251:03/12/10 02:04
>>338
ありがとう。ああやはり。私の記憶は間違っていなかった。
Go To Statement Considered Harmful
の内容は単に「構造化プログラミングの提唱」だ。
「gotoは有害を引き起こす」というのは単なるキャッチコピーだ。
#ダイクストラは自らのキャッチコピーに起因するgoto論争に嫌気がさして
#晩年はgotoと聞いただけで不愉快になったとも聞く

345 :仕様書無しさん:03/12/10 02:38
一気に抜けたくなる設計

for(){
for(){
for(){
処理
if(ループを一気に抜けたい状態が発生) goto loop_exit;
}
}
}
loop_exit:
後始末


他にどーしろってーの?

346 :仕様書無しさん:03/12/10 02:52
>>345
後始末をしてからreturnという方法もある。
が、ここはひとつgoto禁止論者のレスを待ってみようか。

347 :けっ:03/12/10 03:33
フラグ=0
for(){
for(){
for(){
処理
if(ループを一気に抜けたい状態が発生){
フラグ=1;
break;
}
}
if(フラグ) break;
}
if(フラグ) break;
}
後始末



まぢっすか?

348 :仕様書無しさん:03/12/10 03:37
検索処理なら単一のメソッドにしてReturnだろ普通。
getIndexとか。

349 :仕様書無しさん:03/12/10 03:47
>>345
reloadしたら被ってるけど。カキコしてみよ。

boolean proc() {
 boolean result = true;
 for( ; && result ; ){
  何か処理
  if (proc_next_nest()) {
   何か処理
  } else {
   何か処理 /*なくてもいいけど、可能性として*/
   result = false; /*for()の3項目めが実行されちゃうけど、"break;"も避けてみました*/
  }
  /*ここには何も書かない*/
 }
 
 if (result) {
  正常終了処理
 } else {
  異常時後始末
 }
 /*ここには何も書かない*/
 return result;
}

これでネスト構築、とか。ヘタレ過ぎですか?

350 :仕様書無しさん:03/12/10 05:38
大昔のBASICかFortranからプログラミングを始めた人がいるスレはここですか?

351 :仕様書無しさん:03/12/10 05:49
>>346
関数の最後以外のreturnはgotoと似たようなもんですよ

352 :235:03/12/10 06:00
>>340
覚えているかい少年の日の事を
暖かい温もりの中で目覚めた朝を
アムロ 振り向くなアムロー!

いやすまん。なんかこの歌思い出した。
でも本当に初学者の頃を思い出してみていただきたい。
>(初心者ゆえ)gotoを恐れずに使い
>過去の経験から問題ない使い方も知っている)
初学者が問題ないgotoの使い方なぞ意識したりできるだろうか?
俺はベーマガのリスト打ち込んでた頃は本当に無茶苦茶だったんだが。
で、gotoの正しい使い方とは何かなんて考える間もないまま
構造化理論という世論に飲み込まれてしまったよ。

353 :仕様書無しさん:03/12/10 06:18
ばかもの
forの終了条件に一気に抜ける条件も加えるのじゃ


354 :仕様書無しさん:03/12/10 06:54
Dr.D降臨

355 :仕様書無しさん:03/12/10 07:37
>>353
for文は
for(i = 0; i < max; i++)
以外の形で使うことはあまり推奨されていません。

356 :仕様書無しさん:03/12/10 07:41
>>355
ハァ?
何言ってんの?
お前ローカルルールか?

357 :仕様書無しさん:03/12/10 07:52
>>352
>構造化理論という世論に飲み込まれてしまったよ。
ご愁傷様

358 :仕様書無しさん:03/12/10 07:55
>>343
>>297の多重ループは設計上、どうしようも無い時がもしかしたら、あるかもしんない。
>しかし、「一気に抜けたくなる設計」ってのは極悪じゃないか?

>>297の前半だけ読んでね。後半はタダの皮肉だから。
(否定原理主義者には通じないみたいだけど。)

359 :仕様書無しさん:03/12/10 08:00
>>356
こう書けばC言語知ってる奴は一瞬で理解できるんだけど
それすら知らないとは・・・

360 :仕様書無しさん:03/12/10 08:26
>>359
同意。
>>355は全面的には支持できないけど、>>353は明らかに「for文の誤用」だ


361 :仕様書無しさん:03/12/10 08:56
>>336
>>318
>そう読めたあなたの我田引水な思考回路のソース(ファイル)を晒して下さい。

うん?偉い先生は「ルールにしろ」とは言っていないってこと?
だったら、「構造化はルールであり絶対外れてはならない。」ってのはどこから出てきたんだ?
>>335が提唱しているだけ?

362 :仕様書無しさん:03/12/10 09:05
`>>343
>それと全然、関係ないのだが「普通」と言うことは軽々しく使わないほうが良い。
今は促成栽培が「普通」だからねw
(だからgoto禁止を「ルールとして採用」するところが多いのは納得するところだ。)

>>346
>後始末をしてからreturnという方法もある。
>が、ここはひとつgoto禁止論者のレスを待ってみようか。
後始末を2箇所(以上)に書かなければならないことの危険性はわかるよな?

363 :346:03/12/10 09:13
>>362
関数化する

364 :仕様書無しさん:03/12/10 09:15
>>361
>>344

365 :仕様書無しさん:03/12/10 09:28
>>363
そしてたいした意味も無く関数が増えるのか?糞コードだな。
いつもそういうコード書いてるのか?

366 :仕様書無しさん:03/12/10 09:40
>>365
「マクロ化する」って言っても「糞コードだな」と返すんだろう。
関数に意味が有るか無いかはそのプログラムのコンテキストに依存する問題で
一概に「意味が無い」と断ずるのは「強弁」だ。
そんなことより>>345へのレスを書いてみたらどうなんだ。

367 :仕様書無しさん:03/12/10 09:45
>>359
ちなみにどんな使い方をするとダメだって?

368 :仕様書無しさん:03/12/10 10:01
for(int i = 0, loop = TRUE; i < 100 && loop; i++){
  for(int j = 0; j < 100 && loop; j++){
    for(int h = 0; h < 100 && loop; h++){

    }
  }
}

例えばこういうこと?

369 :仕様書無しさん:03/12/10 10:24
>>368
たぶん、そういうことだ。しかもこの方法は、
「最内周での脱出しなければならない事象の発生以降に実行される文がある」
場合は使えない。
まあbreakすればいいんだが

370 :仕様書無しさん:03/12/10 10:44
そんなの、こうすればいいじゃん

LOOP: for(int i = 0; i < 100; i++){
  for(int j = 0; j < 100; j++){
    for(int h = 0; h < 100; h++){
     break LOOP;
    }
  }
}


371 :仕様書無しさん:03/12/10 10:51
>>370 このスレタイの言語はcだぞ

372 :これで万事解決:03/12/10 11:03
#define breakex goto

373 :仕様書無しさん:03/12/10 11:12
>>366
そういうマクロの使い方は好きではないが、無意味な関数化よりかはましだろう。

>関数に意味が有るか無いかはそのプログラムのコンテキストに依存する問題で
>一概に「意味が無い」と断ずるのは「強弁」だ。
「後始末が複数になることの回避」のため(だけ)の関数化が無意味だといってるの。

コンテキストに従い関数化し、結果としてgotoがなくなるのであれば、もちろん問題
なんかあるはずが無い。例えば、「後処理」が本来呼び出し側で実行される処理であ
れば、処理をそちらに移した上でループの最内周からreturnするのは全然間違ってい
ない。ここで無理にgotoを使っても読みにくくなるだけだ。

あと、俺はアンチgoto否定論者なので、俺的には>>345は正解。

374 :366:03/12/10 11:31
>>373
大筋は合意だが。
「後処理が本来呼び出し側で実行される処理」であるか否かの判断はなにを基準に行う。
これは「呼び出し元において、後処理に必要な情報が変数スコープとして見えているか否か」か?
見えていなければ下位関数化することに意味があり、見えていれば下位関数化することに意味が無い。
ということでよろしいか。

375 :373:03/12/10 12:10
>>374
後処理に必要な情報がどっちの関数に「所属」しているかによる、かな?
情報を処理する責任の問題。「コーディングのテクニック」とは別問題だと
考える。

というか、>>373は「関数化」の意味を間違えてたっぽいか。
>>345のgotoをなくす方法としては、
・必要な情報を作成し、>>345のような関数を呼び、戻ってきたら作成した情報の
 後処理をする(wrapper関数作成型?)
・後処理をする関数を作成し、returnの前で必ず呼ぶ(下位関数作成型?)。
の2種類あるわけだけど、>>373は前者。>>366は後者だよね?

後者は前処理との対称性が崩れるので、俺はよろしくないと思う(マクロも同じ理由)。
まぁ、必要な情報を構造体化して、前処理も関数化すれば、問題は無いと思うが
(構造体化するのは、必要な情報の型や数が変更される場合の保守性を考えて。
この場合、「必要な情報」を処理する責任は前処理、後処理関数にある。)

ただ、その場合でも、returnの前に必ず同じ文を入れないといけないわけで、
>>362で指摘した危険性からは逃れられないね(最小化はされるけど)。
なので、こういう場合に限りgotoを使った方がよいというのが、俺の結論。

376 :211:03/12/10 12:44
なんでもっと抽象水準を上げて考えられないかね。
>>375
>こういう場合
それじゃ条件が限定されすぎじゃないですか?

>>345って、要するに同じ(ループを抜けるための)条件式を複数回評価するのは
保守性が悪い、あるいはエレガントじゃない、ってことでしょ。

377 :373:03/12/10 12:51
微妙に論点が違ってる罠。

378 :366:03/12/10 13:57
対照性か。言い事がわかってきたよ。
>後処理に必要な情報がどっちの関数に「所属」しているかによる、かな?
>情報を処理する責任の問題。「コーディングのテクニック」とは別問題だと
>考える。
確かに。プログラム設計方法論の問題だ。

親関数で
 前処理関数参照
 本処理関数参照
 後処理関数参照
と順次参照するのがbetterだという見解だな。
以下の部分を良く読んでくれ。
>>345が親関数なのかそれとも本処理関数なのかのどちらにみなすか
によって、判断が違ってくる。
あなたは345が本処理関数だと思っていた。私は345が親関数だと思っていた。
どうよ?

>ただ、その場合でも、returnの前に必ず同じ文を入れないといけないわけで、
>>362で指摘した危険性からは逃れられないね(最小化はされるけど)。
>なので、こういう場合に限りgotoを使った方がよいというのが、俺の結論。
「return 後処理関数参照」でも駄目か?

379 :仕様書無しさん:03/12/10 14:02
ごらぁコーダ!
バカな屁理屈ばっかこいてないで
とっとと仕事しろ!

あっお前のソース全部書き直しな。

380 :仕様書無しさん:03/12/10 14:32
長いものに巻かれたい人へ
http://pplab.snu.ac.kr/courses/PL2001/papers/p261-knuth.pdf
こっちはまだ御存命のアルゴリズムの大家だよん。
元々、クヌース先生はgoto擁護派なんだ。

381 :仕様書無しさん:03/12/10 16:01
有り余る時間があればgotoは不要かもしれない
差し迫る納期との戦いではgotoでやっつけ仕事もやむなし
一般人は理論より実践が大切

382 :仕様書無しさん:03/12/10 16:03
キチがった中年のアルゴリズムの大家とやらに巻かれると妊娠でもするのか?

383 :仕様書無しさん:03/12/10 16:37
>>382
さあ?。
でも偉い先生の発言が即「法律」とか「ルール」とか思う香具師もいるようだから、
選択肢を増やしてやるのも医院んじゃネ?

384 :仕様書無しさん:03/12/10 16:38
社会人の俺にとってはスヌース大先生よりも仕事を依頼してくるクライアントの方が格上。
クライアントの要求を満たすためならgotoでも何でも使ってやる。

385 :仕様書無しさん:03/12/10 16:45
マンコムの要求を満たすならバイブでも何でも使ってみたい。

386 :仕様書無しさん:03/12/10 20:46
君は、gotoだけでプログラムを書けるか?

387 :仕様書無しさん:03/12/10 20:57
>385
マンコムからのRFPを提示てくれ
検討してみる。

388 :>>386:03/12/10 22:01
if文も許されるものなら。
後、普通の代入と計算と。

389 :仕様書無しさん:03/12/10 22:19
cでなら書ける。

390 :仕様書無しさん:03/12/10 22:43
いまどきフロー書いてるウチの職場ではgotoなど当たり前。
ラベル名が番号だったり、ラベル1コつけるのにハンコが4つ、だったりね、
あははははは・・・・

391 :仕様書無しさん:03/12/10 23:04
ハンコwww

392 :仕様書無しさん:03/12/10 23:04
>>390
気の毒だが
当然ながらフローチャートでも構造化は出来るぞ

393 :仕様書無しさん:03/12/10 23:26
おお、今ってどこもフロー書いてないのか?

394 :仕様書無しさん:03/12/10 23:27
PAD図だろ?

395 :仕様書無しさん:03/12/10 23:29
>>393
せいぜいシーケンス図(?)とか
状態遷移図or表とか

396 :392:03/12/10 23:30
>>393
書いてないよ。ところでツール使ってで書いてるんだよね。
まさかテンプレート使って手書きじゃないよね。

397 :仕様書無しさん:03/12/10 23:37
ここでfor文の多重ネストからgotoで抜けるとか言ってる奴ってバカ?
while文とかdo while文とか知らないの?
頭わるーい(w

398 :仕様書無しさん:03/12/10 23:41
恥ずかしい香具師

399 :235:03/12/10 23:41
>>380 >>383
クヌースはA級永久戦犯。
そもそも俺はアルゴリズム厨は好きじゃない。
構造化もダイクストラが偉い先生だから有用なのではない。
法律ではなく法則だと前スレで書いた。
ルールという言葉から強制しか思い浮かばない己の心の貧しさを恥じろ。

400 :373:03/12/10 23:48
もうなんか>>235たんはどうでもイイや。

401 :仕様書無しさん:03/12/11 00:13
>>394-396
いや、漏れはまだ現場を知らないアオい香具師だから・・・
どんな参考書読んでも「フロー書け」みたいな感じになってるんでね。
あのマンドクセーのが無いなら少し安心だよ

402 :仕様書無しさん:03/12/11 00:36
>>399
あのさあ、単に「A級永久戦犯」とか「好きじゃない」だけじゃ
なにを言ってるかが全然わかんないんだけど。
もう少し理解出来るように書いてくれないかなあ。

403 :仕様書無しさん:03/12/11 00:43
>>402
もう相手すんなって。

404 :仕様書無しさん:03/12/11 00:46
ある法則が成立するからといって、それが常に最適解を提供するとは限らない。

405 :前スレ124:03/12/11 01:30
>>404
概出ですよ。それとも偶然の一致ですか?

406 :仕様書無しさん:03/12/11 01:49
前スレまで見てられるかよ。

407 :仕様書無しさん:03/12/11 06:38
>>402>>403>>305
藻舞勝てなくなるといつもそればかりだな。

408 :402:03/12/11 09:54
>>407
なにいってるか和姦ね。
藻舞、かわりに>>399がなにいってるかを説明してくれ

409 :仕様書無しさん:03/12/11 10:43
俺は、>>399の最後の行で幻滅した。
散々法律と比較しておいてそれかYOwってな。

410 :仕様書無しさん:03/12/11 12:55
goto を使わないよう等値に変換したときのデメリット
(実行速度の低下、不要なブレークダウンの発生、
シーケンシャルな処理の分断、etc) よりも
莫迦が goto を乱用した場合のデメリットの方が
インパクトが大きい、とでも思ってるんじゃない? >>235 って。
まあ思うのは勝手だから、放っといてあげよう。

…ふと思ったんだが、>>235
  1. 最近になって構造化 COBOL に触れて感激した人
  2. 30年前からタイムスリップしてきて、その間の議論を知らない人
のどちらかじゃないかと思うんだけど、あってる?

411 :仕様書無しさん:03/12/11 13:02
235はバカだが
410は論外だな。

412 :仕様書無しさん:03/12/11 13:41
>莫迦が goto を乱用した場合のデメリットの方が
>インパクトが大きい、とでも思ってるんじゃない? >>235 って。
実際、大きいよ。

同様に
・バカが意味不明な変数名をつけたときのデメリット
・バカが不用意にポインタを乱用したときのデメリット
・バカがマクロを乱用したときのデメリット
・バカがforやwhileの条件に何でもかけることを乱用したときのデメリット
・バカが不用意に3項演算子を乱用したときのデメリット
・バカがフラグ変数を乱用(多様)したときのデメリット
・バカが保守性も解析性も悪いC言語コードを乱発したときのデメリット
も大きいな。

つまりは、そういう話だ。

413 :仕様書無しさん:03/12/11 13:54
>>410
>goto を使わないよう等値に変換したときのデメリットよりも
>莫迦が goto を乱用した場合のデメリットの方がインパクトが大きい、とでも思ってるんじゃない?
235ではないが、思っている。
だからこそ、goto使うべきところでは使うべきだし、それ以上にgoto誤用は絶対に防止すべきなんだ。
「goto使用禁止を規約にすることは反対」というスタンス。

>1. 最近になって構造化 COBOL に触れて感激した人
いやベーマガとか言ってるからコボラじゃないと思うよ。
#「構造化 COBOL」ってモジュールコンパイルできる?
>2. 30年前からタイムスリップしてきて、その間の議論を知らない人
俺も1968から始まったgoto論議について、内容までは白根。
ただプログラミング始めてから今までのあいだに、
ああいう宗教みたいな信念が形成されたんじゃないの。

414 :仕様書無しさん:03/12/11 13:57
というか、一人で全部作ればいいじゃない。
今時のプログラミング環境はそれが出来るくらい秀逸でしょ。

415 :仕様書無しさん:03/12/11 14:04
>>412
×・バカが意味不明な変数名をつけたときのデメリット
○・バカが意味不明な識別子をつけたときのデメリット

それと
・バカがグローバル変数を乱用したときのデメリット
・バカが環境変数を乱用したときのデメリット
を是非とも追加してくれ。

結局、最後の
・バカが保守性も解析性も悪いC言語コードを乱発したときのデメリット
に集約されるんだけどね。

416 :仕様書無しさん:03/12/11 14:25
>>414
もっと発言してくれ。
「若い」ということがどういう事であったのかを、もっと思い出したい

417 :!414:03/12/11 15:49
intは2バイトだろ?

418 :仕様書無しさん:03/12/11 16:48
>>416
社内失業者でつか?

419 :416:03/12/11 19:00
>>418 だったらいいんだけどね

420 :仕様書無しさん:03/12/11 19:33
なんだ、ただの失業者か。

421 :418:03/12/11 20:51
既にもう何年も前から >>414 の意見があながち無闇でもなくなってますよ。
個々のモジュールを小さく設計しておいて、腐れきったコードはばっさり捨てればそれでいい。
もちろんメンテしながら長く使えるコードを書いといたほうが生産性は高くなるわけだが
解読不能なほどまでになったものを無理に残すより、イチから作り直したほうが早い。
読めなければ他人のコードを読む必要は無い。1人で開発しているのと同じ。

営業、SE、管理職が客の言葉をプログラマーのとこまで、一字一句そのままに運んで
今すぐ修正作業にとりかかれと要求するから、プログラムはグチャグチャで納期がノビノビするんです。

今どき goto を使うなだのなんだのウダウダ言ってるのは、いわずもがなで既に過去の人。
まったく別の業界に転職するのが最善の選択肢。

422 :418:03/12/11 21:00
>>412
・バカが保守性も解析性も悪いC言語コードを乱発したときのデメリット

これ以外は、むしろ >>412 の頭が悪くてコードを読めないんじゃないかと思うが、どうだ?

保守性とか解析性とかと goto やら他の文法的なものが関係あると思っているようじゃ、
今まで何年やってようが >>412 の履歴書は既に古紙だ。
他の業界に転職して、プログラミングは趣味にとどめておけ。

423 :211:03/12/11 21:08
>保守性とか解析性とかと goto やら他の文法的なものが関係あると思っているようじゃ、
>今まで何年やってようが >>412 の履歴書は既に古紙だ。
なんかネタでも釣りでもなく、本気でこう思ってる悪寒。。。
それは把握・識別能力が常人のそれを遥かに超える天才ゆえにか、
はたまたその逆なのか........。

424 :C++忠 ◆IvraPLuPLU :03/12/11 21:13
若い方なのではないでしょうか?
BASICやCOBOLのgotoだらけのコードを呼んだことのない人は
gotoに対して生理的な嫌悪感などは抱いていないのかもしれません。

425 :仕様書無しさん:03/12/11 21:32
ここはバカ大集合スレか?(´,_ゝ`)

426 :418:03/12/11 21:42
いま >>1 から順に読んだけど、勝手に感想を述べると
「goto を使うな」は「コメントを書け」と同じだ。
無理に goto を使わないように書き直したり、
無闇矢鱈とコメントを書けば、 むしろコードの可読性が悪くなる。
何年現場にいようとプログラミング言語の読書きができない、
言ってるバカの知能程度を晒しているだけのこと。
そんなバカを管理職にして部下をつけてると、会社があぼーんするぞ。

ほな さいなら

427 :仕様書無しさん:03/12/11 21:48
http://www.sessame.jp/workinggroup/WorkingGroup2/StructuredAnalysis.html

おまいらの大半はここのメイビー君だろ。

428 :仕様書無しさん:03/12/11 21:50
>>424
いっぱい読んだこと有るけど、生理的嫌悪など抱きませんが?
書いた人でなく、言語全体でもなく、gotoに焦点を当てる理由を聞かせて?

429 :仕様書無しさん:03/12/11 21:59
gotoを使わないのは手段であって目的ではない
>>424はそこを勘違いしている


430 :仕様書無しさん:03/12/11 21:59
>>423
>それは把握・識別能力が常人のそれを遥かに超える天才ゆえにか、
>はたまたその逆なのか........。
もちろん、自分のプログラムしか見たことないからに決まってるじゃん。
独りで出来るんだから、他人のプログラム解析する必要も無いわけだからな。

431 :仕様書無しさん:03/12/11 22:01
>>424
つまり、Cを使いこなせない人が自分の勝手な嫌悪感を判断基準にして
プログラムを組んでいるというわけですね?

432 :仕様書無しさん:03/12/11 22:45
・・・とか反論してると、反論した人はgotoを使いまくるという前提のものに再反論
してくるに100goto。あ、反論じゃないとか話題を変えて逃げるのにも150break。

433 :仕様書無しさん:03/12/11 22:54
素朴な疑問だがcでgoto使いまくりの奴はいるのだろうか?
いるならどのようなプログラムを書いているのか見てみたい

434 :仕様書無しさん:03/12/11 22:56
1関数が2000行くらいあって、その中でgotoで行き来しているプログラムなら見たことある。

435 :251:03/12/11 22:56
さいならって書いてあるから418はもう来ないかな

>>421
>解読不能なほどまでになったものを無理に残すより、イチから作り直したほうが早い。
正論だ。だがこれはコストの問題だ。「イチから作り直したほうが早い」が事実だとしても
次回の保守はどうする。また「イチから作り直したほうが早い」と言うか?
一人の人間に延々といくつかのプログラムを保守させ続けることなぞ出来はしない。

>>422
>>412 の頭が悪くてコードを読めないんじゃないかと思うが、どうだ?
思わない。あなたに保守不能なコードを見た経験があろうとは思えない。

>>426
>「goto を使うな」は「コメントを書け」と同じだ。
支持。
そこまでの洞察力を持っていながら「>>422のような頓珍漢なことを言う」という事実が、
やはり「経験が無いから」という類推の根拠となっているんだ。
私が、「わかりやすいプログラムスレ」で「コメントは通常、あまり書かない」と書いたら大叩きされたが。

>>429
その手段は常にその目的に適合するのかな?
あなたがフラグを全く作成しないという力量があるなら、支持できる。

>>430
私もそう思う。

436 :仕様書無しさん:03/12/11 22:59
結論:場合による。
-----------------終了----------------

437 :434:03/12/11 23:01
>私が、「わかりやすいプログラムスレ」で「コメントは通常、あまり書かない」と書いたら大叩きされたが。

>>434のプログラムには1行毎にコメントがついていたよ。
a = 12345;   /* aに12345を代入する */
とかそういうの。

438 :仕様書無しさん:03/12/11 23:08
アセンブラ並だな。

439 :仕様書無しさん:03/12/11 23:14
潔癖症だが掃除が出来ずゴミ屋敷に住んでいるタイプと見た

440 :251:03/12/11 23:38
>>428
えっと、それには歴史的な経緯がある。
1968年という大昔にダイクストラという計算機科学者が>>338の論文を書いた。
その頃のプログラミング言語は構造化構文を備えたものは
(殆ど?)無かったので当時のPGはこれを無視したようだが。
その後、ダイクストラ自らの手によるalgolを初めとして、
構造化構文を備えた言語が次々と誕生した。
またダイクストラのみならず、多数のいわゆる「伝道者」が
>>166のような援護射撃を行い、構造化プログラミングを提唱し、現在に至る。

gotoを備えていないのはメジャーな手続き型言語ではjavaだけだ。
つまりgotoは言語を超えてPG全体に関係する問題であるわけ。
構造化構文を備えていない言語を使っていたPGが
構造化構文を備えている言語の使用を余儀なくされたときから(あるいはもっと早く)
上記の論文の題名が刺激的であるという事実も拍車をかけ、
goto論争は始まった。そして今も続いている。

#記憶だけで書いてるから間違いがあったら指摘してネ

441 :仕様書無しさん:03/12/11 23:42
なぜgotoが憎いのか?

442 :仕様書無しさん:03/12/11 23:43
もう業務でC言語を使う用途は速度を要求される物ばかりだから、
Cで書く時は構造化、関数化はなるべくしないように意識をしている。
いくらコンパイラの最適化が進化したとはいえ、関数呼び出しまで最適化はしないからな。


443 :仕様書無しさん:03/12/11 23:49
>>440
つまり、そのgoto論争に嫌気が差して、gotoという単語を見るだけで気分が悪くなった
らしいダイクストラと同じような症状になっていると?

でも、そう考えると
>BASICやCOBOLのgotoだらけのコードを呼んだことのない人は
が謎だなぁ…

444 :仕様書無しさん:03/12/11 23:51
>>428
なに今頃マヌケな事言ってんだコイツは…

445 :仕様書無しさん:03/12/11 23:58
「今頃」と「マヌケ」について、それぞれ解説をお願いします。

446 :C++忠 ◆IvraPLuPLU :03/12/11 23:59
>>428
> 書いた人でなく、言語全体でもなく、gotoに焦点を当てる理由を聞かせて?
書いた人はもう居なかったり、知らない人だったり。
言語全体はgoto以外は目立った不満はなかったり。
でもそんな事よりも

gotoを使ってメンテナンス不能なプログラムを書いても
「動けばいいだろ」がまかり通ってしまう、
そんな現実に対して嫌悪感を抱いているのかもしれませんね。

まだCOBOLerだった頃の思い出なぞ含めながらのレスでした。

447 :C++忠 ◆IvraPLuPLU :03/12/12 00:01
完全に蛇足ですが、C++使いではgoto使う人にあったことがないです。
COBOLerは(PERFORMがなかった当時の名残かもしれませんが)みなさんgotoがお好きなようで。


448 :仕様書無しさん:03/12/12 00:04
>>446
それは、goto以外の原因でメンテ不能に陥っているプログラムを経験したことないからでは?

449 :C++忠 ◆IvraPLuPLU :03/12/12 00:15
>>448
あるいはそうかも知れませんね。
でも識別子などはエディタの置き換えで
わりと簡単に改善できたりします。

PGの能力が低くてgotoを悪用しているケースは
人材が不足している所では多いでしょうし、
構造的にダメなプログラムは
つじつま合わせでgotoを使っている場合もあったりと
ダメなプログラムでgotoを見かける確率が
高いのではないかと思いますよ。
で、何をしているのか見極めて直すのが結構手間がかかるんですよ。

結果、悪いプログラムでよくみるgotoは、
そんなに悪くない使い方でも生理的に嫌なものを感じる。と。

450 :仕様書無しさん:03/12/12 00:20
まるで2chのJava使いのようだな
可哀想なgoto

451 :251:03/12/12 00:22
>>443 誤爆です。私は>>424ではありません。

452 :仕様書無しさん:03/12/12 00:24
C++等では例外を使って、関数の壁をぶち破ってプログラムの流れを変えることもできるからね。
gotoなんてまだかわいいほうだ。


453 :443:03/12/12 00:25
>>451
いや、それはわかってるよ。
>>251が、>>424(と>>428)のレスの解釈を間違ってるんじゃネーノ?という意味。

454 :仕様書無しさん:03/12/12 00:26
basicでgoto使ってないのなんてあるの?


455 :仕様書無しさん:03/12/12 00:28
>>449
たしかにgotoが使われているプログラム全体とそれ以外を比べれば、
gotoアリの方が品質が悪い傾向にあるだろうね。
だけど、それで目を曇らせてしまうようじゃ頭が固いと言われてもしょうがないかもね。

gotoを見て「警戒する」ことと「嫌悪する」ことは全然違うことだからね。
(ぶっちゃけていうと、技術者の取るような態度ではないなぁ、と。)

456 :251:03/12/12 00:34
>>453
・・・間違っていたかも知れません。スレ汚し失礼
#眠くて頭が動きません

457 :仕様書無しさん:03/12/12 00:39
>>448
>それは、goto以外の原因でメンテ不能に陥っているプログラムを経験したことないからでは?
多分違うよ。
goto以外のクソコードも見たことはあって、クソだとも思ってるんだ。
でもgotoだけに言及するのは、gotoが見た目にも分かりやすく、批判しやすく、
広く流布している説でもあるからそう思い込んじゃってるだけだよ。
んで、トラウマになったような「気分」になってるだけ。こんな気持ちになれる
オレはスゲーぜって。たぶん>>235もそうだろうね。

458 :仕様書無しさん:03/12/12 00:46
>>452
スマートポインタなんかと組み合わせれば、結構安全にプログラミングできるけどね。
明示的に後始末しなければならない(忘れると不具合の原因になる)なんて、既に古い
書き方なんじゃないかと思う。

459 :仕様書無しさん:03/12/12 01:32
そんなgotoを適切に使えるオレはスゲーぜ、とどこが違うんだそれ。

460 :仕様書無しさん:03/12/12 02:40
>>455
>(ぶっちゃけていうと、技術者の取るような態度ではないなぁ、と。)

おい、そこのお前! ちょっとこっちへ来い。
http://pc.2ch.net/test/read.cgi/prog/1070958293/l50


461 :仕様書無しさん:03/12/12 05:57
>>442
そんなことしても
処理速度にはほとんど影響しないよ


462 :仕様書無しさん:03/12/12 07:54
やはり年寄りがしがみついているのなw

463 :仕様書無しさん:03/12/12 08:21
>>459
別に「スゲー」ことじゃないと思うが…?

464 :仕様書無しさん:03/12/12 08:24
>>460
別に「プログラマのとる態度でない」でもいいよ。

465 :251:03/12/12 09:54
>>462
私は「年寄り」かもシレンが「しがみついている」とは思わんぞ。
gotoは、無くてもプログラムは書ける。
それが証拠にここ数年のgoto使用の実績は、一行/二万行だ。

466 :仕様書無しさん:03/12/12 09:57
「しがみついてる」ってのは、goto否定原理主義者の苦し紛れの妄想でしょ。
だれもしがみついて無いし…

467 :仕様書無しさん:03/12/12 11:18
goto >>1001

468 :仕様書無しさん:03/12/12 12:44
>>465
たしかに書ける。
でもそれはgotoを使わない理由にはならんのでは?

gotoを使うことでシンプルになる場合もまれにある。そう言うときは使うべき。

ただ、バカがgotoを連発するとプログラムが読めなくなるので、
バカが所属する可能性のあるプロジェクトでは規約として

「goto禁止」

を明示するほうが安全。

一番安全なのはバカをプロジェクトにいれないことだが、
たまに紛れ込む場合があるからなーw

この程度の話ではないのかな?

469 :仕様書無しさん:03/12/12 12:47
>>468
>この程度の話ではないのかな?
ということで前スレの早い段階で決着したんだが
「紛れ込んできたバカ」が
終わった話をここまで引っ張ってくれるわけさ。

470 :仕様書無しさん:03/12/12 12:48
>>469
なるほど。よくわかった。

471 :251:03/12/12 14:03
>>468
>gotoを使うことでシンプルになる場合もまれにある。そう言うときは使うべき。
支持

>ただ、バカがgotoを連発するとプログラムが読めなくなるので、
>バカが所属する可能性のあるプロジェクトでは規約として
>「goto禁止」
>を明示するほうが安全。
それはコードの解析性/保守性の低減を防止する方法として、支持できない。
>>412>>414にもあるように、「解析性/保守性の低減」を起こす要因は沢山ある。
「goto禁止を規則にすること」は「解析性/保守性の低減を防止する方法」として不充分&不完全だ。

>一番安全なのはバカをプロジェクトにいれないことだが、たまに紛れ込む場合があるからなーw
俺は入る人間の「前の仕事のソースコード」を必ずみることにしている。これで「バカの紛れ込み」を防げる。

>>469
>>234をレスする。

472 :251:03/12/12 14:15
>>471 五面
s/414/415/
です。

473 :仕様書無しさん:03/12/12 14:39
>>412>>414にもあるように、「解析性/保守性の低減」を起こす要因は沢山ある。

要因が他にたくさんあるからといって、(個別に)gotoを禁止してはいけない
ことの理由にはなりませんがな。

「すべからくgotoは禁止されるべきである」への反論なら一貫性が無いこと
の指摘として有効なんだけども。>>412>>415はそういう意味だと思う。

474 :251:03/12/12 14:47
>>473
goto禁止の目的はなに?
goto禁止の利点と欠点はなに?
#ちなみに>>415は私です

475 :仕様書無しさん:03/12/12 14:59
>>471
書き方がまずかったね。多分、考えてることとか方針は同じ。

「goto禁止を規則にする」ですべてが解決するわけではない。
それは重々承知してる。gotoを使わなくても読みにくいクソコードは書けるからね。
でも最低限、goto全開で何がなんだかわからないコードだけは避けられる。

漏れも前のコードくらい読んで人は選んでるけど、「OJTです。」とかいって人を
押しつけられることってないですか?毎回、1人2人は押し付けられるんだよね。
規約は主にそういう奴のためにあると思ってる。

優秀な奴は細かい記述規約は守らなくても許す。goto? 必要なら使え。
てな感じです。

プロジェクトを引っ張る立場なら当然でしょw

476 :仕様書無しさん:03/12/12 15:51
まぁ、473=412だったりするわけだが…
>>475が言いたい事を言ってくれました。

それでもやっぱりgoto禁止反対なら、goto禁止がまったく効果が無いことを示すか、
逆に他の部分に悪影響が出ることを示さないと。
(まぁ、既に上のほうや前スレである程度示されていると思うし、うまく説得
すれば「なるべく使用しないことを方針にする」くらいにはできると思うけど。)

477 :仕様書無しさん:03/12/12 16:06
>475 プロジェクトを引っ張る立場なら当然でしょw

君の文章読んでいるととても上の立場で仕事してる人間には思えないな。
引っ張ってるのは足だろ。


478 :仕様書無しさん:03/12/12 16:15
>>475
> 優秀な奴は細かい記述規約は守らなくても許す。goto? 必要なら使え。
規約破っても構わないと勘違いされるほうが重大な問題引き起こすぞ。


479 :仕様書無しさん:03/12/12 16:22
問題を引き起こすバカは規約を守れ、ということだろ。

規約を守らず問題を起こしたら、即、さようなら。

480 :仕様書無しさん:03/12/12 16:29
プロジェクトのメンバーに規約を守らせることすらできなかった奴もさようなら。


481 :仕様書無しさん:03/12/12 16:35
>>480
そして誰もいなくなった。

482 :仕様書無しさん:03/12/12 16:38
>>474

http://with2ch.net/cgi-bin/pict/img-box/img20031211180242.png

483 :仕様書無しさん:03/12/12 16:56
ワラタ

484 :251:03/12/12 17:12
>>475
>漏れも前のコードくらい読んで人は選んでるけど、「OJTです。」とかいって人を
>押しつけられることってないですか?毎回、1人2人は押し付けられるんだよね。
「押し付けられること」あります。// 1人2人ならいいんだが
当然、素人さんにはみっちり品質管理が必要となるわけで、
そういうときの回答は決まっています。「もう一人、面倒を見るから、管理に徹する」

>規約は主にそういう奴のためにあると思ってる。
規約が、力量が最下位レベルの人間に合わせて作成されるのは、良くあることですね

>優秀な奴は細かい記述規約は守らなくても許す。goto? 必要なら使え。
>てな感じです。
姿勢は支持しますが、プロジェクトを引っ張る立場のみならず、
規約の逸脱の許可権限をきちんと取得しておくべきです
それが運用ルール上できないのなら、やはり「goto禁止を規約とすることに反対すべき」だと思いますが

>>476
>それでもやっぱりgoto禁止反対なら、goto禁止がまったく効果が無いことを示すか、
>逆に他の部分に悪影響が出ることを示さないと。
私は逆だと思います。つまり
「goto禁止なら、goto使用が常に悪影響が出ることを示さないと」
です。

>>482 結構、かわいい子だね。何歳?

485 :仕様書無しさん:03/12/12 17:38
>「goto禁止なら、goto使用が常に悪影響が出ることを示さないと」
どうして「常に」なの?個別の禁止/許可ならトレードオフの話でしょ?

486 :251:03/12/12 18:54
>>485 それはですね。
gotoについて、個々の各使用ケースにおいて、
誤用か誤用で無いかの判断の、衆目の一致が得られないから
なんです。
goto禁止反対論者間でも意見の一致を見ないというこの点が、
現在に至るまで論争が続いているという真の原因かと判断しています。
この問題が無ければ単にgoto論争は「ものわかれに終わる」となると思いますよ

487 :仕様書無しさん:03/12/12 19:44
規約は妥協の産物なんだから、むしろgoto禁止を規約として取り入れて
どうしても必要なときは例外として認める、のが現実的じゃない?

有象無象ひっくるめて開発してる「生産現場w」としちゃそんなとこ。

488 :仕様書無しさん:03/12/12 19:49
>>486
そりゃ思考停止だよ。goto禁止派と同じ間違いを犯してる。

というか、その理論で行くと、どちらも根拠を出せないんだから、
禁止にすべきかそうでないかは「決められない」ハズなんだけど、
どうして禁止すべきでないと言えるの?

489 :仕様書無しさん:03/12/12 19:56
fortranの計算型gotoとか算術if、cobolのalterとかも上手に使えばエレガントな
コードにはなったがたいてい禁止だった。

gotoを禁止する規約を作ることと、論理的にいいコードかどうかは別件かも?

490 :仕様書無しさん:03/12/12 19:57
>>487
割れ窓理論的には、gotoが地下鉄の落書きだとすると、
規約の逸脱は暴動に匹敵する治安悪化だと思うが。

491 :仕様書無しさん:03/12/12 20:45
シャアや黒い三連星クラスなら場合によって規約を通り越してgoto使用可。
一般層は基本的に規約通りgoto不可。ジーンがどうなったか考えろ。

ギレンザビであるプロジェクトリーダーは階級付けをちゃんとやれということだ。

492 :仕様書無しさん:03/12/12 21:09
わかりやすい。結論が出たなw

493 :仕様書無しさん:03/12/12 21:23
たいがい反発するのは、「僕はこんなにできるのにどうしてgotoを使わせてもらえないんですか!」かな。
そしたら「坊や(ry」かねw

「あのプロセスはなぜ氏(ry」がないとまずいか。

494 :仕様書無しさん:03/12/12 21:27
なにをいうか!gotoを規約で禁止している者がなにをいうのか!

これが・・・規約・・・

495 :仕様書無しさん:03/12/12 21:31
口で言うほど自由ではないのだyp、gotoというものは。

496 :仕様書無しさん:03/12/12 21:35
ならgoto禁止。そうすればララァも喜ぶ。

497 :仕様書無しさん:03/12/12 21:37
「とうさんにだってlabelをつけられたことないのに!」

498 :仕様書無しさん:03/12/12 21:40
一気にネタスレ化の予感

499 :仕様書無しさん:03/12/12 21:41
とうさんはgoto拒絶症なんだ!

500 :仕様書無しさん:03/12/12 21:45
アムロ、フローを書いて変数表を作れ。そしてgoto禁止だ。

課長・・・こんな古い知識を・・・酸素欠乏症にかかって・・・

501 :仕様書無しさん:03/12/12 21:47
ラベル・・・私の好きなラベル・・・

502 :仕様書無しさん:03/12/12 21:47
クライアントとの戦いがまだまだ困難を極めるという時我々は
gotoを使うの使わないのでマジレスし貴重な時間を次々と失っていく・・・
寒い時代だと思わんか

503 :仕様書無しさん:03/12/12 21:53
gotoを使ったね!

使ってなぜ悪いか!貴様はいい、そうやって規約を守っていれば気分も晴れるんだからな!

ぼ、ぼくがそんなに安っぽい人間ですか!?

2度も使った! 例外処理でも使ったことないのに!

それが甘ったれなんだ! gotoも使わずに一人前になった奴がどこにいるものか!

504 :仕様書無しさん:03/12/12 21:55
ふふふ・・・ガルマ、聞こえていたら君の規約の不幸を呪うがいい
君はよい同僚であったが、goto禁止の規約がいけないのだよ

505 :仕様書無しさん:03/12/12 21:56
全部ネタだろ?
マジレスだったら・・・

506 :仕様書無しさん:03/12/12 21:57
このプロジェクトだって規約があるだろうに・・・それを・・・gotoでジャンプするなんて・・・
すさんだねえ・・・・

507 :仕様書無しさん:03/12/12 21:58
サボテン:
  砂漠に花は咲くか?


508 :仕様書無しさん:03/12/12 22:08
>>507
それをいうなら

サボテン:
  砂漠に蝶は飛ぶのか? //砂漠に飛ぶのはサボテンのトゲ

509 :仕様書無しさん:03/12/12 22:10
このgotoをプロジェクトリーダに届けてくれよ! あれは、いいものだぁーーーー!!

510 :仕様書無しさん:03/12/12 22:12
オイラが、今までgoto文使ったほうが良いかなあ、と思ったのは、
双方向リストを非再帰で書いたときかなあ。
再帰で書いたら楽なんだけど、いろんなことが理由で、
どうしても非再帰で書かなくちゃいけないときなんか、goto文使うと
楽だし、見やすくない??
まあ、考える過程ではgoto文使って、最終的にはなんとなく使わない
ようにしているけど。(でもgoto文のほうが後で、知らぬ人が見ても
追いやすいかな。)

511 :仕様書無しさん:03/12/12 22:16
認めたくないものだな、若さ故の過ちというものを(まんまや)

512 :251:03/12/12 22:53
>>488
いやどうも説得力のあるレスが書けるか否かが、心もとないのですが。理由が二つあります。

一つ目の理由
>>345のような場合があるからです。
#>>346は私ですが

二つ目の理由
まず最初に前スレの>124(私ですが)のコピペから始めます。
>構造化プログラミングは万能かも知れないですが、
>全ての場合において最適解であるかというと、私は懐疑的です。
#当スレ>>404にも同様の見解

この例示を前スレの>699(goto付き)と>700(構造化)で行っています。
このレスを始点とする論争は延々と前スレ終了間際まで続きました。構造化を用いた別法を何人かの人に
示してまでもらいました。ですが私は、やはり前スレ>699がベストだと判断しています。
#バグの有無ではなくて表記方法です
つまり「gotoレスでなくgotoを使用した、より良い方法が存在する場合がある(と思っているから)」です。
あるアルゴリズム(というほど大袈裟ではありませんが)の表記(コーディング)には
gotoを使うのが最適であるとの判断をPGがした場合、goto禁止規約なぞ邪魔なだけです。

#まあ「規約の逸脱が簡単に可能である」というところならば「どっちでもいい」に宗旨変えしますよ。
#三つ目の理由 gotoがあるから
##しかしまあ、なんて論理的に話が出来る人(達)だろう。前スレとは雲泥の差だ

513 :仕様書無しさん:03/12/12 23:18
int i,j,k;
for(i = 0; next && i < 10; i++){
for(j = 0; next && j < 10; j++){
for(k = 0; next && k < 10; k++){
処理
if(ループを一気に抜けたい状態が発生) next = 0;
}
}
}
後始末


514 :仕様書無しさん:03/12/12 23:19
>「規約の逸脱が簡単に可能である」
簡単に、ではないことに気がついてもらわないと困るね。
規約ではない以上、優位さを常に提示してもらわねばな、なんつって。

515 :仕様書無しさん:03/12/12 23:20
>>512
まぁ、オレは>>412は個別にgotoを禁止する場合の反論にはならないよって言いたい
だけなわけだけど。

とりあえず、枕詞として
>構造化プログラミングは万能かも知れないですが、
>全ての場合において最適解であるかというと、私は懐疑的です。
「個別にgotoを禁止するのを是とする」かという問題の是非は、構造化が云々とは関係ない。
>>487がいみじくも仰っておられるが、「現場の判断」が重要なわけだからな。俺構造化云々
は禁止原理主義者の苦し紛れの(最後の砦としての)たわごと。当然、現場で通用する理論
でもない。(まぁ、このスレの議論を見てれば、その辺は自明だと思うが。)
あー、構造化を否定しているわけじゃないよ?(…と噛み付く人用。)

んでもって本論。
>つまり「gotoレスでなくgotoを使用した、より良い方法が存在する場合がある(と思っているから)」です。
ここで、トレードオフとして判断を行う必要があるわけ。gotoが規制されやすいのは、その利点
が軽視されやすい(見えにくい)ってのが一番の理由なんだから。

ということで、個別にgotoを禁止するのを是とするかという問題では
>それでもやっぱりgoto禁止反対なら、goto禁止がまったく効果が無いことを示すか、
>逆に他の部分に悪影響が出ることを示さないと。
をしないといけない、ということを納得してもらえるかな?
>>512はまさにそういう意見だよね。

>#まあ「規約の逸脱が簡単に可能である」というところならば「どっちでもいい」に宗旨変えしますよ。
だから、ベターなのは、『「基本的に」gotoを使用しないこと』あたりとオレは思うわけだ。
個別の環境での判断として、それが必要な状況ならば、ね。

516 :仕様書無しさん:03/12/12 23:20
>>512
>##しかしまあ、なんて論理的に話が出来る人(達)だろう。前スレとは雲泥の差だ
あんたの努力じゃないの?
gotoマンセー派にはあきれ返るばかりだけどさ、>>5によれば
あんたらが感情論で語らなくなったからこそ
goto否定派も話に付き合わざるを得ないんだよ。


517 :仕様書無しさん:03/12/12 23:20
規約が有るのは知ってるが、今まで一度も見た事が無い。
現実の規約は先輩からの口伝だけ。
基本的には結果オーライ。

518 :仕様書無しさん:03/12/12 23:25
> ここで、トレードオフとして判断を行う必要があるわけ。
> gotoが規制されやすいのは、その利点が軽視されやすい(見えにくい)ってのが一番の理由なんだから。

トレードオフって言葉まで出ながら次の文がまったく噛みあってないな。
gotoが規制されやすいのは利点のリターンより欠点のリスクのが大きいと
多くの人が判断するからだ。これがトレードオフ。

利点はさんざんgoto肯定派が書いてくれているし、
欠点もgoto否定派が沢山書いているのであえて書かないが。

519 :仕様書無しさん:03/12/12 23:32
>>518
>多くの人が判断するからだ。これがトレードオフ。
「一番の理由なんだから」、逆に利点をちゃんと説明しなければならないわけね。
んで、>>471, >>473に続く


520 :仕様書無しさん:03/12/12 23:36
>規約が有るのは知ってるが、今まで一度も見た事が無い。
大きい企業とか「昔」先進的wなひとがいただけなところだと
これが結構あるんだなぁ…(もちろんgotoだけじゃない。)

521 :ニセ235=828:03/12/12 23:40
>>516
いやぁ、照れるな。

522 :仕様書無しさん:03/12/12 23:42
永久ループっしょ?
トレードオフの結果は人によりけりっしょ?



523 :仕様書無しさん:03/12/12 23:46
そうじゃなくて、環境や状況によりけり、とも言えるよ。

524 :仕様書無しさん:03/12/12 23:58
「間違ったgotoの使用法」はあると思うが、それは「間違ったクラス設計」と同じようなものだ。
「間違ったクラス設計をする馬鹿がいるから、クラス使用禁止」は「間違った努力」だと思うぞ。

525 :仕様書無しさん:03/12/13 00:01
結局、gotoの肯定禁止が技術力の高低の話に摩り替わっちゃうのが長期化の原因
2chの技術系では良くある展開だけどさ

526 :仕様書無しさん:03/12/13 00:18
>>524
gotoはその反省として構造化構文ができたが
クラスにはより進歩した方法は提唱されてない。

gotoを使わなければほぼ80点が取れるのに
100点を取るために頻繁に0点を取る可能性と格闘するのは
間違った努力だと思うゾ!

527 :仕様書無しさん:03/12/13 00:30
結局、goto使いたがる香具師は自称スーパープログラマーばかりでないの?
ホントのスーパーな人達はgotoなんざ使わなくてもスマートなコードが書けるって。
脳の造りが根本的に違う、って感じだからYO!

528 :仕様書無しさん:03/12/13 00:34



           本物のプログラマはgotoを恐れずに使う。

529 :仕様書無しさん:03/12/13 00:34
いまさらgoto かよ

530 :251:03/12/13 00:34
>>515
#「構造化とgotoはある意味で、対立概念である」という理解をしています。

>「現場の判断」が重要なわけだからな。
全面的に支持します。禿同

>>それでもやっぱりgoto禁止反対なら、goto禁止がまったく効果が無いことを示すか、
>>逆に他の部分に悪影響が出ることを示さないと。
>をしないといけない、ということを納得してもらえるかな?
うーん。少し考えてみましたが、これは出自の違いなのかもしれません。
最初から構造化言語を使ってプログラミングしている者と、そうでない者です。
非構造化言語でプログラミングを始めた私は構造化言語を使い始めて
「わかりやすくなってきて嬉しい。でもgotoの使い道はまだあるな。有限状態遷移はgotoがベストだし」
の心象であったのですが、goto禁止規約化などと聞いて反対しました。
しかしながら「goto禁止がまったく効果が無いことを示す」とか「逆に他の部分に悪影響が出ることを示す」
などとの説明責任/立証責任がgoto禁止規約化反対をする側にあるとは思えないのです。
「最初に覚えた言語が構造化言語である人はその様に判断するのだろうか」などとも思います。
#まあ「昔から使っているものを何で禁止するのか」という素朴な疑問もありますが

>>516 少し泣いてしまいました。(本当に涙が出たわけではないのですが)

531 :仕様書無しさん:03/12/13 00:41
>>527
goto禁止するとホントのスーパーな人達でないとまともなコードがかけなくなってしまうので困るだろ。

532 :仕様書無しさん:03/12/13 00:44
>>531
goto推奨するとまったく無能な人がコードを書き散らすので困るだろ?

533 :仕様書無しさん:03/12/13 00:44
推奨する奴なんているのか!?

534 :仕様書無しさん:03/12/13 00:46
goto使用許可証を持ってる奴以外は使っちゃダメ!

535 :仕様書無しさん:03/12/13 00:49
プログラマめんky(ry

536 :235:03/12/13 00:49
>>530
>説明責任/立証責任がgoto禁止規約化反対をする側にあるとは思えないのです
少なくともこのスレで説明責任/立証責任を先に求めてきたのはgoto禁止反対派


>最初に覚えた言語が構造化言語である人はその様に判断するのだろうか
SA >>266.

>昔から使っているものを何で禁止するのか
SA >>268

537 :仕様書無しさん:03/12/13 00:52
>>235たんキタ━━━━(゚∀゚)━━━━!!!!
相変わらず、どうでもいいところばかりレスするね!!

538 :仕様書無しさん:03/12/13 00:53
出自で逃げられたら元COBOLerなんてどうなるんだろう
...考えるだに怖ろしい

539 :仕様書無しさん:03/12/13 00:57
初心者時代はgoto使ったことなかったけど、あるコードでエラー処理を後ろにまとめる
使い方に感銘を受けてgoto使うようになりましたが。

540 :仕様書無しさん:03/12/13 00:58
>>539
その考え方が、C++でさらに洗練されてexception(例外)になっています。

541 :仕様書無しさん:03/12/13 00:58
VBでつか?(w

542 :235:03/12/13 01:00
>>537
どこにレスして欲しいのか示せよ。

>>539
VBのOn Error GoToじゃないだろうな?あれはgotoであってgotoではないぞ。

543 :235:03/12/13 01:01
>>540
違います。まず向かう方向が違う。

>>541
Will you marry me?

544 :539:03/12/13 01:02
>>542
ここは、Cのスレですが?

545 :仕様書無しさん:03/12/13 01:03
setjmp()/longjmp()でわなかろーか(^^;;>>540

546 :仕様書無しさん:03/12/13 01:04
>>542
自分で読めよw。2日レスしなかったら置いてかれたか?ww

547 :仕様書無しさん:03/12/13 01:05
>>545
それもある。

548 :235:03/12/13 01:08
>>544
さっきから非構造化言語の話やらなにやら出ているようだし、
Cならではの話題は今の所は特になさそうだが(つまり手続き型言語一般に通じるとして)。

>>546
どうでもいいところばかりと言われたからな。
俺のレスしたい所にレスするだけで不満なら
レスして欲しい所を明示しろというまでだ。

549 :仕様書無しさん:03/12/13 01:09
別に>>235にレスしろとは言ってないし。読みきれないなら黙ってたら?

550 :235:03/12/13 01:11
>>546
>2日レスしなかったら置いてかれたか?ww
つーかよ、俺自身何日レスしてないのかよくわからないのに
いちいち調べるお前の粘着体質に驚きの色を隠せません。
もしかして俺のレスを楽しみに指折り数えていてくれたのか?

551 :539:03/12/13 01:11
>>548
でも、gotoとVBのon error gotoは(使ったことないからよくわからんけど)違うんでしょ?
関係ないものをわざわざ持ち出す必要はないのでは?

552 :235:03/12/13 01:14
>>549
>537 >537 >537 >537 >537 >537 >537 >537 >537 >537

>>551
gotoってキーワードだけで同一視して語る奴が出てくると混乱の元だからな、
混乱の芽は早いうちに摘み取るのがモットーだ。

553 :539:03/12/13 01:15
混乱しているのは、542だろう。

554 :仕様書無しさん:03/12/13 01:15
>>550
まぁ、このスレに欠かせないキャラクターだからな。
>>407のレスのあとどうしていたのかと心配していたわけだ。

555 :235:03/12/13 01:15
goto許容派は好きなおかずは先に食べるだろ?
goto禁止派は好きなおかずは最後に残すだろ?

どうだ?

556 :仕様書無しさん:03/12/13 01:16
バランスよく食べます。

557 :仕様書無しさん:03/12/13 01:17
そのときどきによる。

558 :235:03/12/13 01:17
>>554
妄想が激しすぎると禿げるぞ。
禿げはOOの達人の証だから勲章だがな。

559 :仕様書無しさん:03/12/13 01:19
>>556-557
スレの内容を汲んだ秀逸なレスだな。

560 :仕様書無しさん:03/12/13 01:20
>>558
あれ?違うの?
ごめん。レスする時間がいつもどおりだから名前入れ忘れたのかと思った。

561 :235:03/12/13 01:21
>>559
そう、バランスよくとか場合によるとか書きながら一番初めにがっついてる図が目に浮かぶあたりが。

562 :仕様書無しさん:03/12/13 01:22
>>561
妄想妄想www

563 :仕様書無しさん:03/12/13 01:22
なんだか、妄想が激しい人が居るようで。

564 :235:03/12/13 01:24
>>560
みごとなくらいにほぼぴったりの午前1時15分前後に
否定を書き込んでもなんだかきな臭い気がするが俺じゃない。

565 :235:03/12/13 01:28
てか俺>>560のレスの時間みて書き込んでるな。
週末で疲れてるんだ。

566 :235:03/12/13 01:30
また間違えてる。
>>560じゃなくて>>554だな。

というわけで
http://pc.2ch.net/test/read.cgi/prog/1036336572/l50

567 :仕様書無しさん:03/12/13 02:21
>>530
>「goto禁止がまったく効果が無いことを示す」とか「逆に他の部分に悪影響が出ることを示す」
>などとの説明責任/立証責任がgoto禁止規約化反対をする側にあるとは思えないのです。
禁止→原則禁止と規制を緩和するためでいいなら、gotoの利点を説くというのも有効。
だけど、「goto禁止」は禁止というなら上記を立証する必要があると思うよ。
(そして、それはかなり無理筋であり、goto禁止を強弁している原理主義者と同じ道。)

あと、構造化構文以外の構文は、構造化(が実現しないこと)を補うためにあるんだよ。
構造化プログラミング自体が完璧ではないことは、>>251自身も言ってることだよね。

568 :仕様書無しさん:03/12/13 05:09
いっこうに進展してないね。
同じことばかり繰り返してる
もうやめたら?
goto 1001

569 :仕様書無しさん:03/12/13 09:03
while((all != yes_goto) && (all != no_goto));

570 :251:03/12/13 10:29
>>526
>gotoを使わなければほぼ80点が取れるのに
>100点を取るために頻繁に0点を取る可能性と格闘するのは間違った努力だと思うゾ!
正しい様ですが、重大な錯誤が二つ存在します。
一つ目「頻繁に」です。gotoの使用頻度は、関数数ベースで0.1%程度ですよ。#「私の場合」ですが
二つ目「gotoを使わなければ60点しか取れないので、80点を取るためにgotoを使う」のですが

>>567
無理筋かも知れないけど少し書いてみますか。
「goto禁止がまったく効果が無いことを示す」
・スパゲッティを完全に防止できる。だが単にそれだけである。
 またレビューを行うことでそれ以上の効果を期待できる(その他の品質低下要素も防止できる)。
 元来、規約の存在理由は「コードの均質化」であって「品質低下の防止」ではない。
「逆に他の部分に悪影響が出ることを示す」
・フラグ変数の乱用を招く(制御結合を招く)
・関数の肥大化 
 #これは「構造化構文により論理構造の見通しが良くなっている」という利点の、裏返しの欠点です

うむむ。やはりgoto論争の結論は「goto誤用をする人間を、goto誤用をしない人間にする」以外に
ないような気がしてきました。いや「goto誤用」というのは、単にわかりやすい氷山の一角であって、
「プログラムを書くスキルの無い人間にプログラムを書かせる」という作業環境が原因であるのでしょう。
上記の「無理筋の理由」の真の元凶は「プログラム設計能力の欠如/不足」であるからです。
#経営側からは「そんなに教育投資する余裕は無い」という返答がいつも返ってきます。
#「余裕が無いという状況」を、改善する予定があるのか否かを聞きたいものです。

>構造化構文以外の構文は、構造化(が実現しないこと)を補うためにあるんだよ。
continue/break/(途中での)return 等ですね。
#do while 構文は微妙なところ。(もともとの構造化にはなかったような気が)

>>569
笑いました。無限ループを書くことに心理的な抵抗はありましたか?

571 :仕様書無しさん:03/12/13 11:11
末尾再帰にgotoは必須ですよ

572 :仕様書無しさん:03/12/13 11:28
goto or not goto, it is no longer a problem.

573 :仕様書無しさん:03/12/13 11:42
色んな場面でCソースを吐くツールとか作らない?
そんなとき、プログラムのフロー制御についgoto 使わない?


のかな?

574 :仕様書無しさん:03/12/13 11:47
お前ら過去に散々なされた議論の劣化コピーばら撒いて楽しいか?

575 :仕様書無しさん:03/12/13 11:53
>574
藻前にとっては過去かもしれないが
此処等の香具師には違うんだって

いい加減自己中心的なものの考え方、改めたら?

576 :仕様書無しさん:03/12/13 11:58
>>573
だから、switchにしろって。

577 :仕様書無しさん:03/12/13 12:05
>>575
事故中ってなんだよw
もし本当に理解を深めたいならまず過去の議論を先にフォローするのが筋だろ。
それをやらずに議論したって意味ないだろ。
そんなの唯Googleのキャッシュを汚すだけの雑談だ。


578 :仕様書無しさん:03/12/13 12:15
>>577
それってこの掲示板だけでいいの?
「過去の議論」ってのがいつ始まったか知っていれば
全部なんて言えないはずだけど

579 :仕様書無しさん:03/12/13 12:19
>>251

> 以下は俺の意見
> 「大きな事故を引き起こす」ってのは「gotoの誤用」が原因の一つになりうることを認める。
> しかし「gotoの誤用」は「大きな事故を引き起こす」原因群の最大の悪玉ではない。
> また「gotoの誤用」を起こさないための仕組みとして「goto使用禁止」を選択するのは不適切だろう。
> #大きな事故を引き起こさない事がそんなに重要ならば、
> #goto使用禁止を叫ぶより、もっと有効な行動があるのではないか

#goto使用禁止を叫ぶより、もっと有効な行動を以下に明示する。

どうしてもgotoを使いたい時は例外処理 try-catch statementをgoto文変わりにする。
for, whileの多重ループの脱出, switchなどの脱出にはラベルつきbreak, ラベルつきcontinueを使う。


580 :235:03/12/13 12:24
おはよう日本
>>570
>gotoの使用頻度は、関数数ベースで0.1%程度ですよ。#「私の場合」ですが
ほんとうに統計とった?
それに元々の数は関係ないって言ってるのわかるよね?
一個あるだけで増殖する危険性があんだよ。

>gotoを使わなければ60点しか取れないので、80点を取るためにgotoを使う
じゃあ60点でいいんじゃね?60点があんたらの点数なんだよ。
背伸びして80点目指して0点の危険性ばら撒かれたら困る。

>>573
>>280の最後


581 :235:03/12/13 12:26
>>579
>どうしてもgotoを使いたい時は例外処理 try-catch statementをgoto文変わりにする。
本当に例外処理に使うならいいけどよ、
例外処理以外にtryブロックを使うのはgotoの乱用に匹敵する悪行だと思うけどどうよ?

582 :仕様書無しさん:03/12/13 12:34
>>578
>それってこの掲示板だけでいいの?
誰もそんなことは言ってないが。

>全部なんて言えないはずだけど
誰もそんなことは言ってないが。

ちょっと検索してみればここでやってる議論になんら新規性がないことがわかるよ。
このレスさえもなw

583 :仕様書無しさん:03/12/13 12:34
>>579
「例外処理 try-catch statement」「ラベルつきbreak」「ラベルつきcontinue」
なんてもんはcにはねえんだ

584 :仕様書無しさん:03/12/13 12:35
Cもわかってない人が多いみたいですねぇ。

585 :仕様書無しさん:03/12/13 12:37
>>577 雑談じゃあいけないのか

586 :235:03/12/13 12:39
>>584
Cでgotoを使わない理由を考察するスレのCはComputer、Cyber、Creator、CP/MのCなのです。


587 :235:03/12/13 12:43
C → 視力検査に使うO の一部が開いている Open O → OO

OOにgotoは無用

588 :仕様書無しさん:03/12/13 12:48
疲れてるんなら休んどけ。

589 :仕様書無しさん:03/12/13 12:56
>>581
性能劣化も激しいからな。

590 :仕様書無しさん:03/12/13 13:09
結局、
たばこ嫌いな人 VS たばこ吸いたい人

と同じぢゃ。
吸っていない人までの健康を害するとかで、禁止されとる。
吸いたい人は肩身が狭いのう。。。

わしはgoto使うがの。

591 :仕様書無しさん:03/12/13 13:09
goto使わなくても0点にするのは簡単

592 :仕様書無しさん:03/12/13 13:13
>>591
それはgotoを使う理由にならんぞ
もっともgoto使っただけで 0点だ、と言ってる香具師も同類だが

593 :結局:03/12/13 14:31
家の子があそこの子より劣っているってゆーの?きーっ!!
運動会の駆けっこ反対!!

って事?
(gotoうまく使えない人がきーっ!!してるだけ)

594 :仕様書無しさん:03/12/13 15:11
Cでgotoを使わない理由

Java使いだから。
なんですかgotoって?

595 :仕様書無しさん:03/12/13 15:16
Cでgotoを使わない理由?
使いますよ。
/* $Id: main.cpp,v 1.8 2003/12/13 02:55:45 goto Exp $ */

596 :仕様書無しさん:03/12/13 16:15
>>235は果てしなく馬鹿だってことがこのスレの結論です

597 :仕様書無しさん:03/12/13 16:27
Cでgotoを使わない理由?

gotoはVBしかできないしなぁ。
katoやsaitoはCで使っても大丈夫。


598 :仕様書無しさん:03/12/13 22:59
>516
>>##しかしまあ、なんて論理的に話が出来る人(達)だろう。前スレとは雲泥の差だ
>あんたの努力じゃないの?

バカとアホが褒めあってるよ


599 :仕様書無しさん:03/12/13 23:29
>>593
>(gotoうまく使えない人がきーっ!!してるだけ)

「うまく使える」の定義をキボン

600 :仕様書無しさん:03/12/14 01:36
600 get!

いいじゃん、別に2chだし。
悔しかったら全部goto文で書いてみろ。
関数の呼び出しもwhile文も使っちゃだめだ。まあmain() ぐらいは使ってもいいけど。
あとみんなgotoだ。

601 :仕様書無しさん:03/12/14 01:42
for 文を goto で実装する。

  i = 0
hajime:
  message = "回数 = ";
  times = i;
  goto print:
modoru:
  ++i;
  if(i < 10)
    goto hajime;
  goto end;

print:
  printf("%s%d\n", message, times);


こんな感じか。あ、printf 関数は使っちゃいけないんだ。
表示部分も関数なしで書かなきゃ > 宿題。


602 :仕様書無しさん:03/12/14 01:43
>>601
printf の下に goto modoru; がいるだろ。


603 :仕様書無しさん:03/12/14 01:43
こんなに面倒だから goto は使わない方がいいんだね。


604 :仕様書無しさん:03/12/14 01:45
>>601
ふーん、goto 使う派は、こんなコード書いてるんだあ。


605 :仕様書無しさん:03/12/14 01:46
頭いいんですね。


606 :仕様書無しさん:03/12/14 02:06
自画自賛してどーすんのよw

607 :251:03/12/14 02:27
下手ですね。for文を正しく理解していますか。こう書くものです。
  times = 0;
  message = "回数 = ";
modoru:
  if ( times > 10 ) goto end;
  printf("%s%d\n", message, times++);
  goto modoru;
end:
もちろん冗談ですが。

608 :仕様書無しさん:03/12/14 02:55
>>607
ステキ!!

609 :仕様書無しさん:03/12/14 02:56
だが、Cの欠陥としてはPascalにある手続き内手続きの不備を指摘しなくてはなるまい。
多重ループだのなんだのは、ローカルな関数としてくくり出せればいい。
PL/IにすらあるのにCにないのが欠陥だろう。

610 :仕様書無しさん:03/12/14 03:05
>>609
実装を知らない厨房ハケーン!


611 :仕様書無しさん:03/12/14 03:05
>>607
正解はこう。

i = 0; for_1: if (!(i < 10)) goto for_end_1; i++; {
  printf("i = %d\n", i);
} goto for_1; for_end_1:;


612 :仕様書無しさん:03/12/14 03:09
>>609
関数内関数は変数スコープ制御にも大きな利点がありますからね。
#言語規格策定委員会(?)の一部にそのような動きがあったとか無かったとか

613 :仕様書無しさん:03/12/14 03:11
>>611
どこがちがうねん

614 :仕様書無しさん:03/12/14 03:16
>>612
基本的にCは機械非依存のアセンブラとして設計された。
当然速度優先の設計となる。
必然性が無く、効率を落とすような概念は全て切り捨てる。
当たり前のこと。

615 :仕様書無しさん:03/12/14 03:23
俺はgoto避けるために変なコーディングする奴がムカツク。
あいつらgoto使わなかったらなにしてもいいと思ってやがる。

616 :仕様書無しさん:03/12/14 03:29
next_1にして欲しかったな。

617 :仕様書無しさん:03/12/14 03:34
>>615
規約に「変なコーディングしない」という項目を入れるべきだな。

618 :仕様書無しさん:03/12/14 03:35
>>614
であればCでgotoを使うのは全然かまわないということですね。ありがとうございます。

619 :235:03/12/14 10:25
学生はもう冬休みなのか?うらやましいな。
俺も自作自演でスレを盛り上げたい。

もし自作自演でなければ日本のソフトウェア業界は本当に危ないな。


620 :仕様書無しさん:03/12/14 12:11
自分の主張が通らない

相手が自作自演してしてるからそう見えるだけだ!

典型的な負け犬の言い訳ですなww

621 :235:03/12/14 13:49
>>620
だがよ、普通にプログラム組んでたらgotoの使用は身長にならざるを得ない事くらいすぐに覚える。
それを必要だから使うみたいな意見のやつがこんなに大多数だとはとても信じられんよ。

俺はgoto使うべきだと思った時でも本当に使っていいか丸一日悩んだりするぞ。
軽率に使って浪費する時間はその何十倍にもなると思ってるからな。
ここのやつらにはそういうプロセスが無さそうなのだ。
そんな程度の低い奴もしくは極端に程度の高い奴ばかりだとは思えん。

622 :仕様書無しさん:03/12/14 14:29
gotoは使う方も読む方も慎重になるから、バグ防止に役立つ。

623 :仕様書無しさん:03/12/14 14:35
>>621
一日悩むほど変なプログラムを書いているのか。
よっぽどセンスのないプログラム環境で育ったんだろう。

624 :仕様書無しさん:03/12/14 14:45
>235 日本のソフトウェア業界は本当に危ないな。
そんなことは無い。
おまえがいなくなるだけでもかなり違うとおもう。
消えてくれ。

625 :仕様書無しさん:03/12/14 14:47
235ってよほどレベルの低いコードを書いてるんだNE!

626 :235:03/12/14 14:49
>>622
ならない。
使う側は慎重にならない奴らが大勢いる事がこのスレで証明された。
読む側ではgotoに気を取られ肝心な部分を見落とす可能性が高まる。

>>623
おまえがよほど文章の意味を考えるセンスがない事はわかった。
何も考えずに汚いコードを書き散らしている事も。

627 :235:03/12/14 14:50
てか自演うざいって明言しないとわからない?


628 :235:03/12/14 14:52
もういいや。
せっかくの休日までこんな馬鹿のために不愉快になる事ないから。

粘着君。お前の勝ち。
一生自演で2ch内だけで勝ってろボケ。

629 :仕様書無しさん:03/12/14 15:06
>>626
また妄想癖がでてるなぁ。
いろんなタイプのコードに触って育ってれば、問題が出るかどうかはコード触れば
だいたいわかるだろ。
まぁ、「goto禁止」という教えが絶対らしいからしょうがないか。

630 :仕様書無しさん:03/12/14 18:15
>>627
また妄想君か?それとも2ch初心者か?
まーどうでもいいけど。

631 :仕様書無しさん:03/12/14 19:56
さてさて、
>使う側は慎重にならない奴らが大勢いる事がこのスレで証明された。
>読む側ではgotoに気を取られ肝心な部分を見落とす可能性が高まる。
この2つの文に、goto否定原理主義者が持つ「勝手な前提」がいっぱい詰まってますね。

632 :仕様書無しさん:03/12/15 00:19
>>607
下手ですね。for文を正しく理解していますか。こう書くものです。
  times = 0;
  message = "回数 = ";
  goto check;
loop:
  printf("%s%d\n", message, times);
  ++times;
check:
  if ( times < 10 ) goto loop;
もちろん冗談ですが。


633 :仕様書無しさん:03/12/15 00:43
漏れのコンパイラは最適化したらこんなコードを吐いて下さいました。

  times = 0;
  message = "回数 = ";
  //goto check;
loop:
  printf("%s%d\n", message, times);
  ++times;
//check:
  if (times < 10) goto loop;

もちろん冗談ですが。


634 :仕様書無しさん:03/12/15 00:52
へ〜
そのコンパイラって、初期値が10とかだと何も作らなくなるのかな?

635 :251:03/12/15 01:02
>>632
笑いました。もちろんそれもアリです。for文が継続条件事前判定型反復構文であることから、
まず、判定を行うのが正しいわけで、その判定を先頭に書くのが通例だと思いこんでいました。
判定を最後に持っていって、最初にそこに飛ぶという手ですか。
#冗談には「冗談返し」というわけね

636 :仕様書無しさん:03/12/15 01:14
>>634

void check_loop()
{
  char *message = "回数 = ";
  for (int times = 10; times < 10; times++)
  {
    printf("%s%d", message, times);
  }
}



PUBLIC?check_loop@@YAXXZ  ; check_loop
_TEXTSEGMENT
?check_loop@@YAXXZ PROC NEAR ; check_loop, COMDAT
  ret 0
?check_loop@@YAXXZ ENDP ; check_loop
_TEXTENDS

となりますタ。


637 :仕様書無しさん:03/12/15 10:48
gotoを使うと最適化が阻害されるから使ってはいけない…という主張かな?
新展開?

638 :仕様書無しさん:03/12/15 11:37
>>637
最適化するとforブロック自体が消滅して、「意味が無い関数があるよ」ってエラーが出ているだけだと思うけど

639 :仕様書無しさん:03/12/15 13:14
エラーなのか?

640 :仕様書無しさん:03/12/15 13:31
>>637
最適化が阻害されるといっても、>>345>>368とでは前者の方が
速いと思うぞ。
ループ自体は速い方がいいが、その脱出は速くなくてもいいし。

gotoが阻害する最適化って何がある?とりあえず思いつくのは
レジスタ割付ぐらいだけど。

641 :251:03/12/15 19:41
ほんとうは、goto誤用も重大な問題ではないのです。#ここで読むのをやめないで下さいね
>>150にも書きましたが
「(混沌に)秩序をもたらす」のは「構造化プログラム設計」であって「構造化コード」ではない
ってのが本音です。
関数のサイズが30行位迄なら、その中でgotoが多用されていても読めば判るものです。
また、そのサイズなら関数レベルのリファクタリングも容易です。
何百行(あるいはそれ以上)もある関数を作って、そこでgoto誤用をしていたら、
そんなコードは保守なぞ出来るはずがありません。
goto誤用が混沌の発生源みたいに言われますが、実のところ「そんな長大な関数を設計する」のが、
設計ミスという名の「本当の混沌の発生源」です。
「スパゲティで保守できない」というのはとても判りやすい表現です。
ですがスパゲティにならない一番簡単な方法として、「規約でgoto使用禁止にする」ことを選択するのは、
問題の本質に目を背けた愚かしい行為でしょう。
「goto禁止規約」は、既存コードが保守できないという事実の本当の原因が、果たして本当にgotoを使用して
いるからなのか、それとも別に真の原因があるのかを、考える労力を惜しんだ結果だとしか思えません。
「規約におけるgoto禁止の有無」は「その組織が問題の本質を理解出来る組織であるか否か」
の試金石の一つです。

gotoを使うか使わないかは大した問題ではない
gotoを禁止しているかしていないかは結構、重要な問題である

642 :仕様書無しさん:03/12/15 19:50
じゃ、「構造化プログラム設計」とgotoの両立について語ってもらいましょうか。

643 :251:03/12/15 19:57
>>642
>>150を読んでください

644 :仕様書無しさん:03/12/15 20:04
>>150に書いてあるのは設計とコーディングは分けて考えるべきだ
って事だけだと思うんだけど。
なので構造化プログラム設計を前提とした、許されるgotoの使い方に
ついて語って欲しいのだが。

645 :251:03/12/15 20:23
>>644
私が考える「許されるgotoの使い方」は>>293に書きました
「分けて考えるべきだ」との主張なので、「構造化プログラム設計を前提」としているわけではありません。

646 :251:03/12/15 20:29
>>644
>>512にも書いています。内容は同様?です。

647 :仕様書無しさん:03/12/15 20:39
>多重ネストからのネスト直後への脱出と有限状態遷移の表現だ。それ以外は全部誤用だ。曖昧かな?
>#前者は、gotoでなくreturnを使うほうがベターである場合も多い。

多重ループ抜け以外は「場合による」ってことですかね?
しかし、途中returnも場合によってはありなんてルールにしたら混乱しませんか?
自分がルールブックな自己完結な事なら問題なさそうですが、明文化できないと
それこそ「考える労力を惜しんだ結果」なのではないかと思いますが。
>>251さんとこは全部明文化しているのですか?

648 :仕様書無しさん:03/12/15 20:50
混乱する人が多そうなときはgotoを禁止する(手間かけてもいいなら、メンバーごとに
許可・禁止する)。コーディングとプロジェクト運用も分けて考えよう。

649 :仕様書無しさん:03/12/15 21:14
「犯罪者は、ココは管理されていない、警戒心が薄いということを感じ取って
犯罪に走るわけですね。」TVタックルの割れ窓理論の解説VTRより。
gotoも同じ?

650 :仕様書無しさん:03/12/15 21:19
>混乱する人が多そうなときはgotoを禁止する

よく判らないのですが、ルールが曖昧なことによる混乱と明確に書
かれたルールを理解できない人が居た場合を混同していませんか?
メンバーごとに許可制しなければならないのも暗黙の了解に頼った
曖昧な部分があるからではないですか?

651 :仕様書無しさん:03/12/15 21:41
>かれたルールを理解できない人が居た場合を混同していませんか?
「goto禁止」を理解できないPGがいる場合????
「ルール」にするなら曖昧にするな、というのは正論だね。
だから、明確(goto禁止みたいな)にする必要がある。

>メンバーごとに許可制しなければならないのも暗黙の了解に頼った
暗黙の了解????「ルール」が?

オレも言ってることが良く分からないです。

652 :251:03/12/15 21:42
>>647
途中returnは禁止事項でも制限事項でもありません。規約そのものは少量です。
混乱を避けるためにもコードレビューは必須です。
プロジェクト毎にあるいはプログラム毎にコードの品質特性の優先順位を決めておきます。
ほとんどの場合「解析性」が最優先ですが
レビューはその優先順位を前提として議論します。

653 :仕様書無しさん:03/12/15 22:13
>暗黙の了解????「ルール」が?

ルールのほうでは無く、メンバーごとに許可制にすることについて
です。おそらく過去に実績があるので判ってくれているだろう程度
の認識で判断するのではないかと思いました。表現が良くなかった
ですね。

>混乱を避けるためにもコードレビューは必須です。

結局、これになるんですかね?
goto禁止とわりきるほうが問題発生率が低そうに思えるのですが。

654 :251:03/12/15 22:49
>>653
>goto禁止とわりきるほうが問題発生率が低そうに思えるのですが。
その種の見解についての反論は何度も書いていますので、繰り返しません。
#>>641もその一つです。

655 :仕様書無しさん:03/12/15 22:50
>ルールのほうでは無く、メンバーごとに許可制にすることについて
もちろん、その人にgoto使わせてダイジョウブかはプロジェクトリーダ(など)が
決めるんだよ。場合によってはコードレビューや過去のコードを参考にして。
goto以外のルールを適用するかどうかも同様。

で、プロジェクトリーダに無能な人が付きそうだと心配するなら、もう一つ上のレベル
(部とか事業所とか会社全体とか)で決める。決める人は決める日とで、個別に規制
するのか、一律に規制するのかを決定する(分かってると思うけど、gotoに限った話
じゃないよ?)。

これが、「運用で」の意味。

>goto禁止とわりきるほうが問題発生率が低そうに思えるのですが。
goto以外は?基準が曖昧じゃない?(もしくはC言語禁止?w)
・・・と自己矛盾しているように見える。オレにはね。

656 :仕様書無しさん:03/12/15 23:37
>その種の見解についての反論は何度も書いていますので、繰り返しません。

了解です。
内容には納得できませんでしたが。

>goto以外は?基準が曖昧じゃない?(もしくはC言語禁止?w)

gotoスレなのでgoto禁止をルールの一例として取り上げたまでですが。
一部分でしかないの曖昧といえば、たしかに曖昧ですが。。。。。。


657 :仕様書無しさん:03/12/15 23:51
んじゃ、>>412>>415について、全て「明確な」基準が有ると?
「運用でなく一般的に」そう言えるというなら、個々人の能力を考慮しなくてもイイ基準なんだよね?

658 :仕様書無しさん:03/12/15 23:52
あ、>>412>>415は、例えばの話で、それ以外にも有ると思うよ。

659 :仕様書無しさん:03/12/15 23:54
いろいろな処理の中断条件があって、
中断する時は必ず何かのオブジェクトを破棄する必要がある場合どうするの?
いちいち中断用の関数にオブジェクト渡すの?

660 :仕様書無しさん:03/12/16 00:05
>>641
CPUのエミュレーションのコードで
インストラクションをそれぞれの動作に振り分けるswitchを含む関数が
どうしても大きくなってしまいます。
どうやって分割しましょう?
関数ポインタは遅くなるので嫌です。

661 :仕様書無しさん:03/12/16 00:05
>その人にgoto使わせてダイジョウブかはプロジェクトリーダ(など)が
決めるんだよ。

開発フェーズになれば数百人がかかわるだろ。
そんなことは可能なのか?
とても現実的には思えないけど。


662 :仕様書無しさん:03/12/16 00:06
サイズが合わない人は、ソックタッチでコンドームを固定するといいらしいぞ。

663 :仕様書無しさん:03/12/16 00:08
>>662
お前は2枚重ねだよな。
早漏だし。

664 :仕様書無しさん:03/12/16 00:25
>>661
選択肢は三つある。
・一律禁止
・それぞれのサブシステム(モジュール)のチームリーダーに一任する
・(暗黙に)個々人とチームリーダーにまかせる

こういう人間系がちゃんと出来てないところは、goto禁止したって結局ダメ。
まぁ、「ダメということが分かってる」なら、goto一律禁止したほうが良いわけだが…

665 :251:03/12/16 00:37
>>660
関数サイズを行数で表現したのは「それが一番わかりやすいだろう」と判断したからで、本意ではありません
関数のサイズを行数で測るのは不適切です。
何で測るのが適切かというと関数内の識別子の種類数であろうと考えています。
それでも長いですか?。

さらに書きますか。それぞれのインストラクションに対する制御の流れの交錯が無いのなら、その種の関数は
「情報的強度を持つ」と表現されます。
これは「概念とかデータ構造とか資源を一関数内に隔離する」という目的で設計されます。
分割の必要は無いと考えます。悪い設計ではありません。
#プログラム設計相談室回答者をやるのも本意ではないのですが。

666 :仕様書無しさん:03/12/16 00:47
コーダに相談してもご覧のとおりのまぬけぶりだしな。


667 :仕様書無しさん:03/12/16 01:09
いつまでぐだぐだ言ってるんだ。
どうでもいいじゃん、こんなこと。

668 :仕様書無しさん:03/12/16 01:13
>>667
って、ageるなよ・・・

669 :仕様書無しさん:03/12/16 01:15
あいかわらず自作自演続いてるのか
なんか可哀想に思えてくるな

670 :仕様書無しさん:03/12/16 01:21
>>669
俺は、>>235のほうが哀れだよ…(ノД`)゚。

671 :仕様書無しさん:03/12/16 02:30
電車で電車で電車で電車で
goto goto


672 :仕様書無しさん:03/12/16 23:07
>>670
お前>>669>>235だと思ってるんだろクスクス

お前は被害妄想で頭がおかしくなって死ぬんだぞクスクス

お前が気づいていなくても俺はあちこちのスレにいるぞクスクス

何しろお前の意見に反対してる奴はみんな俺だからなクスクス


673 :仕様書無しさん:03/12/16 23:45
毎日ご苦労様です

674 :仕様書無しさん:03/12/16 23:52
そういえば、「割れ窓」についての議論は深まらないの?
gotoを安易に使える環境では、初心者も気軽にgotoを使ってしまうゆえ、
「割れ窓」理論により、少しずつとはいえ悪い方向に落ちていく、というのは
結構うなずけるんだが。そして結局組織全体の、もしくは、世界全体の技術力が
落ちていくわけでしょ。

上のほうの議論だと、どこまでが「割れ窓」か、という線引きが難しそうだけど、
現実だってそうなわけで、gotoが本当に「割れ窓」かどうかを議論するのは
有用なことだと思うよ。

PG界のジュリアーノは君だ!。。。とか?

675 :仕様書無しさん:03/12/17 00:09
>>674
お前は割れ窓理論を誤解している

676 :仕様書無しさん:03/12/17 00:22
そうか?

「ココは規制がゆるいから自由に(gotoを使って)やろう」と思われるんだぞ?
んで、「こういうコードが許されるんだから、俺も」と広まっていく。
結果全体的なレベルが下がる。

677 :仕様書無しさん:03/12/17 00:24
>>676
やっぱり誤解してる

678 :仕様書無しさん:03/12/17 00:34
そして、どこを誤解しているかを言わない、と。典型的な逃げだな。

679 :仕様書無しさん:03/12/17 00:43
割れ窓を見る犯罪者(予備軍)など存在しない

680 :仕様書無しさん:03/12/17 00:47
どうしてそう思うの?

681 :仕様書無しさん:03/12/17 01:01
>>678
「gotoが割れ窓かどうか」などという質問はばかげてる

682 :仕様書無しさん:03/12/17 01:05
あぁそうか、なぜばかげているかがわからんのだな。
「gotoは割れ窓ではない」として考えを進めてみろ。

683 :仕様書無しさん:03/12/17 02:23
お前らあほか?
お前の記憶マジックナンバいくつだ?おい

684 :仕様書無しさん:03/12/17 08:03
記憶マジックナンバ

685 :仕様書無しさん:03/12/17 08:52
水の流れは同じに見えて同じにあらず

絵描きにも2種類ある
 毎回異なる事が要求される芸術家と
 毎回同じ事が要求される職人と

しかし、どちらも同じ絵描きだ。2種類あると思うのもまた便益にすぎないといえる


プログラマも、労働を要求されるプログラマと技を要求されるプログラマに別けられるのかもしれないし、それも無意味な区別かもしれない。

gotoがあるなら、あるようい使えばいいし、なければないように使えばいい。
所詮道具で、道具は道具以上ではないんだ。

そんなところにプライドまで持ち出す方が恥ずかしいとも思えるし、また恥ずかしいと思う方が恥ずかしいのかもしれない。

686 :仕様書無しさん:03/12/17 09:07
いくら気持ちいいとは言われても
オナホを使うのは人としてどうかと思うので私は使わない




687 :仕様書無しさん:03/12/17 10:58
>>683
短期記憶(チャンク)のこと?そりゃ7±2だけど
それがどんな関係があるの?

688 :仕様書無しさん:03/12/17 10:59
割れ窓云々は別にしても
>>676
「ということにしたい」気持ちは伝わってきます。ビンビン。

689 :仕様書無しさん:03/12/17 11:05
>>685
「まったく関係ない話をし出したかと思っていたら
 『〜も同じです』で話を繋げる手法」の多くは
1) 単なる喩え話をしたい、或いは 2)やっぱり関係ない話、の
どちらかだと常々思っていたんですが、この場合は
前者でしたか。

690 :仕様書無しさん:03/12/17 13:11

int function(...) {
void* handle;
void* handle2;

if ((handle=create(...)) != NULL) {

if ((handle2=create2(handle, ...)) != NULL) {

if ((handle3=create3(handle2, ...)) != NULL) {
int v=getValue(handle3);

destory(handle3);
destory(handle2);
destory(handle);

return v;
}

destory(handle2);

}

destory(handle);

}

return 0;
}

691 :仕様書無しさん:03/12/17 13:11
int function(...) {
void* handle=NULL;
void* handle2=NULL;
void* handle3=NULL;

if ((handle=create(...)) == NULL) goto error;
if ((handle2=create2(handle, ...)) == NULL) goto error;
if ((handle3=create3(handle2, ...)) == NULL) goto error;

int v=getValue(handle3);

destory(handle3);
destory(handle2);
destory(handle);

return v;

error:

destory(handle3);
destory(handle2);
destory(handle);

return 0;
}

692 :仕様書無しさん:03/12/17 13:12
どちらが見やすいだろうか・・・

693 :仕様書無しさん:03/12/17 13:26
パァ?

694 :仕様書無しさん:03/12/17 13:28
たった3個だから「どちらが見やすいだろうか」なんて迷うんだよ。

695 :仕様書無しさん:03/12/17 14:32
>>691 は destroy(NULL) が可能だという前提で書いていながら
>>690 をそうしないのは恣意的だ、ってのは置いといても

int function(...) {
  void* handle=NULL;
  void* handle2=NULL;
  void* handle3=NULL;

  v = 0;
  if ((handle=create(...)) &&
  (handle2=create2(handle, ...)) &&
  (handle3=create3(handle2, ...))) {
  int v = getValue(handle3);
  }

  destory(handle3);
  destory(handle2);
  destory(handle);
  return v;
}

こうだろ。

696 :仕様書無しさん:03/12/17 14:32
int create3_wrapper( void* handle2, ... ){
  int v;
  void* handle3;
  v = ( handle3 = create3( handle2, ...) ) ? getValue( handle3 ) : 0;
  destory( handle3 );
  return v:
}
int create2_wrapper( void* handle, ... ){
  int v;
  void* handle2;
  v = ( handle2 = create2( handle, ...) ) ? create3_wrapper( handle2, ... ) : 0;
  destory( handle2 );
  return v:
}
int function(...) {
  int v;
  void* handle;
  v = ( handle = create(...) ) ? create2_wrapper( handle, ... ) : 0;
  destory( handle );
  return v;
}

697 :696:03/12/17 15:07
>>695
負けました
_| ̄|○


698 :仕様書無しさん:03/12/17 17:37
ちょっとまてよ
>>695のスタイルは常識だよね?
>>690 691 696はネタなんだよね?

699 :仕様書無しさん:03/12/17 17:41
1.gotoを使わないようにしている。
2.場合によってはgotoを使うが、出来れば使わない方がよいと思っている。
3.gotoを使うことに何のためらいもなく、goto不要論などキニシナイ。
4.gotoは悪なので絶対に使わない。使う奴がいれば理由如何にかかわらず問答無用で叩く。

あなたは何番?

700 :仕様書無しさん:03/12/17 17:45
これも追加してくれ。

5.goto論議をするやつは厨房なので相手にしない。
6.NIFTYのプログラマーフォーラムにいるイタい論客にまかせる。


701 :仕様書無しさん:03/12/17 17:45
後藤

702 :仕様書無しさん:03/12/17 17:49
小学生のころBASICでgotoを使いまくっていたのが懐かしい。
if ループ条件 then goto ラベル
って感じ〜〜〜


703 :仕様書無しさん:03/12/17 18:22
BASICのGOTOは別にいいだろ

7. goto使う必要に迫られたことは無い

704 :仕様書無しさん:03/12/17 18:33
俗にスパゲッティとはgotoを使いまくってぐちゃぐちゃ
にからまってるプログラムのこと。

705 :696:03/12/17 18:40
>>698
恥かしながら、いつもの自分の書き方です

706 :251:03/12/17 18:51
>>704
解説をつけて下さってありがとう御座います。
「スパゲッティ」が死語になりつつあることを知りませんでした。
#typoもしてるし

707 :251:03/12/17 19:10
>>699-700
通常は使わないが、使った方が良いと判断したら使う

708 :仕様書無しさん:03/12/17 19:26
例えば2重ループを脱出するとかには使えるが・・・。
その他に使う必要性はないと思われ。
その他にあるとしたら、人に解り難くするためと解釈している。


709 :ヽ(´ー`)ノ:03/12/17 19:39
7.


710 :仕様書無しさん:03/12/17 21:11
Perlなら分かりやすく書けるのにヽ(´ー`)ノ

LOOP: foreach my $i (keys %hash) {
 my $nested_hash = $hash{$i};
 foreach my $j (keys %$nested_hash) {
  last FAST_LOOP if $nested->{$j} < 0;
  hoge();
 }
}
clean_up();

711 :仕様書無しさん:03/12/17 21:31
スレタイ嫁。

712 :仕様書無しさん:03/12/17 21:44
>>698
if の中に副作用を持つものを書きすぎるのは
わかりにくいと個人的には思う。好みの問題だが。

>>699
2.
多重ループの内側から抜け出す時に使う。
continue label; break label; が可能なら使う機会はもっと減るだろう。
有限状態遷移なプログラムを書くときにも時々使う。


713 :仕様書無しさん:03/12/17 21:54
有限状態遷移ではつかわねーな、それこそオブジェクト指向の得意技だし。
あ、Cでだからだめなんか。Cでやるったらステートもたしてイベントドリブンもどき
にするね。switchが汚いと思う人もいるだろうけど。gotoで実装しちゃうと後で
ステート増えたときがマンドクセェ。

714 :251:03/12/17 21:58
おお私と同じ習慣の人がやっとあらわれたか

715 :仕様書無しさん:03/12/17 22:18
たとえばコマンドラインパーサ(有限状態遷移)やなんかをぜんぶgotoで実装したらすごいだろ。
もちろんgotoは使われるけど、深いモードからの脱出だけ。だから脱出に限定していいと思うぞ、
Cでのgotoは。そうそう頻繁にないけど、つかこないだ使ったのいつだっけ?

716 :仕様書無しさん:03/12/18 00:20
>>660
>関数ポインタは遅くなる
switchの方が関数ポインタより早いの?


717 :仕様書無しさん:03/12/18 02:21
>>716
>switchの方が関数ポインタより早いの?
普通、そうだろ? 何か違うのか?


718 :仕様書無しさん:03/12/18 02:21
ってゆーか、gotoを使いたくなったのは以下のようなコードを見た時
  void* handle=NULL;
  void* handle2=NULL;
  void* handle3=NULL;

  handle=create(...);
  if(handle==NULL){
    エラー時処理
    return -1;
  }
  handle2=create2(handle, ...);
  if(handle2==NULL){
    destory(handle);
    エラー時処理
    return -1;
  }
  handle3=create3(handle2, ...);
  if(handle3==NULL){
    destory(handle);
    destory(handle2);
    エラー時処理
    return -1;
  }

  v = getValue(handle3);

  destory(handle3);
  destory(handle2);
  destory(handle);

  return v;


719 :仕様書無しさん:03/12/18 07:31
>>
そのコードはちょっと人として間違っている

720 :仕様書無しさん:03/12/18 09:56
>>719
うん。
3個だからまだいいけど7個のやつを見たことがある。
「自分のいつもの方法を押し通すとひどいことになるって事がわかった段階で相談しろ」
ってやつだ

721 :仕様書無しさん:03/12/18 11:15
>>717
極端な話、

  switch (op) {
   case 0x00:
     :
   case 0x01:
     :
     :
     :
   case 0xFF:
     :
  }

よりは

  op_tbl[op]();

の方が早い。

722 :仕様書無しさん:03/12/18 11:51
>>721
関数呼び出しのコストを忘れてないか?
(inline化である程度最適化できるとはいえ)


723 :仕様書無しさん:03/12/18 12:01
スイッチ・関数どっちでもいいと思う。
実装やメンテのコストの方が大事。

実行スピードが気になるならアセンブラ出して比べればいいし、
他にチューニングすべきところが山ほどあるはず。(こんなことで悩む位なら)

724 :仕様書無しさん:03/12/18 12:14
ところが、どっちの方法を使うかでエミュレート速度がぜんぜん違ってきたりするんだよな。


725 :仕様書無しさん:03/12/18 14:50
>>722
op の値によっては jump を数十回繰り返す事を
忘れてないか?

>>723
>実行スピードが気になるなら
いや…そういう話をしてるわけで。
ま、コード見るよりは実測するのが常識だけどね。

726 :仕様書無しさん:03/12/18 16:11
>>725
switchから生成されるコードは主に
- if〜elseの羅列
- テーブルを使ったジャンプ
の2通りがある。
テーブルジャンプになった場合、関数呼び出しのコストがないため
関数テーブルを使ったものより早くなる。

どちらを生成するかは処理系に依存する。
実測だけではどちらを吐いているのかわからないので、
コードを吐かせて確認すべき。

処理系に依存させたくない場合は、
安定している関数テーブルの方を使った方がよいと思う。

727 :仕様書無しさん:03/12/18 16:27
718のどこがどう悪いんでつか?
この例ではgoto使ったほうがいいのでつか?
718がダメならイイ例のソース書いて。

728 :仕様書無しさん:03/12/18 16:38
>>718みたいなコード書くなんて
ハイパー短気な奴なんだろうなぁ

729 :仕様書無しさん:03/12/18 17:13
>>727
int func_with_goto()
{
  void *handle = NULL, *handle2 = NULL, *handle3 = NULL;
  int v = -1;
  
  handle = create(...);
  if (handle == NULL)
    goto error;
  handle2 = create2(handle, ...);
  if (handle2 == NULL)
    goto error;
  handle3 = create3(handle2, ...);
  if (handle3 == NULL)
    goto error;
  v = getValue(handle3);
 error:
  if (handle3)
    destory(handle3);
  if (handle2)
    destory(handle2);
  if (handle)
    destory(handle);
  if (v == -1)
    エラー時処理;
  return v;
}


730 :仕様書無しさん:03/12/18 17:14
int func_without_goto()
{
  int v = -1;
  void *handle = create(...);
  if (handle) {
    void *handle2 = create2(handle, ...);
    if (handle2) {
      void *handle3 = create3(handle2, ...);
      if (handle3) {
        v = getValue(handle3);
        destory(handle3);
      }
      destory(handle2);
    }
    destory(handle);
  }
  if (v == -1)
    エラー時処理;
  return v;
}


731 :仕様書無しさん:03/12/18 17:15
int func_without_goto2()
{
  void *handle = NULL, *handle2 = NULL, *handle3 = NULL;
  int v = -1;
  if (((handle = create(...))) &&
    ((handle2 = create2(handle, ...))) &&
    ((handle3 = create3(handle2, ...)))
    v = getValue(handle3);
  else
    エラー時処理;
  if (handle3)
    destory(handle3);
  if (handle2)
    destory(handle2);
  if (handle)
    destory(handle);
  return v;
}

func_without_goto() が美しく見えるが、
エラー処理がもっと沢山増えるとネストが深くなるので、
func_with_goto() にしたくなるんだよな。
難しい…
ま、C++ 使っとけと。


732 :仕様書無しさん:03/12/18 17:21
というわけで
どれも目くそ鼻くそ
趣味の問題っつーことだ。
お好きものをお試しあれ。

733 :仕様書無しさん:03/12/18 20:10
うちの会社の場合、
goto Kumiko;  /* 40代上司には評価される */
goto Maki;  /* 20代後輩には評価される */
こんな感じです。

734 :仕様書無しさん:03/12/18 21:51
Cだからあんな糞コードになるんであって、
C++でデストラクタを使えば無問題。

735 :仕様書無しさん:03/12/18 22:02
ここは汗もできない低能のすくつか

736 :仕様書無しさん:03/12/18 22:46
throw-catchのように使うのだけはありなんでない?

737 :仕様書無しさん:03/12/19 00:16
お前らの小細工などCPUに渡る頃には何の意味もない

738 :仕様書無しさん:03/12/19 01:19
C++でもすまぽつかわないとろくなことにならないけどな。

739 :仕様書無しさん:03/12/19 01:20
C++でfinally実装しなかった積極的な理由ってなにかあるの?

740 :仕様書無しさん:03/12/19 01:37
>>722
関数テーブルを通している時点でinlineになるわけない。

swtich対関数テーブルは、オレが試したところswitchの方が速い。


>>725
>op の値によっては jump を数十回繰り返す事を
>忘れてないか?

お前はswitchがif文の羅列になると思ってるのか?
まぁcaseの値によってはそうなる時はあるが、>>721は確実にそうならないケースだ。







741 :こうだな:03/12/19 02:55
with_goto
  void* handle1=NULL;
  void* handle2=NULL;
  void* handle3=NULL;

  handle=create(...);
  if(handle==NULL) goto ERR_EXIT;
  handle2=create2(handle, ...);
  if(handle2==NULL) goto ERR_EXIT;
  handle3=create3(handle2, ...);
  if(handle3==NULL) goto ERR_EXIT;
  v = getValue(handle3);
  destory(handle3);
  destory(handle2);
  destory(handle);
  return v;

ERR_EXIT:
  if(handle==NULL){
    エラー時処理
  }else if(handle2==NULL){
    エラー時処理
  }else if(handle3==NULL){
    エラー時処理
  }
  if(handle3) destory(handle3);
  if(handle2) destory(handle2);
  if(handle1) destory(handle);
  return -1;

742 :仕様書無しさん:03/12/19 02:57
if(handle1) って何だよ...

743 :仕様書無しさん:03/12/19 07:49
とりあえず
もうとっくに21世紀だぞ
いったいどれほどそんなチャチなチューニングをする機会があるのだ?

744 :仕様書無しさん:03/12/19 10:50
チューニングっていうのか?

745 :仕様書無しさん:03/12/19 11:11
まぁ、いまどき速度とか読みやすさとか気にする奴がバカってことで。


746 :仕様書無しさん:03/12/19 12:12
昔も今も大事でしょ。

747 :仕様書無しさん:03/12/19 12:14
>>741
gotoを使わないためにどんな汚い重複したコードをも正当化してしまうアンチってバカだね。

748 :仕様書無しさん:03/12/20 00:05
>>747
gotoを使わないと重複した汚いコードしか書けないロートルC厨ってバカだね。

749 :こんなんどう?:03/12/20 00:44
#define MAX(a,b) a>b?a:b

void* my_create(int kind, void *handle){
  void *p_ret;
  switch(kind){
  case 0x00: p_ret = create(...); break;
  case 0x01: p_ret = create2(handle, ...); break;
  case 0x02: p_ret = create3(handle, ...); break;
  }
  return p_ret;
}

int func_with_func(){
  void *handle[3] = {NULL,NULL,NULL};
  int i, v;
  for(i = 0; i < 3; i++){
    handle[i] = my_create(i, handle[MAX(i-1,0)]);
    if(!handle[i]){
      /* エラー時処理 */
      break;
    }
  }
  if(handle[2] && (v = getValue(handle[2])) == -1)){
    /* エラー時処理 */
  }
  for(i = 2; i >= 0; i--){
    if(handle[i]) destroy(handle[i]);
  }
  return v;
}


750 :仕様書無しさん:03/12/20 00:46
ゲロ吐きそうなコードだな

751 :仕様書無しさん:03/12/20 01:11
>>741>>729のgoto使いには悪いが、>>718の方が読みやすい。

そもそも、エラー処理が必ずしも共通で無い事を考えると>>718>>741の方法は使えない。
エラー処理が違う場合にgotoを使われるとソースが凄く読みづらくなる。
無意味にif〜elseを増やしてしまうからな。
って言うか、>>741よ。ifは出来るだけ、一つにまとめろ。

  if(handle==NULL){
    エラー時処理
  }else if(handle2==NULL){
    エラー時処理
  }else if(handle3==NULL){
    エラー時処理
  }

これはやめれ。


752 :仕様書無しさん:03/12/20 01:19
>>751
読み易いことは重要だが、
>>729 の注目すべきところは、
destory (というか後始末) する処理を 1 ヵ所にしか書かなくてすむ、
というところじゃないのか?


753 :仕様書無しさん:03/12/20 01:21
>>751
関数一個の中で、複雑なエラー処理になってしまうセンスに問題がある。

754 :749:03/12/20 01:56
今はhandleが3つだけど、handleが10コ20コになったときに俺の偉大さが
わかるだろう。カッカッカッ!
ていうか、カッコ1個たんないとこあるけどね(恥

755 :仕様書無しさん:03/12/20 01:57
>>741はどう考えても安置の刺客だろ。
int ret = -1;
if(!create1()) goto err1;
if(!create2()) goto err2;
if(!create3()) goto err3;
ret = exec();
err1: destroy1();
err2: destroy2();
err3: destroy3();
return ret;

>>751
>エラー処理が必ずしも共通で無い事を考えると
これはエラー処理ではなくリソース開放だから常に一定だ。

756 :仕様書無しさん:03/12/20 02:03
11 名前: 名無しさん@1周年 投稿日: 2000/09/15(金) 15:34

読み易い日本語について論じた本のなかで、2冊の本が紹介されている。

Aの本は「漢字を最小限にとどめた方が読み易い」と述べている。
Bの本は「漢字を適度に使った方が読み易い」と述べている。
A,Bそれぞれ、その主張どおりの漢字の使用法を使って記述されているが、
どちらも非常に読み易い。

この本の著者の主張こそ、至言だと思う。読み易さの本質は漢字の使用量と
は別なところにある。goto文にも同じ事がいえるのではないか。

757 :仕様書無しさん:03/12/20 02:09
>>751
「ifは出来るだけ、一つにまとめろ。」?

  if(handle==NULL){
    エラー時処理
    return -1;
  }
  if(handle2==NULL){
    エラー時処理
    return -1;
  }
  if(handle3==NULL){
    エラー時処理
    return -1;
  }

と等価にするには

  if(handle==NULL){
    エラー時処理
  }else if(handle2==NULL){
    エラー時処理
  }else if(handle3==NULL){
    エラー時処理
  }
  return -1;

であってる

758 :高卒アニオタ中年:03/12/20 02:10
>>755
間違えてないか?
gotoなんか使うから、関連が読めなくなるんだよ。

int ret = -1;
if(create1()){
  if(create2()){
    if(create3()){
       ret = exec();
       destroy3();
    }
    destroy2();
  }
  destroy1();
}
return ret;

じゃ嫌なのか?

759 :仕様書無しさん:03/12/20 02:25
>>758
いくつまでならそう書くのですか?

760 :仕様書無しさん:03/12/20 02:34
>>757
if( !handle && !handle2 && !handle3 ){
   エラー一時処理
}

761 :757:03/12/20 02:53
>>760
エラー処理が同じ、って事かよ

762 :仕様書無しさん:03/12/20 02:54
>>758
こいつはコード書かせても糞だな。

763 :高卒アニオタ中年:03/12/20 03:00
>>759
普通、そんなコードはかかんだろ(w
設計から見直してみな?

>>762
ハ?>>755 のポカミスを修正してやっただけだが・・・?

764 :仕様書無しさん:03/12/20 03:01
>>755 は解放漏れありそー。
>>760 は&&→||だよね?
>>718 は冗長性を嫌ってるわけで...。冗長を取り除きたければ、
gotoではなく、ループ使うこと考えないとねー。

765 :仕様書無しさん:03/12/20 03:05
>>755のコードってあぼーんしませんか?

766 :仕様書無しさん:03/12/20 03:10
結局 718 はクソ

767 :仕様書無しさん:03/12/20 03:37
どっちかっつーと 758 の方がクソ

768 :718:03/12/20 03:53
>>764
冗長性を嫌っているのではない。エラー処理ばっかり目立つので
ソースを見て何をしたいのかがぼやけてしまってつかみにくくなっている点が嫌。

あと 759 の言う通り
3つくらいなら問題ではないがすごく深いネストは嫌

769 :仕様書無しさん:03/12/20 04:34
「この戦(いくさ)、だめぽ」と皇(きみ)が言ったから8月15は オサマ記念日

770 :仕様書無しさん:03/12/20 09:05
↑なんじゃそりゃ


771 :720:03/12/20 09:13
>>718
だれもきちんと指摘して無いから718の問題点を指摘するが、
三個の場合は(1+2)=3個の途中のdestroyで済むが、
仮に10個の場合だと(1+2+・・・+9)=45個の途中のdestroyが必要となる。
正常終了時のdestroyを含めると55個だ。
そんな場合でもそう書くのか

772 :仕様書無しさん:03/12/20 10:27
たとえ3個でも、メンテナンス性を考えるとどっかにまとめといたほうがいいと思われ。

773 :仕様書無しさん:03/12/20 11:11
いつまでもCに固執しているから無益な議論が必要なんだよ

void DoSomething() {
struct HandleManager {
private: HANDLE handle;
public: HANDLE getHandle() const { return handle; }
public: HandleManager() : handle(Create()) {}
public: explicit HandleManager(HANDLE src) : handle(Create(src)) {}
~HandleManager() { if (handle != INVALID_HANDLE) { Destroy(handle); } }
};

HandleManager handleMgr1 = HandleManager();
HandleManager handleMgr2 = HandleManager(handleMgr1.getHandle());
HandleManager handleMgr3 = HandleManager(handleMgr2.getHandle());
if (handleMgr3.getHandle() != INVALID_HANDLE) { Execute(handleMgr3.getHandle()); }
}

774 :仕様書無しさん:03/12/20 11:13
インデント付け忘れた。

void DoSomething() {
 struct HandleManager {
  private: HANDLE handle;
  public: HANDLE getHandle() const { return handle; }
  public: HandleManager() : handle(Create()) {}
  public: explicit HandleManager(HANDLE src) : handle(Create(src)) {}
  ~HandleManager() { if (handle != INVALID_HANDLE) { Destroy(handle); } }
 };

 HandleManager handleMgr1 = HandleManager();
 HandleManager handleMgr2 = HandleManager(handleMgr1.getHandle());
 HandleManager handleMgr3 = HandleManager(handleMgr2.getHandle());
 if (handleMgr3.getHandle() != INVALID_HANDLE) { Execute(handleMgr3.getHandle()); }
}

775 :仕様書無しさん:03/12/20 11:40
>>773
C++ にしたところでまた別の無益な議論が始まる。とりあえず例外でも使ってみるか。
class HandleManager
{
  HANDLE handle;
  static HANDLE create_(HANDLE src = NULL)
  {
    HANDLE h = Create(src);
    if (h == INVALID_HANDLE)
      throw(何か);
    return h;
  }
public:
  HANDLE getHandle() const { return handle; }
  explicit HandleManager(HANDLE src) : handle(src) { }
  ~HandleManager() { if (handle != INVALID_HANDLE) Destroy(handle); }
};

void DoSomething()
{
  try {
    HandleManager handleMgr1();
    HandleManager handleMgr2(handleMgr1.getHandle());
    HandleManager handleMgr3(handleMgr2.getHandle());
    Execute(handleMgr3.getHandle());
  } catch (...) {
    エラー処理;
  }
}


776 :718:03/12/20 12:36
>>771
(もれはgoto使ってみたくなると言ってんのに...)
単純に「何をやっているの?」が読み取りやすいコードより
「何をしたいか」が読み取りやすいコードを要望している

ハンドル確保して
ハンドル使って
ハンドル解放

ってだけだろ? それが読み取りにくいのが嫌と言っている

取り敢えず数が多くて問題になるケースとは区別したい


777 :仕様書無しさん:03/12/20 12:37
関数に分ければ何の問題も無いのでは?

int f(void){void *handle; int v=-1;
if((handle=create(...))!=NULL) v=f2(handle);
destory(handle);
return v;}

int f2(void *handle){void *handle2; int v=-1;
if((handle2=create(...))!=NULL) v=f3(handle,handle2);
destory(handle2);
return v;}

int f3(void *handle,void *handle2){void *handle3; int v=-1;
if((handle3=create(...))!=NULL) v=getValue(handle3);
destory(handle3);
return v;}

f1 や f2 がまったく同じ処理なら再帰を使えばよい。


778 :仕様書無しさん:03/12/20 12:41
>>777
...もまえ、いっつもそんなコード作ってのか?
そんな aはbを bはcを cはdを...ってよく把握できるなぁ 頭いいんだね


779 :仕様書無しさん:03/12/20 12:53
へ? >>777 が難しいコードなのか?
因みに再帰ならこうか。

int f(int n, void *handles){int v=-1;
if(!n) v=getValue(handles[0]);
else if((handle[--n]=create(...))!=NULL) {v=f(n,handles);destory(handles[n]);}
return v;}


780 :仕様書無しさん:03/12/20 12:55
すまそ、間違えたか・・・

int f(int n, void *handles){int v=-1;

int f(int n, void **handles){int v=-1;


781 :仕様書無しさん:03/12/20 13:11
すべてのオブジェクトに同じ操作を適応するものと勘違いしてるな。

782 :778:03/12/20 13:13
1000行もある長い関数を処理分割して直せって言ったら

f(...){
100行
f2();
}

f2(...){
100行
f3();
}

:

ってやった奴を思い出したもので

783 :仕様書無しさん:03/12/20 13:17
>>781
藻前の言うオブジェクトの生成順に規則があるならば、
その規則に従った再帰を書けばよい。
無いならば >>777

一体何の問題があるんだ?


784 :仕様書無しさん:03/12/20 13:30
>>783
「操作」だ
「生成順」とは関係ない


785 :仕様書無しさん:03/12/20 13:32
handle1.5を加えたい場合とか、handle2を使わなくなった場合とか。
そういえば、fの中でhandle2とかhandle3とかを使いたい場合には
どうすればいいんだろう?
#まぁ、すべてf3の中に押し込めるぜんていなんだろうけど。

786 :仕様書無しさん:03/12/20 13:34
>>784
何故ここで「生成順」と書いたのか、意味分かっていないだろ。

>>777 若しくは >>779 で問題が発生する例を挙げてみてくれ。


787 :仕様書無しさん:03/12/20 13:38
779に関しては、すべてのオブジェクトがcreateとdestroyという名前の操作を備えている必要があるな。

788 :仕様書無しさん:03/12/20 13:47
>>786
もまえは create() と create2(),create3() を同一視しているが
何故781,784で「操作」と書いたのか、意味分かってないだろ。


789 :仕様書無しさん:03/12/20 13:49
先生、大変です
gotoの話と関係なくなっています(あげ)

790 :仕様書無しさん:03/12/20 13:50
>>785
む、これが例か?

>handle1.5を加えたい場合
途中で追加しても良いが、なぜ handle4 としないの?
途中に追加するということは、f2 以降の関数呼び出しから
getValue の呼び出しまでの間に handle1.5 を使わなければ
ならない状況が発生したと言うことだよね?
それならば追加前のコードは最初からまともに動作していなかった
という事になるのでは?(最初の設計間違え)

>handle2を使わなくなった場合とか。
普通に f2 を削除すればよい。

>そういえば、fの中でhandle2とかhandle3とかを使いたい場合には
>>777 の f で使いたいのなら、それはただのスパゲッティーコード。
根本的に設計が間違っている。
create されていない handle2 とかを使ってどうするよ?

>>779 の f の場合
handles[2] handles[3]
で解決(勿論、create されていない handlle は使用しない)。


791 :仕様書無しさん:03/12/20 13:52
つーか、これって昔からよく行われて、
実績のある方法だと思うのだが・・・


792 :仕様書無しさん:03/12/20 13:53
つまり、ちょっとでも設計間違ってたり仕様が変更されたら
使い物にならないコードというわけか。

793 :仕様書無しさん:03/12/20 13:56
>>788
分かっていない。説明してくれ。

もしそれが各オブジェクト毎の destroy の実体が違う
という内容ならば、>>777 でかたがつくと思うが。


794 :仕様書無しさん:03/12/20 13:56
>>790
変数一個消すのに、関数一個消して複数の関数を書き換える必要があるのか。
大変だな。

795 :仕様書無しさん:03/12/20 13:57
>>792
で結局gotoがどうの、ってよりCがダメって事で。

796 :仕様書無しさん:03/12/20 13:58
>>792
>つまり、ちょっとでも設計間違ってたり仕様が変更されたら
>使い物にならないコードというわけか。
一体どっからその結論がでてくるか、よく分からん・・・


797 :仕様書無しさん:03/12/20 14:01
>>796

794嫁

798 :仕様書無しさん:03/12/20 14:16
>>775
何が問題?構築済みのオブジェクトのデストラクタはちゃんと呼ばれるよ。

>>781
>すべてのオブジェクトに同じ操作を適応するものと勘違いしてるな。
template<typename HandleType> struct HandleManager
{
 中略
 public: HandleManager() : handle(CreationPolicy<HandleType>::Create()) {}
  public: explicit HandleManager(HANDLE src) : handle(CreationPolicy<HandleType>::Create(src)) {}
  ~HandleManager() { if (handle != INVALID_HANDLE) { CreationPolicy<HandleType>::Destroy(handle); } }
};

799 :798:03/12/20 14:19
template<typename HandleType> struct HandleManager
{
 中略
 public: HandleManager() : handle(CreationPolicy<HandleType>::Create()) {}
 public: explicit HandleManager(HandleType src) : handle(CreationPolicy<HandleType>::Create(src)) {}
 ~HandleManager() { if (handle != INVALID_HANDLE) { CreationPolicy<HandleType>::Destroy(handle); } }
};

か。テンプレートにしたから関数内には定義できなくなったかな。
ま、いずれにせよ C++ に移行していれば無益な議論は避けられるわけだ。

800 :後藤嫌い:03/12/20 14:19
結論 >>758が一番ミスが少なそうだよ

801 :仕様書無しさん:03/12/20 14:22
今はC++を使う積極的な理由がないからなぁ。

802 :仕様書無しさん:03/12/20 14:27
>>798
>何が問題?構築済みのオブジェクトのデストラクタはちゃんと呼ばれるよ。

各ハンドルの開放時にそのハンドルの生成前に生成したハンドルを
使用する場合、うまく開放できる保障はあるの?
(開放順の問題)


803 :仕様書無しさん:03/12/20 14:27
もはや(Cを使ってる分野で)C++を使わない積極的な理由を考えられない時代なんだがなぁ。


804 :仕様書無しさん:03/12/20 14:32
C++にはラベルbreakが無い

805 :仕様書無しさん:03/12/20 14:34
>>802
ISO標準の仕様書じゃなくてすまんが準標準仕様書のプログラミング言語C++第3版(日本語版)から
P294の下の方。

局所変数のデストラクタは、構築とは逆の順番で実行される。


806 :仕様書無しさん:03/12/20 14:35
>>804
Cにも無い
Javaとは比べてない

807 :仕様書無しさん:03/12/20 14:45
>>805
>局所変数のデストラクタは、構築とは逆の順番で実行される。

それは "静的な" オブジェクトについてだろ?
もしかして、オブジェクト内のメンバと
そのメンバがハンドルとして持つ別のオブジェクトを
ごっちゃにしていない?


808 :仕様書無しさん:03/12/20 14:47
>>807
ハァ?局所変数って書いてあるだろ?
デストラクタで破棄してんだろ?

もう一回勉強しなおしてこいや。

809 :808:03/12/20 14:48
ああ、C++デストラクタをJavaファイナライザと勘違いしてんのか。
C++のデストラクタは解体時に確実に実行される。

810 :仕様書無しさん:03/12/20 15:40
おわったのか?

811 :仕様書無しさん:03/12/20 16:35
>>775
create(...) と create2(handle, ...) と create3(handle, ...)
の呼び分けは無視?

812 :後藤嫌い:03/12/20 18:03
>>810
結局、goto推進派が >>755 みたいなミスを犯したことで、
gotoはバグを盛り込みやすいということを立証しただけだよな・・・

gotoは糞ということで終了

813 :仕様書無しさん:03/12/20 18:29
いわゆる刀狩ってやつだな。
刀は危ないので、暴徒に持たせるのはやめましょうってさ。
まあ、意味のある政策だとは思う。
おれはgotoを使うけどね。

814 :仕様書無しさん:03/12/20 18:30
>>812
前スレの早い段階で「莫迦はgoto使うな」という話は
出ているし、このスレでももう「一切使わせないとするか
どうか」の話まで進んでいるというのに…
「推進派」とはね。ヤレヤレ

815 :仕様書無しさん:03/12/20 19:16
C++やJavaでtry-catchを乱用してる奴は、Cでgoto使えないと
しんどいだろーなー。
俺はgotoもtry-catchも滅多に使わないよ。
まあ、使用を強制させられる場面もあるけど。

816 :仕様書無しさん:03/12/20 19:58
なんで頭がいいからgotoを使っても良い使うのだっていう発想になるのかね?
頭が悪いからgotoしか方法がないんだろ?

817 :仕様書無しさん:03/12/20 21:01
だからー。一気にループ分を抜けたいときに便利だろ?
while(){
while(){
goto ddd;
}
}

ddd:

もしくは、エラー処理。


818 :仕様書無しさん:03/12/20 21:07
>>817
同じ話題を何度も持ち出すお前は、そうとう頭悪いな。

819 :仕様書無しさん:03/12/20 21:39
>>817
後処理の類にはデストラクタ使え、
エラー処理には例外使え。

Cしか使えないのは無能の証拠。

820 :仕様書無しさん:03/12/20 21:51
>>819
Cでしか開発できないもの(または製品)に対してC++だったらできるのに〜
などと言う奴は池沼以下の役立たず。


821 :749:03/12/20 22:10
結局、俺のコードが一番かっけーなー。
vの初期化忘れてるが(恥


822 :仕様書無しさん:03/12/20 22:30
>821
my_create()の中のp_retも初期化忘れてるって


823 :仕様書無しさん:03/12/20 22:40
void型にポインタも気持ちが悪い。

824 :仕様書無しさん:03/12/20 22:42
>>819はスレタイも読めない真性馬鹿

825 :749:03/12/20 22:48
>>822
p_retの初期化はいらんがな。行数の関係でswitchのdefault省略
したんだよ。
>>823
勝手にキャストせいっ!


826 :仕様書無しさん:03/12/20 22:48
>>819にはとりあえず、論理的に考える癖を身に付けることをお勧めする。

827 :仕様書無しさん:03/12/20 22:53
>825
何故初期化がいらないのか解説キボン

# 不定値が返るのはイカンだろ、普通

828 :749:03/12/20 23:08
>>827
switchのどっか通れば、値入るっしょ?不定値は返らん。
今回は0,1,2しか引数とらないから、行数減らすために
default: p_ret = NULL; break; を省略。

829 :仕様書無しさん:03/12/20 23:20
どちらでも書けるのがプロ

830 :仕様書無しさん:03/12/20 23:28
>>749
my_create関数は在った方がいい?
俺の目には関数化する意味はあまりないように見えるんだけど
行数減らすためだったら関数ポインタの配列つかえばいいし

831 :仕様書無しさん:03/12/20 23:50
あのー、そもそも1関数内でcreateの入れ子をそんなにやる設計が間違ってないか?

832 :749:03/12/20 23:54
>>830
関数ポインタ配列じゃ、型合わせないとだよね?
create(...)とcreate2(handle, ...)とcreate3(handle, ...)
は型違うから配列にしても使い勝手が悪いような。

833 :仕様書無しさん:03/12/21 00:17
817の言う通り、多重ループからのbreakとエラー処理に関しては
goto使っても問題なし。ほかにはないかな?

834 :696:03/12/21 00:17
>>831
>>696


835 :仕様書無しさん:03/12/21 00:18
>>831
入力ファイル数個+出力ファイル数個+その他
で5〜6個くらいは簡単にいくけど。

836 :仕様書無しさん:03/12/21 00:28
>>833
goto使っても問題ない場合を列挙したいの?
なんで?

837 :仕様書無しさん:03/12/21 00:42
ちょっと整理したい >>718 ではイヤなので、

1.goto使って書き換えた場合
>>729 ※エラー処理を同一視
>>741

2.エラー処理を同一視し、ifを並べた場合
>>730

3.エラー処理を同一視し、ifの構造を変更
>>731

4.エラー処理を同一視し、ループ
>>749

5.関数化(呼び元のコードは不明)
>>777

---
※もはや等価ではないが、再帰
 >>779
 
 もはやCでないが
 >>773
 >>775
---

で、「gotoを使わない理由」は何?
使う理由としては 718、730よりはましと思うからだが


838 :仕様書無しさん:03/12/21 00:43
>>731
もれなら(エラー時処理が同一だったとして) 一つのifにしないで

 void *handle = NULL, *handle2 = NULL, *handle3 = NULL;
 int v = -1;
 handle=create(...);
 if(handle)
  handle2=create2(handle, ...);
 if(handle2)
  handle3=create3(handle2, ...);
 if(handle3)
  v = getValue(handle3);
 else{
  エラー時処理
 }
 if(handle3)
  destory(handle3);
 if(handle2)
  destory(handle2);
 if(handle)
  destory(handle);
 return v;

こう書くな


839 :仕様書無しさん:03/12/21 00:44
>>749
もれなら(エラー時処理が同一だったとして)

void* my_create(int kind, void *handle){
  void *p_ret;
  switch(kind){
  case 1: p_ret = create(...); break;
  case 2: p_ret = create2(handle, ...); break;
  case 3: p_ret = create3(handle, ...); break;
  }
  return p_ret;
}

int func_with_func(){
  void *handle[3+1] = {NULL,NULL,NULL,NULL}; /* [0]は にせ */
  int i, v=-1;
  for(i = 1; i <= 3; i++){
    handle[i] = my_create(i, handle[i-1]);
    if(handle[i]==NULL){
      /* エラー時処理 */
      break;
    }
  }
  if(handle[3]) v = getValue(handle[3]);
  for(i = 3; i >= 1; i--){
    if(handle[i]) destroy(handle[i]);
  }
  return v;
}

ってする


840 :仕様書無しさん:03/12/21 00:51
gotoだろとうなんだろうと使いたきゃ使えばいいじゃねーか。
死ぬわけじゃあるめーし、減るもんじゃあるめーし。
てめーらいちいちうるせーんだよ。goto、goto、そんなに goto が好きなら goto と
結婚すればいいんだよ。T シャツにも goto ってでっかくプリントしとけ。


841 :仕様書無しさん:03/12/21 00:54
プロジェクトを複数人でやってる時はgotoヤバいだろ
「自分だけ特例」とか考えちゃうのか?goto推進派わ

一人で組んでる&運用/メンテも責任持つ、ってのなら
どうやっても構わないがな

842 :仕様書無しさん:03/12/21 01:01
>>841
goto否定派も
「初心者が馬鹿なコードを書くから規約で禁止。
でも上級者が使うのはかまわない」
とか言ってるので、あまり変わらないかと。

843 :仕様書無しさん:03/12/21 01:03
ああ次から次に構造化コード原理主義者が参加してくる
話が進まないじゃないか。大変だろうと思うけどスレの先頭から読んでくれ

844 :仕様書無しさん:03/12/21 01:09
>>841
禁止したって、ヤバいプログラム作る組織が改善されるわけでもないし、
まともなコードがぐちゃぐちゃにされた例も何度も見てるし。
(プログラムの変更履歴を追っていくと、ぐちゃぐちゃになる過程が見えて
それはそれで興味深いけど)

845 :仕様書無しさん:03/12/21 01:10
>>839って何時もそういうコード書いてるの?
ほんとに?


846 :仕様書無しさん:03/12/21 01:31
>>843
話を20年巻き戻してるのはそっちだろう?
大変だろうけど時代の流れを読んでくれ

847 :仕様書無しさん:03/12/21 01:31
>>846がうまいこと言った!!

848 :仕様書無しさん:03/12/21 01:33
>でも上級者が使うのはかまわない

と言っている上級者なんてみたことないんだけど。
自称上級者だろ、その手のバカは

849 :仕様書無しさん:03/12/21 01:47
本物のプログラマはgotoを恐れずに使う。の
本物のプログラマを字面通りの意味(上級者)に取ったと思われ
goto利用者を馬鹿にされているとは思いたくなかったのだろう

850 :仕様書無しさん:03/12/21 01:49
もはや(Cを使ってる分野で)C++を使わない積極的な理由を考えられない時代なんだがなぁ。

851 :仕様書無しさん:03/12/21 01:53
本物のプログラマをジョークだと解釈しないやつは
相当イタいな。けっこう出会ったけど。
もちろん、そいつらはかなり融通の効かない天然ボケばっかりだったが(w

852 :仕様書無しさん:03/12/21 02:06
goto否定派は勘違い君ばっかりということで。

853 :749:03/12/21 02:15
>>837
エラー処理を同一視はしてないぞ。indexで分岐すりゃいい話。
あとgoto使わないのは、Cに思い入れがあるからかな。
そりゃ、VB使う時はgoto使ってるし、昔BASICやってたから
別にgoto否定はしないが、「Cなんだからさー」という漠然とした感覚はある。
Cじゃgoto使わないのがスタンダード。
伝統を汚されて難色示す人間がいないと思うのは間違い。

854 :仕様書無しさん:03/12/21 02:16
gotoはむやみに使ってはならぬのぢゃ
理解せずに使っていくととてつもなく恐ろしい事が起こるのでナ

それが証拠にJavaでは決して使われる事の無いように封印されておる
良いな?皆の為にも使ってはならん

...これだけ言ってもまだ分からぬか...


855 :843:03/12/21 02:24
>>846
時代の流れ?。何それ?。構造化のこと?
構造化が良い方法であることは認めるけどそれだけのことだろ

856 :仕様書無しさん:03/12/21 02:27
>>855
gotoを使わない時代の流れがどんな物だったかはもう昔の事すぎてわからないよ
gotoを使って処理の流れを制御していた頃はそれよりもっと前の時代の事だから
ぼくら現代人にはわからないよ

857 :仕様書無しさん:03/12/21 02:27
構造化ってgoto使っててもできるだろが、あに言ってんだ?
構造化=gotoレスってあほか

858 :仕様書無しさん:03/12/21 02:27
>>854
javaには備わっているラベル付きのbreak/continueがcには無いんだ。
あんたはそのようなことをしたいときにはcではどう書くというんだ

859 :仕様書無しさん:03/12/21 02:27
>>852
書き間違えてるよ。
goto肯定派だろ(w

860 :仕様書無しさん:03/12/21 02:31
>>858
ラベル付きbreakはともかく、C++ならgotoを使わずに済むのに
Cに固執してるあたりがgoto使いのダメなところだと気づけ。
Javaは使えなくてもCの分野ならC++はとっくに実用段階だろうが。

861 :仕様書無しさん:03/12/21 02:31
gotoかめはめ派


862 :仕様書無しさん:03/12/21 02:35
>>857
文法レベルの話をしている場合は
構造化=構造化フロー制御だろが
話の流れも満足に追えない池沼が
gotoでスパゲッティ作ってんじゃねーぞ

863 :仕様書無しさん:03/12/21 02:35
>>857
構造化についての認識が違うんだ。構造化コード原理主義者の認識は>>166だ。

864 :仕様書無しさん:03/12/21 02:36
>>851
このスレには結構いるみたいだな


865 :仕様書無しさん:03/12/21 02:40
>>863
原理主義ってあなた…。
まあ理想は>>166だけど現実的じゃないから細かい回避手段があるんだけどね。
でもgotoは細かい回避手段には含まれないと思うよ。
明らかに構造化をぶち壊す存在だよ。

866 :仕様書無しさん:03/12/21 02:42
「本物」ってつまり新しい良いものになじめず古い言語にしがみついているってだけの事だろ

867 :仕様書無しさん:03/12/21 02:42
>>851
基本的にはジョークなんだが。完全にはジョークでは無いんだ。
なぜなら本物のプログラマに書いてある「本物のプログラマ」は沢山実在した。
あれはプログラマを取り巻く開発環境が変化し続けている事実を特殊な視点から表現したものなんだ。

868 :仕様書無しさん:03/12/21 02:44
やっぱり、goto否定派には「本物のプログラマ」を真に受けてると真に受けてる人が多いらしい。

869 :858:03/12/21 02:45
>>865
>>858

870 :858:03/12/21 02:47
>>860
別言語の話をしてどうなる

871 :251:03/12/21 02:51
>>856
失礼な人ですね。私は現代人です。

872 :857:03/12/21 02:52
(166読みますた)
所詮ループはifとgotoの組み合わせでしかないだろがヴォケ
入り口と出口が一つって、なんじゃそりゃ?幼稚園児並みの脳みそか?

...って思いました

873 :仕様書無しさん:03/12/21 03:03
>>872
まあ構造化定理自身が「実践」から遠く離れている前提を使っていることは間違い無いです。
これで「プログラムの証明」も可能なようですよ。実践には使えないレベルですけど。

874 :仕様書無しさん:03/12/21 03:05
まぁ紙のお告げにしたがってさえいれば幸せでつからね

875 :仕様書無しさん:03/12/21 03:19
どっちにしても自分のことを「本物のプログラマ」などとほざくのに
本物などいないというこった。羞恥心がないって意味も含めて。

876 :仕様書無しさん:03/12/21 03:26
>>875 人間不信?

877 :251:03/12/21 03:29
>875
それ経験十年未満の人間に限った話にはなりませんか

878 :仕様書無しさん:03/12/21 03:32
十年以上プログラマな奴は、無能に決まっている。

879 :仕様書無しさん:03/12/21 03:34
経験年数には関係ないだろう。


880 :仕様書無しさん:03/12/21 03:38
夜中の間に自作自演で自分のムードに持っていこうとしている人がいるスレはここですか?
夜中の間に自作自演で自分のムードに持っていこうとしている人がいるスレはここですか?
夜中の間に自作自演で自分のムードに持っていこうとしている人がいるスレはここですか?
夜中の間に自作自演で自分のムードに持っていこうとしている人がいるスレはここですか?
夜中の間に自作自演で自分のムードに持っていこうとしている人がいるスレはここですか?

881 :仕様書無しさん:03/12/21 03:39
このスレのはじめのほうからずっと自作自演だけで話を進めている人がいるスレはここですか?
このスレのはじめのほうからずっと自作自演だけで話を進めている人がいるスレはここですか?
このスレのはじめのほうからずっと自作自演だけで話を進めている人がいるスレはここですか?
このスレのはじめのほうからずっと自作自演だけで話を進めている人がいるスレはここですか?
このスレのはじめのほうからずっと自作自演だけで話を進めている人がいるスレはここですか?

882 :仕様書無しさん:03/12/21 03:39
このスレのはじめのほうからずっと自作自演だけで話を進めている人がいるスレはここですか?
このスレのはじめのほうからずっと自作自演だけで話を進めている人がいるスレはここですか?
このスレのはじめのほうからずっと自作自演だけで話を進めている人がいるスレはここですか?
このスレのはじめのほうからずっと自作自演だけで話を進めている人がいるスレはここですか?
このスレのはじめのほうからずっと自作自演だけで話を進めている人がいるスレはここですか?

883 :仕様書無しさん:03/12/21 03:40
子供のお人形遊びのように自分と会話している人がいるスレはここですか?
子供のお人形遊びのように自分と会話している人がいるスレはここですか?
子供のお人形遊びのように自分と会話している人がいるスレはここですか?
子供のお人形遊びのように自分と会話している人がいるスレはここですか?
子供のお人形遊びのように自分と会話している人がいるスレはここですか?

884 :仕様書無しさん:03/12/21 03:40
そうやって自作自演でやってて何が楽しいんですか?そうやって自作自演でやってて何が楽しいんですか?
そうやって自作自演でやってて何が楽しいんですか?そうやって自作自演でやってて何が楽しいんですか?
そうやって自作自演でやってて何が楽しいんですか?そうやって自作自演でやってて何が楽しいんですか?
そうやって自作自演でやってて何が楽しいんですか?そうやって自作自演でやってて何が楽しいんですか?
そうやって自作自演でやってて何が楽しいんですか?そうやって自作自演でやってて何が楽しいんですか?

885 :仕様書無しさん:03/12/21 03:41
そろそろ現実を見つめませんか?そろそろ現実を見つめませんか?そろそろ現実を見つめませんか?
そろそろ現実を見つめませんか?そろそろ現実を見つめませんか?そろそろ現実を見つめませんか?
そろそろ現実を見つめませんか?そろそろ現実を見つめませんか?そろそろ現実を見つめませんか?
そろそろ現実を見つめませんか?そろそろ現実を見つめませんか?そろそろ現実を見つめませんか?
そろそろ現実を見つめませんか?そろそろ現実を見つめませんか?そろそろ現実を見つめませんか?

886 :仕様書無しさん:03/12/21 03:43
>251お前の事だよ>251お前の事だよ>251お前の事だよ>251お前の事だよ>251お前の事だよ
>251お前の事だよ>251お前の事だよ>251お前の事だよ>251お前の事だよ>251お前の事だよ
>251お前の事だよ>251お前の事だよ>251お前の事だよ>251お前の事だよ>251お前の事だよ
>251お前の事だよ>251お前の事だよ>251お前の事だよ>251お前の事だよ>251お前の事だよ
>251お前の事だよ>251お前の事だよ>251お前の事だよ>251お前の事だよ>251お前の事だよ

887 :251:03/12/21 03:44
>878
>879
そうかもしれませんね。私も「本物のプログラマ」になるのを諦めた人間ですが

888 :仕様書無しさん:03/12/21 03:49
やぱり、gotoを使うのにラベルは分かり図らいですよ。
gotoなら飛び先は行番号で指定しないと。
行番号が無いってところが、Cでgotoを使わない理由だと思いますよ。


889 :仕様書無しさん:03/12/21 03:51
>>888>>251
何でバカのふりして書きこんでんの?

890 :仕様書無しさん:03/12/21 03:53
>>880-886
現実は以外にも >>880-886 の書き込みが
このスレの半数以上を占めているという罠(w

891 :仕様書無しさん:03/12/21 03:54
>>890>>251
おつかれさん。

892 :仕様書無しさん:03/12/21 03:56
>>888>>890>>251
誤変換多いじゃん。
動揺してんのかな?


                  か  わ  い  い  〜



893 :仕様書無しさん:03/12/21 04:04
最近マ・ム板双方で、他人の文を引用するのに'>' を使わず
'>' を使う奴の書き込みがやたらウザイと思わない?

試しに(このスレだけでなく)いろいろなスレで、
'>' をキーワードにしてレスを絞り込んでみると、
そいつの性格・能力が丸見えになって実に笑える。


894 :仕様書無しさん:03/12/21 04:07
>>893=>251
きたー!妄想断定厨!
「こういう書き方する奴ってウザくない?」
ってたまたま似た書き方の奴まで勝手に敵と断定。
相手があきれるまで粘着。

あのな、なんで荒らしまでしてると思う?
俺はてめーのその勝手な断定で迷惑してんだよ。
あっちこっちのスレで喧嘩売りやがっていいかげんにしやがれボケ。

895 :仕様書無しさん:03/12/21 04:08
>>893
ヒッキーってうらやましいよな
一日中へばりついて自作自演しほうだいだもんな
ただ人生廃業してるだけじゃないよな
2ちゃんで第二の人生これだけ謳歌してんだもんな

896 :仕様書無しさん:03/12/21 04:10
で、結局このスレでマジメに議論したいgoto肯定派のみなさんは
どこへいっちゃったのかな?
教えて欲しいな〜〜〜。



897 :仕様書無しさん:03/12/21 04:12
今から注意したところで、既に書き込んだレスは
決して消えない。。。と(w


898 :仕様書無しさん:03/12/21 04:15
>>897
オマエモナー

その特徴のレスにことごとく噛み付きレス番号なしで自作自演し続ける
バカの粘着っぷりを皆様にもごらん頂きたい。是非!

899 :仕様書無しさん:03/12/21 04:20
傍で腹を抱えて大笑いしている >>251 の姿が目に浮かぶ。


900 :仕様書無しさん:03/12/21 04:21
>>899
そういう書き込みをしなくちゃいけない>>251の姿が目に浮かんで腹を抱えて笑いたくなる。

901 :仕様書無しさん:03/12/21 04:22
いいか、俺がお前から唯一教わった事がある。
粘着自作自演で話を進められるといかに人間が不愉快な気持ちになるか。
お前もその気持ちを味わったらどうだ?
そもそも俺はお前が敵だと思った香具師にたまたま文体が似ていただけだ。
それであちこちで常に自作自演され続けてきた。
今では俺の文体の方をお前の敵だと誤解しているんだろう。
そうやってお前は敵を増やしつづけていくんだ。

902 :仕様書無しさん:03/12/21 04:28
>>901
>いいか、俺がお前から唯一教わった事がある。
>粘着自作自演で話を進められるといかに人間が不愉快な気持ちになるか。

スゲー! 成長したじゃん!


903 :仕様書無しさん:03/12/21 04:29
>>899
冷静に考えたらわかるよね?
そんな事わざわざ書くのは>>251だけだって。

そろそろ>>251として
「私は笑いませんよ。かわいそうな人だから」
とでも書き込むんですか?

904 :仕様書無しさん:03/12/21 04:34
ところで >>903>>880-886 とは別人だよな?
ああ、当たり前だよな。

'>' 使っていないしな。

905 :仕様書無しさん:03/12/21 04:36
>>902>>904
必死に関係ない話に持っていこうとするなよ

906 :仕様書無しさん:03/12/21 04:40
さて十分に揚げ足とって楽しんだからもう寝るか。




これから複数人による荒らしの批判がはじまりますが、
全部同一人物の自作自演なので気にしないで下さい。敬具。

907 :仕様書無しさん:03/12/21 04:40
ああ、それから>>251もレス番号付きで登場します。


908 :仕様書無しさん:03/12/21 04:41
って書いておくとその通りにしづらくて効果的だよね〜

909 :仕様書無しさん:03/12/21 04:43
>>894-900
基地外の自作自演を眺めるスレはここでつか?

910 :>>894-900 のうち、>>897,899:03/12/21 04:47
>>909
すいません、やぱーり俺も吉外ですか?


911 :仕様書無しさん:03/12/21 04:48
>>251
明日の朝まで待ったら?
「なんか夜中の間に強烈な妄想電波粘着がいたみたいだな」
って書けばいいんじゃな〜い?

「それともgoto否定原理主義者は負けそうになると基地外」
でもいいかもね〜

912 :仕様書無しさん:03/12/21 04:49
>>910
はーい吉外でーす。

そんなあからさまに文体変えるなよ。
お前人にばれないように街中歩こうとしたときに
サングラスにつけヒゲとかするのか?

913 :仕様書無しさん:03/12/21 04:57
なにこのスレ?出来すぎてる。
ひとり漫才やってるわけではないよな
とりあえず記念パピコ


914 :仕様書無しさん:03/12/21 04:59
>>913
希望があって、まだ '>' がいれば、
もっと続けてもいいけど、どうよ?


915 :仕様書無しさん:03/12/21 05:14
>>914
お前'>'に無駄につっかかる人だから'<'な。


916 :仕様書無しさん:03/12/21 05:20
いや、できれば >>251 と呼んで欲しいのだが・・・
ただ、>>913 の希望がないのでやめた。


917 :仕様書無しさん:03/12/21 10:10
ついにキレた香具師が出てきたか。
あまりにも酷いやり方だったから、いつかはこうなるとは思っていたが・・・

918 :仕様書無しさん:03/12/21 10:36
しかし、朝5時まで一人で書き込みつづけるとは、すごいな。。

919 :仕様書無しさん:03/12/21 10:37
オモシロ杉

920 :仕様書無しさん:03/12/21 10:46
あの野郎このスレでも多数派工作してやがんの(プ

921 :373:03/12/21 10:50
>希望があって、まだ '>' がいれば、
記念パピコ

922 :仕様書無しさん:03/12/21 10:52
夜中の間なにやってんの?

 藤井総裁<プ。

923 :仕様書無しさん:03/12/21 10:52
なにこのスレ




                  か  わ  い  い  〜





924 :仕様書無しさん:03/12/21 10:55
>>251
電車には飛び込むなよ。
人に迷惑かけっぱなしのおまえの人生
最後まで他人に迷惑かけるな。

925 :仕様書無しさん:03/12/21 10:59
次スレはここと一緒にしようぜ。
C++使えばgoto議論なんて必要ないんだからさあ。
http://pc.2ch.net/test/read.cgi/prog/1061940405/l50

926 :仕様書無しさん:03/12/21 12:45
ラベルbreak相当もExceptionで?
try {
 for (...) {
  for (...) {
   :
   if (hogehoge)
    throw ...;
   :
  }
 }
} catch (...) {
 :
}

927 :仕様書無しさん:03/12/21 14:47
int func_without_goto3()
{
  void *handle = NULL, *handle2 = NULL, *handle3 = NULL;
  int v;
  handle = create(...);
  if(!handle)
   handle2 = create2(handle, ...);
  if(!handle2)
   handle3 = create3(handle2, ...);
  if (handle3) {
    v = getValue(handle3);
    destory(handle3);
  } else
   v = -1;
  if (handle2)
    destory(handle2);
  if (handle)
    destory(handle);

  if (v<0)
   エラー処理;
  return v;
}

漏れのうんと前に書いたCはこんなことしてた。我ながら馬鹿正直ッツか馬鹿w


928 :仕様書無しさん:03/12/21 15:14
次スレ
http://pc.2ch.net/test/read.cgi/prog/1066222336/

929 :251:03/12/21 16:01
私は、>>570>>641へのレスを希望します。
#肯定も否定もなく「無視」ではどうもレスし辛いです。
#誰かの怒りをかっている様ですが、全く身に覚えがありません。
#自分のレスに自己レスしたこともありませんしね。

930 :仕様書無しさん:03/12/21 16:25
>>251
あなたに簡潔な伝達能力が欠如しているのでレスする必要なし、と判断されたのでは。

931 :仕様書無しさん:03/12/21 16:28
後藤君モテモテだね

932 :251:03/12/21 16:34
>930
「あなたに簡潔な伝達能力が欠如しているのでレスする必要なしと判断した」
なら納得しますが。

933 :仕様書無しさん:03/12/21 17:39
自演ばらされて何食わぬ顔で出てきたと思ったら言葉じり捕らえての返答か
苦しすぎるな後藤君

934 :211:03/12/21 18:57
結局、本質的な議論はあまりなされないまま急速にスレの幼稚化だけが進行しているようですね。

continueやbreakがgotoだ、なんていう倒錯したレスに対する反論も何もないようだし。
そりゃそうだが、それを言ったらifもwhileもswitchもgoto(というかjump)を
隠蔽するための仕組みな訳で。

多重ループから一気に抜けたいときにはgotoは有用だ、という議論も、
間違ってはいないが抽象水準が低過ぎる。もっと条件を一般化して語るべきだろう。

そもそも構造化言語でそのようなgotoを隠蔽するような仕組みを作り、
gotoを推奨しないわけは、それは人間の認識能力にあるわけだろう。

つまり、昔よく「マジカルナンバー7」とか言ったけど普通の人の頭脳は、
「意味を把握しやすい(=言語化しやすい)ひとかたまりの処理」の間の分岐として
書かれていないコードを簡単に把握できるようには出来ていないのだが、gotoの乱用は、
一塊のコードを意味をもった「ブロック」と認識する可能性をを阻害するから。

ただ、そうやってifやwhileでgotoを隠蔽したことの弊害も確かにあって、
それは「意味をもった処理ブロック」へ分岐する入口が1つに制限されてしまうことだろう。

935 :高卒アニオタ中年@酔っ払い:03/12/21 19:02
>>929
最近このスレ読み始めたので読み漏れが多のだが・・・

gotoの使用により、以下の問題点が回避できると考えてるようだが
・フラグ変数の乱用を招く(制御結合を招く)
・関数の肥大化
本当にgotoによってもたらされる効果なのか?
正しく関数化/構造化されたコードを書けば、gotoなぞ使わなくとも
読みやすいコードを生成することは可能だろ。

>>641 に関しては大筋同意なんだが、「gotoを正しく使う」というのが
いまいち理解できない。
どれだけ上手い香具師が書いたにしろ、C言語のgoto構文は、
構造化されたコードにメスを入れていることは確かだろ。
後のメンテナンスでバグを盛り込む可能性も少なくは無い。
Javaのように文法上保証されているのならともかく、
書いた本人の意識だけに任されるようなあいまいな規約なら
多人数開発では大きな障害になることもある。

個人的な意見で悪いが、gotoを庇護する251の意見は、
「まともに設計されていない構造を少しでも読みやすくしたい」
としか見えない。

gotoの回避にかかる手間なんてちょっとしたものだろ?
あえて gotoを許容するだけのメリットが見えてこないぞ?
漏れは、gogoを禁止することで、
「もっとまともに設計汁!!」という規制にしたいがどうか?

# つまるところ、「C言語のgoto文の仕様が糞」が原因で、
# それを 使うか 使わないか だけの議論だよな?

936 :仕様書無しさん:03/12/21 19:05
入り口という考えが、すでに「意味を持った処理ブロック」から外れてない?
そもそも「処理の共通化」っつ低レベルのサブルーチンから
意味を抜き出すのが構造化で、30年以上前あったことだろ。

937 :仕様書無しさん:03/12/21 19:06
60年代でつね>gogo禁止。

938 :仕様書無しさん:03/12/21 19:09
>>934
そりゃ、乱用すれば何だって「ブロック」と認識できなくなるし、
人間の短期記憶の容量をオーバーするわな。

そのまま書き下していたら煩雑になるものを、意味のある
ブロックに分割するためにgotoを使うことだってあるわけで。

939 :仕様書無しさん:03/12/21 19:11
>>927
おいおい、関数を呼び出しちゃだめだろ。構造化プログラミングになっちゃうから。
ちゃんと、goto で関数相当のサブルーチンを呼び出して、goto で元のところに
戻って来なきゃ。


940 :仕様書無しさん:03/12/21 20:32
>急速にスレの幼稚化だけが進行しているようですね。

はじめから幼稚なスレだったが。

941 :251:03/12/21 22:47
>>934
総論が良く理解できません。各論は

>多重ループから一気に抜けたいときにはgotoは有用だ、という議論も、
>間違ってはいないが抽象水準が低過ぎる。もっと条件を一般化して語るべきだろう。
正しい様に聞こえますが、「抽象化/一般化」の具体的な理解が及びません。
私の想像力が貧困であるせいかも知れません。
多重ループという実例に対しては、goto否定論者から「設計が悪い」という曖昧な
回答と、ループの継続条件に多重ループ終了のフラグ情報を加味するべしという実例
が回答されていますね。
ここが焦点です。判りやすさという主観が、二つに分かれています。
goto肯定側はgotoを使って脱出して方がわかりやすいと判断し、
goto否定側はフラグ情報を使用するほうがわかりやすいと判断しています。(違う?)
こうなると話は平行線ではないでしょうか。
そこでこの件については「開発担当に一任する」という結論しか出ないのではないかと
思いますよ。つまり「有用だと開発担当が判断すれば有用」ということです。

>ただ、そうやってifやwhileでgotoを隠蔽したことの弊害も確かにあって、
>それは「意味をもった処理ブロック」へ分岐する入口が1つに制限されてしまうことだろう。
それが弊害であるとは思いません。構造化コードはこの点が最重要項目なのです。

942 :仕様書無しさん:03/12/21 22:55
>>941
君はいったい何を主張したいの?

943 :仕様書無しさん:03/12/21 23:04
要するに関数の作り方が分からない人が goto を使うのさ。


944 :仕様書無しさん:03/12/21 23:05
OO が分からない人が C++ を C のように使うみたいに。


945 :仕様書無しさん:03/12/21 23:06
あと、if 文とか while 文とかが理解できない人。


946 :仕様書無しさん:03/12/21 23:07
C でも N-BASIC みたいに main ひとつで書くような人か。


947 :仕様書無しさん:03/12/21 23:08
>>946
COBOL はそうせざるを得ないみたい。
COBOL 上がりの人が goto 使うんじゃん? 構造化プログラミングになじめなくて。


948 :仕様書無しさん:03/12/21 23:12
そんな奴いるの?...コボラーさん?

949 :仕様書無しさん:03/12/21 23:15
>>935
「構造化されたコードがそうでないコードより必ず読みやすい」ということをまず示してください。

950 :251:03/12/21 23:16
>>935
>gotoの使用により、以下の問題点が回避できると考えてるようだが
>・フラグ変数の乱用を招く(制御結合を招く)
>・関数の肥大化
>本当にgotoによってもたらされる効果なのか?
その記述は正確には「gotoを禁止することにより発生しうる問題点の列挙」です。
「現在gotoは禁止だが、解禁することによってどうなるのか?」という視点だけで考えていませんか?
#また、現在そのような問題点は存在していない判断をしていますか?

>正しく関数化/構造化されたコードを書けば、gotoなぞ使わなくとも
>読みやすいコードを生成することは可能だろ。
論点が微妙にずれています。私の主張は
「正しく関数化(構造化プログラム設計)がされてさえいれば、gotoを使用しても読みやすいコードを生成することは可能だろ」
ですよ。

>書いた本人の意識だけに任されるようなあいまいな規約なら
>多人数開発では大きな障害になることもある。
その種の障害はコードレビューを行うことで完全に回避できます。

951 :251:03/12/21 23:16
>gotoの回避にかかる手間なんてちょっとしたものだろ?
>あえて gotoを許容するだけのメリットが見えてこないぞ?
ああ。あなたも「gotoを使えば常にわかりやすさが低下する。例外は無い」
と思っているのですね。
その命題はわかりやすさというものが主観に属する事項である限り証明不能でしょう。
また、その様には思わない人間も確実に存在します。
「あえて gotoを許容するだけのメリット」という表現自体が
「goto禁止が前提である」ように考えている様に思われます。まず、その前提を捨てていただきたいのです。

>漏れは、gogoを禁止することで、
>「もっとまともに設計汁!!」という規制にしたいがどうか?
規制という表現が何を意味するか良くわからないのですが、
「PGにプログラム設計方法論を教育すべし」であるならば支持します。

># つまるところ、「C言語のgoto文の仕様が糞」が原因で、それを 使うか 使わないか だけの議論だよな?
はい。それが本論なのです。その本論から外れて「gotoを禁止すべきだ(goto禁止規約)」
という人があらわれて、禁止すべきか禁止すべきでないかの方向に話が進みそうでした。
「使うか 使わないか」と「禁止すべきか禁止すべきでないか」では全然違いますね。
>>641には、「本論に戻したい」との願いの含みもありました。
ご指摘の「251の意見」は「私の個人的な願望」です。
>>641における私の裏の主張は「本論から外れるから『禁止』を口にするな」
であると考えてください。

952 :親から伝え聞いた世代:03/12/21 23:16
>>937
ワロタ

953 :仕様書無しさん:03/12/21 23:21
>「正しく関数化(構造化プログラム設計)がされてさえいれば、gotoを使用しても読みやすいコードを生成することは可能だろ」
可能だよ。でも規約にはするよ。あんただけがコード書くんぢゃないから。満足した?

954 :仕様書無しさん:03/12/21 23:24
>>947
どちらかというと、COBOL上がりの方がgotoに嫌悪感持ってる奴が多いな。

955 :仕様書無しさん:03/12/21 23:26
>>954
さすがに自分のプログラミング人生が2回も否定されるのは嫌なんだろ。

956 :251:03/12/21 23:28
>>953
満足なぞしませんが、どうぞ御自由に。>>641を御参照下さい。

957 :仕様書無しさん:03/12/21 23:29
コードレビューしよう。
gotoを使っていたらちゃんと注意してあげよう。
「gotoなんか使ってたらコードレビューだけで仕事の時間が全部無くなっちまうから、
もうgotoは使うのはやめような。」

958 :仕様書無しさん:03/12/21 23:30
>>955
プログラミング人生、って否定され続けるもんじゃなかったのか・・・漏れはそうだよ・・・(´・ェ・`)

959 :仕様書無しさん:03/12/21 23:33
>>934
>そもそも構造化言語でそのようなgotoを隠蔽するような仕組みを作り、
>gotoを推奨しないわけは、それは人間の認識能力にあるわけだろう。
俺は、ここ賛成。
プログラミング言語の進化はそのためで「も」あるからね。
で、このスレは、翻ってCでは?という話であるのを認識してほしい。

>>956
>>953はどっちかというと>>211向けのような気がする。

960 :仕様書無しさん:03/12/21 23:37
てか、コード書くときにすでに goto が存在することなんて忘れてる。
たまーに C++ で goto とか書いてあるソース見ると、「ああ、goto って使えたんだ」って
思う。


961 :仕様書無しさん:03/12/21 23:38
goto なんて発想の外だよなあ。
てか、なんの役に立つのやら……


962 :仕様書無しさん:03/12/21 23:39
>>954
ちょうどそのあたりで、例の「構造化〜」が流行ってたんじゃないかと。

963 :仕様書無しさん:03/12/21 23:39
>>961
関数が作れない言語。


964 :仕様書無しさん:03/12/21 23:40
俺は、>>211の「抽象化/一般化」した意見が聞きたい。
ということで、よろしく>>211


965 :仕様書無しさん:03/12/21 23:40
goto より gosub の方がまだ分かりやすい気がする。


966 :仕様書無しさん:03/12/21 23:41
構造化プログラミングが害があると言う人は、関数を呼び出しちゃだめなんだろうな。
暗に goto を隠している。
標準関数も呼んじゃだめだぞ。

967 :仕様書無しさん:03/12/21 23:42
static finalizeA(void) {A;B;C;};
static finalizeB(void) {D;E;F;};

void func(void)
{
  if(...) {
    ....
    switch(...) {
    case ...:
      finalizeA();
      return;
    case ...:
      finalizeB();
      return;
    case ...:
      finalizeB();
      return;
    case ...:
      finalizeA();
      return;
    }
  }
  ....
  if(...) finalizeA();
  else finalizeB();
}


968 :仕様書無しさん:03/12/21 23:43
void func(void)
{
  if(...) {
    ....
    switch(...) {
    case ...:
      goto finalizeA;
    case ...:
      goto finalizeB;
    case ...:
      goto finalizeB;
    case ...:
      goto finalizeA;
    }
  }
  ....
  if(...) goto finalizeA;
  else goto finalizeB;

finalizeA:
  A;B;C;
  return;
finalizeB:
  D;E;F;
  return;
}


969 :仕様書無しさん:03/12/21 23:44
void func(void)
{
  enum {A,B} kind;
  if(...) {
    ....
    switch(...) {
    case ...:
      kind=A;      break;
    case ...:
      kind=B;      break;
    case ...:
      kind=B;      break;
    case ...:
      kind=A;      break;
    }
  } else {
    ....
    if(...) kind=A;
    else kind=B;
  }
  switch(kind) {
  case A:
    A;B;C;
    break;
  case B:
    D;E;F;
    break;
  }
}


970 :仕様書無しさん:03/12/21 23:46
>>967
のstatic関数の型を忘れてますけど、気にしないでくださいm(__)m

971 :仕様書無しさん:03/12/21 23:47
>>965
あれは、手続きが作れなかったころの変な遺産だし。
まぁ、Cでも関数内関数を使えば問題ないんだろうけど、誰も使ってないからねぇ。

972 :仕様書無しさん:03/12/21 23:47
>>966
また電波ハケーンヽ(・∀・)人(・∀・)ノ
受信しても外に出さないでほしい…

973 :仕様書無しさん:03/12/21 23:48
関数内関数使いたいなー

974 :仕様書無しさん:03/12/21 23:49
1000とるぞ!!

975 :仕様書無しさん:03/12/21 23:50
>>970
残りレスも少ないんだから、せめて何がいいたいのかくらい書けよバーカ。

976 :高卒アニオタ中年:03/12/21 23:50
>>950
なるほど。前提が違うわけか。
漏れの前提は、「機械に任せるべきものは、機械に任せろ」なんだが・・・。
コードレビューは、ロジックだけのチェックにしないと、
時間かかってしぁあないだろ。
漏れは、その「チェックにかかる時間がもったいない」といってるんだが?

もちろん、どんな言語でも(たとえばマシン語でも)構造化プログラムは書ける。
しかし、「正しく構造化できているか」なんてチェックを人がするのは馬鹿らしくないか?
何のために構造化言語があるのか考えてみ?

漏れには、なぜ251が「goto」にこだわるのか理解できないんだが・・・

977 :仕様書無しさん:03/12/21 23:50
1000とるぞ!!
( ´ゝ_`)フーン

978 :仕様書無しさん:03/12/21 23:52
正直、なぜそんなに構造化にこだわるのか理解できない。

979 :仕様書無しさん:03/12/21 23:52
漏れはstatic関数をPascalの内部手続き風に使ってたら、先輩に
お前、ターパス厨だろw
言われて悲しかった記憶があるよ・・・

980 :仕様書無しさん:03/12/21 23:52
>しかし、「正しく構造化できているか」なんてチェックを人がするのは馬鹿らしくないか?
「正しく構造化できているか」をチェックすると「読みやすさ」がチェックできるのか?

981 :仕様書無しさん:03/12/21 23:52
1000とった!!

982 :仕様書無しさん:03/12/21 23:53
>>975
書き込み規制で書けなかったんですが?
で、どれがわかりやすいですか?

983 :仕様書無しさん:03/12/21 23:53
>>980
読みやすいもの=構造化されているもの
という前提だからねぇ。

984 :仕様書無しさん:03/12/21 23:54
おまえら他いけ
1000とるぞ

985 :仕様書無しさん:03/12/21 23:54
Cでgotoを使わない理由を考察するスレ goto loop3;
http://pc.2ch.net/test/read.cgi/prog/1072018444/

次スレ

986 :仕様書無しさん:03/12/21 23:55
1000とったよママ!!


987 :仕様書無しさん:03/12/21 23:56
goto loop3;

988 :高卒アニオタ中年:03/12/21 23:56
>>980
251が、gotoが正しく使われているかは「人がチェックする」といってるんだが・・・
読みやすさとは別の議論だろ。

989 :仕様書無しさん:03/12/21 23:56
誰も狙ってないな
今のうち
1000とるぞ

990 :仕様書無しさん:03/12/21 23:57


誰も狙ってないな
今のうち
1000とるぞ


991 :sage:03/12/21 23:58
誰も狙ってないな
今のうち
1000とるぞ


992 :sage:03/12/22 00:00

誰も狙ってないな

今のうち
1000とるぞ


993 :仕様書無しさん:03/12/22 00:01
>>988
んじゃ、
・バカが意味不明な変数名をつけてないかチェックする時間がもったいない
・バカが不用意にポインタを乱用してないかチェックする時間がもったいない
・バカがマクロを乱用してないかチェックする時間がもったいない
・バカがforやwhileの条件に何でもかけることを乱用してないかチェックする時間がもったいない
・バカが不用意に3項演算子を乱用してないかチェックする時間がもったいない
・バカがフラグ変数を乱用(多様)してないかチェックする時間がもったいない
・バカが保守性も解析性も悪いC言語コードを乱発してないかチェックする時間がもったいない
・バカがグローバル変数を乱用してないかチェックする時間がもったいない
・バカがグローバル変数を乱用してないかチェックする時間がもったいない
・バカが環境変数を乱用してないかチェックする時間がもったいない
・バカが環境変数を乱用してないかチェックする時間がもったいない
ので、それらの使用を禁止する、といういういつもの議論に収束しそうだな。

994 :sage:03/12/22 00:01
誰も狙ってないな

今のうち
1000とるぞ

995 :sage:03/12/22 00:02
1000とった!!!!

996 :993:03/12/22 00:03
・バカが保守性も解析性も悪いC言語コードを乱発したときのデメリット
が抜けてた!
スマン。

997 :sage:03/12/22 00:03

1000とった!!!!

998 :仕様書無しさん:03/12/22 00:03
初めての1000

999 :sage:03/12/22 00:04



1000とった!!!

1000 :仕様書無しさん:03/12/22 00:04
goto http://pc.2ch.net/test/read.cgi/prog/1053627318/


1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

274 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)