なあ、再帰関数好きな人いる？

1 名前：名無しのプログラマ [2015/08/09(日) 17:46:33.69 ID:Icb40LOY.net] for,while使うの嫌いで基本的に再帰多用するんだが、だめなの？ 皆から敬遠されてる気がする 121 名前：デフォルトの名無しさん [2015/08/13(木) 00:17:24.90 ID:AIiQbQBJ.net] >>117 パターンマッチはifで書けばいいし、再帰はループで書けばいい。 いきがるな。 122 名前：デフォルトの名無しさん [2015/08/13(木) 00:18:56.16 ID:AIiQbQBJ.net] ループで書けるものを再帰で書くやつって結局ヒッピーなんだよね。 ラリってるだけ。 123 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 00:23:14.84 ID:Vkqae3ee.net] >>120 ifはパターンマッチ漏れをコンパイラが警告してくれないんやで val a = list match { case Nil => Nil case head :: tail => tail } をifで書くと var a; if(list.isEmpty){ a = Nil } else { a = list.tail } だろ　辛い 124 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 00:24:32.15 ID:NebXzry6.net] >>117 JavaScriptならswitch(true)で頑張れば、ある程度は代替できそうですが、 基本的に静的型言語じゃないと真価を発揮できない気がしますね 125 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 00:24:38.47 ID:Vkqae3ee.net] >>121 言語の違い、データ構造の違い 126 名前：デフォルトの名無しさん [2015/08/13(木) 00:27:11.91 ID:AIiQbQBJ.net] >>124 ループを再帰で書く奴はミーハーで頭の中ハコスカなだけ 127 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 00:28:36.37 ID:FUyksqfE.net] アホばっか 再帰的なアルゴリズムなら再帰を使えばいいし 反復なアルゴリズムならループを使えばいいし どちらでもいいなら気分でかけばいいじゃん？ どっちか一方しか使わない使えないでは話にならん 128 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 00:33:41.96 ID:Vkqae3ee.net] ループを再帰で書くというのがなんか違う むしろ最初に再帰が浮かび後からループにいやいや書き換えるのではないか 129 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 00:38:27.39 ID:FUyksqfE.net] >>127 アルゴリズムの考え方が先行して考えられると思うけど 130 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 00:57:49.87 ID:NebXzry6.net] >>128 ループや再帰処理それ自身がアルゴリズムなので、 強いて依存先として挙げるならデータ構造じゃないかと 131 名前：ID:JsRAlNhV mailto:sage [2015/08/13(木) 01:30:53.70 ID:1C0y4JfF.net] ちょっと深夜のランニングをしてきたわけだが、誰にレスするべかな？ 反論者と擁護してくれる人の両方がいるな。 132 名前：デフォルトの名無しさん [2015/08/13(木) 01:35:10.57 ID:G0UckYXU.net] 末尾再帰云々言ってる人は、コンパイラがループに変換してくれるから 再帰を使うべきって話ですか？ 133 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 01:35:43.95 ID:1C0y4JfF.net] >>113 > レッテル張り 全くだね〜ｗ >>115 > ここは言語の違いだと思うけどjavascriptみたいな手続き型で再帰を特にサポートしていない言語は > 再帰は基本的に使わない方がいいけど というか逆だね。（一部の？）関数型言語のような、 ループを再帰よりも書きづらくしているものに限って言えば、 再帰を使うしか無いよ。仕方なく。 そういう言語以外は、再帰よりもループのほうが簡単に書ける。 （データ構造自体が再帰に適している場合は除く） > ループだとそのコードみたいに破壊的代入が含まれるし 破壊的代入はするよりもしないほうがいいのは確かで、 俺もコードレビューなどで破壊的代入はするなって言ってるけど、 それは方針であって絶対的なもんじゃない。 破壊的代入をしたほうがわかりやすい場合もある。 よく言われるように手段と目的を履き違えるな問題だよ。 134 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 01:37:43.32 ID:1C0y4JfF.net] >>126 > どっちか一方しか使わない使えないでは話にならん 俺もそれを言ってる。 再帰を知った奴がなんでも再帰を使って 解こうとしている。それに対して警告してる。 まだまだだよって。 135 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 01:38:45.50 ID:1C0y4JfF.net] >>131 > 末尾再帰云々言ってる人は、コンパイラがループに変換してくれるから ↓　俺が最初のほうで書いたレスｗ 24 自分：デフォルトの名無しさん[sage] 投稿日：2015/08/11(火) 18:24:05.65 ID:Ghx6BuLg ループで実装する ↓ （意味なく）再帰にしたい！ ↓ 再帰にするとスタックがー、関数呼び出しがー、どうのこうの ↓ 末尾最適化される再帰にすればいいんだぜ！フフン ↓ 末尾最適化されるような再帰コードを書く ↓ コンパイラがループの実装に戻す 結論 人間がループを再帰に変換し、 コンパイラが再帰をループに戻すという無駄！ 136 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 01:43:20.43 ID:1C0y4JfF.net] >>127 > むしろ最初に再帰が浮かび後からループにいやいや書き換えるのではないか 女性の列の中から男の娘を探しなさいって言われた時、 前から一人づつ見ていくという方法を思いつく人は多くいると思うが、 俺「一人だけ確認した。あとは俺に頼む」→俺「はーい、わかりました。俺も同じことをしまーす。」→俺「以下同文」 という考え方をする人は滅多に居ないと思うが。 137 名前：まーた連続書き込み規制だよ mailto:sage [2015/08/13(木) 01:50:39.52 ID:kS/o56L+.net] >>117とか>>120とか>>122とか>>123 そういう場合、switchを使うんだけど ちょっと数が増えただけで、循環的複雑度を調べるツールで 複雑だって言われるんで、これぐらいいいじゃねーかと思いながら （※注 そのツールを導入したのは俺ｗしきい値を8に設定してるのも俺ｗ） 関数テーブル呼び出し的なコード（意味わかるよね？）に書き換えるんだけど、 そうしたらやっぱり前よりわかりやすくなって、 やっぱりswitchいらねーか、とか思ってしまうｗ 関数テーブル呼び出し的なコードにすれば、パターンマッチ漏れは nullを関数呼び出しすることになって、実行時エラーになってはくれるよ。 138 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 01:54:14.37 ID:NebXzry6.net] 元から再帰で無理矢理書くことを勧めてる人は、そういないんじゃないかと 私は相手をその手の人間と決め付けて話す事が、 おかしいといってるだけですよ 139 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 01:59:57.44 ID:kS/o56L+.net] >>137 > 元から再帰で無理矢理書くことを勧めてる人は、そういないんじゃないかと うん、こいつらぐらいかな？ 適切なものを選ぼうとせずに 何でも再帰、再帰のほうがわかりやすい。 再帰使うほうが頭いい、（理由ないけど）普通に再帰だわ とか言ってる人。 25 名前：デフォルトの名無しさん[] 投稿日：2015/08/11(火) 20:07:51.21 ID:SPQSl72c [2/2] 再帰のほうがわかりやすいと思えない子が 26 名前：デフォルトの名無しさん[sage] 投稿日：2015/08/11(火) 20:55:40.81 ID:I9e7/X97 [1/2] 再起が得意かどうかで頭の良さが決まる 33 名前：デフォルトの名無しさん[] 投稿日：2015/08/11(火) 23:39:17.34 ID:BomPGBV/ [2/2] 再帰苦手なのは練習不足なだけ 理解が早いのは完全に地頭がいいだけじゃね？ 74 返信：デフォルトの名無しさん[] 投稿日：2015/08/12(水) 23:00:43.40 ID:ALDJfVhA [5/11] >>73 >だけどデータがリスト構造なだけなら >普通にループを使ったほうがわかりやすい。 んなわけねーだろ 普通に再帰使うわ 140 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 02:00:23.27 ID:NebXzry6.net] >>135 それってfoldかfilterで良くないですか？ そう言う意味で、再帰よりループのが不要に見えるんですが 141 名前：デフォルトの名無しさん [2015/08/13(木) 02:03:39.26 ID:G0UckYXU.net] まだ関数型言語の時代は来てないんで、手続型前提で良いんじゃないですかね。 142 名前：デフォルトの名無しさん [2015/08/13(木) 02:06:24.18 ID:G0UckYXU.net] 関数型がうまく機能する時代にはC++のようなマルチパラダイムの言語に取り込まれて 結局、純粋な関数型言語の時代は来ないんじゃないですかね。 143 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 02:07:07.66 ID:kS/o56L+.net] > それってfoldかfilterで良くないですか？ > そう言う意味で、再帰よりループのが不要に見えるんですが え？ 君、foldかfilterでいいにしても、再帰の話してないよね？ foldもfilterもループでも再帰でも書けるわけだから。 高階関数呼び出しを行うそれらの関数を使えば ループ（または再帰）が不要になるっていう話なら別に否定してない。 俺もよく使うし、上の方でも書いたよ。 >>54 > 最近ではMIMEメールのパースとか、連想配列の > 全ての値の処理とかで使ったかな。 > > 再帰を使うことはめったにない。そしてミスをしやすい所でもある。 > だから再帰を使うときは、再帰を考慮しなくていい形に置き換えるようにしている。 > つまりJavaScriptでいうmapやreduceの形にする。再帰部分と処理部分に分けて再帰部分を隠ぺいする。 > 通常書くのはコールバックで呼ばれる処理部分のみ。 > そうすることで可読性も大きく上昇する。 再帰はわかりづらいからtraverseみたいな形にすることで再帰を内部に隠ぺいする。 ループを内部に隠蔽してfoldかfilterがあればループが不要だというのなら、 同じ理由で、再帰を内部に隠蔽したtraverseで良いから、再帰は不要だって言えばいいの？ 144 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 02:13:00.97 ID:NebXzry6.net] >>142 必要性の比較として、その手の関数で簡単に書き下せるloopの方が、 再帰より不要ではないですか？と言う意味ですよ 実装としては、さすがにループが完全になくなるとは思ってません 145 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 02:15:06.80 ID:kS/o56L+.net] そういや高階関数使える言語ばっかりになったよな。 >>141 > 結局、純粋な関数型言語の時代は来ないんじゃないですかね。 俺もそう思う。 高階関数は便利だけど、純粋な関数型言語まではいらないかな。 あとScalaでいうval、再代入不可能な変数も欲しいけど。 146 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 02:19:20.99 ID:NFzWJ2Cc.net] 何でこんなに伸びてるの… 147 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 02:19:45.60 ID:kS/o56L+.net] >>143 そもそもの話が、「ループで簡単に書けるようなもの」を 再帰でわざわざ書くなって話なんだよ。 正確に言うと、再帰を使わないでいいような処理に 再帰を使うなという話。 だから、その手の関数で簡単に書き下せる処理に 再帰を使うなっていう話でも有る。 148 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 02:20:52.90 ID:kS/o56L+.net] >>145 話が再帰してるから （ループをわざわざ再帰にしてみました！） 149 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 02:24:57.75 ID:NebXzry6.net] >>146 では、それを踏まえた上でどう思います？ 150 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 03:17:20.09 ID:kS/o56L+.net] >>148 最初っからおんなじ 再帰は可読性悪いんで 使わずに済むなら使わない方がいい。 151 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 03:18:50.05 ID:WDxyRHha.net] あとどうしても必要な場合は 152 名前：、 内部に隠蔽して、再帰であると意識せずに また再帰のコードを見ずに、処理できるようにした方がいい。 [] [ここ壊れてます] 153 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 03:30:05.42 ID:NebXzry6.net] >>149 いえ、そうではなく、二者択一で 再帰とループで、必要性が高いのはどっちだと思います？ もちろん、高階関数や各種操作関数での置き換えを踏まえた上での話です 必要と思うならどういう場面なのかなと 154 名前：>>150 mailto:sage [2015/08/13(木) 03:31:16.05 ID:NebXzry6.net] 最後の行は削除忘れです 155 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 03:36:08.86 ID:WDxyRHha.net] >>151 お前バカじゃね？ 足し算と掛け算どっちが必要かって 言ってるようにしか聞こえん。 適切なものを使えよ。 156 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 03:39:48.62 ID:WDxyRHha.net] そういや実務で再帰使う必要せいってねーな。 あっても隠蔽するから両手で数えられるほどしか無い。 片手でもいけるかもｗ 157 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 03:51:07.78 ID:NebXzry6.net] >>153 私はそこまで一般化はしてないですし、適材適所も否定してません それと必要性の比較も関係ありませんよ 例えばgoto文も適材適所ですが、必要性は低いと思ってます 再帰がループと同程度に必要と思うなら、そう言ってくれればいいです 違う場合に、その先の話がしたいだけなので 158 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 04:15:21.85 ID:NebXzry6.net] ループが本当に必要な部分というのを、議論してみたかったんですが どうあっても再帰は不要といいつつ、ループが必要とは言わないんですね… 159 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 04:27:48.44 ID:WDxyRHha.net] >>155 実践では再帰はあまり使いません。 必要性の話をするのなら それが現実では？ 160 名前：デフォルトの名無しさん [2015/08/13(木) 07:42:46.93 ID:GBQWWFg+.net] クイックソートもループで書くんですか? 161 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 07:48:57.17 ID:FXSompvo.net] アスペかよ 162 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 08:21:16.88 ID:Iax2S8IU.net] >>158 実用的なクイックソートはループ。 まさか再帰でしか実現できないなんて考えとるんか？ 163 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 08:52:19.31 ID:GBQWWFg+.net] >>160 再帰より可読性の高い、ループでのクイックソートの実装は寡聞にして知りません。 164 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 09:30:01.18 ID:Iax2S8IU.net] ループ方式も可読性は高い。 特別なことはやらないから、誰でもすぐ実現できるはず。 Cどころか昔のVBのようなへぼ環境でも 何百万ものデータを高速にソートできてしまう。 165 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 09:53:04.16 ID:GBQWWFg+.net] 例えばこれ https://github.com/lattera/glibc/blob/master/stdlib/qsort.c 本来の再帰アルゴリズムを、非再帰で記述するために状態を自前のスタックで管理しなきゃならない。 余計なコードが必要な分、可読性は低いですね。 166 名前：デフォルトの名無しさん [2015/08/13(木) 10:07:42.74 ID:Q4WJ33HH.net] >>163 FSF、Microsoft、そしてAppleが再帰を避けるのは何故か考えてみては。 167 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:10:35.79 ID:wsd38m6J.net] 再帰関数をスタック無視して設計するような馬鹿じゃなけりゃ、 どっちでもいいよ。 金太郎飴をループで切るか再帰で切るか、程度の話しかしてない みたいだしな。その関数がその構造のどこまでのデータを扱うのか ってことを意識してりゃ別にいい。 再帰でよその子をいじったりとかするのは馬鹿のやること。 168 名前：デフォルトの名無しさん [2015/08/13(木) 10:13:00.13 ID:1x08JE5T.net] 論点がずれてないか？ >>163は可読性について論じているのに 169 名前：デフォルトの名無しさん [2015/08/13(木) 10:27:03.54 ID:Q4WJ33HH.net] >>166 わざわざglibcのソース引っ張り出してるとこからして、本人も言いたいことが自分で分かっていないのでは？ Cで再帰するコードを書けば、たいていのチェッカが警告するし、品質保証からお叱りを受けるはず。 やってはいけないことの一つとして、ほとんどの企業で明文化されているはずです。 そして良く知られるMISRA-Cも通りません。 こういう状況下で、glibcのソースを引用して再帰するべきと主張するのはおかしい。 glibcでも再帰は避けている、再帰するべきでないという主張になるのが当然だと思う。 そうなっていないという事は、本人が一番自分の主張をわかっていない。 と思うのです。 170 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:30:12.83 ID:NebXzry6.net] さすがにこれを可読性が高いとは言うのは無茶じゃないかと 171 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:30:37.05 ID:Iax2S8IU.net] 可読性が悪いかどうかじゃなく、 再帰の場合よりも良くなくてはいけないと？ 理解困難なコードでなく実用性があるのなら採用するでしょ。 プログラマはソート処理のコードは使いまわして 比較関数を用意すればいいだけだし。 172 名前：デフォルトの名無しさん [2015/08/13(木) 10:32:46.72 ID:GBQWWFg+.net] >>167 可読性の話をしてるんですが? 173 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:38:27.46 ID:WDxyRHha.net] >>163 > 本来の再帰アルゴリズムを、非再帰で記述するために状態を自前のスタックで管理しなきゃならない。 だから適切なものを選べって言ってるじゃん。 誰が、再帰が適切なものまで、 ループにしろって言ったよ？ ループで済むものを再帰でやるなって話。 ほんと>>42で書いた4の段階のやつだなお前は。 174 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:40:07.80 ID:WDxyRHha.net] >>169 > プログラマはソート処理のコードは使いまわして > 比較関数を用意すればいいだけだし。 そういう場合、そのソートは何に使われるかわからないから 往々にして、速度が一番早い方法を選ぶんだよね。 つまりループで実装。 175 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:41:21.58 ID:A9RCljrX.net] ソースがコンパイラにどう最適化されて実行時にどう動かされるかを考えてると 可読性の基準が変わってくるでしょ 再帰で触感的に記述できるのは再帰構造持ったアルゴであって 本来行うべき実行じゃないから非直観的なんよ 可読性として表現したい対象がそもそも違うのよね 176 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:42:13.58 ID:96XWMJC8.net] 実用向けだと可読性だけと言うわけにはいかないからなぁ スタックオーバーフローを検出して適切にエラー処理するために自前のスタックにするとかは普通にあるし 177 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:43:10.07 ID:NebXzry6.net] >>167 中身ちゃんと読んでますか？ このソース要素数が一定以上の場合、どうやらquicksortしない仕様で、 quicksort処理部もスタック使ってるようですよ 要素数で分けて安全性を保っているだけで、 処理そのものの安全性そのものは再帰と変わってません 178 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:47:32.08 ID:Iax2S8IU.net] ＞このソース要素数が一定以上の場合、どうやらquicksortしない仕様で、 何言っとるんだ？ 179 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:47:43.55 ID:WDxyRHha.net] >>173 > ソースがコンパイラにどう最適化されて実行時にどう動かされるかを考えてると > 可読性の基準が変わってくるでしょ 可読性の読みやすさって 人間の読みやすさだからｗ コンパイラにとっては可読性関係ないよ どんなに読みづらいコードでも 書いてあるとおりに解釈してくれる。 180 名前：デフォルトの名無しさん [2015/08/13(木) 10:48:35.29 ID:Q4WJ33HH.net] >>175 自前のスタックを使っています。 確かにあなたのおっしゃる通り*自前の*スタックを使っています。 ですが再帰ではありません。 181 名前：デフォルトの名無しさん [2015/08/13(木) 10:48:36.95 ID:Q4WJ33HH.net] >>175 自前のスタックを使っています。 確かにあなたのおっしゃる通り*自前の*スタックを使っています。 ですが再帰ではありません。 182 名前：デフォルトの名無しさん [2015/08/13(木) 10:51:04.09 ID:Q4WJ33HH.net] C/C++で再帰を使うことが良くないマナーであることは、とっくの昔に 明文化された事実なんですよ。 手間がかかろうがなんだろうが、再帰を無くさなければならない。 そんなこと当たり前じゃないですか。 183 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 10:51:19.49 ID:GBQWWFg+.net] >>164 glibcのqsortでもstack_node stack[STACK_SIZE]が溢れますね。 メモリ消費量は、再帰で書くとそれに加えて、リターンアドレスやフレームの保存領域が余計に必要になるだけですよね。 184 名前：デフォルトの名無しさん [2015/08/13(木) 10:53:38.16 ID:Q4WJ33HH.net] >>181 じゃあ品証にそう言って噛みついてみては？ 185 名前：デフォルトの名無しさん [2015/08/13(木) 10:55:16.00 ID:Q4WJ33HH.net] こんな当たり前のことで今更何議論してるんだって話。 186 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 11:01:18.21 ID:Iax2S8IU.net] ＞stack_node stack[STACK_SIZE]が溢れますね。 これは指定の番号のデータが、ソート結果として 第何番目になるかを出力させるといい。 つまり順番に数値を格納した配列を用意して その要素をクイックソートの置き換え処理の対象にさせる。 また、 187 名前：比較関数もこれに対応したものを用意する。 この方式なら int stack[STACK_SIZE] を用意すればいいので、件数は多くても メモリ消費量はそんなに必要にならない。 [] [ここ壊れてます] 188 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 11:01:20.46 ID:GBQWWFg+.net] >>171 >>54が言い出した「再帰は可読性が悪い」に対する反論なのですが。 189 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 11:01:38.29 ID:NebXzry6.net] >>176 コメントとMAX_THRESHで追えば解ると思います 全くしないわけではないです 190 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 11:13:50.27 ID:GBQWWFg+.net] >>184 非再帰版は再帰を自前のスタック管理でエミュレートしているだけなんだから、 同一データを、再帰版と非再帰版で実行すると再帰版の再帰の深さと、 非再帰版のstackの使用個数は同じになるに決まってるじゃないですか。 191 名前：デフォルトの名無しさん [2015/08/13(木) 11:15:13.87 ID:1x08JE5T.net] 再帰は普通につかうでしょ ＯＳとかの制作には向いてないってことで 普通のソフトならオーバーフローしない限り問題ない 192 名前：デフォルトの名無しさん [2015/08/13(木) 11:22:16.59 ID:Q4WJ33HH.net] >>188 使いません。 193 名前：デフォルトの名無しさん [2015/08/13(木) 11:24:47.30 ID:Q4WJ33HH.net] CERT C Secure Coding Standard、ISO/IEC TR 24772:2013、MISRA-C。 よく使われるガイドライン、規約で明示的に禁止されています。 C/C++で再帰は邪悪なのです。 再帰を使う人は悪人です。 194 名前：デフォルトの名無しさん [2015/08/13(木) 11:26:18.86 ID:1x08JE5T.net] おれたちにとってそれを書いた人の意見が正しいわけじゃないから 195 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 12:51:43.10 ID:GBQWWFg+.net] >>190 ウソつき。 禁止してるのってMISRA-Cだけですね。 CERT C Secure Coding Standard Recursion can also lead to large stack allocations. Recursive functions must ensure that they do not exhaust the stack as a result of excessive recursions. ISO/IEC TR 24772:2013 6.37.5 Avoiding the vulnerability or mitigating its effects Software developers can avoid the vulnerability or mitigate its ill effects in the following ways: + Minimize the use of recursion. + Converting recursive calculations to the corresponding iterative calculation. In principle, any recursive calculation can be remodeled as an iterative calculation which will have a smaller impact on some computing resources but which may be harder for a human to comprehend. The cost to human understanding must be weighed against the practical limits of computing resource. + In cases where the depth of recursion can be shown to be statically bounded by a tolerable number, then recursion may be acceptable, but should be documented for the use of maintainers. 196 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 12:54:40.29 ID:V/aggySn.net] Scala だと末尾再帰が推奨されてる感じだけど 197 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:05:26.51 ID:WDxyRHha.net] 特定の言語特有の例外でしょうね 198 名前：デフォルトの名無しさん [2015/08/13(木) 13:06:35.36 ID:t3mydoM3.net] 特有というか関数型言語 199 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:12:01.20 ID:WDxyRHha.net] でも推奨してるのはScalaだけなのでしょう？ 200 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:12:01.28 ID:A9RCljrX.net] おれの予想だとそろそろ 糞みたいな本のコピペ宣伝がくるね 201 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:13:19.26 ID:WDxyRHha.net] >>197 それは、押すなよ、押すなよってやつですか？ それとも自分でコピペして、ほら俺の言ったとおりだった（ドヤ顔）を やるための布石ですか？ 202 名前：デフォルトの名無しさん [2015/08/13(木) 13:13:33.60 ID:GBQWWFg+.net] クイックソートは再帰版の方が可読性が高い。 これに異論はありますか? 203 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:14:50.27 ID:aB+CmHXz.net] >>195も言ってるが関数型言語のような破壊的代入を避けることが推奨の言語は、 ループは再帰で表現するのが推奨 Scala特有とか意味わからん 204 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:19:18.15 ID:WDxyRHha.net] >>199 中途半端な質問するなよｗ クイックソートは再帰版の方が可読性が高い。 バブルソートは再帰版の方が可読性が高い。 マージソートは再帰版の方が可読性が高い。 これに異論はありますか? やるならこれぐらいやれよｗ その言い方だとクイックソートだけしか勝ち目がないと 自覚しているかのようだぞ。 なお、ソートの種類には以下の様なものが有るらしい。 https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%BC%E3%83%88 バブルソート、シェーカーソート、コムソート、ノームソート、選択ソート、挿入ソート シェルソート、2分木ソート、ライブラリソート、マージソート、In-place マージソート ヒープソート、スムースソート、クイックソート、イントロソート、ペイシェンスソート ストランドソート、奇偶転置ソート、シェアソート 半分も知らんなｗ 205 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:20:57.51 ID:WDxyRHha.net] >>200 推奨とか、破壊的代入を禁止するという制約のために 選択肢がないだけに見えますが。 破壊的代入を禁止することが、 必ずしも可読性を高めるとは限らないので。 206 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:24:34.58 ID:NebXzry6.net] >>201 fold mapでループは消えますので、再帰より不要ですね(煽り) 207 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:27:20.56 ID:WDxyRHha.net] >>203 fold mapによって消えるものがなぜループだと？ fold mapによって再帰が消えるのではないのですか？ 208 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:28:32.66 ID:W1EX3EBl.net] やっぱりfold mapの実装はループであるべきだって 自覚してるんでしょうね（煽り） 209 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:30:40.85 ID:GBQWWFg+.net] >>201 >>54 > 普段はやはり再帰のコードは書くべきじゃないよ。 > 可読性悪いからね。 これが間違いであることは、反例を1つ示せば十分ですよね。足りないというなら、 ID:Q4WJ33HH氏がドヤ顔で言い出したISO/IEC 24772:2013にも In principle, any recursive calculation can be remodeled as an iterative calculation which will have a smaller impact on some computing resources but which may be harder for a human to comprehend. The cost to human understanding must be weighed against the practical limits of computing resource. って明記されてるし。 210 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:34:22.81 ID:W1EX3EBl.net] "普段は" って書いてあることから 普段に当てはまらない場合は違うと言ってるわけで、 反例があるってことは、最初から言ってることですね。 211 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:43:25.91 ID:GBQWWFg+.net] >>207 その「普段」は発言者の彼によると、「再帰を繰り返しに置き換える」ので、クイックソート非再帰版が「普段」ですよね。 > 再帰を使うことはめったにない。そしてミスをしやすい所でもある。 > だから再帰を使うときは、再帰を考慮しなくていい形に置き換えるようにしている。 212 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:44:15.15 ID:W1EX3EBl.net] >>208 その発言者は私ですが、普段というのは 日々の仕事の話ですよｗ 普段あなたは何をしてるのですか？ の普段です。 213 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:47:30.00 ID:W1EX3EBl.net] クイックソートの話で言えば、 普段はクイックソートの実装などせずに 予め用意されたソート関数、つまり高階関数を引数にしたソート関数を 呼び出すだけなので普段は再帰を使ったコードを書きません。 >>203の発言風に言うと、 sortで再帰は消えますので、再帰は不要ですね（煽り） 214 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:47:49.82 ID:GBQWWFg+.net] >>209 「普段」はクイックソートのように再帰版の方が可読性の高いものを、非再帰版に書き直さないのですか? 215 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 13:50:17.90 ID:W1EX3EBl.net] >>211 普段は再帰は可読性が低いので、 再帰だとわからないように sort関数のようなものを作ります。 再帰が可読性高かったら、 わざわざsort関数なんて作りませんよｗ 216 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 14:02:03.63 ID:GBQWWFg+.net] >>212 再帰版クイックソートは可読性が低いという主張ですね。 >>207と矛盾しますが。 > 普段に当てはまらない場合は違うと言ってるわけで、 217 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 14:09:44.52 ID:NebXzry6.net] >>204 え…？再帰構造にmap使うんですか？ かなり効率悪いと思いますが 218 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 14:23:38.44 ID:W1EX3EBl.net] >>214 え？そんな話してませんよ。 話の内容を整理しましょう。 fold mapによって消えるものがなぜループだと 思っているということは、fold mapが再帰ではなく ループで実装されていると思っているからでしょう？ fold mapを使えば、ループが要らないっていうのはそういうことですね。 もしfold mapの中身が、ループではなく再帰で実装されていると思っているのなら、 fold mapで消えるのは再帰だと考えるはずです。 だから、ははん、こいつはループを使ったほうが適切な問題だって わかっていると言ったんです。 最初っから言ってるように、適切なものを使う。 単なるリスト構造であればループで良い。 再帰的な構造であれば再帰使えばいいと言ってます。 219 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 14:27:29.97 ID:W1EX3EBl.net] >>213 > 再帰版クイックソートは可読性が低いという主張ですね。 全く違います。 再帰を使ったコードは可読性が低いので、 sort等の関数を使って再帰を隠蔽するというのが 私の主張です。 何回も説明したはずですが？ 「普段」というのは>>209で書いたように、 日々の仕事のことですから、普段は再帰は使いません。 使うことがあっても内部で隠蔽されたsort関数などを使うし、 自分で隠蔽するので、普段は再帰は使いません。 220 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 14:29:35.52 ID:NebXzry6.net] >fold mapによって消えるものがなぜループだと >思っているということは、fold mapが再帰ではなく >ループで実装されていると思っているからでしょう？ 全然違います ループに代替可能、かつ効率が上がる可能性があるからです mapの実装がループって…ループや再帰で実装はできますが、 逐次処理に書き下したらmapの優位性なくなりますよ その下は間違った前提で話してるのでスルーします 221 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 14:31:12.41 ID:NebXzry6.net] 安価忘れ >>215 間違い訂正：ループに代替可能 → ループを代替可能

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef